Reverting WordPress back a version via Ansible/Trellis

trellis
1

I’m trying to figure out how to role back our versions of WordPress using ansible. The latest version of wp 4.6 has broken a few modules (specifically anything using the WP_HTTP class).

We’ve exhausted all possible solitions and we’d like to revert back to the last stable version we had before updating to 4.6.

Thanks for reading

Cheers

2

We’ve exhausted all possible solitions

Specifically what did you try?

3

Don’t you just have to set the version of WP you want in the Composer file, and deploy?

1 Like
4

I don’t see anything in my composer.json file that indiates a wordpress version. We were updating WP via the Admin.

5

Good question, I should have included more information.

We updated WordPress to 4.6 and that broke our integration with an internal api we have.

That integration, written by a third party agency, uses the WP_HTTP class to make “ajax” calls. We believe this broke when we updated a few weeks ago. That module is timing out and we can’t figure out where.

  • checked plugins that could override the timeout setting
  • did a curl on our server to be sure WordPress was the blocker and not the api
  • checked filters for overrides
  • checked for competing processes on the server that could be causing a timeout or delay
  • var_dump’d every possible call our custom module is making to see what the timeouts are

Something in WordPress is caching or overriding the API calls and we can’t seem to figure out what. I even had the original developer on a call to help but we ran out of time. He broke up with us.

After some deliberation, the solution was to “simply” revert back to a previous version of WordPress when the API was functioning properly.

I’m currently looking through Varnish and Memcache.

6

If you’re using Trellis with Bedrock you can change the WordPress version in /site/composer.json where it includes WordPress as a dependency

I hate to say I told you so but Bedrock ships with DISALLOW_FILE_MODS enabled by default to encourage you to test WordPress updates locally before committing the change to the repo and deploying it to production.

(I’m a bit late, it looks like you’ve already rolled WordPress back but I’m posting this for future readers)

2 Likes
7

Haven’t reverted back yet. I’m reviewing all my options in Bedrock and Trellis first.

The DISALLOW_FILE_MODS is interesting and will help going forward. I’ll keep this in mind.

8

I’ve just tried this but nothing happened.

My site is on 4.6. The composer.json says “4.4” (because updates were done via the “Please Update Now!” button in the Admin…which is now disabled thanks to @paul_tibbetts )

I changed it to:

“johnpbloch/wordpress”: “4.5.3”.

Deleted composer.lock file.
Ran composer update and composer install

The site WP version didn’t change. I know I’m missing something.

9
  1. Have you committed the new composer.json and composer.lock files to git, pushed to the remote and then run ./deploy.sh production sitename.com ?

The deploy script uses the values in the lock file (on the production server) to pull the dependencies in.

  1. Is the line in composer.json now
    "johnpbloch/wordpress": "4.5.3",
    or
    "johnpbloch/wordpress": "^4.5.3", ?

It needs to be the first one where you explicitly require 4.5.3, if it’s ^4.5.3 then that means at least this version (which means 4.6 won’t downgrade to 4.5.3)

If you load up Vagrant and run composer update (from the /site folder on the Vagrant box) you should get:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing johnpbloch/wordpress (4.6)
  - Installing johnpbloch/wordpress (4.5.3)
    Loading from cache
3 Likes
10

@paul_tibbetts I just did exactly what you suggested and it worked. Not sure what I was doing differently originally but hey it works.

Thanks for you help.

1 Like