4

This is really driving me up the wall now.

Randomly, all my menu items for all menus are just being deleted on their own. Not the menus themselves but all items within them.

This is a custom theme we built upon the Bones boilerplate. We've built plenty of sites on Bones though and we're not experiencing the problem with any others.

I know the usual advice will be:-

  • Deactivate all plugins and see if the problem persists.
  • Revert to the default Wordpress theme and see if the problem persists.

But this isn't particularly practical as it means breaking our website for weeks on end waiting to see whether the problem occurs again.

Each time this happens, we have to manually rebuild all our menus and it is becoming a real pain now plus potentially catastrophic if Google crawl our website when these menu items have all been deleted.

This only started happening since the 3.8 update but occurs within four days of reinstating all the menu items again.

There is nothing of note in the error logs. This last happened in the past 48 hours and all we have in the error log from this period is the following (actual domain replaced with domain.com):-

[Sun May 25 02:32:23 2014] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/vhosts/domain.com/cgi-bin/php
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/vhosts/domain.com/cgi-bin/php5
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/vhosts/domain.com/cgi-bin/php-cgi
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/vhosts/domain.com/cgi-bin/php.cgi
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/vhosts/domain.com/cgi-bin/php4
[Tue May 27 04:10:55 2014] [error] [client 188.143.234.90] script not found or unable to stat: /var/www/cgi-bin/cgi_wrapper/php

If all anyone can suggest is the above bullet points, then all I can really think of is to replicate the website in a dev environment and noindex the site for web crawlers (I've asked in various communities already) - there does seem to be a few other people that have experienced the same problem with little idea of resolution although for some it seemed to be related to plugins (although I don't have those plugins installed on our website).

Frustrating! Can anyone shed some better light on how to get to the bottom (debug) of this one?

I've just found this same question on here as well...

The database has been repaired as well to no avail.

11
  • 2
    Just replicated site on dev environment, set to NOINDEX. Will leave as is just until the menu items disappear again just so I can confirm that the problem will still occur on the dev version. As soon as it does, I'll remove all plugins first and then wait. If still a problem, I'll revert to the 2014 theme and wait. Will update back here with results...
    – zigojacko
    Commented May 28, 2014 at 13:04
  • 1
    We are experiencing a similar bug which has to do with the wp_scheduled_auto_draft_delete cron job, I have asked an own question here: wordpress.stackexchange.com/questions/145953/….
    – Gellweiler
    Commented May 29, 2014 at 18:50
  • 1
    I've now just read the other thread you linked to since all your debugging and notes and we only go and use the 'Stealth Publish' plugin on our site as well! Could be identical case...
    – zigojacko
    Commented Jun 12, 2014 at 13:35
  • 1
    @zigojacko had you confirmed that it's Stealth Publish in your case too? too be honest if you use current version it's almost certainly is. I'd like to close this as duplicate so we can consolidate the issue. :\
    – Rarst
    Commented Jun 18, 2014 at 9:35
  • 1
    @Rarst - now definitely confirmed, Stealth Publish to blame - updated my answer to confirm also. Thanks for your support on this in the other thread also.
    – zigojacko
    Commented Jul 14, 2014 at 9:31

2 Answers 2

1

Here are two loggers to help you to tackle the problem.

1) If you want to know when the number of nav menu items changes, you can use the following logger:

/**
 * A logger for nav menu items count - writes to the nav.log file.
 *
 * @link http://wordpress.stackexchange.com/a/149394/26350
 */

add_filter( 'wp_get_nav_menu_items', 
    function( $items, $menu, $args ) 
    {
        $file = '/path/to/nav.log'; // Edit this filepath to your needs.
        if( file_exists( $file ) && is_writeable( $file ) )
        {
            $s = sprintf( " %s - menu: %s - count: %d %s" , date( "c" ),
                $menu->slug,
                $menu->count,
                PHP_EOL
            );
            file_put_contents( $file, $s, FILE_APPEND | LOCK_EX );
        }
        return $items;
    }
, PHP_INT_MAX, 3 );

I've suggested this logger on another site to a user having similar problem.

Here's an example of the output:

 2014-06-12T13:14:47+00:00 - menu: primary - count: 11
 2014-06-12T13:14:47+00:00 - menu: primary - count: 11

2) You could try to log the INSERT, UPDATE and DELETE queries executed by the $wpdb object.

/**
 * Log the INSERT, UPDATE, DELETE database queries to the sql.log file.
 *
 * @link http://wordpress.stackexchange.com/a/149394/26350
 */

add_filter( 'query', 
    function( $query )
    {
        if( FALSE !== stripos( $query, 'UPDATE ' )
            || FALSE !== stripos( $query, 'INSERT ' )
            || FALSE !== stripos( $query, 'DELETE ' )
         ) {
                $file =  '/path/to/sql.log'; // Edit this filepath to your needs.  
                if( file_exists( $file ) && is_writeable( $file ) ) 
                    file_put_contents( 
                        $file, 
                        date( 'c' ) . ' - ' . $query . PHP_EOL, 
                        FILE_APPEND | LOCK_EX 
                    );            
        }
        return $query;
    }
, PHP_INT_MAX );

So you could try to use the info from nav.log to inspect the SQL queries from sql.log around the time the nav menu items changes.

Just remember to modify the log file paths and make sure the log files are writeable.

These loggers could be extended further. We could for example additionally log:

  • the current url,
  • the current user,
  • etc.

I hope this helps.

12
  • Excellent, thanks for providing these - this is a great help to try and debug. I've added these loggers to the theme functions.php and after deleting a menu item and re-adding it, nothing was logged (logs/nav.log and 'logs/sql.log are all writeable). Does the path to logs need to exist within the theme folder?
    – zigojacko
    Commented Jun 12, 2014 at 12:14
  • You can place the log files outside the theme. Try including the full path. You could for example try: WP_CONTENT_DIR . '/nav.log, or within some secret directory: WP_CONTENT_DIR . '/a4xp9tw/nav.log or better yet somewhere where you can't view it in the browser or with modified .htaccess/nginx rules to prevent direct access to it.
    – birgire
    Commented Jun 12, 2014 at 12:31
  • Hmm. Nothing is getting logged still. Log files just remain empty.
    – zigojacko
    Commented Jun 12, 2014 at 13:00
  • Works on my install, just tested and I updated the answer with an example output. I guess it's still not writeable on your server?
    – birgire
    Commented Jun 12, 2014 at 13:17
  • /wp-content/logs, /wp-content/logs/nav.log, /wp-content/logs/sql.log are all CHMOD 777 and CHOWN apache:apache. Line in function reads $file = WP_CONTENT_DIR . 'logs/nav.log'; // Edit this filepath to your needs. Nothing being wrote to these log files when I delete menu items. It's definitely all writeable.
    – zigojacko
    Commented Jun 12, 2014 at 13:22
1

I'm going to answer my own question primarily to keep a log of debugging until I get to the bottom of this (hopefully resulting in an answer to my question for the benefit of other SE users):-

28th May 2014

Asked question as per above. Ongoing issue with menu items being deleted randomly all the time. Duplicated website on a sub domain for testing purposes.

6th June 2014

Menu items deleted on live site. Still intact on dev site however noticed there were 4 plugin updates as per the below:-

  • CM Tooltip Glossary (active)
  • Form Maker (inactive)
  • Share This (inactive)
  • Wordpress SEO (active)

Updated all four plugins, within 10 seconds, all menu items were deleted on the dev site. Manually reinstated menu items.

Manually deactivated and reactivated the plugins CM Tooltip Glossary and Wordpress SEO (trying to replicate part of the update process). After a few minutes, all menu items still intact and have not been deleted.

I think perhaps update plugins one at a time in future so that can pinpoint exactly which is causing the issue.

8th June 2014

Okay, so the menu items on the live site have all just disappeared again. No updates in Wordpress were performed at all. They are still intact on dev site. No files had been modified on the server since 6th June for the live site.

Manually reinstated menu items on the live site again.

Two plugin updates available on the live site:-

  • Form Maker (inactive)
  • Share This (inactive)

Updated both plugins, menu items still intact...

One plugin update available on the dev site:-

  • Form Maker (inactive)

Updated plugin, menu items still intact...

Ran a diff check on the database dumps before and after plugin updates and reinstating of the menu items on the live site (as suggested in the comments):-

What is interesting is the insertion of the below line which is slapped in the middle of the wp_posts table:-

(1170, 2, '2014-06-08 11:02:05', '2014-06-08 10:02:05', ' ', '', '', 'publish', 'open', 'open', '', '1170', '', '', '2014-06-08 11:02:05', '2014-06-08 10:02:05', '', 0, 'http://www.domain.com/?p=1170', 4, 'nav_menu_item', '', 0),

This row is inserted between 688 and 689 so looks like this in the table:-

688
1170
689

Just seemed peculiar that it would insert this randomly there...

I also noticed the following difference in the wp_usermeta table:-

(542, 2, 'nav_menu_recently_edited', '44'),

My user ID is 2 and this seems like it is suggesting that my user ID recently edited 44 nav menu items... Which would probably be the deleting of them all?

Just installed the plugin Stream on live and dev sites to track any changes made in the Wordpress admin.

Also upgraded every single module on the Apache server, including mysql and repaired the mysql database. Everything I came across on the server, I upgraded. I then added max_input_vars to the php.ini (2000).

12th June 2014

Menu items all deleted again in live site. No updates were processed. The menu items have been deleted without anyone even touching anything on the website. Menu items still intact on dev site.

With the menu items not being deleted at the same time on live site and dev site (the site and database being identical other than loads more comments and things like that) is probably indicative of something, I'm just unsure what.

Attempting Wordpress's built in database and repair tool by adding the following to wp_config.php:-

define('WP_ALLOW_REPAIR', TRUE);

Didn't seem to find anything wrong, results below:-

The wp_users table is okay.

Failed to optimize the wp_users table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_usermeta table is okay.

Failed to optimize the wp_usermeta table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_posts table is okay. The wp_posts table is already optimized.

The wp_comments table is okay.

Failed to optimize the wp_comments table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_links table is okay.

Failed to optimize the wp_links table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_options table is okay.

Failed to optimize the wp_options table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_postmeta table is okay.

Failed to optimize the wp_postmeta table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_terms table is okay.

Failed to optimize the wp_terms table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_term_taxonomy table is okay.

Failed to optimize the wp_term_taxonomy table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_term_relationships table is okay.

Failed to optimize the wp_term_relationships table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_commentmeta table is okay.

Failed to optimize the wp_commentmeta table. Error: Table does not support optimize, doing recreate + analyze instead

The wp_snippets table is okay.

Failed to optimize the wp_snippets table. Error: Table does not support optimize, doing recreate + analyze instead

Repairs complete. Please remove the following line from wp-config.php to prevent this page from being used by unauthorized users.

define('WP_ALLOW_REPAIR', true);

Also installed logging from point 1 of @birgire's answer.

14th July 2014

I just wanted to confirm that since the removal of the Stealth Publish plugin, the menu items have no longer been deleted. Thanks to Rarst's contribution in the other thread that this one has been marked as a duplicate of.

The plugin developer has been made aware of the issue on Wordpress but it is becoming apparent that they don't care and the plugin has been abandoned/is not maintained any longer.

1
  • Just an idea: Make a full backup before and after update of plugins, maybe a diff shows something relevant, even if I don't know now what it could be ;)
    – kraftner
    Commented Jun 6, 2014 at 14:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.