I am working on updating our PB instance to 4.5 (from 3.9.9). All seems to be going well, but we are cautious given that there are a lot of potentially breaking changes, so we’ve been slow to adopt. That said, we’ve got things set up, we’ve made changes to our plugins that hook into PB at various places, and it seems to be working on local and in our sandbox.
Our greatest concern is if there is something we overlooked or the update breaks some/most/all of our books in production, we would want to rollback to the previous state. What I’m running into though, is when I do the rollback, all of the catalog pages become inaccessible. I get a “Sorry, but this page does not exist” page. The rollback also seems to break the theme on all of our books.
Aside from doing a database backup/restore, can you think of other possible simpler/less time-consuming solutions?
Just to clarify, by catalog pages you mean the pages at /catalog/username/? We made some changes to allow a page at the network root with the bare /catalog/ URL. You should be able to flush the rewrite rules for the catalog following rollback. In order to do so, you’d need to delete the following options from the root site (see #905, #939, #953):
pressbooks_flushed_catalog
pressbooks_flushed_catalog_V2
pressbooks_flushed_catalog_V3
pressbooks_flushed_catalog_V4
You can also force a flush by adding this line to your wp-config.php (ref):
$_GLOBALS['PB_SECRET_SAUCE']['FORCE_FLUSH'] = 1;
And, for themes—which themes are the affected books using? The 3.9.9 → 4.x update moves core themes out of the plugin and changes some theme slugs in the process so that is a harder one to undo, but you could probably script it with wp-cli (ref):
wp site list --field=url | xargs -n1 -I % sh -c 'if wp --url=% option get stylesheet | grep "pressbooks-clarke" > /dev/null; then wp --url=% theme activate clarke; fi'
The above pipes each book URL to another wp-cli command which checks to see if the theme is set to pressbooks-clarke (standalone theme, Pressbooks >= 4.x) and if so, switches it to clarke (bundled theme, Pressbooks < 4.0). See here for the themes for which you’d need to perform this operation.
Before you do this you might need to run:
wp theme list
This should refresh the list of themes in their new (old) locations.
EDIT: Added force flush instructions and theme list refresh note.
Hey @ned. Chiming in to let you know that the suggestions didn’t work.
For the catalog, I first attempted to use the globals variable in the wp-config.php. When nothing appeared to be different, I went into the database and removed the pressbooks_flushed_catalog* options from the root site. This also still yielded a “page not found.”
For the themes, I still have some things to test here. I was unable to get wp cli to behave (that’s probably me not having it properly configured). I did try going into the database on one of the books to reset the data in wp_*_options, on the option_name values (template, stylesheet, template_root, stylesheet_root, and current_theme), but that also didn’t work on that book.
I’m going to try spinning up a new instance of our current 3.9.9 dev environment, apply all the updates, then try rolling back again to 3.9.9, only this time keeping our the themes in the wp-content/themes directory to see what happens.
Though, after I flushed the rewrite rules by visiting pressbooks/wp-admin/options-permalink.php and clicking Save, per @ned’s instructions to @SteelWagstaff, It changed to this:
Also! I discovered that the themes were broken in large part due to Redis caching. All I had to do was flushall and the correct themes / styling were loaded. For some reason, your rewrite flush recommendations reminded me of that.
So, I think this assuages our biggest problem areas for rollback planning. I’ll do more testing and come back here if I run into anything else. Thank you so much @dac.chartrand and @ned for your help. Cheers!
One other note, @bryan: we just tagged 4.5.1, which is a forward-compatibility release for Pressbooks 5. I need to put out a blog post about it today. I’d suggest expanding your testing to 4.5.1, because that will make your network forwards-compatible with Pressbooks 5 when it comes out (targetting February 14th ).
Turns out I was a bit hasty to say that Redis was more or less responsible for the themes breaking on rollback. I’ve identified a 3 step process we’d have to do manually for each book:
Navigate to the “Appearance” menu of a book (it’ll say “theme is broken, reverting to default”)
Refresh page and then reset to the theme we want
Go to a page in the book and do a hard browser refresh
I’m working on automating these steps with a bash script and a few wp-cli commands. Under ordinary hosting situations, what I’ve come up with would work great, but we’re on a solution that makes automating this a bit more tricky.
Anyway, I thought I’d add this comment for later reference in case someone comes around and reads the Redis solution posted earlier, tries it, and finds that it doesn’t work for them. Cheers!
).