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.
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 just recently started by creating a EC2 instance on AWS. I used the Amazon Linux package. I changed the PHP settings to include the ability to upload files larger than 200MB. Got phpinfo.php working. Installed phpMyAdmin. Everything looked good.
Next, I installed Wordpress. It worked great. Then I tried installing a theme. Worked great. Then I started installing some plugins for that theme. Something made the site crash. I tried a few things, but since I couldn't go to the sites Wordpress Admin panel, it seemed hopeless. So I decided to start from scratch. I deleted the html directory (including wp-content) and dropped all the wordpress tables. I moved a fresh copy of Wordpress into the html directory, reconfigured the config.php file, and it recreated the Wordpress tables in the database. Seems to work great. When I try to upload a theme, it says:
Connection Information
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I noticed that wp-content didn't have a uploads directory, so I created one. That seemed to let me upload the theme, but it showed up as a media file. I moved it to the theme directory and that worked. But when I tried to upload a plugin, I got the same message as a above.
What happened when I deleted everything? Or rather, where was information stored that when I reinstalled Wordpress, it didn't create a uploads directory? I am fine with reinstalling Wordpress from scratch, but I don't want to reinstall the whole LAMP stack or redo the AWS instance. Any thoughts?
The issue is that your web server doesn't have the proper permissions to write to your content directory.
The WordPress Codex has some good info for proper file and directory permissions. Ideally, all files should have 644 permissions, and all directories should be 755 (no higher).
If you're still running into issues adding plugins and updating WordPress, you should heed the advice of the following (so that you don't have to enter FTP details into WordPress each time):
Any file that needs write access from WordPress should be writable by the web server. If your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.
git n00b here. My boss and I are developing a wordpress workflow with git. We'd like to have a copy of all the files on our local machines, but 95% of time we only want to edit a certain theme folder. But our efforts so far haven't yielded a working solution yet. Here's what I've tried:
I originally set my repository to include all wordpress files, so I could always get latest core files from server. Then I discovered files on server were getting overwritten by local copies even if I didn't edit them (eg i do a wordpress update on server and next time I push from local, the old files overwrite the newer ones on server)
So I used git ignore to drill all the way down to my theme folder. Git was still tracking them, so I used rm to stop tracking. But then git deleted all the other files.
How do people here use git with multiple people to update Wordpress? Any perspectives much appreciated - thanks!
You should keep all the files in your git repository, but you should avoid doing any modifications directlry on the server.
Your wordpress update should be done on any of your local checkout of the repository and then pushed on the server via git.
Another possibility will be to commit / push the update changes once they have been done on the server, but I would prefer working locally and then deploying the update.
We're using Subversion to keep track of the changes our web team makes to our Wordpress site. We do nothing more than modify and update our custom theme, but we have difficulty updating the Wordpress core and plugins.
Right now, I have my checked out copy working on a local WordPress install. However, when I run the automatic WordPress updates on this local copy, the updates overwrite the .svn folders in the respective subfolders, resulting in a "Directory .svn containing working copy admin area is missing" error when I try to commit the update.
How can I do these updates automatically without overwriting the .svn folder? As of now I am resorting to copying the files in manually.
If you're just maintaining your theme, you should not have the whole wordpess install under svn but just the theme. I also think in your case it doesn't make sense to actually use a working copy of your repository in the actual live site. In your case I'd keep a working copy of your theme somewhere on your server and then rsync on demand to your theme folder. This way you can update wordpress and your plugins automatically and without problems.
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.