@pedrosanta thanks for the great writeup about the state of the template. I've skimmed the linked PRs and I get the consensus here that #2972 was too aggressive.

Two options to help us get back to a good place with this template:

• merge this PR and then refine it with follow-up changes
• use this PR as a chance to discuss the changes before merging

Happy to go with either option here, and I'll cc everyone who has been active in the linked PRs to get their feeling for the situation: @rohanvakharia @malithmcr @kolorafa @hdwebpros @chougron @samuraijane @NerdsvilleCEO @Triloworld @stkrzysiak

If we're in agreement with using this PR as a baseline, then I'll close out the other open PRs and funnel them into this PR.

In general, WordPress plugins and themes create files and directories in distributed places. For example, they do create cache files/directories in the wp-content directory, but log files in the root directory. That is the precise reason I have excluded all the files and directories.

In the WordPress ecosystem users create following things custom made:

1. Plugins (wp-content/plugins)
2. Must use plugins (wp-content/mu-plugins)
3. Themes (wp-content/themes)

We must allow only the above three directories with a selective approach. The reason for being selective is to exclude the pre-installed plugins and themes. Besides, we must exclude log files, DB backup files, cache directories, etc which people keep dangling the root directory and other places.

I am not against the declarative approach, it is just that it will not work here because of the too many unknowns.

In general, WordPress plugins and themes create files and directories in distributed places. For example, they do create cache files/directories in the wp-content directory, but log files in the root directory. That is the precise reason I have excluded all the files and directories.
(...)
We must allow only the above three directories with a selective approach. The reason for being selective is to exclude the pre-installed plugins and themes. Besides, we must exclude log files, DB backup files, cache directories, etc which people keep dangling the root directory and other places.

I am not against the declarative approach, it is just that it will not work here because of the too many unknowns.

Like I said on the PR and previous comments, I have a strong feeling that this .gitignore should only take care of the overly common files and overly common setups and not delve into particular setups or try to do everything. For that one should use this .gitignore and add in/expand it with the rules specific to their own workflow or setup—for instance, I don't consider root .sql to be a common file of a typical WordPress installation. I think there might be a risk of forcing all the others/consider that all the others should adhere to our particular setup or rules, if we go that way.

(Perhaps such an approach might be something that fits better on the community folder, idk.)

About the declarative approach not working, because of the many unknowns, I think my reasoning above effectively makes this a not-problem, because I don't think we should be striving to address all the unknowns in the first place, I don't think that's a sensible approach. This .gitignore should only be a sensible default.

(Though if there's is a provenly hugely used cache plugin, or so, I admit we could ignore that folder, etc.)

And, for the record, I do stress I think this .gitignore should definitely follow a declarative approach, as I've explained above/on the PR—and never do a catch-all ignore on the root.

Also, and the more I think of it, the more I feel there are two major approaches to this (related to my Q1 and Q3).

I'm starting to get the sense that ignoring WP core and blanket allowing only all the themes and plugins (even 3rd party ones) with the purpose if ignoring common/downloadable files, is also valid for 3rd party plugins, which leads for one to whitelist themes and plugins to keep common/downloadable code at minimum (as I say on Q3), but then we would have a .gitignore that ignores everything and that one should add their themes and plugins before using, and that doesn't seem to make much sense or be clear.

If the above is the case, I think it probably makes more sense—an approach that a good number of people use too—to have a repository for each custom theme and custom plugin—and have the repos cloned inside WP file structure.

So, I feel there might be two major approaches to this:

• Commit everything (including WP Core) except for wp-content/uploads (binaries) and wp-config.php—this makes the repo basically closer to a deployable payload, but keeps all the core/3rd party plugins files tracked too (😕something to live with).

• Avoid tracking any common core code or 3rd party plugins by basically having a repository for each custom theme and plugin—on which a common .gitignore like this one is basically useless.

So, I'm not sure if we shouldn't model this .gitignore around the first approach above...

I go for theme as starter, not solution to all problems.
This is for "overly common files and overly common setups "

What scenario is common and proper to be in this template for EVERYONE?

• user generated content
• settings with passwords
• cache in wp-content
• examples that are for novice, not in production env:
  -- themes that are included by default and not the "twentytwenty"
  -- plugins that are included by default ("akismet", "Hello Dolly")

99% just create plugins/themes so this is the case. 3rd-party must be case by case different.
Propose to add two optional (and by default commented) lines:

• wp-content/plugins/* #Uncomment to ignore plugins
• wp-content/themes/* #Uncomment to ignore themes

More? You can customize. After all, is starter and need to be for:

• Core team? No, they have and don't need this repo.
• Theme creators
• Plugins creators

More?
Create new file, why only one if there is different scenarios.
Main file is for any scenario.
Propose if necessary:

• WordPress.core.gitignore
• WordPress.theme.gitignore
• WordPress.plugins.gitignore

This fix any discussion in this field as files name distinguish scenario.
Any fix is in proper line and cover some use examples.
What you thinks?
@pedrosanta - this somehow similar but different to Avoid tracking any common core code or 3rd party plugins

In one line:
What community encourage, to be in Git for production environment as proper start.
Other thinks: Case by case. 3rd party plugins/themes isn't in our radar in this place. Just default Wordpress and how is properly used in GitHub

@Triloworld great contribution, thanks. Will follow through with your suggestions (those two plugin/themes lines and comments) and update the PR.

As for the multiple files that is certainly interesting. Perhaps we can keep a sensible default on root folder and add the other files to the community folder, not sure if that's entirely inline with the contributions guidelines but I'll look at/think about it. But I would imagine that's better to go forward with those two lines and keep discussing the multi-files on community folder approach as a follow up.

Also @Triloworld didn't get your take regarding ignoring WP core or not, etc—see my comment on that.

Based on that comment, what's your take about ignoring WP core or not?

(If we went with multi-files approach perhaps default could have WP core committed/not-ignored and then you could add the WordPress.core.gitignore contents to it if you wish to ignore, etc.)

Because, this list of things to ignore you make below, it's super on point, well-thought and consise, and you haven't enumerated WP core here, so I assume you're considering committing/not-ignoring WP core with this one, yes?

I like this scope/list and I think we should follow it, as it complies with all the requisites of a 'starter sensible default' for WordPress.

What scenario is common and proper to be in this template for EVERYONE?

• user generated content
• settings with passwords
• cache in wp-content
• examples that are for novice, not in production env:
  -- themes that are included by default and not the "twentytwenty"
  -- plugins that are included by default ("akismet", "Hello Dolly")

Example What I think about core files:

# Core
/wp-admin/
/wp-content/index.php
/wp-content/plugins/index.php
/wp-content/themes/twentytwenty/ #Required theme
/wp-content/uploads/
/wp-content/upgrade/
/wp-includes/
/index.php
/license.txt
/readme.html
/wp-*.php
/xmlrpc.php
# Don't use ! as this isn't proper for template file like this one to be easily customizable

#Core - examples that can be safety removed
/wp-content/plugins/hello.php
/wp-content/plugins/akismet/
/wp-content/themes/twentyseventeen/
/wp-content/themes/twentynineteen/

My description what I ask myself about this file:
What You think when downloading this file?
Ignore core file but like a list of places to be easily customizable - important than just ignore.
You need them? just add comment. You, as me, need VERIFIED list of core files? get this one template like it is and have comment to guide you.

My example:
I, about work on theme/plugin without touching core, important file. I mix with proper architecture (Apache, PHP, what on server) to have elegant and clean approach. After me somebody need to be sure that I don't touch important piece of WP system. You need that "security" feel as this file I add to Git. People tend to do mistake, this template must be list of predefined and verified directories/files as a good start to work on.

Hi @Triloworld just noticed these two suggestions you made were already built in:

Propose to add two optional (and by default commented) lines:

• wp-content/plugins/* #Uncomment to ignore plugins

Here: https://github.com/github/gitignore/pull/3295/files#diff-f2cf96854b528e9828c4ca34a4917e54R42

• wp-content/themes/* #Uncomment to ignore themes

And here: https://github.com/github/gitignore/pull/3295/files#diff-f2cf96854b528e9828c4ca34a4917e54R48

Like so?

So if I understand correctly the PR goes along your position/suggestions, yes?

Hi @Triloworld just noticed these two suggestions you made were already built in:

Propose to add two optional (and by default commented) lines:

• wp-content/plugins/* #Uncomment to ignore plugins

Here: https://github.com/github/gitignore/pull/3295/files#diff-f2cf96854b528e9828c4ca34a4917e54R42

• wp-content/themes/* #Uncomment to ignore themes

And here: https://github.com/github/gitignore/pull/3295/files#diff-f2cf96854b528e9828c4ca34a4917e54R48

Like so?

So if I understand correctly the PR goes along your position/suggestions, yes?

Yep. This is great but this will ignore all plugins/themes that wasn't great. By default Wordpress now recommend having one "twentytwenty" theme in dir. So this need to be revalidated

Q1 — Commit WP Core or not?

No commit. Give line by line list of files.

Q2 — Catch-all or declarative approach?

Declarative. Just to have starter, no "guessing"

Q3 — Should we allow all themes and plugins, or ignore all and whitelist our own?

Ignore proper one so now is better to have only one commented as a core one that will go untouched:

/wp-content/themes/twentytwenty/

Yep. This is great but this will ignore all plugins/themes that wasn't great. By default Wordpress now recommend having one "twentytwenty" theme in dir. So this need to be revalidated

You're absolutely right—site health freaks out when there isn't a default one installed, yes. Should I add an exclude for twentytwenty, like so:

# Example themes
/wp-content/themes/twenty*/
!/wp-content/themes/twentytwenty/

Or just add the twentytwenty line commented, like so? Wdyt?

# Example themes
#/wp-content/themes/twentytwenty/

Yep. This is great but this will ignore all plugins/themes that wasn't great. By default Wordpress now recommend having one "twentytwenty" theme in dir. So this need to be revalidated

Hi @Triloworld , but now that I come think of it, even if Health Check gives a warning, since this is an example theme, aren't we overdoing it by commiting twentytwenty code into the repository? Shouldn't we handle that outside of versioning control, as in, it's an issue we should handle on each instance, etc—making sure they have default themes? Or else we would be just committing twentytwenty on each update etc/having twentytwenty code changes on our history log, etc.

Wdyt?

Any further thoughts/discussion on this?

@shiftkey , how to best proceed with this?

I really don't want to be 'that guy', but I think this repository (that depend a lot of popular tools, like for instance toptal/gitignore.io) should really have a working WordPress .gitignore. So, I don't know what's the best way to move forward with this, but I feel it nonetheless should be done, even if it means reverting this all the way back before the broken and controversial PR that updated this .gitignore, #2972, and sort it out afterwards.

@shiftkey any thoughts?