# <img alt="Airplane" src="images/wpforge-icon-orig-c1-sm.jpg" style="vertical-align: middle;"/> `wpforge`
## Motivation
As webmaster of a WordPress website for a non-profit organization qualifying for a "free"
hosting account that does not provide or support its own "Staging" environment, I find it
stressful when making changes directly to the site, since any of them could potentially
cause an outage.
Also, not having prior WordPress expertise, I would like to be able to experiment with
new features and "practice" recommended maintenance procedures prior to their introduction
into the production system, thereby increasing my confidence in these proposed changes and
reducing the risk of an outage when they are applied.
## Approach
Since I am familiar with software development workflows involving a local replica of a
production system using Docker containers, I thought such a workflow might be similarly
valuable to my role as webmaster as described above.
## Goal
Establish a local dockerized "clone" of the organization's WordPress website which already
uses the [Duplicator](https://wordpress.org/plugins/duplicator/) plugin as its backup
strategy as part of a change workflow to mitigate risk and facilitate experimentation.
Proposed changes to the website can then be applied to the local clone within
the expendable Docker container for "practice runs" or "what-if" experiments
without incurring any risk to the production website.
## Workflow
Using the steps below, a Docker container is created (or updated) to run a copy of the
production website, and in which proposed changes can subsequently be made in a completely
separate environment, without incurring risk to the original production website.
See [this tutorial](https://duplicator.com/knowledge-base/classic-install/) for additional
context relevant to the use of "Duplicator" in creating a copy of a WordPress website.
1. From within the production website's `Duplicator` plugin administrator page, create and
download a "Duplicator Package" containing a complete export of the website.
- E.g., download & store the package files within a `backups` sub-folder
2. Copy the files comprising the "Duplicator Package" into an _empty_ `docker/volumes/wordpress`
folder; e.g.:
- `$ mkdir docker/volumes/wordpress || rm -r docker/volumes/wordpress/*`
- `$ (cd backups/230806-duplicator; cp installer.php *_archive.zip ../../docker/volumes/wordpress)`
3. Bring up the local "clone" website by starting the Docker containers; e.g.
- `$ (cd docker; docker-compose up)`
4. After giving enough time for the "Duplicator installer" application to initialize,
navigate to it at [http://localhost:8080/installer.php](http://localhost:8080/installer.php)
in order to install the exported website into the running WordPress container by following
and answering its prompts, as suggested:
- In `Step: Deployment; Section: Setup; Tab: Database` supply the following values:
- Action: `Empty Database`
- Host: `db` (see: `docker-compose.yml:WORDPRESS_DB_HOST`)
- Database: `wordpress` (see: `docker-compose.yml:MYSQL_DATABASE`)
- User: `wordpress` (see: `docker-compose.yml:WORDPRESS_DB_USER`)
- Password: `wordpress` (see: `docker-compose.yml:WORDPRESS_DB_PASSWORD`)
- Proceed to `Validate`, accept the terms, then `Next` to the next step...
- `Step: Test Site`
- Complete the process by pressing on the button to navigate to the
[Admin Login](http://localhost:8080/wp-admin/admin.php)
page, and ... wait until you see the login dialog.
- Log in as the administrator user (i.e., the usual credential should work).
Allow some time to complete and give confirmation / result summary of the
site migration.
- Confirm Independence from Production Website
- At least initially, consider confirming proper operation of the new website in
a completely "local" operating mode (i.e., after dropping your connection to the
internet / production system) in order to gain confidence that making changes
in this system will not have any effect on the production system.
Once the above is complete:
- The `docker/volumes/wordpress` folder contains the activated replica of the production
site's filesystem
- The database managed by the `db` container contains the activated replica of the production
site's database
These resources should not be modified other than by the running container, or cleared manually
in preparation for a subsequent update / installation, as described above.
Now the set of running Docker containers can be used as a sort of "staging" environment,
accessed via the URL [http://localhost:8080](http://localhost:8080), and should behave
similarly to the production environment in response to changes.
## Notes
I've noticed response time for pretty much all operations within the dockerized instance
is _very_ slow - at least 20 seconds or so for every click or operation!
As of late August 2023, after hours spent trying to discover a more precise source of the
slowness, the best solution in hand is to completely disable the "Wordfence" plugin. Doing
so brings the response time down to about 3 seconds for most operations.
## Project Name
I used ChatGPT to help come up with the name for this project. For posterity, I'm including
its summary of how the name fits and why it was chosen:
> "wpforge" is a great choice for your project name. It evokes a sense of craftsmanship and
> creation around WordPress, which aligns well with the essence of your project. The name
> suggests the idea of forging or shaping WordPress resources in a controlled environment,
> which aligns with your goal of creating a safe and controlled space for experimentation
> and changes.
>
> Additionally, "wpforge" subtly hints at the idea of using Docker containers to forge or
> shape the WordPress environment, which resonates with your approach of utilizing Docker
> to create a controlled staging environment.
>
> Overall, "wpforge" effectively captures the core aspects of your project: creating,
> crafting, and shaping a controlled WordPress environment for safe experimentation and changes.