Composer/WordPress : wp-content directory should or should not be committed

2 Views

So I recently started to use Composer with WordPress based on this tutorial.

This is my composer.json file:

Read More
{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "wordpress",
                "type": "webroot",
                "version": "4.3",
                "dist": {
                    "type": "zip",
                    "url": "https://github.com/WordPress/WordPress/archive/4.3.zip"
                },
                "require" : {
                    "fancyguy/webroot-installer": "1.0.0"
                }
            }
        }
    ],
    "require": {
        "wordpress": "4.*",
        "fancyguy/webroot-installer": "1.0.0"
    },
    "extra": {
        "webroot-dir": "public/wp",
        "webroot-package": "wordpress"
    }
}

It worked fine, I got this folder structure:

enter image description here

As it was mentioned in the tutorial, I copied index.php, wp-config.php and the wp-content directory outside the wp directory and replaced the paths.

Everything worked perfect until this point:

Regarding housekeeping with your source code management tool. You’d want to ignore the composer.phar file and public/wp directory.
Everything else can be committed and pushed.

So it seems like that besides the public/wp folder, everything can be committed and pushed. (including wp-content folder)

Here is the thing that I don’t understand. We must commit/push the wp-content directory because it has a different location that it use to have, but in the same time this wp-content folder contains the plugins and themes folder in which our plugins and themes will be added using composer which should not be committed/pushed right ?.

The plugins and themes will be added on the development enviroment also using composer, so we must not commit them, but they are in the wp-content directory which should be committed ?

In another similar tutorial the wp-content is set into the .gitignore file, meaning that it should not be commited/pushed. But If it’s like this, who will move (and how) the wp-content outside wp directory on the development enviroment.

Can somebody clarify this aspect please?

Post Views: 2

Related posts

2 comments

  1. It’s great that you have wp-content split out into a separate directory.

    Personally I only commit items in wp-content that are part of the current project. Another way to think of this is commit anything not added with Composer.

    For example, you could be working on a site with a parent theme, which you are pulling in with Composer and will leave unmodified, and a child theme, which you are making changes to.

    In this example the child theme should be committed and the parent theme ignored since you are only changing code in the child theme.

    The .gitignore file would look like this:

    # Ignore everything in wp-content
wp-content/*

# Do not ignore the themes directory. This is needed to add the child theme (below)
!wp-content/themes

# Ignore all of the themes directory contents, including the parent theme
wp-content/themes/*

# Do not ignore the child theme
!wp-content/themes/child-theme/

    I typically do the same thing with plugins as well. Any plugins pulled in by Composer are ignored but plugins specific to the current project, that you will not use elsewhere, are committed.

    Hope this helps.

  2. The idea is: anything generated should not be versioned.

    who will move (and how) the wp-content outside wp directory on the development environment.

    That is a deployment issue, part of release management.
    That means a post-receive hook on the server side would be in charge of generating the right content based on the newly pushed sources, and move/copy the wp-content folder, once its content has been refreshed.

    The general point is: one generally differentiates versioning from deployment. Moving content is something done at deployment, during release management, for instance by a hook which will move the right resources to the right place.

Comments are closed.