Metadata-Version: 2.1
Name: cdk-static-wordpress
Version: 0.1.18
Summary: Generate a static site from Wordpress (via WP2Static) using AWS CDK
Home-page: https://github.com/blimmer/cdk-static-wordpress.git
Author: Ben Limmer<hello@benlimmer.com>
License: Apache-2.0
Project-URL: Source, https://github.com/blimmer/cdk-static-wordpress.git
Classifier: Intended Audience :: Developers
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: JavaScript
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Programming Language :: Python :: 3.8
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Typing :: Typed
Classifier: Development Status :: 7 - Inactive
Classifier: License :: OSI Approved
Requires-Python: ~=3.8
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: aws-cdk-lib <3.0.0,>=2.59.0
Requires-Dist: constructs <11.0.0,>=10.0.5
Requires-Dist: jsii <2.0.0,>=1.98.0
Requires-Dist: publication >=0.0.3
Requires-Dist: typeguard ~=2.13.3

# CDK Static Wordpress

The goal of this project is to make it easy to deploy a static website, generated by [Wordpress](https://wordpress.org/)
as simple and cost-effective as possible.

It's largely inspired by
[TechToSpeech/terraform-aws-serverless-static-wordpress](https://github.com/TechToSpeech/terraform-aws-serverless-static-wordpress/),
but uses [AWS CDK](https://aws.amazon.com/cdk/) instead of Terraform.

It creates the infrastructure to launch a temporary, transient Wordpress container. You then log in and customize it
like any Wordpress site, and finally publish it as a static site fronted by a global CloudFront CDN and S3 Origin. When
you’re done you shut down the Wordpress container and it costs you almost nothing.

[WP2Static](https://wp2static.com/) is used to generate the static site from the Wordpress container.

## Project Status

⚠️ This project is archived and no longer being maintained. ⚠️

This was a fun side project, but recent external changes have made it challenging to run Wordpress in a cost-efficient
manner.

1. The [deprecation of AWS RDS Serverless v1](https://www.infoq.com/news/2024/01/aurora-serverless-v1-retirement/) means
   that AWS no longer offers a managed MySQL database instance that can scale to 0 when not in use. I
   [considered a few ideas](https://github.com/blimmer/cdk-static-wordpress/issues/32) to work around this, but
   ultimately I decided that the workarounds wouldn't match my personal use case.
2. [WP2Static](https://wp2static.com/) is quite slow, and [many issues](https://github.com/elementor/wp2static) go
   unaddressed. It seems like they're actively pushing their hosted / paid solution, which is fine, but it means that
   the OSS version doesn't receive much attention.
3. I couldn't find a good solution to store images and other media files in a cost-effective manner. Wordpress stores
   uploads in EFS, which is quite expensive for this use case. My primary use case was to host a travel blog with lots
   of high-quality images, so this was a significant cost factor for me.
4. Wordpress is a pain, in general. It's really a beast to maintain. I broke the docker image several times trying to
   keep the PHP / Apache dependencies up-to-date. I'm not a Wordpress expert, so I found it challenging to debug.

For these reasons, I've decided to no longer maintain this package. If anyone would like to pick up the torch and
continue maintaining this project, please feel free to fork it!

### Alternatives

* If you like the idea of this package, you could keep an eye on
  [TechToSpeech/terraform-aws-serverless-static-wordpress](https://github.com/TechToSpeech/terraform-aws-serverless-static-wordpress/).
  That project was the original inspiration for this CDK rewrite. However, that repository still uses Aurora Serverless
  V1 and hasn't received much attention lately (at time of writing - May 2024, it hasn't been updated in > 2 years).
* Consider a tool designed specifically for static site generation. For me, I migrated my project to use
  [Astro](https://astro.build). I used
  [lonekorean/wordpress-export-to-markdown](https://github.com/lonekorean/wordpress-export-to-markdown) to export my
  content from Wordpress to Markdown, and then I manually copied the exported files into my Astro project. It required a
  bit of manual translation, but it worked great for my use case. Astro is very fast compared to WP2Static (for my use
  case > 100x faster) and is designed for this use case. You can also use Astro with
  [many other CMS tools](https://docs.astro.build/en/guides/cms/) if you don't want to write Markdown.
* I've been keeping my eyes on [Webiny](https://www.webiny.com/), a truly serverless CMS tool. This didn't quite work
  for my use case, but it might work for you.

### Decommissioning your Stack

If you'd like to take a final backup, you can use a tool like
[Updraft Plus](https://wordpress.org/plugins/updraftplus/). This will create a portable backup you can use to restore
your Wordpress instance somewhere else (e.g., [Lightsail](https://aws.amazon.com/lightsail/projects/wordpress/), a
hosted Wordpress provider, etc.).

Then, destroy the resources created CDK Static Wordpress by running `cdk destroy`. This will remove all the resources
associated with the project.

## Quick Start

1. Install the construct:

   ```bash
   yarn add @blimmer/cdk-static-wordpress

   # or

   npm i --save @blimmer/cdk-static-wordpress
   ```
2. Instantiate a `StaticWordpress` instance a `Stack`:

   ```python
   import { StaticWordpress } from "@blimmer/cdk-static-wordpress";
   import { Stack, StackProps } from "aws-cdk-lib";
   import { HostedZone } from "aws-cdk-lib/aws-route53";
   import { Construct } from "constructs";

   export class StaticWordpressStack extends Stack {
     constructor(scope: Construct, id: string, props?: StackProps) {
       super(scope, id, props);

       // You can create or import a hosted zone
       // See https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_route53.HostedZone.html
       const exampleHostedZone = new HostedZone(this, "ExampleHostedZone", {
         zoneName: "example.com",
       });
       new StaticWordpress(this, "StaticWordpress", {
         fullyQualifiedSiteName: "blog.example.com",
         hostedZone: exampleHostedZone,
         wordpressAdminProps: {
           email: "me@example.com",
         },
       });
     }
   }
   ```
3. Deploy with the [`cdk deploy` command](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy)
4. Once the deployment completes, visit the Wordpress console at `admin-<fullyQualifiedSiteName>`. E.g., if your static
   site is `blog.example.com`, visit `admin-blog.example.com/wp-admin`. The default password for the wordpress user is
   `changeme` (please change it :smile:).
5. Customize Wordpress as you see fit, create posts, etc.
6. When you're ready to deploy your static site, trigger WP2Static.

   ![](https://github.com/blimmer/cdk-static-wordpress/assets/630449/598ecdd4-ffb6-4381-bd0e-50564622f3c3)
7. Visit your static site (e.g., `blog.example.com`) once WP2Static completes.
8. (optional) Shut down the Wordpress container to save money.

   ```python
   new StaticWordpress(this, "StaticWordpress", {
     fullyQualifiedSiteName: "blog.example.com",
     hostedZone: exampleHostedZone,
     wordpressAdminProps: {
       email: "me@example.com",
       run: false, // <-- Shut down the container after deployment
     },
   });
   ```

## Architecture

TODO

## Escape Hatches

This construct provides escape hatches, to allow you to customize the underlying infrastructure if you need to. This is
a big benefit of using CDK over Terraform (where every customizable property must be manually exposed as a variable).

Look for `*Overrides` in [the API docs](/API.md) for customization options. But, be warned, we allow overriding almost
everything, so you can easily produce invalid infrastructure if you don't know what you're doing.
