So I wrote this script that basically creates a sql dump of the the drupal databases as well as created a tar of of the www directory. I took this off the server and put it on my local machine. I want to take these backup files and test to see if the backup is stable as well as to learn the process.
My problem is that I can't find any clear instructions on how I would be able to do this. Can anyone give me a hand?
Any help is much appreciated.
You need to have a LAMP stack installed on your local machine. In addition, you'll need to modify the settings.php file to change the database connection strings to match your local enviornment. Youi may also need to modify the $base_url variable in the settings.php.
THis would not be necessary if you were simply restoring, but since you're moving the install it is required.
Related
I have a strange behaviour and I need some ideas.
I have a Redhat7 server with standard apache and php7 installation.
The application running on this server uses PHPExcel to export data from a database to an excel file.
Because the appliction is very old and not from me, I dont want to change from PHPExcel to PHPWorksheet if there is any other option.
The server is also not installed by me, but I have sudo access.
What happens:
It looks like every night the server does some changes to the httpd service because every morning when I try to use the application I got an error that PHPExcel cannot create folder /tmp/xxxxxx. All I have to do is restart the httpd service as sudo and the applcation works fine until the next day.
I know this is not much information so if you need something more please ask.
I also know its hard to help here but perhaps someone has a similar problem in the past?
Thanks
Claus
After all I have solution which is not my favorite but it works.
I have changed the
sys_temp_dir
upload_temp_dir
in the php.ini to a different self created folder. It looks like the /tmp folder (which is default) is changed every night from any other application running on the server in that way, that PHP has no longer write access to it.
I am not very sattisfied not knowing exactly whats going wrong with the /tmp folder but because I am not the admin of the server I think I must be ok with it.
I'm new into Git and I'm working with Wordpress themes.
I was always using FTP client to push every small change into my remote server... I mean sometimes it was just one line of code to check the change of CSS. It was easy and nice but there will be always problem with reverting changes and since I'm learning Git, I want to change it.
I've found two ways to do it:
git-ftp
i've tried to connect my local respository with GitHub and my intention was to automatic pull changes into my remote server from GitHub (it's not working yet, i need to configure it better)
BUT, do I have to commit every single small change? Because I cant just save file and check changes with Browsersync on second monitor, I will have to commit so many times. Also which way will be better for me - maybe there are another, better ways?
I really want to improve my performance, but it looks like that's not easy or I'm doing something wrong? I know about existence things like WP-CLI, webpack, gulp but often I'm creating small websites and probably I will spend more time on configurating those things than create theme. Also I thought about working on localhost, but I really think that I'm complicating things and my job.
Really sorry if it's wrong section, but I'm new on stackoverflow - hey! I will be really thankful if you can help me, because I think that i need knowledge of someone experienced.
I'm not sur to be helpful but I'll try :
First, even for a small project, I always prefer to install a local environment for testing. It avoid risks on your remote server !
You can take a look here : https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/
Then, if you have an SSH access to your server, may be you can try to configure it to push directly from your local environment to your remote server. Here is a simple tutorial : https://gist.github.com/noelboss/3fe13927025b89757f8fb12e9066f2fa
It depends on what remote system or vps you are using.
It could be from GCP, AWS, DIGITAL OCEAN, or WP itself.
It looks like that you are using the wordpress hosting your website.
If so, you might use wp cli to login the server.
①As for the frequent testing and updating, it is a good idea to copy the remote project to your localhost. Run your web app using wampserver. And create a new repository in the github and connect it with your local folder.
Then you could use git to version control your codes, do pull and push, stash or whatever.
And after testing, you could upload the specific files or folder to the remote server via ftp or sftp periodically.
②Another way is to install the git bash or git software in your server side.
It depends on the OS you are using. If it is a win or linux.
$ add-apt-repository ppa:git-core/ppa
$ apt update; apt install git
and create new user, add it into the sudo group
create a repository in your server side and link it to the github remote repository.
I am not sure whether the second way would work.
I recommend you try the first method.
Hope this could help. Happy coding.
I am in the process of migrating a D7 site from one server to another. I have successfully exported and uploaded the settings to the new site using Features, but I need to get the content over to the site as well. I've been looking at several modules to try and solve this problem, but I have not found anything suitable for this task. Please let me know if I am overlooking a really simple solution.
Thanks!
Mark
Easiest solution is to export a database dump and import it into your new server. You can do it wotj phpMyAdmin but I recommend using Drush.
This way you can simply do a database dump via:
drush sql-dump > ~/sql-dump-file-name.sql
and later import via:
drush sql-cli < ~/sql-dump-file-name.sql
Also copy your files directory from old server to new server which is located in /sites/default/files.
I've successfully used the backup and migrate module for these tasks. True, creating a dump and then spooling the dump into the other database works, but this typically also copies all caches.
The backup_migrate module allows you save backups on your local server, but also to your hard disk, from where you can upload it again to the other site.
A neat thing here is that you can exclude tables, such as cache tables, which makes the transfer much faster.
Obviously you need a core installation on the other end, and the backup_migrate module already installed for this to work, but I assume that since you only ask about the db, you must have mirrored the file structure already (excluding the settings files).
I just started a new position replacing a developer who left abruptly working on a project that is based in the Kentico CMS. I am completely unfamiliar with ASP and Kentico, so the answer here needs to be tailored for a total beginner. I am familiar with other languages (PHP, Ruby, SQL, etc.) but have no idea where to begin with this.
So, want I am wanting to do is copy everything from our production site (db and all) to my local machine so I can develop on it easier. I have already exported the db into an SQL file, and copied all the files in our Kentico Instance folder into github, and cloned it on my local machine. I assume since Kentico is already "setup," going through the installation process in their documentation is not the way to go about this.
Any help would be incredibly appreciated!
David, basically there are a few "pieces" to running Kentico locally. Since, as you mentioned, Kentico is already set up, you should have an easier go of it.
A database with the necessary Kentico tables (it sound like you
already have this)
The codebase (all of the code files that you copied to github)
A valid license for any domain you want to run Kentico on. Was the site already public facing? Do you know what licenses you have
or can you log into the CMS Desk on the site that you copied
everything from?
Set up IIS for your local website. If you are unsure on this one I can explain further, but basically you need to add a new site,
point it to the root code folder for your site, and set the domain
to be a domain you have a Kentico license key for. You'll also need
to change the app pool settings to "integrated" mode (most likely)
and also set the appropriate version of .NET (if it's a recent
version of Kentico you'll want .NET 4.0)
Next you'll need to edit your hosts file to add the domain and point it to your localhost IP address. So add a line like "127.0.0.1
dev.yourdomain.com" or the equivalent.
Edit the web.config file so that your code can connect to your database. You will need to edit the connection string accordingly to
point to the database on your machine.
Once you have done these steps, your site should start to run just as it had before. I didn't give great detail on all of these pieces so let me know what problems you encounter so I can further clarify. More information about the current situation would also help.
One other note I would make: if you need the client to be able to review your work, it will most likely be more efficient and easier for you to leave the original database on the web server, and (if possible) connect to it remotely from your local machine. Since almost any change you make will result in a database change in Kentico, I find it much easier to be working on 1 database for development with distributed codebases. Otherwise you will probably need to overwrite the other database with your changes constantly and this can be annoying. If you leave the database on the server and just connect remotely, you can just ftp (or use git) to push files to the server that you have edited locally.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-