TechnoBabel

How to work with premium plugins and composer

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.

In the beginning…

In the beginning there was…

Just the web and deployments were hard. I remember initially hand crafting code live on web servers. Then came the advent of FTP and life was good because we could easily work off line locally and then upload the changes to the live system. These were those ancient times before CSS and even before JavaScript. It was all HTML and image assets and it was good.

Until we learned the horror of FTP’s weaknesses. Worst among them the plain text password authentication. Many sites fell to ashes as a result of nefarious dark web types. The odd thing about FTP is that as far as protocols go it was never really the most friendly. I am still amazed that the legions of technically challenge who know “How to” FTP. It persists today when there are so many more options.

SFTP which is a secure file transfer protocol based upon the SSH may not have been the first to replace FTP but it is pretty much the defacto standard among engineers today. Many of the FTP client applications have been rewritten to support SFTP rendering the argument by some relics that they NEED FTP completely mute.

So at this point we have achieved some manual methods of deploying code changes utilizing some pretty basic technologies. While manual SFTP may work well for a dev shop of one maintaining small client sites and web apps it’s the most robust. Fortunately there are services like https://deploybot.com that off a n automated SFTP based solution.

However before we jump to that there are a few other possibilities. Depending upon your server configuration you could setup a cronjob to update the site’s code from a VCS like git on a routine schedule. For instance if your site’s code lived on GitHub then your cron script could check and pull master as things change. There is a hidden gotcha in that this would load your web root with the entirety of your VSC history. In this case meaning that you’d end up with a .git directory in the root.

One way to mitigate this is to structure your repo such that the root of your site resides in an internal directory thus keep the .git management directory out of the web root. However this technique will not work for Subversion which places a .svn directory in every part of the hierarchy. The better option is to instruct Apache to to disallow access to those pesky .FOLDERS.

For Git:

<directorymatch "^="" .*="" \.git="" “="">
	Order deny,allow
	Deny from all

For Subversion:

<directorymatch "^="" .*="" \.svn="" "="">
	Order deny,allow
	Deny from all

Some security issues you should keep in mind are setup Passwordless SSH authentication and ensure that the user id that the script executes as; has limited access to the origin of truth in terms of git we are talking Master. In addition if you are hosted on GitHub I highly recommend that you make your master branch protected and exclude this maintenance user from that group.

So this scripted git pull architecture is probably the most rudimentary automated solution you can roll out. It builds upon most of the skills that you probably already have learned from working with a VCS like git. It is not the most scalable solution but this is the first in what I hope will be a series of articles one the subject of code deployment and it does assume that you have command line access to your server(s) and you re comfortable with complete some basic DevOps tasks like setting up key based authentication, Apache and cronjobs.

In subsequent articles I plan to cover tools like deploybot mentioned earlier as well as Jenkins, rsync and Ansible.

Pain in the development backside

That’s right I am talking about caching and more specifically browser caching. We all know that in order to meet the aggressive page load times necessary to maintain search ranking we must employ various methods of caching. You also know that from my talk about High Performance WordPress I am no stranger to caching.

This issue almost always affect continuous delivery of product updates and system migrations. If I had a dollar for every time I heard on a standup or other status meeting call something like, “It’s a caching problem…” I would have a hell of a lot of cash.

So how do we address the elephant in this room?

Cache busting of course.

The first thing to do is try appending a cache busting query string to the URL in question. For example: https://olivent.com/?nocache=1

The next is to investigate utilizing a cache purge tool in the WordPress CMS. This option is dependent upon the caching plugin and underlying caching system you are using.

If you are using a CDN of course you may eventually need to purge items out of cache on a URL by URL basis or even more battle axe style using an across site cache purge.

It’s a caching problem…

This of course leads us to browser caching which is probably the most temperamental beast. This is because neither you as the developer nor the site owner have control over you visitors browser configurations. Honestly you don’t even have control over which browser or even version they use. Thankfully you are able to design to the most prevalent browsers based on your analytics data.

For Firefox and Chrome we have some nice add-on/extensions that add a single click browser cache clear button.

https://addons.mozilla.org/en-US/firefox/addon/empty-cache-button/

https://chrome.google.com/webstore/detail/clear-cache/cppjkneekbjaeellbfkmgnhonkkjfpdn?hl=en

Unfortunately for Safari at this point we are not so lucky. However all is not lost, in this case you need to enable the developer tools as follows:

Once enable you will see a new ‘developer’ menu option which gives you access to a whole host of other possibilities. Honestly if you are asking non-developers to do this a single button is much cleaner but Apple gives us what Apple gives us. This is an example of what you’ll see in the new Developer menu in Safari;

Now you know the many ways you can clear the cache and more importantly how to communicate to your non-developer staff as well as users how to do the same for their browsers.

If only I could solve the other cash problem then I would have:

… a hell of a lot of cash

What the heck is a Dek

Print writers and editor have a lot of difficulty transitioning to a CMS system like WordPress because they tend to carry a full set of print editorial baggage. Now where is this more prevalent than with their legacy terminology. Concepts of Heds, Deks and even Ledes exist in WordPress however because the CMS was developed from the ground up in the digital realm by individuals who were not print editors the terminology is naturally different.

The Lede is probably the easiest to translate since that is typically just the first sentence of the post, just like on a print article.

Converting the Hed to WordPress vernacular is actually very straight forward it is the same thing as the title field. This title field is automatically set in the page <title></title> tag by WordPress as well as displayed atop the post.

Unfortunately the Dek is where things tend to really fall apart mostly due to conceptual confusion. While in WordPress we do not have a Dek field there is an Excerpt but by default the excerpt field is typically hidden in the CMS. To complicate matters further because the excerpt is optional many theme developers forget that it even exists and neglect to include it in their page designs.

Common definition: the DEK is an abstract, consisting of a sentence or two that reveals what the article is about. It expands on or clarifies what is in the headline.

The WordPress excerpt pretty much performs exactly the same function but it is typically thought of the romance copy summary of what this article is about. It performs the role of the article teaser and it is a tricky beast because it is optional.

Failing to fill the excerpt field, WordPress will take the liberty of automatically generating one out of the first 55 words (default) of the first paragraph for the post. Generally speaking this is not a good idea and bear with me as I explain.

At this point you are probably thinking that the Dek and Excerpt are the same, and while they can be the still perform functions with similar goals. Personally the excerpt is far more powerful than the Dek because Excerpts are used in Google search listings and on automatically in taxonomy and custom post type (CPT) archive pages along with the headline (Title) and the featured image.

There are several reasons you want to ALWAYS explicitly craft your excerpts and not relay on WordPress’s automatic feature. While the first 55 words are likely to include your Lede they are also likely to include less optimized text. You want to truly optimize the content in the excerpt so maximize it’s SEO value. Refer the to image below which is exactly the first 55 words from this very post.

In addition the WordPress will ALWAYs check for data in the field when hydrating the content for delivery to the visitor. If you have one it grabs the field content and uses it accordingly. If no content is found then WordPress begins a more exhaustive operation to generate the content form the first paragraph as previously noted.

For a single article this is not a huge performance issue but extrapolate this operation to a WordPress search results page or category listing page with 50 posts and that heavy operation happens for each article snippet rendered on the page. If your site utilizes continuous scroll this can lead to a very poor user experience.

One final note when crafting a WordPress article always include a featured image. The featured image should be compliant with your site’s primary social share guidelines. For instance is Facebook is your primary venue then ensure that the image meets their minimum requirements which at the time of this article is 1200 x 630, where as twitter shared photos should be 440 x 220 a 2:1 aspect ration. For more example refer to: https://sproutsocial.com/insights/social-media-image-sizes-guide/.

TechnoBabel

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

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

Step 1

Step 2

Step 3

Pro TIP

Please remember to go to WordPress.tv and vote for the presentation

It’s a caching problem…

… a hell of a lot of cash

Common definition: the DEK is an abstract, consisting of a sentence or two that reveals what the article is about. It expands on or clarifies what is in the headline.