Using EFS with Wordpress - Unexpected behavior in 2025

[jdevinemt]

Issue

During this demo lesson, once the first wordpress stack is deleted and the second is created, going to the IP of the new (wordpress 2) EC2 instance loads extremely slow. The displayed page's links, assets and images still reference the IP address of the initial (wordpress 1) EC2 instance.

How to Reproduce

Follow the lesson instructions as of 2025.

Possible Cause

It seems like wordpress may be caching pages, or at least the link, asset and image paths. I'm not very familiar with wordpress, but I'm assuming this may be a feature introduced or enabled by default after this lesson was recorded.
Update: This is not the cause.

Possible Solution

Disable the WP_CACHE option in /var/www/html/wp-config.php. Again, I am not familiar with wordpress, but this seems like the most likely solution.
Update: This is not the solution.

[jdevinemt]

I decided to not be lazy and test out my proposed solution. It did not work. I don't think there is any caching going on with the default installation.

Maybe it has to do with how objects are stored in the database?

[jdevinemt]

I checked the database contents via the worpress 2 stack's EC2 instance. I do see that the content of the post is saved in the database with absolute URLs to the images. I'm not sure why they work in your demonstration in that case, because a google search indicates that WP has always used absolute urls in post content.

I'll leave a recommended solution or explanation to someone more familiar with WP.

If this is an issue due to a change in a change to wordpress, perhaps the user data can be updated to install a specific version of wordpress that is compatible with this demo.

[jdevinemt]

This seems to come from the hardcoded WPHOME value which is addressed in the following section. It would be nice to address in the video or description that the second instance might not work when accessed via HTTP.