I've installed a wordpress blog on my development environment. The URL for this environment is dev.mysite.com and my live environment is located at mysite.com. They both share the same database. There's an SVN that works on both environments.
I've installed the wordpress blog on my development environment and everything is fine, but when I moved to the real environment it does not open.
SELECT * FROM wp_optionsLIMIT 1000
The query above shows, that the siteurl is dev.mysite.com. I can change it, but then it will stop working on the development environment (right?). Is there any way to be able to access the blog from both environments, while sharing the same database?
In short I think the answer is no.
Wordpress stores the site/base URL in a few rows in that wp_options table, so it will only work properly for one URL. Is there a reason you need to point them both to the same DB?
When I'm working on Wordpress I just work on the one dev environment and then update my live site incrementally. I thought that was the reason you would have separate environments!
It is a VERY BAD IDEA to use same DB for both development and production, because you can accidently break it (always have backups!). You should have separate DBs, and the one for production should only be used by production app.
You better use some build tools to update production automatically if you need it often, or at least do it manually. Consider using Phing or another build tools.
Related
I'm working on WP-based project which is installed on my local machine (Wamp), so the latest version of the database and WP files is on my laptop.
I'm pushing WP files into git repository, so another dev can pull the files from there and push his code into the git as well. Merging of WP files works fine with git, the problem is the database changes. Once another dev changed something is his local database, I had to do the same in my DB to keep my database up to date, which didn't really work for us.
We are trying to use a centralized database on an external server: all the files are stored on our local machines and we connect to the external mysql server using different DB users. It works better in terms of merging of DB changes, since we both change the same database, but we're having troubles if one of us need to install a plugin, as in this case the dev who install the plugin physically have the plugin files on his local machine, but another dev - doesn't have it. As a result we have to add plugin files manually and then one of us just activate the plugin. Another downside of such approach is - we both connect to the external database, so we are loosing time based on a ping to the server each time we need to re-load a webpage during development in comparison to the same action using a local database.
Please describe how do you work on Wordpress-based website in parallel with another devs? Which tools are you using to make development process smooth and to avoid issues I described above?
Thanks.
I have a simple Wordpress website that is created using twelve twenty. I need to transfer it from server to my PC to be able to edit it and transfer it back to server. Now that I copied wordpress directory from server to my PC it asks me to reinstall it. How can I do it? Am I missing something? Is it possible to work on website locally and once it is done transger it to the server?
Reason for doing this are:
-don't want to loss data for wrong doing things.
-have a copy of website on local machine.
-easier to work on the local machine offline rather than bing online and accssing the server.
From my point of view , i would suggest u to back-up full website and database from server [every hosting control panels has option to backup same]
Connect via ftp and edit ur files.. there to make lots of changes when u want to move from local to server or server to local.
cheers!!!
Editing the files on a live site directly is a terrible, terrible idea. It invites any number of points of failure. If you're actively developing a site things will break at some point - it's part of the developing process - and you definitely want to break things locally, not on a live site.
There's actually several steps involved, all of which are too long to go into great detail, but here's an overview of what is required along with a few links to get you started. The first time you do it seems laborious, but once you figure it all out it actually only takes 10 minutes.
Firstly you will need a local environment MySQL and PHP environment to install it. As you're on PC look at WAMP; here's a fairly good tutorial on installing it.
If you have a lot of content on the live site you might want to import it into your local environment; you'll need to export the database (probably using PHPMyAdmin) and then import it into your local database. You will need to update a couple of database options so that it points towards your localhost. It's basically the reverse of the process detailed here: you'll be changing your-site.com to localhost:8888. If your site is relatively simple you could skip this stage*
Now you should be able to update your local copy of wp-config.php with the database connect details for your local database (usually it's just localhost for the host name and root for the user and password`). With that in place you should now be able to install WP.
Now that it's installed you can edit away to your heart's content on your local copy, safe in the knowledge that anything you do on your local copy doesn't affect your live copy. When you're ready to push your changes live you can use FTP to copy your local files to your live environment.
* For a lot of projects I don't actually go to the trouble of synching databases - if there's a live site that the client can change the content on it often becomes a futile exercise attempting to synch a database with a moving target. In those instances I'll just use a comprehensive set of test content that contains every conceivable type of content that could possible inserted in to the live site.
your going to love working on your project from your locally. Here's an article I found on wpmudev http://premium.wpmudev.org/blog/how-to-install-wordpress-locally-for-pcwindows-with-xampp/ which gives you a step by step guide for PC / Windows.
I like to use a simple Git workflow for static web sites but I build Joomla and Wordpress sites a semi-regular basis too. However I am at a loss as to how to use Git with with database driven site development.
For a static site I would 'Push' to dev.websitename.com, then push to www.websitename.com once the dev site checks out. How would I mimic that process with database driven site like wordpress or joomla.
Thanks in advance for you insight!
You can definitely use Git with your website code, such as changes to your WordPress theme/plugin, exactly as you would if you are developing a static website.
However, you wouldn't use it for your database. Git provides version control for code, while WordPress and Joomla already manage content stored in the database. Plus, Git wouldn't understand a database, so it wouldn't have any advantage over a periodic backup, which you should already be doing. Take a look at running a dev copy of your site for how to download your database directly from your server.
By the way, if you use Git with WordPress/Joomla, you should add e.g. cache, logs, tmp to .gitignore. There are also lots of tutorials out there--try searching e.g. http://google.com/search?q=wordpress+git.
In addition Chris, you may want to embark on your Git workflow without the handy script approach (at least initially). The script approach and using Git hooks can sure seem sexy (well, because they are) and handy too, but initially why not go with a more manual cmd line approach, which will also help you familiarize yourself with Git.
Once you've got your repo setup (GitHub, Bitbucket, somewhere else) and you've pushed your latest to it and are ready to deploy to production or staging, just login to your host and from wherever you've initialized the git repo (site root, example: /site) just do a:
git pull origin master
This will fetch and merge your code. Good idea to test this on a dev/staging environment and if the merge goes well then do it in production.
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-
Can you help me to understand, how do I do Drupal website deployment and development?
Suppose, I developed 1.0 version of Berty&Frank website. I copied everything to their production server and it is alive and kicking now. Site is already full of contents and is growing.
I am asked to add additional features to the website. I am now experimenting with the way how I can implement them in a dev version. I am creating/deleting content types, fill created nodes with demo data just to see how they look like etc. Now I found the way and I want to upgrade production website to the same structure as my dev version now. How do I do that?
Is the only way to manually make every change I made in dev version?
I would explore the Aegir project for the future management of your website. It allows you to clone a site, then to upgrade the site to a new "platform" which could be the next release of Drupal or another Drupal system (such as OpenAtrium).
More can be found at the aegir wiki.
You can export/import views and contenttypes, but a lot of settings etc is stored in the db. This gives two options
Either to use something like backup & migrate to import your settings from dev. This wont work if you have test data though, as you would overwrite the db.
The other options is to repeat what you did on the live site.
A third options could be to take a fresh dump of the live site, do all the settings in that db in dev environment and overwrite the live db with that. You could loose some comments etc, but shouldn't be a big deal.
I use Subversion, and just do an update on my production server when I am satisfied with the code on my development server (actually, I have a staging server that is a duplicate of the production machine, so I update that before the production; I can see any bugs that might pop up).
For database changes, I haven't found anything better than just keeping track of my changes (usually adding/modifying CCK fields) and performing the same changes to the production database. I also download my production database regularly, so that dev and staging have almost the same content. That helps to minimize the confusion.
read http://www.drupal.org/upgrade/