WordPress Complete .gitignore

wordpress-ignore

## Start .gitignore

*.log
.htaccess
/index.php
license.txt
readme.html
sitemap.xml
sitemap.xml.gz
wp-activate.php
wp-blog-header.php
wp-comments-post.php
wp-config-sample.php
wp-config.php
wp-cron.php
wp-links-opml.php
wp-load.php
wp-login.php
wp-mail.php
wp-settings.php
wp-signup.php
wp-trackback.php
xmlrpc.php
wp-admin/
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/plugins/
wp-content/upgrade/
wp-content/uploads/
wp-content/wp-cache-config.php
wp-includes/

Here's the .gitignore file I use for personal local WordPress projects. It makes sure that only the themes I'm working with get uploaded. I'll change it if I need to commit plugins too.

@jcasabona What is the purpose of this ignore file? I read your blog post... it seems like you're trying to eliminate all of WordPress in this ignore file?

@cdevroe: Yeah basically I want to exclude all core files (this one happens to exclude plugins too). That way I can drop a repo/wp-content folder into any local WP install and have it work.

@jcasabona: Is the point to be able to have a single repo that includes all of your custom WordPress code including themes, plugins, etc, etc?

@cdevroe: yessir!

I would go about this another way... First, I wouldn't store all of your WordPress code in a single repository. This makes it more difficult for anyone that would like to contribute to each specific plugin or theme or file. If your repository gets large, people won't want to grab all of it simply to fix a bug in a single plugin. Second, I wouldn't recommend storing all of your code in a WordPress install's root directory and trying to ignore WordPress itself. Too much to maintain and could get messy very quickly. I'd create the repository somewhere else on your computer, and symlink each project into your local WordPress installations.

So, it could look something like this:

• ~/Sites/JoesWordPressCode
  • plugins
  • themes
  • shared_resources

Each directory could then be symlinked into your local WordPress installation(s). I recommend having three WordPress installations locally. Perhaps 4.

1. A WordPress MU install so that you can test a bunch of sites really easily
2. A local WordPress install a version or two behind the latest release. This helps you be sure that your code will work in WordPress installs that are not up-to-date
3. A WordPress install that is up-to-date.
4. (optional) A bleeding edge WordPress nightly. This can help you be certain that your code will run properly on any upcoming version of WordPress.

I put these WordPress installs in ~/Sites/ as wordpress-wpmu, wordpress-dev, wordpress-staging, wordpress-nightly. Dev is typically one or two versions back. Staging is always up-to-date with latest public release. Nightly is obvious. I also make these installations use the following URLs: wordpress-wpmu.plain, wordpress-dev.plain, wordpress-staging.plain, wordpress-nightly.plain. Makes it easy for testing.

Rather than managing all of your code in a single repository make each project its own repo and make them sub-modules of your larger repo. I can see the advantage for you to have a big repo with all of your stuff in it... but, again, if you want to get feedback, pull requests, etc. from the community - it will be far easier if each project is in its own repo.

That "shared_resources" directory is for things like HTML, CSS, Fonts, Icon Libraries, JavaScript frameworks etc. that you'll no doubt use over an over. This way you only have a single version of each on your computer rather than 10 copies of the same codebase. Also, rather than downloading the zip files for things like Bootstrap, for instance, you could clone its repo and have all of its source locally. This would make updating all of your Bootstrap-related projects a task that could be done in just a few commands. When creating a "release" for any of your projects you can simply use Grunt, or something like it, to pull in those resources and package them up nicely into a zip.

Side note: I'm 100% certain that there is a far better way to set things up like this, and I'm sure a Google search or two would help make your solution even more robust than mine.