I run my blog using Wordpress and all too recently became a big believer in SCM. I really want to put my site into subversion (that's what I'm using right now, maybe git will come later) but I can't think of the correct way to do it yet. Basically, my repository is set up currently with an 'implementation' directory and a 'resources' directory, with implementation holding what will eventually be published to the live site. I want to be able to preview my site locally without having to upload to the server for obvious reasons. However, to do this I found that I needed to actually install Wordpress locally (not just copy the remote site down to my local box). This was told to me over at Wordpress.org.
This brings up the problem of being able to use SCM with the install because I need to upgrade my local site every now and then but this generates inconsistencies with subversion because it can’t track what’s going on because an external system is messing with it’s repository structure. That just won’t work.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
Anyway, I’m sure other people have tackled this and the solution is probably applicable to many apps similar to Wordpress (Drupal, phpBB, phpMyAdmin, etc.). So, how do you do it?
It's actually not that hard to do, but I'll break it down into a few suggestions here. What you're describing is more or less a "vendor drop" directory. This is basically where you maintain the code in SVN, but replace the contents with the newer stuff as it comes out.
What you should start with is an empty directory. Set up an SVN repository, and then do an SVN checkout into the empty directory (it will still be empty, except it will get a hidden .svn directory added). Next, install wordpress here normally, and then add its files to svn. You can probably just "svn add *" but be careful, and remove anything you don't want versioned (uploads/temp/cache directories, if applicable). You can also use the svn:ignore property to tell it to ignore certain directories or file types, if you'd like. Run "svn stat" to show you what is going to be checked in, etc, and once all is good, commit it (svn commit) and start working from there. Now you have a base installation of wordpress in SVN.
As you work and make changes, commit them.
When it comes time to upgrade, simply replace wordpress over top of what you have. Make sure when you replace directories, you replace the contents, and not the whole directory itself. You don't want to lose the hidden .svn folder in every folder because that is what will mess subversion up. Do an svn stat and/or svn diff to figure out what's changed, if anything, and mostly what's newly-added. At this point, you can commit again.
To deploy on your production site, you can do an svn export, or do a regular checkout into the web directory. If you do a checkout, be sure to only update when you are ready to deploy.
This is the method I'm testing. It takes some time to setup but you should then (in theory) have a future-proof install:
Installing WordPress The Right Way
Also look at svn:externals for pulling in plugin updates:
Use svn:externals to install WordPress plugins
I think the upgrade part can even be a little easier than that; I do this with the most current version of both 2.5 and 2.6, as well as bleeding-edge trunk revision of WP.
Since Wordpress offers all of their stuff as subversion repositories, getting the current rev of a stable tag is as easy as making the blog directory and then
# svn co http://svn.automattic.com/wordpress/tags/2.6.2/ (replace the current rev here for the first check out).
When an upgrade is available, simply navigate to your blog directory and run
#svn sw http://svn.automattic.com/wordpress/tags/2.6.3/ (or whatever wordpress rev you're updating to)
Then releasing to your production site is just an export, as gregmac mentions
However, I don't think this answers your actual question, which I interpret as "How do I keep my custom stuff in SCM while being able to upgrade Wordpress". Your instainct about what directories to tack is pretty much on target (your own personal blog's stuff - themes, pplugins - will be in wp-content, so you should only need to put that into subversion) but I'm not proficient enough with subversion to tell you how to place the directory into your own repository while still being able to rely on Wordpress's repo for upgrades. My "SCM" for those files on my site is an off-server copy of the wp-content directory.
Maybe from that standpoint gregmac's answer works better for you.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
That's exactly how I version control my blog. I've found that it works great. Generally, if you're editing WordPress' files, you're doing it wrong and will be in for misery when it's time to upgrade.
To simplify this, I use TortoiseSVN. I navigated to my /wp-content/themes/ directory in Windows Explorer, right clicked on my custom theme's directory, and chose import from the context menu. After importing all of the existing files, I performed a checkout on that directory and everything was set.
Related
For the past 6 or so months I have been working on Laravel projects that are closer to web apps rather than full, content managed sites.
Recently I've started a Wordpress project and there's something that baffles me, how do you use Git with WordPress?
I ask because in Laravel you can basically push everything asides from node_modules, storage and the composer vendor folder.
I have also read that it is not a good idea to store wp-config in your repository, it's a strange one as Laravel uses an .env file to similar effect.
I found the following .gitignore
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php
/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz
You can ignore almost everything with the following exceptions:
wp-content/themes/my-theme (your theme and/or child theme)
wp-content/plugins/my-custom-plugin. (any custom plugins you create)
Additionally, I have found two very good sources for gitignore files for WordPress. The first which is very straightforward is on gitignore.org and the second which is extremely surgical is by Sal Ferrarello and can be found here: https://salferrarello.com/wordpress-gitignore/
Just modify as required and of course, avoid the config.php. It has install specific info such as your database host & login which you may not want to expose to prying eyes.
Laravel's .env file contains sensitive data just as WP's wp-config.php so we don't usually push it into the repo.
As to how I use Git with WordPress:
I exclude the wp-config.php file, the developer cloning the repo doesn't need it anyways: they can fill in the credentials themselves when working on the project on their local development environment. Another good reason to leave this file out is you don't want to expose your site's details (host, database name, username, password, salts, etc) to the world.
I exclude the uploads folder. The reason is that while developing we usually add dummy images to our posts and pages, images that won't be used at all when the site is finally ready for production so there's no reason to "pollute" the repo with these.
One of the things I love about Laravel is that database changes can also be tracked thanks to migrations. WordPress, on the other hand, doesn't have anything like that so you'll have to find a plugin (or some other mean) to keep your local database in sync with the staging one.
Update:
Since you updated your question to ask which files should be specifically excluded from the Git repo, I think the ones you posted from that .gitignore file you found are good enough. I don't see the need to ignore the readme.txt file though but that won't do any harm either.
I'd like to add a installation of a Wordpress site to version control. After researching a little bit, I found some files/folders that should be ignore, like sitemap.xml and cache folders.
Every single one of them say I shouldn't ignore wp-content/plugins/, which is a reasonable advice at first. The question is: How should I deal with plugins that alter the database?
I can see two scenarios:
If the plugin has to add some tables on installation, this trigger would be lost since it would already be "installed" after uploading the files to the server.
If I must access the installation screen on production, then there's no reason to version control these files.
I would suggest to take a look at this great presentation. It's the most complete I saw yet.
http://stevegrunwell.github.io/wordpress-git
You should have your plugins directory in there too since you do want to track plugin files. As for the database, that's another subject completely. Take a look at the development of VersionPress, it should be out at the end of the year.
I am having a website redesigned. The designers plan to use Wordpress as the CMS and want a development copy to work with. Thing is, I now have Wordpress installed to run a blog (only) on a subdirectory of my current site.
Soooo...question is: Can I create a subdomain, install Wordpress on there, point it at a separate (new) schema on MySQL and have them use that for the development work? I know I can physically do this, but will anything about running the the WP install scripts on the subdomain screw up the existing production install on the main domain?
The install itself should not create any problems. Personally, I always develop WP sites in their own subdomain, allowing me to do away with the wordpress/ subdirectory.
The most significant hurdle will come when you are ready to move the development site to a new domain and/or place in the directory hierarchy. Although the theme files and their associated CSS, JS, etc., files should be using relative-path references, the database itself may contain hundreds of fully qualified URLs that reference the development domain and/or directory.
There are a number of WordPress plugins that address this problems. The one I am most familiar with is BackupBuddy from ithemes.com. (I'm not a shill, just a satisfied customer.) BB is useful both for performing scheduled backups (full or database-only), but it is also very useful during development and during deployment. There is an included script, importbuddy.php, than can not only take a .zip of a full backup and restore the site, it can also move the site from one directory and/or domain to another.
Note: BackupBuddy is not free, but it is released under GPLv2. You are paying for the support necessary to keep it tracking changes in the WP ecosystem. If you are doing any serious WP work then it is money well-spent. You might suggest this to your designers.
Yes you can do it. It doesn't matter. You can install your new blogs to any directory or subdomain (actually they're directories, too). Also you can use new MySQL databases for them, or you can use same database for your all WP installations (by editing wp-config.php manually), thereby you'll have same content for your all WP blogs.
Technically, yes you can do it.
However, if you have a live domain with public people using it, you are best not developing on either the same domain or server, because:
Mistakes happen. You can break the database or other code.
While you develop, you can affect performance of the server.
Develop on a local machine, or a completely different server, and when you are happy with it, push the code live onto the production server.
if you are planning to make a test copy of the current install on a subdomain which includes separate source code and database the answer is NO it will not affect your current installation.
I am currently developing a site based on WordPress (3.3) and am having an issue keeping it up to date properly in subversion (my personal svn server), wondering if I could get any help/guidance on how to handle this. I have a working copy checked out, and everything is working fine, accept for when I update a plugin and/or WordPress itself...here's an example for the Woocommerce plugin (hopefully I explain this well enough):
Woocommerce notifies me of update
I update the plugin using the WordPress dashboard
WordPress deletes all files in the wp-content/upgrade directory, and the plugins/woocommerce directory (including the .svn folders).
I then try and either do an svn add and/or svn commit and get errors about the upgrade and woocommerce directory's 'working copy admin area missing' plus a whole bunch of other problems.
I want to be able to keep this WordPress site in subversion and keep the plugins directory updated, so that I can eventually do an export when I'm ready to move the site to my server, but this is proving to be exceptionally difficult (I can re-checkout and replace the .svn directories for each of the WordPress folders that are missing them, but there are a lot of folders, and is very tedious. I can ignore the upgrade and plugin folders, but then they don't get updated and my export won't go as planned...what should I do?
One thing that will help a lot is to upgrade your client to Subversion 1.7. Instead of a .svn folder in each folder, it has a single .svn folder in the root of the working copy and will keep better track of things.
After you upgrade your client, do svn upgrade at the root of your working copy. Note that this is irreversible and incompatible with older versions of SVN.
The SVN server does not have to be upgraded for this, only the client.
I've got Drupal working on a shared host, and I uploaded some modules from my home system successfully, but I've got the message that there is a security update for my version, and I should update immediately.
I'm not sure how I'm supposed to do that. It seems like the update is an entire new installation. I originally installed it using the hosting company's installer, Fantastico. Should I simply over-write the existing installation with the new files? Or ignore the message? I realize I shouldn't over-write the sites folder, or anything I've modified.
The instructions that come with the download seem to be for a major version upgrade, and are way too much trouble for frequent security updates. Searching Drupal's site shows many other methods, but no indication of anything official. And some were ridiculously error-prone, and not really useful.
I don't have shell access to the hosting site, although I can pay extra to get it if I really need to. Or, maybe I can clone the site on my local Linux system, do the update using a script, then upload the whole thing.
Does anyone have experience with this situation?
With only FTP access you should:
Download and extract the new Drupal version.
Delete the sites folder (in the downloaded Drupal), this is very important.
Put your site in maintainance mode.
Upload the content of the new Drupal (not the sites folder). This should give you a new version of all the Drupal core files, but leave the sites folder intact where you have your custom and contrib modules, your settings.php file and your uploaded files.
Run update.php as user 1.
Lastly put your site in online mode again.