WordPress.org

Forums

Why does the publish button disable itself now and then (16 posts)

  1. Strictly Software
    Member
    Posted 10 months ago #

    I have had this for the last few versions.

    The Publish / Draft button will disable itself with the class "disabled" now and then for no apparent reason as I am writing a post OR have created one and want to publish it.

    I am having to edit the DOM, remove the "disabled" class from the button and then press the button to get it to post.

    Is there a logical reason why this is happening and how can I stop it from doing so?

    Thanks

  2. Strictly Software
    Member
    Posted 10 months ago #

    Hi

    Can someone update me on this?

    Is it very annoying when I am watching TOP on my console and see I have over 1GB RAM free and MySQL CPU is not maxing out. So I don't know what causes these disabled classes to be added but they are as anoying as the "saving data locally" messages which appear randomly and go away when I refresh a page or post.

    My old re-connect (in a loop) for 5 times if "MySQL Server Has gone away" errors happened used to fix this but then it seems WP implemented their own version of this in WP 3.9 and the messages have come back.

    What causes this class "disabled" to prevent saving of posts and the message "saving locally" to appear so I know what to do to stop it rather than bypass it by modifying the DOM?

    Thanks

  3. How long does the button stay disabled? Typically, it will only stay disabled for a second or two while the post auto-saves (to prevent data corruption).

    WordPress also periodically saves the post to your browser's local storage in case you lose your internet connection or your server goes offline at any point during composition.

  4. Strictly Software
    Member
    Posted 10 months ago #

    Hi

    Thanks for replying.

    How do you test for internet connectivity?

    Are you constantly doing HTTP calls to the homepage or another page on a different server behind the scenes, and if so how often, and can you change this behaviour in your code?

    In my wp_config.php file for performance sakes and to try and stop all the drafts and auto saves and other performance killers that come as standard I have had these set for years which have helped a lot but if you are saying it's auto saving drafts I don't understand why my config isn't stopping this from happening?

    /* disable WP-CRON from running all the time on every page load! */
    /* Replaced with my own CRON job that runs the same code every 5 minutes */
    define('DISABLE_WP_CRON', true);

    /* turn off post revisions */
    define ('WP_POST_REVISIONS', false);

    /* set auto saves so far in future they shouldn't get saved on autoposts so why are the buttons still being disabled? */
    define( 'AUTOSAVE_INTERVAL', 10000 );

    Wouldn't the last one prevent this auto save behaviour and if not what config is there to manage it?

    Also the server is obviously ONLINE when these buttons are disabled as I can remove the class in the DOM and then hit the button and the page will save so I don't know if the core code has some sort of issue there.

    Also the "saving content locally" message at the top of the page seems to have the same functionality - none - as I can usually refresh another page and it will remove it. So I'd like to know if there is any config related to this feature as well.

    Thanks for your help!

    Rob

  5. Hm, yes, that should disable the auto-save. How long does the button stay disabled?

    I'm trying to get a sense of how much of a "performance killer" this is for you. For me, it's always one or two seconds, and the peace of mind is worth it. If it's significantly more for you, perhaps there's a larger problem elsewhere.

  6. Strictly Software
    Member
    Posted 10 months ago #

    Hi

    It seems to stay disabled until either I go to a "viewable" post on the site and load it OR I remove the class in the DOM.

    If it was just a second or two then I wouldn't mind but the fact I can remove the class and then hit the button and the article saves shows that the server is up and HTTP connectivity is working.

    So I don't know what else to check.

    Do you know where the code is located that implements this class AND the message at the top of the post so I can check what it is checking before it puts the classes on the buttons or shows the "saving locally" message?

    I have a 2GB RAM Linux Server with more for disk swapping. The server loads are pretty low all of the time unless I get a Twitter Rush (where I post tweets to multiple accounts and 50+ BOTS come rushing all at once) - which is why I put timers in my Strictly TweetBOT plugin to stage the Tweets, and cache the page before Tweeting.

    I also have my Strictly System Checker plugin installed which does regular HTTP checks of my homepage, looks for a word that should be there, checks the server load, the DB connections, the RAM used, the PHP memory being used, dropped connections, queries and sends me a report if the system is having issues (which you can configure e.g if the load is over 2.00 or you have a timeout retrieving your homepage over 30 seconds) and I haven't had a report for some time now.

    I increased the memory in the config file to 80MB as well and I am behind Cloudflare with Fail2Ban, DenyHosts and WP plugins that ban login attempts and my own Htaccess rules that ban most CURL like HTTP BOTS or Blank user-agents (and IE 6 seeing most hackers seem to use that and no-one in their right mind should be using that still now) - plus SQL/XSS hack vectors and other rules that replace what WP plugins like WP Firewall do at a PHP level.

    I have WP Super Cache, turned off Apache Caching to get the space back and use WP Widget Cache and very few other plugins.

    I usually find it's after an upgrade to a new WP version or Jetpack version that I get a lot of issues and I am loathe to do it especially as I was using my own version of the new WP-DB.php file years ago (with the re-connect loop on the MySQL Server Has Gone Away error), but now WP are doing it themselves (maybe they read my blog > http://blog.strictly-software.com/2013/08/mysql-server-has-gone-away-fix-for.html ) but whatever the case I would like to know how they are testing for web connectivity and how often as that could be a killer just like the WP_CRON job test on every single page called which can kill sites with heavy hitters.

    Thanks for your help

    Rob

  7. Yeah, that certainly isn't normal. Something must be conflicting with it.

    Try deactivating all plugins. If that resolves the issue, reactivate each one individually until you find the cause.

    If that does not resolve the issue, try switching to the Twenty Fourteen theme to rule-out a theme-specific issue (theme functions can interfere like plugins).

  8. Strictly Software
    Member
    Posted 10 months ago #

    LOL, please don't give me the WordPress equivalent of tech supports "Turn it off and on again" - I've done the IT Crowd routine and tried that already a long time ago - same mantra I tell people complaining to me about my plugins.

    I have a small set of core plugins I have used for years (loathe to add new crap code to the site) and the problem has only started recently since WP 3.8 (educated guess).

    It would just be good to know the file??? the code is in so I can have a butchers and see what is controlling these messages / classes etc.

    I remember when that message first came out people were talking about a styling issue and the need for "display:none" to be added etc not that I did that, just remember talk of that as a "solution" - of course it wasn't - it was just hiding the message.

    If the message is now affecting functionality by adding classes that stop the saving of posts then that is different so there must be a trigger - I just need to find it.

    Would you know where OR how I can find it?

    Thanks for your help!

    Rob

  9. LOL, please don't give me the WordPress equivalent of tech supports "Turn it off and on again"

    I can't help if you aren't willing to troubleshoot, you should know that as a developer.

    Something suddenly broke in your blog that hasn't affected any other WordPress user. It sure sounds like a plugin or theme conflict to me. As you said, it's the "same mantra [you] tell people complaining to [you] about [your] plugins."

    Would you know where OR how I can find it?

    If hacking a core file to correct what is most likely a plugin or theme conflict is the route you want to go: https://core.trac.wordpress.org/browser/tags/3.9.2/src

  10. One thing to try before you go digging, try adding define('CONCATENATE_SCRIPTS', false); to your wp-config.php file just below the define('DB_HOST' line.

    http://codex.wordpress.org/Editing_wp-config.php#Disable_Javascript_Concatenation

    It's really a server misconfiguration, and it can cause what you're describing, but it usually causes much more problems than just this. Fortunately, WordPress has a way around it.

  11. Strictly Software
    Member
    Posted 10 months ago #

    Hi

    Sorry mate, didn't mean to sound condescending it's just that as a developer who writes plugins that is what I tell my users and it's the standard reply to most users as they don't do the basics like
    -check JS/Cookies work
    -check for old browsers
    -check for other plugins causing issues etc

    So it wasn't meant to be a jibe just found it funny as I have been saying that all day long!

    I will try this hack you are talking about and I will look at the source when I get the time.

    I was just interested to know "how" WP knew the server connectivity had gone to apply these classes AND show the message at the top. The only way I can think of is by doing RPC or HTTP requests to another server but then that is why I find it strange I can modify the DOM and still save the post.

    I wonder whether there is a "set" time it puts the message/classes on for OR the gap between tests is due to the WP_CRON job (which I have disabled from running on every page load) - so that could explain why the button/messages stay up longer for me as it's waiting for another REAL (replacement) CRON job to fire the usual WP CRON tasks to "test connectivity" again and REMOVE the classes/messages.

    This would explain the issue handsomely and it would explain why the buttons / message stay up longer for me than others as I am not relying on page requests to fire WP_CRON but a timed job. So in theory it's hit and miss when the job run and I am looking at it AND also a longer wait for it to all go back to normal.

    Would make sense wouldn't it?

    Thanks

    Rob

  12. It would make sense, but I'm not 100% sure how this particular feature operates on the technical level myself. It was introduced during a time when I wasn't able to actively follow core development.

  13. Strictly Software
    Member
    Posted 7 months ago #

    I am guessing this is to do with the HeartBeat functionality that allows the Server to connect to the Browser with AJAX every 15 seconds!

    I checked my log files as I had a post page left open in a browser window by accident and the /wp-admin/admin-ajax.php script was being called every 15 seconds for it.

    I am "guessing" that this functionality which was introduced in 3.6 I believe >> http://www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage

    Is used (from the site) to

    allows WordPress to communicate between the web-browser and the server. It allows for improved user session management, revision tracking, and auto saving.

    The WordPress Heartbeat API uses /wp-admin/admin-ajax.php to run AJAX calls from the web-browser. Which in theory sounds awesome, as WordPress can keep track of what's going on in the dashboard.

    However this can also start sending excessive requests to admin-ajax.php which can lead to high CPU usage. Anytime a web-browser is left open on a page using the Heartbeat API, this could potentially be an issue.

    Therefore as my server bandwidth costs have just jumped a lot I am guessing that having this open page in my browser has cost me a lot of money due to the number of requests it must have made.

    As it talks about auto saving I am willing to guess (I will see if I am right) that the HeartBeat functionality could be causing these long delays in the buttons being disabled even though I have config to disable auto saving and so on.

    Therefore I added this code to my functions.php file to disable HeartBeat and I will see what happens.

    // stop heartbeat RJR
    add_action( 'init', 'stop_heartbeat', 1 );
    
    function stop_heartbeat() {
            wp_deregister_script('heartbeat');
    }
  14. Strictly Software
    Member
    Posted 7 months ago #

    Actually I now use this code as it seems the previous version stopped parts of the post page working e.g showing tags, deleting custom fields (all AJAX related).

    So I now use this

    // stop heartbeat code
    add_action( 'init', 'stop_heartbeat', 1 );
    
    function stop_heartbeat() {
            global $pagenow;
    
            if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' )
      {
       wp_deregister_script('heartbeat');
      }
    }

    And I make sure NOT TO leave any post pages open in the browser.

    A good way to use this hesrtbeat functionality is to check whether any activity has happened on the page within an hour and then stop it until some sort of trigger re-starts it like a keystroke. Then you wouldn't have people wasting bandwidth and all the features of the plugin.

  15. Strictly Software
    Member
    Posted 7 months ago #

    Right this is worrying me now because
    a) if you had a system with multple users
    b) muptiple admin
    c) multiple with post/edit functionality
    d) OR if heartbeat is enabled on plugins that are then used on pages that are then available on pages that users could let hang >> have open in browser for weeks n weeks.

    This could kill bandwidth, make log file rotation a nightmare, kill CPU/Memory and most imoportantly make the cost of running the server a lot more expensive

    Therefore WP need to implement a strategy for auto disabling this "pluse" when no activity is de-tected to prevent this.

    I don't want to accidentally leave a post-edit page open on even with

    // stop heartbeat code
    add_action( 'init', 'stop_heartbeat', 1 );
    
    function stop_heartbeat() {
            global $pagenow;
    
            if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' )
      {
       wp_deregister_script('heartbeat');
      }
    }

    enabled to limit to the post page cause me ££££!!!
    A plugin even worse as I would have less control over over it otherwise plugin authors need a hook to tell them whether heartbeat is avaulable to them or not for workarounds.

    A Stop/Start event and Time De-Activate event would be great as you could tell the plugin to stop heartbeat depending on site wide settings. So a "HeatBeat" WP Admin page to let Sys Admin set the pulse of slow, normal and fast beat pulses would be good.

    Also to tell WP when to de-activate it after notifying NO activity on the page it's being used on e.g 10 mins - AND re-activate it once activity is notified again.

    I just don't want want a user/admin/plugin left open on a page costing me the server owner cold cash because of this system.

    I wanted to suggest this to WP as an idea but their advanced forum is locked down. How can I let WP know this would be a good idea to save server side cash?

    Thanks

    Rob

  16. Strictly Software
    Member
    Posted 5 months ago #

    Hi

    Even with that config setting enabled and heartbeat code added I have an issue where one post I am writing has had the publish button disabled the whole time. It's 4 hours since I started writing the article and it's still disabled.

    The site is running quick, other parts run fine, posts load and can be edited but thid one page I am writing has the publish button disabled.

    Have NO idea why.

Reply

You must log in to post.

About this Topic