> For the complete documentation index, see [llms.txt](https://manual.picketstudio.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://manual.picketstudio.com/technology/project-platforms/wordpress-websites.md).
# Wordpress Websites
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](https://www.ibm.com/cloud/learn/lamp-stack-explained) and [running Wordpress on it](https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-lamp-on-ubuntu-18-04) 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](/technology/project-platforms/wordpress-websites.md#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](/technology/project-platforms.md) such as those leveraging [Heroku](https://heroku.com/) or [Vercel](https://vercel.com/) 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](https://ac.mediatemple.net/home.mt) 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](https://www.digitalocean.com/) or [BinaryLane](https://www.binarylane.com.au/) but the decision to migrate is still pending.
### DNS
[Cloudflare](https://dash.cloudflare.com/) 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](https://gsuite.google.com/intl/en_au/) 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](https://www.phpmyadmin.net/) 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
* [x] Tools
* [x] Migrating databases
* [ ] Backing up databases
## 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
## 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
* [ ] Wordpress updates
* [ ] JS package updates
* [ ] User prunes
* [ ] GI tests
* [ ] Backup tests
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://manual.picketstudio.com/technology/project-platforms/wordpress-websites.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.