Hi @trent.greenwood, let me give a bit of context of the changes.
Currently it was not possible to customize the WordPress Production Ready console. If you launched the AMI you would not be able to add things such as custom Apache configuration, PHP configuration, etc., as the configuration was not ready or it would be overwritten afterwards.
With the new changes that were implemented in 5.2.1-2, users will be able to customize Apache and PHP configuration files since the boot. Also, in this release configuration files are regenerated at each new re-deployment, meaning they won't be persisted at
/bitnami. The reasoning is that configuration files may change once there is a major change to Apache or PHP, and users should be aware of that.
As for your issues, I'm a bit confused by what you have mentioned in your previous posts. How did you launch WordPress Production Ready 5.2.1-2 or later? I'm mentioning this since it has not yet been published (the latest release is 5.2.0-3), although it should appear soon.
If you upgraded WordPress Production Ready from 5.1 to 5.2 by updating the CloudFormation template (following this guide), the
/bitnami configuration should still be used in the new 5.2 template (from
/bitnami). However, if you launch the 5.2 template from scratch, it will not persist across runs. The reasoning of this is to allow a transition period.
1) How would you go about applying group-wide (not instance-specific) environment variables? I could amend the launch configuration to add some userdata to each instance launch, but this is not as elegant a solution for configuration parameters.
We recommend to use launch configuration for this, or services such as Stacksmith for applying the customizations automatically.
In order to create the automated launch script, you can launch the AMI manually with the following Bash script as launch configuration:
Then apply the changes and store any commands you used in the new launch configuration (without SKIP_FIRST_BOOT, which avoids running the initialization scripts).
The good thing is you can manually start Apache and PHP-FPM to test your configuration, to ensure it is correct, as the configuration you include will be exactly the same as what gets deployed (which was not the case before).
2) Is there any documentation or decision log on why the change was made to relocate the PHP and Apache config files from the central location (/bitnami) to the actual instance code (/opt/bitnami)? I'd like to understand the rationale and this is quite a bit change to the approach.
We have explained the rationale above. As for documentation, we have an internal task in our backlog to create a guide on how to customizing the WordPress Production Ready template for docs.bitnami.com, which will basically explain what I described above with more details. However, it has still not been completed. I will check the task to ensure it gets started the sooner possible.
Please let us know if you have any questions.