• spinhead

    (@spinhead)


    I realize this question is incredibly vague and I don’t really expect meaningful answers.

    I created a custom theme based on underscores years ago. I have modified it many times over the years.

    Some time in the past few months, revisions have stopped working. When a post is updated previous versions do not appear in the database. ‘Revisions’ does not appear in Screen Options.

    When I add define( 'WP_POST_REVISIONS', true ) to wp-config the problem is solved going forward, but I am curious where in the code for a custom theme something could have changed to break revisions.

    I can certainly diff an older version of the theme but I’m hoping for some insight from the inside, from how WordPress actually works (which I’d like to understand better.)

    The page I need help with: [log in to see the link]

Viewing 8 replies - 1 through 8 (of 8 total)
  • Moderator threadi

    (@threadi)

    Revisions can be disabled in various ways:

    • Via plugin: check whether you are using a plugin that performs this task or has a setting for it. The latter could be the case with optimization plugins, for example.
    • Check whether you are using the hook https://developer.wordpress.org/reference/hooks/wp_revisions_to_keep/ anywhere. If this returns the value 0, no revisions will be saved either.
    • Check whether you are using the constant WP_POST_REVISIONS anywhere. You have already entered it in wp-config.php, but it may be mentioned again elsewhere.
    Thread Starter spinhead

    (@spinhead)

    none of those are happening. thanks.

    Moderator bcworkz

    (@bcworkz)

    There are numerous reasons why revisions wouldn’t be saved. Review the source code for wp_save_post_revision(). This function should be called from the “post_updated” action. You could debug the function to learn exactly where it’s failing to work as expected. While we’re not supposed to alter core code, doing so temporarily isn’t a problem.

    Thread Starter spinhead

    (@spinhead)

    That’s WordPress core stuff. I’m working with a theme, not a whole new core.

    Whatever changed would be a minor tweak to a theme, not to the WordPress core which I never ever touch for any reason.

    Moderator bcworkz

    (@bcworkz)

    Yes, but it’s only to identify exactly why it’s failing. Once that’s known it should be a good clue on where to investigate further. Without such knowledge, you’re basically shooting in the dark.

    You’re wise to avoid core code, usually no good good will come of it. However, in this case it’s only a temporary change. Keep a copy of the original file so you can easily revert back at any time. If you’re still not comfortable doing so, then don’t do it. But then it’s anyone’s guess about what has gone wrong.

    Thread Starter spinhead

    (@spinhead)

    well, wp_save_post_revision() is in wp-includes/revision.php but I wouldn’t have a clue how to troubleshoot it.

    Moderator threadi

    (@threadi)

    wp_save_post_revision() uses the wp_revisions_to_keep() function to decide whether revisions are used. In wp_revisions_to_keep(), the constant WP_POST_REVISIONS is used as the starting point for the result. This can in turn be influenced by the hook wp_revisions_to_keep mentioned above.

    What I find surprising is your description that adding define( 'WP_POST_REVISIONS', true ); to wp-config.php solves the problem. Looking at how the two functions are structured, WP_POST_REVISIONS must already be set somewhere before your entry in wp-config.php, namely to false or 0 – and you are overwriting this entry with your addition there.

    So take a close look to see if the constant is not already present in wp-config.php. Also check if you have a mu-plugin that might set the value here – it’s easy to overlook.

    And yes, I can understand your confusion.

    Thread Starter spinhead

    (@spinhead)

    Two plugins: classic editor and classic widgets. I’ve been using them both since Gutenberg was added. I don’t see them doing this.

    I have not ever even once changed core code, so there is zero chance that WP_POST_REVISIONS has been altered wherever it originally lives.

    wp-config is a couple dozen lines long. this variable is not set elsewhere in this file.

    here’s what all these answers aren’t taking into account: something changed IN MY THEME over the past couple months to cause this. I’m using the default WP core for every install. unless something in a theme conflicts with something NEW in the WP core files, it’s not going to be in the core files.

    apparently it’s time to diff the two theme folders and see what shifted from September till now.

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.