Skip to content

Instantly share code, notes, and snippets.

@ibes
Last active June 20, 2018 17:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ibes/c85c4aab737f4817f352d8f33ba8117d to your computer and use it in GitHub Desktop.
Save ibes/c85c4aab737f4817f352d8f33ba8117d to your computer and use it in GitHub Desktop.
Install Beans in WordPlate

Use Beans with WordPlate

What is WordPlate?

"WordPlate is a modern WordPress stack built with Composer. It simplifies the fuzziness around WordPress development." - that is, what they say on their website

I don't yet work with it in production but what I saw so far is brilliant. It has a similar approach to Bedrock. WordPlate offers a folder structure and a setup that enables you to manage your WordPress installation via Composer.

What is Composer?

Composer is the package / dependency manager for PHP. Similar to npm / yarn for JS / node or gem for Ruby. So you can define your dependencies in a config file (for composer it's composer.json) and if you trigger the command for it, all needed dependencies will be loaded into your project.

Why do I want Composer?

Mainly, because stuff needs to be version controlled. If you want to offer a solid result if you collaborate with others and if you want to have a good sleep your projects should be in version control - eg. git. But WordPress and WordPress plugins are already version controlled. It is unless to put that code in git again. Besides of further convenience, Composer allows to just add the needed information to your project: which dependencies in which version do you need.

I have good hope that Composer will help me and my co-workers to finally be for sure on the same versions of WP and WP plugins - and also have our staging, testing and live system on for sure the same versions.

OK, great - but now: what is WordPlate good for?

WordPlate is a well thought out folder structure, a bunch of suggestions for config files (eg. .editorconfig), a setup to have a different configuration for different environments and it helps to get all packages on the right place.

This is just possible because other people created the WPackagist - a service that gets all themes and plugins for the official repository and makes them accessible via Composer. So you can use all plugins and themes you already use and WPackagist together with WordPlate make sure, that the files will land on the right place so WordPress can work with that files.

But Beans needs a special way

Using Beans with WordPlate / composer

Beans is not prepared to be used via Composer. But that is no problem - as Composer can also use code that is offered in other ways - eg. in a GitHub profile.

! I added comments to this file for easier reference - they need to be removed to use this file

Comments look like this: // [1]

{
    "name": "wordplate/wordplate",
    "description": "A modern WordPress stack built with Composer",
    "keywords": ["wordplate", "wordpress", "boilerplate", "plate"],
    "license": "MIT",
    "require": {
        "php": "^7.1.3",
        "wordplate/framework": "^6.2",
        "beans/beans" : "1.4.0" // [1]
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://wpackagist.org"
        },
        { // [2]
           "type":"package",
           "package": {
             "name": "beans/beans", // [3]
             "version": "1.4.0", // [4]
             "type": "wordpress-theme", // [5]
             "source": {
                 "url": "https://github.com/getbeans/Beans.git",
                 "type": "git",
                 "reference": "master" // [6]
               }
           }
       }
    ],
    "scripts": {
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ]
    },
    "extra": {
        "installer-paths": {
            "public/mu-plugins/{$name}": [
              "type:wordpress-muplugin"
            ],
            "public/plugins/{$name}": ["type:wordpress-plugin"],
            "public/themes/{$name}": ["type:wordpress-theme"] // [7]
        },
        "wordpress-install-dir": "public/wordpress",
    },
    "config": {
        "preferred-install": "dist",
        "optimize-autoloader": true,
        "sort-packages": true
    }
}

This is the composer.json file of WordPlate with Beans in place. For more info how to normally install dependencies that are existing in the official repository, please check the WordPlate documentation.

What was needed?

[1] add Beans as a dependency, where the name is the name I gave the dependency in [3]

[2] define where Beans is coming from. Already in place was WPackagist as a further source to load dependencies from. The source of Beans need to be defined manually (one time)

[3] names the dependency - can be whatever you feel like. 'beans/beans' feels familiar and clear.

[4] version number -> that needs to be the same as a tag in the git repository and needs to be manually updated. Normal composer dependencies are able to specify a minimum version - that is not possible with this approach. Could also refer to any other label set in the defined branch.

[5] this is important as it helps WordPlate to put the files of Beans in the themes folder and not just in the /vendors folder as per default. This works because of [7]

[6] the branch to pull from. Needs to be 'master' as we need tags and the develop branch of beans is quite different from the master branch.

Important to know

Beans needs to be updated manually by changing the version at [4] manually. [4] refers to a tag in the repository - so could also refer to '1.4.0-rc' and '1.3.1-beta'.

Also important to know: I am a beginner with composer - so if you think information of me is not correct - it likely is not correct. Let me know!

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