Upgrade a deprecated AWS Elastic Beanstalk environment in place using the CLI

When a major PHP version change (eg. 5.7 to 7.0, or 7.0 to 8.0) occurs, Amazon AWS Elastic Beanstalk typically does not allow for automated platform version updates but instead requires the cloning of an interface and a CNAME switch. For less available environments, use the following steps to upgrade-in-place using the AWS command line interface:

  1. Take a look at the list of currently supported PHP platforms on Elastic Beanstalk; you’ll want to decide which Solution Stack Name (eg. “64bit Amazon Linux 2 v3.4.1 running PHP 8.1”) corresponds to the platform you wish to upgrade to.
  2. In the Elastic Beanstalk web configuration page, get the environment ID for the environment you wish to upgrade (eg. “e-jwfjvy57r3”).
  3. Run the aws command to upgrade the environment in place:
    aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2 v3.4.1 running PHP 8.1" --environment-id "e-2iuwivbgzc" --region "ca-central-1"


Controlling the PHP error reporting level of WordPress

One of the annoyances of working with WordPress I’ve had for ages is trying to use the error_reporting() function to do something like temporarily turn off deprecation warnings; WordPress ignores these settings entirely.

Turns out the cause of this is the wp_debug_mode() function, which gets called by wp-settings.php and sets error_reporting(E_ALL). As a result, putting your own call to the error_reporting() function in wp-config.php won’t have any effect; you need to place your call after wp_debug_mode() runs. One smart solution is to create a very simple mu-plugin for this purpose.

Of course, it goes without saying that ignoring errors and warnings is done at your own risk.

Making scheduled posts in WordPress public so they can be scheduled / scraped on social media

The basics of scheduling in WordPress are quite simple: If you give a WordPress post a published date set in the future, it’ll remain “hidden” on your website until that date and time arrives. It’ll then appear, right on time, at the top of your list of public posts.

But here’s an interesting problem: Social media is now a major driver (maybe the driver) of traffic to digital media websites. When you schedule your post in WordPress, you’ll also naturally want to schedule that post to appear on Facebook and Twitter – but that would require the WordPress post to be public, which in its “future” post status isn’t yet.

The code snippet below can be placed in your theme’s functions.php file, and allows non-logged-in website visitors to view posts in the “future” post status as well as merely “publish”ed posts.

// Allow site visitors (people not logged in to WordPress) to view posts in the "future" post status.
function show_future_posts_pre_get_posts($query) {
    if ( is_single() && !is_admin() && $query->is_main_query() ) { 
        if ( !is_user_logged_in() ) {
            $query->set("post_status", array("publish", "future")); 
add_filter('pre_get_posts', 'show_future_posts_pre_get_posts');