Feature description

We currently have multiple code paths that deal with transforming the content for the different modes. In the future, we plan to add REST API requests, optimized AMP and more that will also need to be accommodated. With the current design, this would probably mean copy-pasting and adapting large parts of the code for each use case, making extension and long-term maintenance difficult and costly.

I suggest refactoring the content transformation conceptually into a middleware stack. This would allow easy reuse of code paths while making them extensible to address each use case as needed.

The model can be similar to what most modern frameworks use right now for their HTTP stack, only that it would start slightly later in the process. So where a traditional HTTP stack starts with an HTTP request and has as an end-result an HTTP response, we would also target the HTTP response as the end result but start after the initial WordPress processing of the HTTP request.

The middleware concept allows all the different behaviors we need to account for to be cleanly separated from each other and the main use case to be a matter of assembling the correct stack. It is a flexible pipeline that takes us from input to output in a structured way.

Here's a (very improvised and probably incorrect) example of how such a middleware stack would be constructed:

$amp_stack = new AMP_Stack(
	new AMP_Error_Logger(),
	new AMP_Dev_Mode(),
	new AMP_Reader_Mode_Theme_Switcher(),
	new AMP_Content_Sanitizer(),
	new AMP_Optimizer(),
	new AMP_Internal_Cache(),
);

$output = $amp_stack->process( $input );

If we need different modes, we encode them as one or more steps to add to the middleware (no duplication required).

If we need conditional behavior, we encode them as one or more steps to add to the middleware (no wading through lots of places in the code to find the correct injection point).

If we need cross-cutting concerns like caching or logging, we encode them as one or more steps to add to the middleware (no obfuscation of the actual logic by these cross-cutting concerns).

Everything adheres to the same structure, and it becomes obvious where to look for which part of the logic.

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Implementation brief

QA testing instructions

Demo

Changelog entry