DEV Community: Lee Mason

WPDock - A Simple WordPress Development Environment Using Docker

Lee Mason — Tue, 26 Jan 2021 13:23:04 +0000

Here at WP Git Updater we are announcing a new WordPress development environment using Docker!

WordPress already provides a docker image which can be used for development, but it has a few problems that are not dealt with in the usual docker way. We never really found a configurable solution to these problems, which always meant using the docker image requiring some repeated “must know” steps for everything the containers need to be built. Or reverting to using developer machines local php/apache/mysql or another dev environment tool.

We have used various other tools and they do not work well for us. Some just take over the host machine ports without telling you, others just do not provide all the features we need. WPDock is purposely designed to be a very thin layer over docker.

By design, the WordPress image is just WordPress. There is no https support, mail catching or database access. This means again polluting your dev machines MySql tool of choice with numerous connection profiles.

We wanted to find a way to run the WordPress Docker stack as it’s a perfect use case for docker in a team/collaboration environment. With Docker Compose we wanted a setup you can just "start" that includes some common tools used for WordPress local development.

We set out to achieve the following:

A single command to start/stop the whole environment
Easy access to the MySql database
Mail catching out of the box
No WordPress loopback or Rest Api health check errors
Simple access to WP-CLI
HTTPS/domain name support
As little development machine pollution as possible
Simple database sharing between team members

Enter WPDock

WPDock is a very simple bash script that gives you all of the above. All you need is docker for basic operation, and if you want https/tls support there is only 1 other dependency mkcert.

Checkout the repository and install instructions over on Github. WPDock is a simple executable you just need to place in your path.

You can create a WPDock environment with the following command:

wpdock init

This will create a .env file in your current folder with the required environment variables for operation. It will also add the .env file and the .wpdock folder to a gitignore file and finally it will create a .htaccess file which prevents these dot files ever being accessible should you mistakenly upload them to a server.

Then to run the whole stack:

wpdock up or wpdock start

That’s it!

With this (and depending on what you have changed in the .env file. You will have access to:

WordPress on localhost:8080
PhpMyAdmin on localhost:8181
Mailhog catching WordPress emails for review on localhost:8282
MySql on localhost:33060

Your current directory is bound as the wp-content folder on the WordPress container and WordPress is already installed for you to start developing with.

What's more, the only development machine pollution is the ports being bound. WpDock will not use anything other than docker and those ports. This is perfect and gives you the flexibility to adjust the .env variables in another folder and run multiple instances at the same time!

This also follows WP Git Updaters recommended structure for WordPress source controlled setups. With this setup you can git init in the bound wp-content folder, ignore the uploads folder and your all set.

Need to access `WP-CLI`?

Of course we have made this simple too:

wpdock user list

Any commands not recognised by wpdock will pass through to the cli container.

Sharing Databases Between Team Members

You can of course use various mature tools to synchronise databases. But for simple usage wpdock provides dump and import commands:

wpdock dump # dump.sql will be in your current directory
wpdock import # will import the dump.sql file in your current directory

Stopping Environment

Stopping the environment can be done in a few ways:

wpdock stop # stops the containers
wpdock down # stops and removes the containers
wpdock destroy # stops and removes the containers + shared volumes

Other Commands

[service] can be one of: wordpress, cli, db, mailhag, phpmyadmin, and caddy (more on this later).

wpdock help # displays command help

wpdock file .env # displays the default env variables should you want to create or amend an existing .env file

wpdock exec [service] # eg: wpdock exec wordpress bash

wpdock run [service] … # eg: wpdock run cli bash

wpdock logs [service] # tails all container logs, or pass a service to view specific logs

wpdock compose … # proxy commands directly to docker-compose

wpdock … # is the same as wpdock run cli wp …

As you can see WPDock is a very thin layer over Docker Compose commands.

Real Domains with Valid Local TLS/HTTPS Certificates

Inline with the The Twelve Factor App recommendations on Dev/Prod parity.
In 2021 there really isn’t an excuse not to use TLS even for local development.

What’s more if you plan on using any form of shopping cart plugins without TLS you're likely to run into some issues over plain http.

WPDock provides a simple option to enable custom domains with https for your development environments.

Let's take a look and how it works:

wpdock up --https

With the above command and the WORDPRESS_SITE_HOST .env variable setup you can develop locally with trusted TLS encryption for WordPress!

How does this work?

WpDock needs 1 additional tool to provide this feature: mkcert.
Mkcert adds a locally trusted CA to your development machine, and allows you to generate TLS certificates against that CA.

This means no more untrusted certificate warnings.

First install Mkcert as detailed in their documentation. Run mkcert -install once to install the CA and let WpDock take over from there.

When you run wpdock up —https the following additional steps are performed.

wpdock will generate a Caddyfile in the .wpdock folder.
wpdock will generate certificate and key files from your WORDPRESS_SITE_HOST env variable in the .wpdock/certs folder.
A new caddy web server container will be started, with the generated files mapped into the correct locations.

Caddy is a super simple to use web server which is perfect for what wpdock needs to provide TLS support.
The generated Caddfyfile simply creates a reverse proxy from WORDPRESS_SITE_HOST to the wordpress container

The Caddy container does need to bind to ports 80 and 443 on your development machine to provide this mapping.

Now all you need to do is make sure WORDPRESS_SITE_HOST points to 127.0.0.1 via your /etc/hosts file.

Your website will be available over https/tls, automatically forwarding http requests, with a trusted certificate.

Additionally wpdock will update your database and replace the localhost:${PORT} urls with the new domain name.

When you stop your development environment, everything is cleaned up. Port 80 and 443 are free again to be used.

Head over to the Project to find out how to install and more on the commands: https://github.com/wpgitupdater/wpdock.

Feedback Welcome

We hope you enjoy using WPDock. For us it's a small but useful addition to our development workflow.

WPDock is open source and can be found at https://github.com/wpgitupdater/wpdock. Any improvements/suggestions are more than welcome.

At Wp Git Updater we develop locally using Apple machines, but we believe all of the commands will also work on Linux environments (please let us know if you have any issues).

For windows users we are more than happy to accept PR’s that provide support if it can be achieved.

Stay tuned, in the next few posts we are going to cover some of the features in more detail, and show you a setup automatically resolving your chosen tld to localhost using DNSMasq.

And We're Live!

Lee Mason — Tue, 19 Jan 2021 15:59:23 +0000

Over the last few months we have been testing, adding new features and getting ready for the big launch.

Its finally here with automated theme and plugin updates, run via gitlab action workflows.

We still have much more we are working on that will be coming in the future:

mu-plugin updates
Gitlab, Bitbucket, Travis and Circle CI integrations
Auto update disabler plugin for plugins managed by WP Git Updater
Auto merging updates

Additionally in the coming days we will be launching our Docker based WordPress development environment we use internally for WordPress development.

As part of the launch we are offering you a massive 40% discount on any of the subscription plans FOREVER.

Simply use the coupon code LAUNCH when subscribing.

But don’t wait too long, the LAUNCH coupon expires the 28th of February.

Before then you can take advantage of the 10 day free trial offered for new users.

Once again thank you for your interest in WP Git Updater, if you need support, want to request a feature, or just catch up please don’t hesitate to let us know

Signup Today!

WP Git Updater – A Month In Review

Lee Mason — Thu, 07 Jan 2021 16:35:33 +0000

At Gambit Nash we have been working on a service to automate WordPress plugin and theme updates for Git source controlled sites called WP Git Updater.

WP Git Updater will be available for usage before the end of January 2021 and we are super excited about it.

We have been using the service internally for some time alongside some beta testers to make sure it’s ready for a wider audience on launch day.

Now is probably a good time to take a look at the service it provides and how it aids our development team.

I’m going to focus on the usage in 3 of our WordPress repositories that have a variety of plugins and themes.

The Projects

Each of the projects is a WordPress site, that has between 10-25 plugins, and they all have child theme setups using different parent themes.

Additionally each project has staging and production environments, where staging is auto deployed from the develop branch in GIT when changes occur.

Each project has a number of “boilerplate” plugins we use for all our WordPress websites, namely: Jetpack, Yoast SEO, Post SMTP, and WP Git Updaters handy Display Git Status plugin.

These types of projects are the target use cases for WP Git Updater. But it’s in no way limited to them.

At its heart WP Git Updater creates branches and Pull Requests for plugin or theme updates, how you choose to organise your Git strategy or deploy changes is up to you. WP Git Updater is agnostic in that regard.

The projects were chosen specifically due to the high numbers of plugins in use on them.

It’s no secret that with WordPress websites you should aim to use as few plugins as possible, so we would categories the above stats as “high” usage projects.

The Stats

Although highly variable depending on the quantity and especially the update frequency of the plugins or themes in question. We chose the 3 projects above to try and give you a feel for the anticipated usage you may have if you used WP Git Updater.

Over a 30 day period WP Git Updater performed:

67 Total Updates

59 Plugin Updates

8 Parent Theme Updates

These updates were relatively even across the 3 projects.

This would put us in the “Professional” plan with plenty of room to spare, we could estimate from this that the plan would support 5 or more high usage projects for Gambit Nash.

In reality we have many more projects which is why the rest of this article is so important for us.

The Professional plan is priced at $50 per month, so what do the above stats mean as a cost/benefit ratio on 5 projects?

The answer as always is “it depends”. For us the breakdown isn’t just as simple as the number of updates performed:

How do we even know updates are required?

Well before WP Git Updater our update strategy was a mixture of scheduled maintenance reviews for lower activity projects, and general awareness of the team interacting with the project on a day to day basis.

This isn’t necessarily a developer, but someone in the team needs to review the project’s status.

This is especially painful as we need to allocate time to that team member to physically visit the staging sites, review any update notifications and then create tasks to be scheduled.

We have a pretty streamlined project management process using Monday.com but that’s out of the scope of this article.

Even with our streamlined approach an optimistic estimate per project just for the updates would be around 5 minutes.

How does WP Git Updater compare?

Well as we use Monday.com we can automate task creation so the cost to us is zero.

But taking Monday.com out of the equation our team members get emails when the pull request is created, from this they can action right away.

So per project the time shrinks to below 1 minute.

Time Saved

(5 min x 5) – (1 min x 5)

20 minutes per month

How much time do we need to plan updates?

Our old approach would be a conversation between the project managers and developers.

The first topic is always “where’s the changelog”, so off to google the plugin repository, search for the plugin, click the development tab and review.

Precious minutes lost with the same problem every time. I would estimate 20 seconds per plugin optimistically.

With WP Git Updater the changelog is pulled into the pull request for you, so it’s right in your email! It’s probably 5 seconds per plugin.

Knowing from experience there are a lot of common plugins/themes, so a quick review of the changelog and past experience most estimates per plugin could be agreed in a few minutes. This is no different with WP Git Updater so is left out of any comparison.

The unit of measure here is “per plugin” so let’s average that out at 12 plugins per project. Giving us 20 mins and 5 mins respectively.

Time Saved

15 minutes per month

How much time does a developer need to perform the update?

This is a difficult question to answer as every update is different.

What we can say is many updates can be signed off quickly by an experienced developer just by reviewing a diff of the changes.

To review a diff of an update without WP Git Updater you need to ensure you’re on the latest commit, run your local environment, perform the update either via the admin or cli, open the diffing tool of your choice and review.

With WP Git Updater you click the email link to see the diff in GitHub. It really is that simple.

For these types of updates the difference per plugin can be minutes (or more depending on how you run your local development environment).

For larger updates you would still likely want to perform initial testing in your local environment, but you can skip a step and save time even here. As WP Git Updater has already updated the plugin in a new branch, you can just checkout the update branch, run your environment and perform usual testing.

Between those two optimisations at Gambit Nash we would estimate on 5 projects over a month they could save us around 1-2 hours.

Time Saved

1.5 hours per month

How quickly can we get those updates to the testing team?

Without WP Git Updater the answer is monthly as per our update schedule. This is obviously sequential too.

Once we have made the updates the testing team needs to validate them before ever going to production.

Now we can react to updates more effectively, we can also provide the testing team with a steady stream of testing to perform.

Our updates are no longer just a scheduled block of work.

The time impact isn’t in the testing itself, but in building a backlog of work the testing team can complete.

While no direct time savings are made, having a steady backlog of testing requirements reduces the context shifting, waiting and communication requirements.

Time Saved

30 minutes per month

Totals

Above we have been pretty pessimistic about the time savings, there are areas hard to quantify but its clear WP Git Updater has had a positive impact on our workflows. If it wasn’t our own product I’d be much more inclined to increase those estimates.

Across just 5 projects for $50 at least 2 hours can be saved.

Most of this is developer time.

With an average developer salary of $60-$80 per hour that’s a monthly saving worth considering.

Especially when you consider this is just 5 projects. What about 10, 20, 100?

But time and savings are not why this service is important.

How often should we perform updates?

Before WP Git Updater we always aimed to do this every month for every project.

We still do monthly updates for every project now. But there is a massive difference.

On top of the monthly updates, we can now fast track many “considered safe” updates just by merging the pull requests to the staging (develop) branch.

As we run a staging and production setup for our sites, we can with good confidence simply merge updates for some of the more common plugins.

If a problem with one of these updates is found in staging, no harm no foul we can just revert and investigate.

We only do this for updates with a proven track record, honourable mentions include: Jetpack, Yoast SEO, Advanced Custom Fields, Post SMTP.

Technically there is no time saved over the usual savings referenced above, but the benefit here isn’t time.

At Gambit Nash our clients play an active role in using the staging sites, the staging area is for them as much as it is for us.

These fast track updates demonstrate our active involvement day to day with their project.

The admin areas aren’t an ever increasing update notification hell that resets once a month.

If we need to release a new production deployment outside of the usual schedule, we can also rely on updates which might not have been completed till the next maintenance schedule being present.

Simple patch release updates for security issues with plugins or themes can be notified, merged, tested and deployed within a day.

These benefits outweigh any time saving or process optimisations.

WP Git Updater allows us to provide a faster, ever improving experience for our clients. And this is the real value from the automated plugin and theme updates WP Git Updater provides.

Laravel Nova Resource Stubs For Spark Teams

Lee Mason — Mon, 04 Jan 2021 21:41:19 +0000

At Gambit Nash we are on the verge of releasing WP Git Updater. WP Git Updater provides automated source control updates for WordPress websites stored in git. Very much like dependabot but for WordPress sites not using composer version management.

As this is a service which has a monthly subscription. The obvious choice was to implement Laravel Spark and let it take care of the subscription management. As an added bonus it provided us with a base to work from for the rest of the site (layouts, style, etc).

Im going to review Spark in a broader post, so I’m not going to go too far into a review, but suffice to say the kiosk feature is “ok”, but its not on the level of Laravel Nova (and nor should it be). So we took the decision to build a nova backend for the site too.

I was quite surprised to find scarce examples or packages to display Spark information in Nova. Might even be worth Spark having some stubs included to show this info when Nova is also installed.

We have used Spark through a team billing profile, so the following stubs don’t take into account user subscriptions, but I’m sure you could modify the resources to work for users if needed.

Team Resource

<?php
namespace App\Nova;

use Illuminate\Support\Str;
use Laravel\Nova\Fields\BelongsToMany;
use Laravel\Nova\Fields\DateTime;
use Laravel\Nova\Fields\HasMany;
use Laravel\Nova\Fields\ID;
use Illuminate\Http\Request;
use Laravel\Nova\Fields\Select;
use Laravel\Nova\Fields\Text;
use Laravel\Spark\Spark;

class Team extends Resource
{
    public static $model = \App\Models\Team::class;

    public static $group = 'Spark';

    public static $search = [
        'id',
        'name',
        'update_token'
    ];

    public static $title = 'name';

    public function fields(Request $request)
    {
        return [
            ID::make('ID', 'id')->sortable(),
            Text::make('Name', 'name')->sortable()->rules('required', 'max:255'),
            Text::make('Slug', 'slug'),
            Text::make('Update Token', 'update_token')->readonly(),
            Text::make('Stripe ID', 'stripe_id')->nullable(),
            Text::make('Current Plan', 'current_billing_plan')->nullable(),
            DateTime::make('Trial Ends', 'trial_ends_at')->nullable(),
            DateTime::make('Created At', 'created_at')->readonly()->hideFromIndex(),
            DateTime::make('Updated At', 'updated_at')->readonly()->hideFromIndex(),
            HasMany::make('Subscriptions', 'subscriptions', TeamSubscription::class),
            BelongsToMany::make('Team Members', 'users', User::class)
                ->fields(function () {
                    return [
                        Select::make('Role')
                            ->options(
                                array_merge(
                                    Spark::roles(),
                                    [
                                        //default role
                                        Spark::defaultRole() => Str::ucfirst(Spark::defaultRole()),
                                        //owner role
                                        'owner' => 'Owner'
                                    ]
                                )
                            )
                    ];
                }),
        ];
    }
}

Team Subscription Resource

<?php
namespace App\Nova;

use Laravel\Nova\Fields\BelongsTo;
use Laravel\Nova\Fields\DateTime;
use Laravel\Nova\Fields\HasMany;
use Laravel\Nova\Fields\ID;
use Illuminate\Http\Request;
use Laravel\Nova\Fields\Number;
use Laravel\Nova\Fields\Text;

class TeamSubscription extends Resource
{
    public static $model = \Laravel\Spark\TeamSubscription::class;

    public static $group = 'Spark';

    public static $search = [
        'id',
        'name',
        'stripe_id',
        'stripe_plan',
        'stripe_status'
    ];

    public static $title = 'name';

    public function fields(Request $request)
    {
        return [
            ID::make()->sortable(),
            Text::make('Name', 'name')->nullable(),
            Text::make('Stripe ID', 'stripe_id')->nullable(),
            Text::make('Stripe Plan', 'stripe_plan')->nullable(),
            Text::make('Stripe Status', 'stripe_status')->nullable()->sortable(),
            Number::make('QTY', 'quantity')->nullable(),
            DateTime::make('Trial Ends', 'trial_ends_at')->nullable()->sortable(),
            DateTime::make('Ends At', 'ends_at')->nullable()->sortable(),
            DateTime::make('Created', 'created_at')->sortable()->readonly()->hideFromIndex(),
            DateTime::make('Updated At', 'updated_at')->sortable()->readonly()->hideFromIndex(),
            BelongsTo::make('Team', 'team', Team::class)->searchable(),
            HasMany::make('Subscription Items', 'items', TeamSubscriptionItem::class)
        ];
    }
}

Team Subscription Item Resource

<?php
namespace App\Nova;

use Laravel\Nova\Fields\BelongsTo;
use Laravel\Nova\Fields\DateTime;
use Laravel\Nova\Fields\ID;
use Illuminate\Http\Request;
use Laravel\Nova\Fields\Number;
use Laravel\Nova\Fields\Text;

class TeamSubscriptionItem extends Resource
{
    public static $model = \Laravel\Spark\TeamSubscriptionItem::class;

    public static $group = 'Spark';

    public static $search = [
        'id',
        'stripe_id',
        'stripe_plan',
    ];

    public function fields(Request $request)
    {
        return [
            ID::make()->sortable(),
            Text::make('Stripe ID', 'stripe_id')->nullable(),
            Text::make('Stripe Plan', 'stripe_plan')->nullable(),
            Number::make('QTY', 'quantity')->nullable(),
            DateTime::make('Created', 'created_at')->sortable()->readonly()->hideFromIndex(),
            DateTime::make('Updated At', 'updated_at')->sortable()->readonly()->hideFromIndex(),
            BelongsTo::make('Team Subscription', 'subscription', TeamSubscription::class)->searchable(),
        ];
    }
}

Our Display Git Status plugin has just been approved on the WordPress.org plugin marketplace

Lee Mason — Sat, 19 Dec 2020 00:14:06 +0000

Display Git Status is a utility plugin to provide basic git status information right in the WordPress admin bar.

We have created this plugin as a complimentary and free plugin for our users. Given our service offers Git source controlled plugin and theme updates. It's obvious such a feature would be beneficial right within the admin area. And we were surprised there wasn't already a solution.

This plugin is great as a gentle reminder or flag to see if your staging or even production site becomes out of sync with your repository.

Once activated just look out for the admin bar icon link turning to a red background, which indicates there are changes you probably need to investigate.

We have added a new page to the documentation for our plugin (soon to be plugins) here.

WP Git Updater now supports theme updates

Lee Mason — Thu, 17 Dec 2020 20:07:39 +0000

That's right! You can now update WordPress plugins and themes using WP Git Updater.

The primary goal of WP Git Updater is to optimize and automate updates on your Git controlled WordPress websites. We started with plugins but early on it became clear theme updates were a must have. We felt this was such a critical feature we needed to make sure it was available before we officially released WP Git Updater.

Additionally we have been able to retain the same configuration format with some new additions. This is down to some forward thinking knowing theme features were coming in the future.

In short just adding:

themes:
  enabled: true
  path: themes

To your config file is sufficient to enable theme updates.

There are of course further customizations available if required. Full details can be found in the Documentation.

Just like plugins you can now automate theme branch and pull request creation on infrastructure and terms you define.

Laravel On Shared Hosting

Lee Mason — Tue, 15 Dec 2020 15:42:46 +0000

Before we start its worth caveating this post with the message: It’s always more desirable and recommended to serve Laravel apps from bespoke hosting environment.

There are plenty to choose, from first party tools like Forge and Vapour to more general providers like Digital Ocean, AWS and GCP.

However as i find myself in a similar situation there may be times you have to deploy on a CPanel environment.

I am going to cover the usual quite simple redirect you see across the web, but more importantly a second step thats usually left out. This second step can have a massive impact on your SEO.

The Redirect

As you may of found elsewhere theres a simple redirect you can put in the root folder of your project:

# Internally rewrite all top-level requests to the public directory
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^(.*)$ public/$1 [L]
</IfModule>

It’s very simple and just redirects everything from the root of your site public_html down into the public folder of your Laravel project.

From there the .htaccess provided with Laravel will take over and route incoming requests.

Job done? Maybe not…

The SEO Problem

The problem with the above redirect is that it doesn’t prevent access to ALL of your urls with a /public/ prefix. So both / and /public/ will server your applications homepage!

This is obviously bad for any SEO efforts your planning to make to the site as you now have duplicate pages and on top of that if someone stumbles upon those urls its not great for users.

I spent sometime trying out redirects to prevent this from the .htaccess file itself but came up blank. In my particular case this is a CPanel server with Litespeed installed. And i know from experience its not quite 100% like for like with Apache.

The Solution

With the .htaccess approach coming up blank i went with a Middleware solution. Again this isn’t ideal as its not really the applications responsibility but we are not in an ideal situation anyway.

It’s a pretty simple middleware, it looks for the public prefix and returns a 301 redirect if found. This does mean you cannot have urls that start with public but in our case this wasn’t a problem:

<?php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class RedirectPublicFolderRequests
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle(Request $request, Closure $next)
    {
        if (strpos($request->getRequestUri(), '/public') === 0) {
            return redirect()
                ->to($request->getSchemeAndHttpHost() . '/' . substr($request->getRequestUri(), 8))
                ->setStatusCode(301);
        }
        return $next($request);
    }
}

Once again this isn’t ideal but works for our purposes.

Add this to your global middleware stack before anything else.

Note how we use the $request->getRequestUri() method and not simply $request->path(). As the path will be effected by the servers rewrites.

Now any requests for public will redirect with a 301 and you wont be serving duplicate pages.

A look at WordPress source control strategies

Lee Mason — Mon, 14 Dec 2020 22:09:22 +0000

In this post we are going to look at the benefits, available tools and a few common patterns to use source control with a WordPress powered website.

Source control is quite a generalisation. There are many source control implementations. The two biggest are GIT and SVN.

For the purposes of this post we are going to be talking about GIT as a source control tool, after all it’s in our name.

What are the benefits

If you are a single administrator of a WordPress website, source control allows you to maintain a single source of truth for your website’s files. In case of problems it provides the ability to “revert/rollback” changes and it allows you to review the history of file changes.

Additionally with branches, tags and commits you have fine grain control and authority on changes to be made.

For mission critical Websites with development/staging environments, you can selectively apply changes and review before “merging” into the production codebase.

Source control really shines when working in larger teams. It enables easier collaboration and mechanisms for applying outside changes to your own work. Conflict resolution is provided with diffing tools to review and apply.

When twinned with a source control provider like Github, Gitlab, or Bitbucket you have additional features like Pull Requests and issue trackers to cross reference changes with bugs whilst giving project maintainers control over which updates are applied to main branches and when.

For WordPress specifically, source control can remove the variability of WordPress core, plugin and theme updates. For most WordPress websites there are third party files operating your website, and depending on your update strategy these changes may be out of your control.

Existing tools

VersionPress

VersionPress treats your site file and its database as one and source controls everything. This takes the concept of GIT and brings it into the WordPress admin area. Instead of GIT being used as a background process to manage the state of your website files, VersionPress turns your whole website including content and settings into a GIT repository.

WP Pusher

WP Pusher is more traditional and looks specifically at individual plugins or themes. It provides the ability to install or update directly from a GIT repository, with features to choose a specific branch to use.

WP Rollback

WP Rollback takes a defensive approach and utilises source control to rollback plugin or theme updates directly from WordPress repositories.

Common source control approaches

Although some of the tools mentioned above do more than source control your files, in this section we are going to focus on WordPress file source control.

We are also going to look at these patterns from a “pull changes” perspective. This means the website is only updated from source control. The website doesn’t "push changes" back to GIT.

Source control everything

This pattern takes your website files, including WordPress itself and commits it to source.

Using this approach, core, plugin and theme updates should be turned off within the administration area.

The advantages of this are that everything, even down to the specific WordPress version, is static and controlled. For mission critical sites this could be the right approach as it leaves nothing to chance.

Unfortunately this advantage is also its disadvantage. WordPress core updates can be applied automatically for good reason. Updates may include security patches to protect your website and without automatic updates, you would be responsible to ensure WordPress is always up to date.

Source control the `wp-content` folder

This is a common approach and provides an advantage over the first method. Using this approach WordPress core updates are usually turned on to ensure a secure system.

This pattern also provides some flexibility. For example you may choose some highly trusted plugins or themes that can be automatically updated. For this to work without your Website and GIT becoming divergent you can “ignore” certain files and folders from source.

Excluding any ignored files or folder (or uploads) everything within your wp-content directory would be controlled. This would mean themes and plugins would only be updated when they are updated in GIT.

A disadvantage of this approach is that updates would require manual intervention. You would need to apply the updates in source and pull them to your website.

This approach provides protection against incompatibilities between plugins and themes. It doesn't safeguard against WordPress core updates. However, WordPress has a long and positive history on unknown breaking changes for core updates, so it is suitable for most scenarios.

Source control per plugin/theme

This approach does not source control your website in any way it controls a particular plugin or theme. You could use this approach along with some of the tools mentioned earlier to manage individual parts of your website.

This approach won't provide you any safeguards against future update compatibilities as the pattern is concerned only with the plugin or theme it controls.

What about the `uploads` folder?

In all of the patterns above you would not source control the uploads folder. Unless you're using a tool like VersionPress, this content is directly related to the contents of your database. This content is also ever changing via administrators so whenever new uploads are created your website and source control would be out of sync.

Where does WP Git Updater fit in?

WP GIT Updater is designed to make the first two patterns (source control everything, source control the wp-content folder) much easier to manage and maintain.

WP GIT Updater will automate branch and pull request creation for any updates available, from the WordPress plugins or themes repository.

It can automate this process via manual invocation, or via a schedule defined within a continuous integration environment (for example Github Actions).

What this means in practise is once in place, every day (or a schedule you define) you can take advantage of your CI system to reduce developer hours performing updates.

To "make an update" on a source controlled website the steps usually involved are:

Pull down the source
Review each plugin/theme for updates (either via a local environment, or manual searching)
Perform each update
Add the update files
Commit the changes
Push the changes to a branch
Create a pull request for review

These steps may take a seasoned developer only a few minutes for each update, but a website may have many updates, especially if the task is performed infrequently.

WP GIT Updater automates this process for you. What's more, each update branch and pull request will have consistent naming, version from and to details, and any author provided changelog added to the pull request for review, eliminating a low complexity but time consuming task.

My First Useful Tagged Template Literal

Lee Mason — Mon, 14 Dec 2020 21:43:47 +0000

Since their inclusion in Javascript tagged template literals have had developers on edge about possible use cases for them. There are the obvious ones. For me they seemed soo useful. Yet I found myself looking for a problem to solve, instead of it being obvious they were the right tool for the job.

Very recently i think i’ve happened upon a problem they solve elegantly.

So the background story is I am working on a large scale SPA project. This project interfaces with an api server. Nothing unusual there.

What is unusual is the id for a lot of these resources is actually user submitted text strings. They have to be unique, not include certain characters etc, but the key is “its user submitted text”. We had no option to change this (at least for now).

This creates what is at least for me an unusual situation. The api resource urls can contain certain “must be encoded” characters (spaces, commas, full stops, accents).

The Existing Solution

Another lead developer on the project created a solution i’ve seen before to construct the url, and escape the correct variables using indexed replacement from an array.

['/api/v1/{0}/{1}', varName, anotherVar]

This solution works and we have been using it successfully for a while now.

Alongside this a VueJs mixin was created which did some further magic to make replacements directly on a string using something similar to literal syntax: /api/v1/{varName}. Where varName could be accessed directly off the Vue instance.

The problem with these 2 methods are:

The array syntax feels awkward
Option 2 (the clearer option) can only be used inside a component instance, not for example in a store module
A limitation of option 2 is that it requires the “vars” used in the string be accessible on this
Option 2 caught a few members of the team out, thinking it was actually a string literal when they started to reuse from examples

The (possible) Tagged Template Literal Solution

So i had a bit of an idea, it takes the existing concept further and addresses some of the issues.

It does use a template literal with a tagged function
Its clearer than the array syntax
The vars can be anything you have access to, as its a literal any javascript inside placeholders ${} works.
It can be used from anywhere

Usage is very much the same as before (via the mixin), you just convert the string to a literal, prepend the tagged function url and you use real placeholder syntax ${}.

// Existing solution (result not implementation)
const existingWay = theUrlConstructor([
    '/api/v1/resource/{0}/{1}',
  'my string, with unsafe',
  'url +characters+'
])
// /api/v1/resource/my%20string%2C%20with%20unsafe/url%20%2Bcharacters%2B
// New solution
const url = (strings, ...values) => {
    return strings.reduce((compiled, string, index) => {
    return compiled.concat(string, encodeURIComponent(values[index] || ''))
  }, []).join('')
}
const first = 'my string, with unsafe'
const second = 'url +characters+'
const newWay = url`/api/v1/resource/${first}/${second}`
// /api/v1/resource/my%20string%2C%20with%20unsafe/url%20%2Bcharacters%2B

I’ve introduced this to the team, but haven’t yet had any real feedback, let me know what you think.

DEV Community: Lee Mason

WPDock - A Simple WordPress Development Environment Using Docker

Enter WPDock

Need to access WP-CLI?

Sharing Databases Between Team Members

Stopping Environment

Other Commands

Real Domains with Valid Local TLS/HTTPS Certificates

How does this work?

Feedback Welcome

And We're Live!

WP Git Updater – A Month In Review

The Projects

The Stats

How do we even know updates are required?

How does WP Git Updater compare?

Time Saved

How much time do we need to plan updates?

Time Saved

How much time does a developer need to perform the update?

Time Saved

How quickly can we get those updates to the testing team?

Time Saved

Totals

How often should we perform updates?

WP Git Updater allows us to provide a faster, ever improving experience for our clients. And this is the real value from the automated plugin and theme updates WP Git Updater provides.

Laravel Nova Resource Stubs For Spark Teams

Our Display Git Status plugin has just been approved on the WordPress.org plugin marketplace

WP Git Updater now supports theme updates

Laravel On Shared Hosting

The Redirect

The SEO Problem

The Solution

A look at WordPress source control strategies

What are the benefits

Existing tools

VersionPress

WP Pusher

WP Rollback

Common source control approaches

Source control everything

Source control the wp-content folder

Source control per plugin/theme

What about the uploads folder?

Where does WP Git Updater fit in?

My First Useful Tagged Template Literal

The Existing Solution

The (possible) Tagged Template Literal Solution

Need to access `WP-CLI`?

Source control the `wp-content` folder

What about the `uploads` folder?