Wordpress Websites
The good old days are now.
Wordpress sites are inherently PHP-based and almost always rely on a mySQL database, although other databases are optional if you want to bark up a different tree. Apache on Linux is the mainstream hosting choice, due to cost and availability as well as PHP's relatively tight integration with Apache.
These basics of the LAMP stack and running Wordpress on it are covered widely online, so the information below pertains only to our particular approach to implementing these sites.
Architecture
One of the unique challenges with Wordpress is that CMS users have the ability to modify not only the database but also the filesystem—and these changes can result in system file changes, too, in the event of plug-ins being installed, etc.
In general, we discourage giving clients the ability to install plug-ins themselves (see Security below) and encourage that these are installed on staging and then deployed via Continuous Integration once tested.
However, as plug-ins live "across" both the database and the codebase, settings may need to be manually re-instated on live—running database migrations for these would be overly complex given how un-semantically they are stored in the database.
Standard
SPA/React-based
JSON API
Hosting
As with other Project Platforms such as those leveraging Heroku or Vercel we try to put forward a single hosting provider to use for all clients and projects. This means that we can build tools and process around a standard set-up and don't waste time configuring idiosyncratic options. A control panel with good usability and a responsive support team are some of the most important factors in choosing a standard host, and are much more important than price given the low cost LAMP hosting.
To date, Media Temple has been the preferred provider, however since their acquisition by GoDaddy development of their control panel has stalled and their support isn't as good. Decent alternatives are likely to be Digital Ocean or BinaryLane but the decision to migrate is still pending.
DNS
Cloudflare is recommended wherever possible, however larger organisations may self-manage.
E-mail
Most hosting services come with e-mail, but we steer well clear of having much to do with managing this on clients' behalf. If it's a new domain, we recommend looking at GSuite which opens up some good opportunities for collaboration (with us) and makes Analytics set-up a bit easier. It also offloads any responsibility for managing e-mail from us to Google.
Databases
Tools
The de facto tool for database management in LAMP-world is the web-based phpMyAdmin which often comes pre-installed with hosting packages, accessible at a URL similar to the one below:
https://s199223.gridserver.com/.tools/phpMyAdmin/The advantage with the above is that connections from the tool originate from the (known) server itself, simplifying security.
There's nothing stopping you from using your favourite database admin tool instead, but you may have to use an external hostname to connect and whitelist your IP in the hosting control panel.
Migrating
Working with Wordpress sites often means moving databases between environments, such as local, staging and production. Unfortunately, Wordpress stores absolute references to the site URL in the database, and these need to be manually updated when the URL changes. This is best done by simply exporting the database as SQL, doing a search/replace for the URL and then re-importing to the target.
Todo
Content
Content refers to anything that's not tracked in the repository and/or deployment configuration files.
On the filesystem, 99.9% of CMS-supplied content lives in the wp-content/uploads folder and this can usually be relied upon for migration between environments, and back-ups.
The rest of the content lives in the database.
Deployments
https://picket.deployhq.com/projects/
Managing Credentials
Testing
Back-ups
Plug-ins
Updates
Security
As a rule, we always protect the staging site with a simple username and password so that it's only visible to us and clients, and importantly it can't be consumed by bots and crawlers. This can be done via an .htaccess directive in the site root but this isn't recommended as its easily corruptible during a deployment and prone to human error.
The best way to do this is via the hosting control panel, as per the example below for Media Temple, by setting access control on the parent of the webroot. This prevents the .htaccess file being accidentally overwritten during deployments or config changes.
Maintenance
Staging Site Refresh
As with other apps and sites it's important that the staging environment is regularly refreshed with data and content from production .
This can be a somewhat manual task, however generally developers will (should) have implemented a few scripts in the repository to make this task simpler.
Todo
Last updated
Was this helpful?