Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
See https://salferrarello.com/wordpress-gitignore/ for the latest version of my WordPress .gitignore file
# -----------------------------------------------------------------
# .gitignore for WordPress
# Bare Minimum Git
# http://ironco.de/bare-minimum-git/
# ver 20150227
#
# This file is tailored for a WordPress project
# using the default directory structure
#
# This file specifies intentionally untracked files to ignore
# http://git-scm.com/docs/gitignore
#
# NOTES:
# The purpose of gitignore files is to ensure that certain files not
# tracked by Git remain untracked.
#
# To ignore uncommitted changes in a file that is already tracked,
# use `git update-index --assume-unchanged`.
#
# To stop tracking a file that is currently tracked,
# use `git rm --cached`
#
# Change Log:
# 20150227 Ignore hello.php plugin. props @damienfa
# 20150227 Change theme ignore to wildcard twenty*. props @Z33
# 20140606 Add .editorconfig as a tracked file
# 20140404 Ignore database, compiled, and packaged files
# 20140404 Header Information Updated
# 20140402 Initially Published
#
# -----------------------------------------------------------------
# ignore everything in the root except the "wp-content" directory.
/*
!wp-content/
# ignore all files starting with .
.*
# track this file .gitignore (i.e. do NOT ignore it)
!.gitignore
# track .editorconfig file (i.e. do NOT ignore it)
!.editorconfig
# track readme.md in the root (i.e. do NOT ignore it)
!readme.md
# ignore all files that start with ~
~*
# ignore OS generated files
ehthumbs.db
Thumbs.db
# ignore Editor files
*.sublime-project
*.sublime-workspace
*.komodoproject
# ignore log files and databases
*.log
*.sql
*.sqlite
# ignore compiled files
*.com
*.class
*.dll
*.exe
*.o
*.so
# ignore packaged files
*.7z
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip
# ignore everything in the "wp-content" directory, except:
# "mu-plugins" directory
# "plugins" directory
# "themes" directory
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/
# ignore these plugins
wp-content/plugins/hello.php
# ignore specific themes
wp-content/themes/twenty*/
# ignore node/grunt dependency directories
node_modules/
@damienfa

This comment has been minimized.

Show comment Hide comment
@damienfa

damienfa Jan 21, 2015

You should add :

wp-content/themes/twentyfifteen/

# ignore useless plugins file
wp-content/plugins/hello.php
wp-content/plugins/index.php

You should add :

wp-content/themes/twentyfifteen/

# ignore useless plugins file
wp-content/plugins/hello.php
wp-content/plugins/index.php
@Z33

This comment has been minimized.

Show comment Hide comment
@Z33

Z33 Jan 31, 2015

I use wp-content/themes/twenty* to ignore all default themes.

Z33 commented Jan 31, 2015

I use wp-content/themes/twenty* to ignore all default themes.

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Feb 27, 2015

I'm now using this WordPress .gitignore file instead. I prefer how the other version excludes plugins and themes by default.

Owner

salcode commented Feb 27, 2015

I'm now using this WordPress .gitignore file instead. I prefer how the other version excludes plugins and themes by default.

@danieljsj

This comment has been minimized.

Show comment Hide comment
@danieljsj

danieljsj Apr 10, 2015

I'm thinking these should be ignored as well:
wp-content/plugins/index.php
wp-content/themes/index.php

for example, when I pulled a repo and then rsync'd a fresh empty wp install over it, it's now asking for a commit just because my fresh files didn't have "?>" at the ends of the files.

I'm thinking these should be ignored as well:
wp-content/plugins/index.php
wp-content/themes/index.php

for example, when I pulled a repo and then rsync'd a fresh empty wp install over it, it's now asking for a commit just because my fresh files didn't have "?>" at the ends of the files.

@crgeary

This comment has been minimized.

Show comment Hide comment
@crgeary

crgeary Apr 20, 2015

Thanks for this, You should also track the composer.lock file so your you don't end up with different package versions across developers.

crgeary commented Apr 20, 2015

Thanks for this, You should also track the composer.lock file so your you don't end up with different package versions across developers.

@FullStackForger

This comment has been minimized.

Show comment Hide comment
@FullStackForger

FullStackForger May 22, 2015

Here is quick update for those who are on OSX and/or using IntelliJ
https://gist.github.com/indieforger/d915d8b430fef748f966

Here is quick update for those who are on OSX and/or using IntelliJ
https://gist.github.com/indieforger/d915d8b430fef748f966

@dotZak

This comment has been minimized.

Show comment Hide comment
@dotZak

dotZak Aug 12, 2015

Probably should include:

!wp-content/languages

dotZak commented Aug 12, 2015

Probably should include:

!wp-content/languages

@joequery

This comment has been minimized.

Show comment Hide comment
@joequery

joequery Aug 25, 2015

Thanks for the file. Why ignore plugins though?

Thanks for the file. Why ignore plugins though?

@acal

This comment has been minimized.

Show comment Hide comment
@acal

acal Sep 4, 2015

I like the idea of ignoring the plugins in order to conserve repo size. I'd think ideally, all plugins (custom or third party) should be contained as an object in a discrete repo. Utilities like Composer or even a good old Readme file should allow one to find and install the required plugins to run the WP site/app.

acal commented Sep 4, 2015

I like the idea of ignoring the plugins in order to conserve repo size. I'd think ideally, all plugins (custom or third party) should be contained as an object in a discrete repo. Utilities like Composer or even a good old Readme file should allow one to find and install the required plugins to run the WP site/app.

@mvhoute

This comment has been minimized.

Show comment Hide comment
@mvhoute

mvhoute Sep 5, 2015

Good list, but I feel you should also add:

.DS_Store (OSX Filesystem)
.idea (For PHPStorm etc.)

mvhoute commented Sep 5, 2015

Good list, but I feel you should also add:

.DS_Store (OSX Filesystem)
.idea (For PHPStorm etc.)
@matthijsleenen

This comment has been minimized.

Show comment Hide comment
@matthijsleenen

matthijsleenen Sep 11, 2015

@mvhoute, no need to exclude these implicitly, they are automatically excluded by excluding . files on line #38.

@mvhoute, no need to exclude these implicitly, they are automatically excluded by excluding . files on line #38.

@ajmerainfo

This comment has been minimized.

Show comment Hide comment
@ajmerainfo

ajmerainfo Sep 15, 2015

I like this idea but quick question. Do I need to event push entire WordPress copy first time or not?
And if not then if might in future developer use new version of WP and if something is not support with that version then how it should go workflow?

I like this idea but quick question. Do I need to event push entire WordPress copy first time or not?
And if not then if might in future developer use new version of WP and if something is not support with that version then how it should go workflow?

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Oct 15, 2015

@chrisgeary92 Thanks for your input, I go back and forth on this idea. For 99% of the project on which I work, we update the plugins from within WordPress. When doing development, I pull the repo, run composer, and then update the plugin if necessary. For the other 1% of projects, I do add composer.lock.

Owner

salcode commented Oct 15, 2015

@chrisgeary92 Thanks for your input, I go back and forth on this idea. For 99% of the project on which I work, we update the plugins from within WordPress. When doing development, I pull the repo, run composer, and then update the plugin if necessary. For the other 1% of projects, I do add composer.lock.

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Oct 15, 2015

@ajmerainfo With the backwards compatibility of WordPress, I see this as a rare problem and if it were to occur I'd have to deal with it manually. I know some prefer to keep WordPress core as a composer dependency, which I believe would address your concern.

Owner

salcode commented Oct 15, 2015

@ajmerainfo With the backwards compatibility of WordPress, I see this as a rare problem and if it were to occur I'd have to deal with it manually. I know some prefer to keep WordPress core as a composer dependency, which I believe would address your concern.

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Oct 15, 2015

As I mentioned above, I'm now using this WordPress .gitignore file instead, which ignores everything by default and allows me to whitelist only those plugins and themes I want to version control. Of course, use whatever works best for you.

Owner

salcode commented Oct 15, 2015

As I mentioned above, I'm now using this WordPress .gitignore file instead, which ignores everything by default and allows me to whitelist only those plugins and themes I want to version control. Of course, use whatever works best for you.

@junibrosas

This comment has been minimized.

Show comment Hide comment
@junibrosas

junibrosas Nov 19, 2015

Is it better to just create a repository from your theme only and not the whole Wordpress files?

Is it better to just create a repository from your theme only and not the whole Wordpress files?

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Dec 22, 2015

@junibrosas I would say it depends on what you're building. When I'm doing a site for client, which is what I'm doing most of the time, I create the repo from the root of the website. If I'm specifically just building a theme, not an entire site, then I create the repo for just the theme folder.

Some people prefer to have one project repo (for the entire project) and use a separate repo within the project repo for the theme. For me, I find this adds a lot of complexity and very little benefit, so I do not do this.

Owner

salcode commented Dec 22, 2015

@junibrosas I would say it depends on what you're building. When I'm doing a site for client, which is what I'm doing most of the time, I create the repo from the root of the website. If I'm specifically just building a theme, not an entire site, then I create the repo for just the theme folder.

Some people prefer to have one project repo (for the entire project) and use a separate repo within the project repo for the theme. For me, I find this adds a lot of complexity and very little benefit, so I do not do this.

@chancesmith

This comment has been minimized.

Show comment Hide comment
@chancesmith

chancesmith Mar 30, 2016

@interglobalmedia

This comment has been minimized.

Show comment Hide comment
@interglobalmedia

interglobalmedia Apr 21, 2016

Very helpful @salcode. Thanks so much for sharing.

Very helpful @salcode. Thanks so much for sharing.

@seanbranam

This comment has been minimized.

Show comment Hide comment
@seanbranam

seanbranam May 5, 2016

@salcode Thanks for sharing!

@salcode Thanks for sharing!

@Andekas

This comment has been minimized.

Show comment Hide comment
@Andekas

Andekas Sep 24, 2016

Thanks!

You should add .idea for phpstorm project files also.

Andekas commented Sep 24, 2016

Thanks!

You should add .idea for phpstorm project files also.

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Sep 27, 2016

@Andekas

You should add .idea for phpstorm project files also.

A good thought but this folder is already excluded due to

# ignore all files starting with .
.*

As a side note, I'm now using this other WordPress .gitignore file, which excludes everything by default, allowing me to whitelist only those plugins and/or themes I want to include.

Owner

salcode commented Sep 27, 2016

@Andekas

You should add .idea for phpstorm project files also.

A good thought but this folder is already excluded due to

# ignore all files starting with .
.*

As a side note, I'm now using this other WordPress .gitignore file, which excludes everything by default, allowing me to whitelist only those plugins and/or themes I want to include.

@paradigmaweb

This comment has been minimized.

Show comment Hide comment
@paradigmaweb

paradigmaweb Mar 11, 2017

maybe you could add:

# sublime sftp sensitive info
sftp-config.json

paradigmaweb commented Mar 11, 2017

maybe you could add:

# sublime sftp sensitive info
sftp-config.json

@salcode

This comment has been minimized.

Show comment Hide comment
@salcode

salcode Jun 12, 2017

@paradigmaweb

Thanks for the note. If sftp-config.json is in the root of the project, it should already be ignored. (Everything in the root of the project is ignored unless it is specifically whitelisted, e.g. !.gitignore)

If you're not seeing that behavior (or if you have a use-case for sftp-config.json in a different location), let me know and I'll take a look at it. Unfortunately, Gists don't provide notifications when a comment is left. If you want to leave a comment at https://salferrarello.com/wordpress-gitignore/ instead, I'll get notified in a much more timely manner.

Thanks.

Owner

salcode commented Jun 12, 2017

@paradigmaweb

Thanks for the note. If sftp-config.json is in the root of the project, it should already be ignored. (Everything in the root of the project is ignored unless it is specifically whitelisted, e.g. !.gitignore)

If you're not seeing that behavior (or if you have a use-case for sftp-config.json in a different location), let me know and I'll take a look at it. Unfortunately, Gists don't provide notifications when a comment is left. If you want to leave a comment at https://salferrarello.com/wordpress-gitignore/ instead, I'll get notified in a much more timely manner.

Thanks.

@juanpasolano

This comment has been minimized.

Show comment Hide comment
@juanpasolano

juanpasolano Jun 22, 2017

How do you clone a project with this project structure?
Something like
git clone <repo> . throws fatal: destination path '.' already exists and is not an empty directory.

How do you clone a project with this project structure?
Something like
git clone <repo> . throws fatal: destination path '.' already exists and is not an empty directory.

@sipy

This comment has been minimized.

Show comment Hide comment
@sipy

sipy Nov 16, 2017

Hello, I'm now using this gitignore for development. My question is on the plugins management:

It's very useful to have plugins tracked across environments and this gitignore tracks them unless you ignore specific plugins (like hello.php ecc..) which is fine. The problem is when the plugins have been updated. The files will sync because they are tracked in the GIT repo, which is ok. But what if the updated version of the plugin needs a DB update/upgrade, too? If so, you must always deactivate and activate again all the updated and pulled plugins to ensure eventual tables of the plugins are synced, too.

Do you have a solution for this problem or it is better to not track the plugins at all and install them manually on each environment which is a little bit frustrating to me?

Thanks

sipy commented Nov 16, 2017

Hello, I'm now using this gitignore for development. My question is on the plugins management:

It's very useful to have plugins tracked across environments and this gitignore tracks them unless you ignore specific plugins (like hello.php ecc..) which is fine. The problem is when the plugins have been updated. The files will sync because they are tracked in the GIT repo, which is ok. But what if the updated version of the plugin needs a DB update/upgrade, too? If so, you must always deactivate and activate again all the updated and pulled plugins to ensure eventual tables of the plugins are synced, too.

Do you have a solution for this problem or it is better to not track the plugins at all and install them manually on each environment which is a little bit frustrating to me?

Thanks

@ummahusla

This comment has been minimized.

Show comment Hide comment
@ummahusla

ummahusla Nov 22, 2017

Thank you

Thank you

@andrebian

This comment has been minimized.

Show comment Hide comment
@andrebian

andrebian Dec 29, 2017

Thanks a lot. It worked fine!

Thanks a lot. It worked fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment