TechnoBabel

As with anything UNIX there are a number of ways of getting the job done. To claim one way is more right than another is contentious at best. For instance a recent change connecting GitLab to Jira altered my team’s workflow ever so slightly. The principle are the same for linking Github to Jira and it is really a matter of system your team employs. For my team this is a change that has been a long time coming and it amounted to simply not having enough hours in the day to make improvements. You know the age old problem of the “Developer’s children have no shoes” or some such.

By installing the Gitlab Jira connector developers are not able to reduce the paperwork side of their job connecting the merge requests automatically to the tickets if one follows a simple conventions of including the Jira ticket number in the commit message. The catch is this reference is case sensitive and Jira being Jira like upper case ticket identifiers. My team already has a GitLab push rule that requires every commit message start with the ticket identifier so you can understand that the team has been preparing for this for a long time.

The following is an example of what it look’s like in Jira once connected.

At this point you may be asking yourself what it the big problem this seems all wonderful because the children now have shoes. Developers being highly efficient animals that they are do not like to waste keystrokes so the simple act of typing WP- in lieu of wp- can be rather challenging. In addition there is something that attacks social sensibilities that anything TYPED IN ALL UPPER CASE is harsh and akin to shouting. While I know this is not a huge problem, it is still one worth solving so as to keep my team happy.

I looked at this problem from a number of angles and after determining that the majority of my team is using some form of bash elected to deal with this via simple shell scripting. However to exacerbate things most of the team is still running with Bash 3.2 so I had to look for something relatively universally compatible. One of the other challenges I had to overcome is that we have different ticket prefixes for different boards and projects in Jira so I had to find a solution that would support future growth without much effort.

The following is an example of a standardize commit message as defined by our push rules. They must always start with the ticket number followed by a colon.

“wp-348: Installed the open sourced version of…”

Given this information I started with simple shell script that relies on awk using the – as a field separator to split the string two. As a serendipitous bonus awk provide a series of builtin functions and in this case I was able convert the extracted string to upper case before reassembling it with the rest of the commit message. Finally I passed this to my git commit command followed by a push. The following is what the sample script looks like.

Although it is essentially functional at this point, I felt there is a bit of room for optimization. In addition I wanted to integrate this into my .bash_login as a simple command. Therefore I refactored this into the following;

In the above you see I have converted the previously mentioned script into a BASH function and optimized some of the code. Functionally it is the same except that bash loads this and all the other functions on shell initialization. With this complete I don’t have to remember to chmod +x and script files and my use of bashdoc allows me to type show on the command line to see a list of ALL the commands I have created this way, as demonstrated by the following is an excerpt:

With all this done and my shell reloaded I am now able to type the following command to adjust my commit message in accordance with the new paradigm.

While this is all well and good there is something that gnaws at me about using multiple subshells. In my opinion the first subshell is acceptable since it performs a number of functions all at once but the second is superfluous and somewhat inelegant; therefore, it must be refactored. The following is a cleaner implementation that eliminates the second subshell with some standard bash string manipulation.

I hope that you have enjoyed this discussion and that it has opened you to the possibilities beyond simple shell commands as well as solving that age old problem of:

Developer’s children have no shoes

If you are not familiar with Local it is a WordPress local environment hosting solution originally developed by Flywheel, now a wholly owned subsidiary of WP Engine. While it offers a bunch of features like syncing with a Flywheel or WP Engine account, making it fairly easy to ship things to and from their environments, it does not play nice with git out of the box. In order to achieve this you will need to be comfortable with the command line, as well as editing the wp-config.php and performing SQL dumps and imports.

If you work in an enterprise WordPress development environment and all of your code is stored in version control system like Git then you would want to ensure that your git repository is in control of your local environment just like your staging and production. My company uses GitLab because of their robust CICD offering, and we ship our code up the hosting stack for QA & UAT review before production approval. While WPE’s Local system does not support our workflow, we can take steps to make it conform to our company’s defined best practices. These are not terribly complex tasks and if this is your first time on the command line have no fear as I shall walk you through everything. So let’s get started!

To begin, go to the local site and register for a free account. You DO NOT need Pro to do what we have on the docket today. Once you’ve validated your email address, download and install the version of Local appropriate for your environment. The following environments Mac OS, Windows and Linux are currently supported.

Upon launch of the Local app you should see something similar to the following:

If it is not obvious we need to click the Create New Site button. However before we begin I would like to point out that Local set the initial storage directory to be “Local Sites” which if you know nothing about UNIX will cause ALL kinds of trouble in the latter steps. So let’s take a moment to fix that before we begin. In the file system rename that directory to “LocalSites” and then let’s update the application preferences.

Now that we corrected that before it becomes a huge issue let’s click the “Create New Site” button. In the next screen we will configure our site’s basic parameters.

Please notice the above screen shot is from before I changed the application path. It is present to demonstrate the site naming and .local TLD. Obviously, you will enter the information relevant to your site and then hit continue. In the next screen we will customize the server settings.

Generally the system defaults to the version of PHP 7.3.5 and I know that I want to run 7.4.x so you can just run with the preferred and change the PHP version later or as I have done selected customize and set these items from the start.

In this next screen we will setup the basic WordPress configuration, things such as, default account etcetera which we will need in order to access the CMS.

You will notice that you have the option to make the site a MultiSite and I have selected the subdirectory version because this matches my production,as well as staging, environment. If you are not running WordPress MultiSite then accept the default. When you are ready click the add site button and let the application provision your new environment. When this is completed you will see a screen similar to the following:

One thing you will observe is that the SSL certificate is untrusted in your version. It will be highlighted as shown in the following screen. Simply click the word TRUST and follow the prompts.

While this should save the new cert in your local machine’s certificate database it may not update every browser automatically and when you try to load the local site via https you may see a screen similar to the following.

Simply click Accept the Risk and let’s move on.

By this point you should have a functional WordPress environment albeit a very vanilla one. Which is why we are going to break it. Let’s dive into the command line by opening a site shell. Simply click onthe option under the site name in the left column as shown.

This will launch a new site shell with primed with everything we need to do our work in the appropriate WordPress environment. You can see in the following screen that WP-CLI and MySQL have been primed. There is also a stale version of composer but we will not be using this environment for more than importing our production site and connecting out GitLab repository so we can ignore that limitation.

At this point we need to basically throw away the installed wp-content directory and replace it with our GitLab repository. The commands are really simple if you already have the repository checked out onto your local drive then in essence the following will do.

mv wp-content old-wp-content
ln -s PATH-TO-YOUR-repository wp-content

I know there’s a lot to unpack above so let’s break it down. The first command simply moved the installed wp-content out of our way. The second replaces wp-content with a symbolic link to our repository think of this as an alias. Pretty easy providing you already have the repo cloned from GitLab.

While there are a number of way of exporting the production database my preferred is to use WP Migrate DB Pro from Delicious Brains. If you are running a WordPress MultiSite installation then there just isn’t anything better. I opened WPMDBP on the local system to collect the settings I need to add to the production site exporter as follows:

Then we insert these into the prod replace settings which looks like the following:

A word of caution, if your production site uses a custom table prefix then you should write that down because we will need to modify the local wp-config.php accordingly. For instance if your table prefix is my_awesome_site_ then we need to ensure the the local system knows this. Click the export button and when the export is finished save the file to your local hard disk inside the public folder of the local site. The file will be named something relevant to your production site like jafdip-migrate-20210625165749.sql.gz and once on your local hard disk we will need to gunzip it.

Now jumping back into the terminal let’s import this database update and hydrate our site properly. the following WP-CLI command demonstrates this.

If your table prefix is different than the default you MUST update your wp-config.php accordingly. The following demonstrates this concept using our fictitious prefix from above:

After saving the file it is time to load our recently hydrated site. Logging into the site after hydrating the production db will require using your production credentials because we have replaced the existing local db with the modified prod one. You should see a dashboard similar to your production one.

Next we can load the local site in our browser.

Unfortunately I have not riddled out a way to individually modify the nginx config for each site as one can do with Trellis. In Trellis one can add a nginx-includes directory which a subdirectory matching the site identifier to load custom nginx configuration details like the following which I did attempt to add this nginx config to a new file conf/nginx/includes/media-rewrites.conf.hbs but it failed to load.

   location ~ ^/app/uploads/(.*\.(pdf|png|jpg|jpeg|gif|ico|mp3|mov|tif|tiff|swf|txt|html))$ {
      expires 24h;
      log_not_found off;
      try_files $uri $uri/ @productionjafdip;
   }

   location @productionjafdip {
      resolver 8.8.8.8;
      proxy_pass https://olivent.com/wp-content/uploads/$1;
   }

The above code allows the nginx web server to attempt to load the media from the production server if it is not found locally. There are similar rule one can apply to Apache however Apache still offers, for the time being, one to define these kinds of rule in an .htaccess file. Since this is not the case we must look to other means such as the following command that will sync the media files form production.

cd  wp-content/
rsync --partial --append --stats -avzrp prodsite:~/site/public_html/wp-content/uploads .

These commands change into that directory which is our repository and then perform some file sync magick to bring the production uploads directory into our repository. Since that directory is listed in the .gitignore none of those images will be committed to our repository. At this point we have all of our site code available to this new local site installation as well as a local copy of our content images.

As you can see we have a functioning local copy of our WordPress MultiSite with our GitLab repository in place of the wp-content. I would say that all of this will take most individuals approximately 30 – 45 minutes to complete providing they have the appropriate tools in place to make things go smoothly. Now you have a functional working copy of your site in a local development environment and you can use the normal GitLab workflows to draft merge requests and resolve multi-developer mergeflicts, document feature approvals and ultimate release your team’s code up the stack to production using your custom CICD process.

Happy coding!