In this article we will discuss working with premium plugins and of course themes in WordPress. It will focus on using GitHub private repositories so that you do not violate the terms of the licensing agreement with the vendor/software developer.
In this example we will be working with WordPress SEO Premium from Yoast which unlike the over the counter version of is not available on WordPress Packagistthus it is unavailable for installation with composer. The purpose of this article is not to argue pro or con for the use of composer just to demonstrate a way you can, make it work with your system. In addition one could use your private repository method in your own site either by cloning it directly, using a git submodule or as previously mentioned via composer.
The following is a simple CLI script to clean out the repo and will be referred to as the repo cleanup script in the instructions below. Keep in mind that this is kind of a dangerous command if you are not in the right directory your could wipe out you entire system. Remember that in UNIX there is NO undelete command.
find * -not -name '.git' -not -name '.gitignore' -not -name 'LICENSE' -not -name 'README.md' -not -name 'composer.json' -maxdepth 0 -exec rm -rf {} ;
Upgrading the plugin is a tricky bit of business as you must remove EVERYTHING except the composer.json, LICENSE, the .git directory, .gitignore and of course this README.md file. Once you unpack the new version of WordPress SEO Premium you need to move everything out of that subdirectory into the root. The good news is that composer.json, LICENSE and README do not conflict with the plugin’s original files however keep in mind that there are several ‘.’ hidden directories. Also don’t remove the .git directory or you’ll be sorry.
So in order to make the repository compatible with composer and WordPress you need to ensure that you have a proper composer.json manifest. The following is an example of what that would look like.
{
"name": "ReadersDigest/wordpress-seo-premium",
"description": "Yoast SEO Premium",
"keywords": ["plugin"],
"type": "wordpress-plugin",
"homepage": "http://www.yoast.com/",
"license": "GPL-2",
"require": {
"php": ">=5.5",
"composer/installers": "v1.2.0"
}
}
Step 1
Download the latest copy of WordPress SEO from Yoast.com
Step 2
In the repo pull the latest from the master.
Step 3
Run the repo cleanup script and verify the changes. Everything should be removed with the exception of the following files:
.git .gitignore composer.json LICENSE README.md
Step 4
Commit the changes identifying the version of Yoast being removed.
git commit -am 'devops-5211: removed old 1.1.1 version of the plugin.'
Step 5
Unpack the wordpress seo zip file (previously downloaded) into the repository and move the files up to the root if the repo.
unzip /Downloads/wordpress-seo-premium-5.0.1.zip cd wordpress-seo-premium mv * ../ cd ../ rmdir wordpress-seo-premium
Step 6
Remove the empty wordpress-seo-premium directory and check your git status. If everything looks good then commit the changes.
git add -A # Will add ALL files in the current part including subdirectories. git commit -am 'devops-5211: installed the 5.0.1 version of the WordPress SEO Premium plugin.'
Step 7
Push your changes to master and note the git hash. In this example that final hash would be 068c4bf and it is necessary for tagging the release.
$ git push Counting objects: 16, done. Delta compression using up to 4 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (16/16), 17.39 KiB | 4.35 MiB/s, done. Total 16 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To github.com:ReadersDigest/wordpress-seo-premium.git 706ced0..068c4bf master -> master
Step 8
At this moment we need to make use of that git hash to tag the release. The following is an example of the necessary commands
git tag -a 5.0.1 -m 'WordPress SEO Premium 5.0.1' 068c4bf
Step 9
The final step in upgrading the repo is to push the tag to origin.
git push -u origin 5.0.1 Counting objects: 1, done. Writing objects: 100% (1/1), 183 bytes | 183.00 KiB/s, done. Total 1 (delta 0), reused 0 (delta 0) To github.com:ReadersDigest/wordpress-seo-premium.git * [new tag] 5.0.1 -> 5.0.1
At this point we have successfully updated the repo as well as upgraded the code in the repo for the commercial plugin. We now need to ensure that the composer manifest of the destination repository references this update.
—
Remember the following is performed in the repo where you want to use WordPress SEO Premium and it assumes that you’ve already got composer working with private repositories.
Note
Normal pull request process is in effect on ALL site repositories because master is always a protected branch. Therefore remember to create a new feature branch before starting the following.
Step 1
This is a bit contentious because depending upon how you’ve setup your composer manifest you may not need to do anything other than run composer update If however you like to ensure that the versions of items built into your product are explicit then you will need to edit the composer.json adjusting the requirement to reflect the exact new version.
This means the if your composer is setup to install patches and fixes for 5.0. then this 5.0.1 update will be automatic but if you have explicitly locked your composer directive to 5.0.0 then you will need to adjust.
Also you may find it helpful to brush up on your semantic versioning.
Step 2
After updating the manifest you need to execute composer update to regenerate the lock file.
Step 3
Once the lock file is up to date and verified you should commit and push the manifest and lock to the repo. This will give you a snap shot like roll back point, meaning that you can always check out the code at this point to do regression testing and patching as necessary.
Pro TIP
Adding the git repo cleanup script as a bash alias can make your life easier. Just drop the following into the .bash_login in your home directory. After the alias is activated you’ll be able to simply type cgr to execute the command in whatever directory you are in. So please do be careful.
alias cgr="find * -not -name '.git' -not -name '.gitignore' -not -name 'LICENSE' -not -name 'README.md' -not -name 'composer.json' -maxdepth 0 -exec rm -rf {} ;"
I will note that I have on occasion encountered a few plugins that have their own .git, .gitignore and even composer files. This makes things very tricky to work around but it can be done. I still find that the extra management of the plugin or theme in this manner is well worth it when it is used in multiple deployments.
I hope that you found this article inspirational. Working with third party premium plugins and themes can be a challenge. Whether you opt for the manual method, git submodules or composer as mentioned above, using this method is extremely beneficial especially when managing multiple properties that require the same tools.
ABOUT THE AUTHOR: Mikel King has been a leader in the Information Technology Services field for over 20 years. He is currently the CEO of Olivent Technologies, a professional creative services partnership in NY. Additionally he is currently serving as the Secretary of the BSD Certification group as well as a Senior Editor for the BSD News Network.
Leave a Reply