• I have been rebuilding my website offline for at least 6 months now taking every step to keep the database clean. Most importantly the wp_post data entry auto-increment post id low and not waste them. I’m sure people will tell me it doesn’t matter but I don’t like seeing large post id numbers in my links. I recently moved online and noticed the common suggestion to disable autosave doesn’t stop the first autosave. Since I am copy-n-pasting content to the website I don’t want the autosave wasting post id numbers. I have seen other comments about this issue but they imply we have to deal with it. I myself am willing to hack the WordPress core code. I am asking if anyone can suggest a safe way to block where it creates these initial autosaves. I am including the autosave code that I assume is what I need to edit.

    function wp_create_post_autosave( $post_data ) {
        if ( is_numeric( $post_data ) ) {
            $post_id   = $post_data;
            $post_data = $_POST;
        } else {
            $post_id = (int) $post_data['post_ID'];
        }
     
        $post_data = _wp_translate_postdata( true, $post_data );
        if ( is_wp_error( $post_data ) ) {
            return $post_data;
        }
        $post_data = _wp_get_allowed_postdata( $post_data );
     
        $post_author = get_current_user_id();
     
        // Store one autosave per author. If there is already an autosave, overwrite it.
        $old_autosave = wp_get_post_autosave( $post_id, $post_author );
        if ( $old_autosave ) {
            $new_autosave                = _wp_post_revision_data( $post_data, true );
            $new_autosave['ID']          = $old_autosave->ID;
            $new_autosave['post_author'] = $post_author;
     
            $post = get_post( $post_id );
     
            // If the new autosave has the same content as the post, delete the autosave.
            $autosave_is_different = false;
            foreach ( array_intersect( array_keys( $new_autosave ), array_keys( _wp_post_revision_fields( $post ) ) ) as $field ) {
                if ( normalize_whitespace( $new_autosave[ $field ] ) !== normalize_whitespace( $post->$field ) ) {
                    $autosave_is_different = true;
                    break;
                }
            }
     
            if ( ! $autosave_is_different ) {
                wp_delete_post_revision( $old_autosave->ID );
                return 0;
            }
     
            /**
             * Fires before an autosave is stored.
             *
             * @since 4.1.0
             *
             * @param array $new_autosave Post array - the autosave that is about to be saved.
             */
            do_action( 'wp_creating_autosave', $new_autosave );
     
            return wp_update_post( $new_autosave );
        }
     
        // _wp_put_post_revision() expects unescaped.
        $post_data = wp_unslash( $post_data );
     
        // Otherwise create the new autosave as a special post revision.
        return _wp_put_post_revision( $post_data, true );
    }
Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    Please do not hack core code. No good will come of it. Figure out a way to use filters and actions to accomplish your goals. You needn’t post core source code here. Just tell us the function name you’re looking at, we know how to find core source code ?? Or if you want to be extra helpful, link to the associated docs page or its source code in Trac.

    I think you can use the ‘wp_insert_post_empty_content‘ filter to identify auto-save attempts and cause WP to think it’s an empty post and abort any saving that would have occurred. Unverified, but should work provided we can discern an auto-save from all other post saves. There ought to be some indication in the passed post data.

    If you find large IDs in links offensive, why not use pretty permalinks so IDs don’t appear in links? In any case, if revision saving is otherwise disabled, the auto-saved post would only consume one extra ID per post. It is reused for every auto-save of that post. They don’t significantly contribute to ID consumption. Other post objects will also consume IDs: attachments, menu items, reusable blocks, etc. If low IDs are that important, and you don’t like pretty permalinks, it is feasible to manage an independent ID scheme with which to query posts by, using a custom query var in links. Such a scheme could be rather sophisticated, for example, reassigning orphaned IDs (like those belonging to deleted posts) before assigning a new, larger ID.

    Thread Starter scotth454

    (@scotth454)

    I am trying to stop autosaving at any cost since there is no option built-in. Something like this should be standard since not everyone would need it. Even with the disable code in the config file it still makes a new data entry every time I open the page to edit or after I update to save and continue to work. It makes a new entry every time and doesn’t reuse since that is the part that is disabled.

    The previous site that I am replacing since it was lagging and generally seemed bloated had a database of 240MB after just over a year of use. The current update with me being aware of database management is 64MB with just 8 blog posts content left to build. So pretty sure the current WordPress has no concern for database management.

    I may have found my method to avoid the autosave by creating the page offline and then copy-pasting the database content into the live versions database. So no matter what this is going to be hack.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Disable autosave in core code, block database entry’ is closed to new replies.