CUNY Academic Commons

I'm noticing a few other problems:

1. No "edit" link on pages (e.g., at https://khatchad.commons.gc.cuny.edu/).
2. Editing a page (through the admin console) seems to work, but I get the following error message:

Update failed.

Hey Raymond. Thanks for getting back to me so quickly. I'll look into this further later, but I really haven't added a new content. I was removing an extra space on my front page when I saw the edit failure message.

Well, I just duplicated a page, didn't make any content changes to it, and am getting the error message on an autosave. So, this must be a regression and not some funny characters as part of the page's body.

Now, when trying to publish the duplicated page, I'm getting an error that "publishing failed." But, actually, it succeeds.

Just duplicated and published another page. This one succeeded with no error message.

Raffi, if you continue to experience the issue with confusing error messages, it would be helpful if you could provide a bit more debugging info:

1. The URL of the specific page that you have created/edited, so that we can look to see whether there's something specific about that item that's triggering the problem
2. Screenshots of the error messages
3. If possible, it would be extremely helpful to see if there are errors in your browser's console (F12) or, even more specifically, under the 'Fetch' or 'XHR' filter of your developer tools' Network tab

Raymond Hoh wrote in #note-3:

wp-config file is forbidden to modify due to API hook: litespeed_wpconfig_readonly

Raffi, these caching messages can be ignored. We utilize the Litespeed Cache plugin to handle various caching aspects on the Commons. I'll see if we can limit this message to super administrators only, but this might be a little complicated to do due to the complexity of the plugin and whether there are ways we can short-circuit this.

I haven't seen these before, which makes me think it's related to the below error messages.

No "edit" link on pages (e.g., at https://khatchad.commons.gc.cuny.edu/).

Are you talking about an Edit link in the body of the page?

Yes.

If so, I also do not see such a link, but have you checked the "Edit Page" link in the WP Admin Bar?

Yes, that one works. But, what happened to the one at the bottom of the page? Was there an update recently?

I think this might be due to specific content you are using for your page.

As I mentioned in a previous message, I think that this is a regression because I only removed a blank space that I noticed.

Can you list the specific page(s) you are experiencing this problem on?

I am editing https://khatchad.commons.gc.cuny.edu/wp-admin/post.php?action=edit&post=63. I'm still getting the "updated failed" message, but this time on autosave. Now, when I save it manually, I still get the error, and the browser complains of unsaved changes when I close the tab. But, in fact, the changes are saved.

For example, some have had trouble with Jetpack and their footnotes feature: https://wordpress.com/forums/topic/how-to-fix-the-wordpress-updating-failed-and-publishing-failed-errors/

Sounds reasonable, but, unless there was a recent update, I would think I would have seen these errors before.

I did try editing the Subscribe page of your site to see if I could duplicate the problem and I did not experience any issues.

That one worked fine for me as well.

Another annoying thing here is that the browser complains that I have unsaved changes when closing a tab, but the changes do seem to be reflected when I open the "production" version of the page.

Like your previous issue, this can occur depending on the content you've added to the editor. Here are a few examples I found online:
1. https://wordpress.com/forums/topic/everytime-i-publish-a-post-and-i-navigate-away-it-says-you-have-unsaved-changes/
2. https://wordpress.com/forums/topic/page-not-saved-messages/

Interesting. But, I wonder why now I am experiencing this.

If you can provide some of the pages you are experiencing this issue with, we can hopefully try and provide some guidance.

http://khatchad.commons.gc.cuny.edu

Thanks for this, Raffi. You've mentioned a few times that this must be a regression. We performed regularly-scheduled plugin updates on Tuesday, Aug 26. It's quite possible that the changes here stem from those updates, and there's no need to make further arguments that this is a regression - no one is suggesting that it is not. However, it's not possible for us to roll the entire system back to its previous state just because of this inconvenient message.

The backtrack you provided is helpful, and it may point to the issue. It seems that there's an odd interaction between jetpack-boost and table-of-contents-plus. Specifically:
1. during a certain API request that is initiated by jetpack or jetpack-boost, the TOC Plus plugin fires a hook that generally is not fired during API requests (wp_enqueue_scripts).
2. Jetpack Boost, in turn, has some internal mechanisms that load certain libraries when either you're looking at a wp-admin page or when the current request is for an authenticated REST endpoint.
3. These latter libraries assume that the entire wp-admin apparatus and its related utilities will be available at runtime, but this is not the case during these REST requests. As such, the API request is triggering a fatal error

It seems likely to me that this fatal error is part of why you're seeing the unexpected error messages in the block editor.

You might argue that all three of my points above are "bugs", or at least not-best-practices. However, in this case, it seems that item 2 is probably the direct culprit: I can see in the changelogs that the 'is_authenticated_rest_request' flag was added in the version that was shipped with the August 26 Commons release.

If possible, perhaps you can help to confirm my hypothesis that this interaction is the cause of the behavior. You'd have to deactivate, if only temporarily, one of the two plugins, and then see whether the mysterious messages go away.

I don't think that our team has the resources to propose fixes for the upstream plugin(s), but if you confirm that my hunch is correct, we can at least report the bug to the Jetpack maintainers.

Thanks, Boone. Please see inline below:

Boone Gorges wrote in #note-11:

You've mentioned a few times that this must be a regression. We performed regularly-scheduled plugin updates on Tuesday, Aug 26. It's quite possible that the changes here stem from those updates ...

Yes, that makes sense.

... and there's no need to make further arguments that this is a regression - no one is suggesting that it is not.

I was responding to Ray's previous comment that the error was due to particular characters on the page. That is why I mentioned it was a regression.

However, it's not possible for us to roll the entire system back to its previous state just because of this inconvenient message.

While I understand that rolling back isn't ideal, the symptom is not only the message. Both WordPress and my browser think that the changes are unsaved, which is why I get a dialog from Chrome asking if I want to close unsaved changes. But the problem also triggers the recovery mechanism of WordPress, which autosaves the changes unnecessarily. Then, each page experiencing the problem has spurious autosave checkpoints. I'm bound to get confused at some point between these and real autosaved changes that I actually haven't committed, which could then lead to potential data loss.

...

If possible, perhaps you can help to confirm my hypothesis that this interaction is the cause of the behavior. You'd have to deactivate, if only temporarily, one of the two plugins, and then see whether the mysterious messages go away.

• If I deactivate JetPack Boost, I get the same behavior but a different error message: "Update failed. The response is not a valid JSON response."
• If I disable JetPack, the problem goes away.
• If I re-enable only JetPack boost, I see the problem again with the "JSON response" error message.
• If I re-enable only JetPack, I see the problem again with the "JSON response" error message.
• If I re-enable both JetPack and JetPack boost but disable the TOC+ plug-in, the problem goes away.

Looks like the fatal error Raffi listed is fixed in a later version of Jetpack: https://github.com/Automattic/jetpack/pull/44192.

We're currently running Jetpack 14.8, but the fix is in 14.9+. Boone, do we want to forgo our usual release process and update Jetpack to the latest version? Or do we want to temporarily patch the fix on production?

A workaround would be to permanently disable the JetPack plugins or the TOC+ plugin. Is there supposed to be a native TOC block? I found this article, but I don't see the TOC block come up in the block search.

Raymond Hoh wrote in #note-13:

Looks like the fatal error Raffi listed is fixed in a later version of Jetpack: https://github.com/Automattic/jetpack/pull/44192.

We're currently running Jetpack 14.8, but the fix is in 14.9+. Boone, do we want to forgo our usual release process and update Jetpack to the latest version? Or do we want to temporarily patch the fix on production?

Nice find, Raymond!

I've temporarily added the fix to production, Raffi. Please try again and see if you are able to replicate any of the issues from this thread.

Raymond Hoh wrote in #note-16:

I've temporarily added the fix to production, Raffi. Please try again and see if you are able to replicate any of the issues from this thread.

Sorry, Raymond. I'm still seeing them.

There appears to be another fatal error related to Jetpack Boost:

[27-Aug-2025 22:34:22 UTC] PHP Fatal error:  Uncaught Error: Class "Automattic\Jetpack_Boost\Modules\Optimizations\Page_Cache\Pre_WordPress\Path_Actions\Rebuild_File" not found in /wp-content/plugins/jetpack-boost/app/modules/optimizations/page-cache/pre-wordpress/storage/class-file-storage.php:194
Stack trace:
#0 /wp-content/plugins/jetpack-boost/app/modules/optimizations/page-cache/pre-wordpress/class-boost-cache.php(526): Automattic\Jetpack_Boost\Modules\Optimizations\Page_Cache\Pre_WordPress\Storage\File_Storage->clear()
#1 /wp-content/plugins/jetpack-boost/app/modules/optimizations/page-cache/pre-wordpress/class-boost-cache.php(494): Automattic\Jetpack_Boost\Modules\Optimizations\Page_Cache\Pre_WordPress\Boost_Cache->rebuild_recursive()
#2 /wp-content/plugins/jetpack-boost/app/modules/optimizations/page-cache/pre-wordpress/class-boost-cache.php(369): Automattic\Jetpack_Boost\Modules\Optimizations\Page_Cache\Pre_WordPress\Boost_Cache->rebuild_post_cache()
#3 /wp-includes/class-wp-hook.php(324): Automattic\Jetpack_Boost\Modules\Optimizations\Page_Cache\Pre_WordPress\Boost_Cache->invalidate_on_post_transition()
#4 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#5 /wp-includes/plugin.php(517): WP_Hook->do_action()
#6 /wp-includes/post.php(5740): do_action()
#7 /wp-includes/post.php(5000): wp_transition_post_status()
#8 /wp-includes/post.php(5212): wp_insert_post()
#9 /wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(966): wp_update_post()
#10 /wp-includes/rest-api/class-wp-rest-server.php(1292): WP_REST_Posts_Controller->update_item()
#11 /wp-includes/rest-api/class-wp-rest-server.php(1125): WP_REST_Server->respond_to_request()
#12 /wp-includes/rest-api/class-wp-rest-server.php(439): WP_REST_Server->dispatch()
#13 /wp-includes/rest-api.php(459): WP_REST_Server->serve_request()
#14 /wp-includes/class-wp-hook.php(324): rest_api_loaded()
#15 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#16 /wp-includes/plugin.php(565): WP_Hook->do_action()
#17 /wp-includes/class-wp.php(418): do_action_ref_array()
#18 /wp-includes/class-wp.php(818): WP->parse_request()
#19 /wp-includes/functions.php(1342): WP->main()
#20 /wp-blog-header.php(16): wp()
#21 /index.php(17): require('...')
#22 {main}
  thrown in /wp-content/plugins/jetpack-boost/app/modules/optimizations/page-cache/pre-wordpress/storage/class-file-storage.php on line 194

I don't see a bug report for this on the Github tracker, but the latest version of Jetpack Boost is at v4.3.1, though we're currently running v4.2.1. Raffi, since your site is the only site on the Commons using Jetpack Boost, I've just updated jetpack-boost to v4.3.1 on production. Please check again to see if you are still experiencing these bugs. If not, I will commit the Jetpack Boost change.

UPDATE: I've temporarily removed Jetpack Boost altogether because of #23273.

Raymond Hoh wrote in #note-18:

Raffi, since your site is the only site on the Commons using Jetpack Boost, I've just updated jetpack-boost to v4.3.1 on production. Please check again to see if you are still experiencing these bugs. If not, I will commit the Jetpack Boost change.

I'm still experiencing the problem.

UPDATE: I've temporarily removed Jetpack Boost altogether because of #23273.

Ah, any chances of getting it back sometime in the future? But, even with it removed, I'm still seeing the problem.

I'm still experiencing the problem.

This ticket has a lot going on, so for clarity I'm going to restate what I think "the problem" means in your comment: When editing a post like https://khatchad.commons.gc.cuny.edu/wp-admin/post.php?post=63&action=edit&classic-editor__forget, you can successfully save changes. But then, after the successful save, the editor still thinks you have a "dirty" state, such that when you try to navigate away, you're given the "are you sure" browser message. Please let me know if I've misunderstood this.

Assuming I'm correct, I was able to reproduce the problem, and I was able to trace it back to the table-of-contents-plus script-enqueuing change I described earlier. (The other fatal errors covered in this ticket were also real bugs, and probably resulted in some of the "failure" messages that were reported in the comments above.) Specifically:

1. The table-of-contents-plus plugin now fires the wp_enqueue_scripts action https://github.com/zedzedzed/table-of-contents-plus/blob/eec367b0e4d732b4fb6a7468aab30421d335087e/includes/class-toc-plus.php#L224 on all requests, including REST requests
2. Jetpack hooks into wp_enqueue_scripts, and prints some scripts before the REST response is sent back to the browser
3. As such, the "success" payload for the "save" AJAX contains a version of the post that Jetpack's script data prepended to the post content. The block editor sees this, and sees that the text in the block editor doesn't have the script data appended (Jetpack correctly does not add it on initial block editor load). So the block editor thinks that the canonical version of the post has the script data prepended, and thus thinks that the current editor state is dirty.

This is really a dual bug. table-of-contents-plus should not fire the hook indiscriminately. And Jetpack should not print scripts indiscriminately. Unfortunately, it appears that table-of-contents-plus has been abandoned by the author. But the Jetpack issue appears to be known to the Automattic team: https://github.com/Automattic/jetpack/issues/44437 It appears that the fix introduced in that ticket is not available in the version of Jetpack that we are currently running, so I've manually ported it https://github.com/Automattic/jetpack/commit/b19e025961ba69ff36cb9568fee8cdd5a896ee2d In my tests, this makes the unexpected dirty state go away.

Raffi, once you've confirmed that I'm properly understanding the specific problem, could you please test to see if it's still occurring after my hotfix?

Boone Gorges wrote in #note-20:

... When editing a post like https://khatchad.commons.gc.cuny.edu/wp-admin/post.php?post=63&action=edit&classic-editor__forget, you can successfully save changes.

Yes, but the editor's external behavior is that of the content being unsaved. And, I get the error message I mentioned yesterday.

But then, after the successful save, the editor still thinks you have a "dirty" state, such that when you try to navigate away, you're given the "are you sure" browser message.

Right. Basically, it acts as I haven't saved the changes, including creating autosaves that save intermediate progress. Next time I go to visit the page, I'm prompted to restore a previously "unsaved" state, when, in fact, it was saved.

Assuming I'm correct, I was able to reproduce the problem, and I was able to trace it back to the table-of-contents-plus script-enqueuing change I described earlier. (The other fatal errors covered in this ticket were also real bugs, and probably resulted in some of the "failure" messages that were reported in the comments above.) Specifically:

1. The table-of-contents-plus plugin now fires the wp_enqueue_scripts action https://github.com/zedzedzed/table-of-contents-plus/blob/eec367b0e4d732b4fb6a7468aab30421d335087e/includes/class-toc-plus.php#L224 on all requests, including REST requests
2. Jetpack hooks into wp_enqueue_scripts, and prints some scripts before the REST response is sent back to the browser
3. As such, the "success" payload for the "save" AJAX contains a version of the post that Jetpack's script data prepended to the post content. The block editor sees this, and sees that the text in the block editor doesn't have the script data appended (Jetpack correctly does not add it on initial block editor load). So the block editor thinks that the canonical version of the post has the script data prepended, and thus thinks that the current editor state is dirty.

This is really a dual bug. table-of-contents-plus should not fire the hook indiscriminately. And Jetpack should not print scripts indiscriminately. Unfortunately, it appears that table-of-contents-plus has been abandoned by the author. But the Jetpack issue appears to be known to the Automattic team: https://github.com/Automattic/jetpack/issues/44437 It appears that the fix introduced in that ticket is not available in the version of Jetpack that we are currently running, so I've manually ported it https://github.com/Automattic/jetpack/commit/b19e025961ba69ff36cb9568fee8cdd5a896ee2d In my tests, this makes the unexpected dirty state go away.

Raffi, once you've confirmed that I'm properly understanding the specific problem, could you please test to see if it's still occurring after my hotfix?

It works. Thanks!