This repository hosts the codebase for two sites, both
- are built using WordPress.org
- are deployed on Platform.sh in Multi-App setup
- have their codebase managed via Composer, thanks to
johnpbloch/wordpressand WordPress Packagist - have their dependencies automatically upgraded by Dependabot
- have their Dependabot PRs automatically merged by Mergify when builds pass
- have new code deployed to production automatically on every PR merge
- use Redis as back-end caching
- use Cloudflare as CDN
- use GitHub Actions as CI/CD and Cron Scheduler
In addition to the above:
- the
itasite uses Elasticsearch - the
engsite uses Algolia
WordPress remains by far the CMS that is easiest to adopt, and that provides a fast time to market in the majority of use cases. There is so much high quality stuff out there for WordPress, be it OSS or Premium, that one can have beautiful sites powered by an easy-to-use CMS up and running in no time.
Platform.sh provide an incredibly flexible and powerful PaaS. As they like to call it, it is the Idea-to-Cloud PaaS. With a GitHub integration, you can have a child environment cloned from your a parent environment (the root of the tree is usually the production environment) for each pull request, and a Status Check that runs a build on Platform.sh out of the new branch, so to verify that the changes do not break anything. Upon merging a PR, the code is deployed straight to the parent environment.
Feel free to poke around the Platform.sh configuration files in this repo to see how the sites were set up with a multi-container deployment comprising of various services.
Now part of the GitHub family, it provides a free plan for public repositories, and it supports PHP+Composer. You can configure it to decide what kind of upgrades you want to perform on your dependencies, and the bot will issue pull requests periodically, avoiding stale dependencies.
This service, too, provides a free plan for public repositories. You can configure it with a number of conditions that, when met, will trigger an automatic merge of your pull requests.
Redis is an open source, in-memory data structure store, that here I use as a back-end cache system via the Redis Object Cache plugin. It is easy to adopt with Platform.sh, as it is one of the many containeresed services that you can add to your project.
Cloudflare is one of the CDNs best supported by Platform.sh; it is also one that provides a good free plan. When you combine that with the awesome plugin WP Cloudflare Super Page Cache, choosing Cloudflare for your personal sites becomes really a no-brainer.
One of the sites is not in English and uses translation files for WordPress core, themes, and plugins for an optimal setup. WordPress Packagist does not currently provide such files, but—–thankfully–—the OSS community never rests, and inpsyde/wp-translation-downloader is a great Composer plugin to manage WordPress translations.
It seemed like the obvious choice. Currently no particular CI/CD task is implemented, as Platform.sh provide their own built-in CI/CD for builds and deployments. Moreover, I do not require particular testing at present, so I am not using Actions for that either. However, I am using it as Cron Scheduler, to perform regular tasks on my Platform.sh project.
Although Platform.sh allow you to do that by defining Cron Jobs on their own platform, I chose to have this functionality decoupled from Platform.sh.
Elasticsearch is a distributed, RESTful search and analytics engine that centrally stores your data for lightning fast search, fine‑tuned relevancy, and powerful analytics that scale with ease. Platform.sh allows a very easy adoption of the service. ElasticPress provides a seamless integration with WordPress.
Algolia is a commercial service similar to ElasticSearch or Solr, but that claims to be up to 200x faster than Elasticsearch. There is a free plan that is definitely suitable for small sites. Algolia no longer maintains an official WordPress plugin but their former official plugin was forked and it is now known as WP Search with Algolia. It is actively maintained and works well as far as we have been able to ascertain.
"Distros" or "install profiles" are essentially a way to have your own default installation configuration. Whilst some softwares have built-in support for that, WordPress does not. Our rudimentary support for this in WordPress relies on two things: a bespoke section in the composer.json file and a script that uses the information in that section to perform some initial setup. The script is then executed as part of the deploy hook in Platform.sh. If you are wondering why we didn't simply use the scripts.postbuild section in composer.json to run such a script, the reason is that during the build phase in Platform.sh (when composer is run) the database service is not yet available.
You may know that Jetpack can suffer from identity crisis. This template is configured so that non-production environments on Platform.sh automatically adopt Offline Mode, thus averting the identity crisis. It would've been preferable to use Staging Mode instead of Offline Mode, but it turns out—after a long chat with WordPress support—that just adding define( 'JETPACK_STAGING_MODE', true ); to wp-config.php for a site that already has an active production connection to Jetpack doesn't actually put that site in Safe Mode automatically as described, but still causes the identity crisis.