Rohjay

Hey Mikko,

You’re not wrong, sir! That is an issue when things get deleted in non-standard ways. In the realm of WordPress though… not an impossible scenario. To be honest, I don’t know how it’s happening on my client’s site – or what took place to get to this state.

I figured you’d want to know about this corner case – I can continue to hack around it to prevent fatals in the event this happens again =]

Cheers,
Ryan

I realize I’m not about to answer your question exactly as you ask it, but perhaps what I’m about to say will answer the cause of your question… I’m guessing the question has been caused by slow site performance issues, right? If so, here you go:

Your biggest problem here is almost certainly the “tracked visitor stats etc” in the database – not the number of ID’s. Inserts on every pageload are really hard as writes are much heavier processes than reads – not to mention they cause table locking for their write duration. Even if the tracking table is it’s own optimized table, it will still be detrimental to site performance.

This is one of the single biggest contributors to db load at scale I’ve ever seen – and I’ve seen it a lot. Offload your visitor tracking functionality from your WP database, and you’ll find your site has a ton more headroom for performance.

Good luck!

• This reply was modified 3 years, 3 months ago by Rohjay. Reason: Clarity

Yep – I saw them return shortly thereafter. It did fix some things, but then there must be a cronjob that comes in and starts rewriting caches and whatnot. One thing I’ve been meaning to try is to turn of WP Cron by adding the following line to the wp-config.php file:

define('DISABLE_WP_CRON', true);

If you need cron still, I know WPE has a process where they’ll hit the wp cron url locally. I can’t remember if that happens in an authenticated fashion though… so again, no promises.

In the 11th hour last night, I finally disabled ai1ec to get the site up to php7.2 =\

This does boil down to write permissions from unauthenticated requests though; Can’t write executable files to disk when the requests aren’t logged in. This is a bit of a pickle considering how ai1ec works.

Feels like this could be handled a little more gracefully by checking first if is_writable and if is_readable when caching to prevent the fatals beforehand. I’d dig deeper, but I got deadlines! D=

• This reply was modified 6 years, 1 month ago by Rohjay.

Correct – but I’m familiar with the way/reason for his work around. I naively assumed that it was *just* the JS caching, started digging into more of the code and holy smokes! Lot’s of caching on the file system! We’re gonna need more checkboxes xD

I’m wondering how effective it would be temporarily to just have that _cache method simply return false… at least to stop the bleeding.

Nope! No dice. Still getting the 502 randomly. I’ll keep digging.

In the wp-admin area, goto Events -> Settings, Advanced Settings -> Cache Report… now be careful, if you bonk the “check again” you can whitescreen your site for non-logged in users getting uncached hits.

Yeah brother – it’s a great calendar plugin! We’re using it on trainthemind.com – and to be honest, I’d like to keep using it =]

Let me know if there’s anything I can do to help with a more graceful fallback!

Cheers!
Ryan

I think this issue is solved much easier. In the wp-admin section, go to Events -> settings -> advanced -> advanced settings.

In there, uncheck the “Use advanced JS cache” option. It’s not an issue with memory usage in php 7.2, but one of the security protocols on WPE with write permissions.

Solved some fatals from happening for me instantly… haven’t seen any 502’s, but I’ll report back if I do. (silence is golden, right?)

Hi Marcus,

Glad you have it working. I have to apologize, I did it wrong the first example I gave you! Yikes!

The action I gave you to hook into was wrong:
add_action('wp_head', 'my_register_jquery_function');

That’s why when you put this in:
add_action('wp_enqueue_scripts', 'my_register_jquery_function');
it started working. Aha! Right hook!

Well done. See? You didn’t need anyone’s help. Here’s how it should look in total then:

function my_register_jquery_function() {
  wp_deregister_script('jquery');
  wp_register_script('jquery', ("https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"), false, '1.7.1');
  wp_enqueue_script('jquery');

  wp_enqueue_script(
    'slipSlap'
    , get_stylesheet_directory_uri() . '/js/slipSlap.js'
    , array('jquery')
  );
}
add_action('wp_enqueue_scripts', 'my_register_jquery_function');

You can put all of the scripts you want to enqueue inside of this one function like I did for you with slipslap.

Lesson to me – do not do from memory. Sorry for the confusion I might have given anyone!

Cheers,
Ryan

Hi Marcus,

Sorry I wasn’t very clear in my original reply. Replace the ‘before’ piece of code with the ‘after’ piece of code.

I’m not sure what you mean regarding plugins. All of your plugins will still be handled through the wp-admin backend – as long as your theme still has the wp_head() and wp_footer() functions and they’re in the right place.

If you’re talking about using your functions.php to call/include scripts, do the exact same thing as the “after” piece of code (except you probably don’t need to wp_deregister_script() for most). You can add the code into your header.php file to include it, but it’s much easier to run into conflicts and as a wp nerd I am obliged to at least say it’s considered “bad coding practice” to do that.

wp_enqueue_script(
  'Script' // Unique handle for the script
  , get_stylesheet_directory_uri() . '/js_folder/script.js'
  , array('jquery') /* This is an array of handles for scripts that need to be included before we can enqueue this script i.e. slipslap needs jquery to run, hence slipslap will have array('jquery') as a dependency */
  , $ver // version of the script
  , $in_footer /* if set to true, it will call this script in wp_footer(). This is probably the exact same thing Chris Coyier was doing - not necessary but it can help optimize page load times or at least the appearance of page load times. */
);

Regarding the “jQuery prefix”, it does not matter. As long as you enqueue the script with its dependencies and refer to those dependencies by their handle – for example array('jquery') – wordpress will know that it needs to include the jquery script first. /* run on sentence - will fix later */

Hope that helps… cheers!

Anytime you use wp_enqueue_script(), make sure you use it within an action.

BEFORE:
if( !is_admin()){
wp_deregister_script(‘jquery’);
wp_register_script(‘jquery’, (“https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js”), false, ‘1.7.1’);
wp_enqueue_script(‘jquery’);
}

AFTER:
add_action(‘wp_head’, ‘my_register_jquery_function’);
function my_register_jquery_function() {
wp_deregister_script(‘jquery’);
wp_register_script(‘jquery’, (“https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js”), false, ‘1.7.1’);
wp_enqueue_script(‘jquery’);
}

This issue caused me all sorts of headache a couple months ago. Hope that helps…

Cheers!
Ryan