jondaley

i think that is saying you already put noindex/follow in all links anyway? I’ll have to see if that is actually working.

that seems unlikely since Google is still crawling. I do think Amazon’s crawler is broken, since it didn’t even ever look at robots.txt – I have complained to their abuse department about that.

Until a fix/setting is added to the plugin, I just block all of the robots in my nginx config:

    location /calendar {
      if ($http_user_agent ~* (amazon|google|spider|bot) ) {
        return 403;
      }

No. It is related to performance. My server is getting swamped due to having all of these dynamic links getting hit over and over again by various crawlers, legitimate and illegitimate. I think you should have a setting in the software that disables the “next month” (and any other links) for a user configurable amount.

As far as I can see, the link you gave doesn’t mention anything like that.

ah, right. I did see that, but then forgot. Thanks!

widgets were suddenly broken for me too. The patched version works for me, thanks!

I can’t disable it, since that would make the site go slowly. We saw a great improvement with the site when we enabled memcached years ago. It seems to me that something has changed with the events plugin, because we have used this plugin for a long time, and have only started having problems with it in the last release or two.

I don’t use minify via W3. I do use cloudflare, which I think minifies things. Sounds like you need to do some edits on your code if minifying breaks it?

disabling the object cache switches to transients and this function starts working as expected.

If I call wp_cache_get directly after the wp_cache_set, it works properly, but the next visit to the site may or may not contain the set value…

weird.

Not sure what this means, if anything. I expected to see the timestamp in the cache.

>/usr/share/memcached/scripts/memcached-tool ~/memcached.socket dump | grep -a tec_custom_tables_v1_initialized
Dumping memcache contents
a:7:{s:10:”last_error”;s:0:””;s:10:”last_query”;s:109:”SELECT option_value FROM wp_options WHERE option_name = ‘_transient_tec_custom_tables_v1_initialized’ LIMIT 1″;s:11:”last_result”;a:0:{}s:8:”col_info”;a:1:{i:0;O:8:”stdClass”:13:{s:4:”name”;s:12:”option_value”;s:7:”orgname”;s:12:”option_value”;s:5:”table”;s:10:”wp_options”;s:8:”orgtable”;s:10:”wp_options”;s:3:”def”;s:0:””;s:2:”db”;s:15:”brett_strenuous”;s:7:”catalog”;s:3:”def”;s:10:”max_length”;i:0;s:6:”length”;i:4294967295;s:9:”charsetnr”;i:246;s:5:”flags”;i:4113;s:4:”type”;i:252;s:8:”decimals”;i:0;}}s:8:”num_rows”;i:0;s:10:”return_val”;i:0;s:11:”key_version”;i:4045940;}

a:7:{s:10:”last_error”;s:0:””;s:10:”last_query”;s:117:”SELECT option_value FROM wp_options WHERE option_name = ‘_transient_timeout_tec_custom_tables_v1_initialized’ LIMIT 1″;s:11:”last_result”;a:0:{}s:8:”col_info”;a:1:{i:0;O:8:”stdClass”:13:{s:4:”name”;s:12:”option_value”;s:7:”orgname”;s:12:”option_value”;s:5:”table”;s:10:”wp_options”;s:8:”orgtable”;s:10:”wp_options”;s:3:”def”;s:0:””;s:2:”db”;s:15:”brett_strenuous”;s:7:”catalog”;s:3:”def”;s:10:”max_length”;i:0;s:6:”length”;i:4294967295;s:9:”charsetnr”;i:246;s:5:”flags”;i:4113;s:4:”type”;i:252;s:8:”decimals”;i:0;}}s:8:”num_rows”;i:0;s:10:”return_val”;i:0;s:11:”key_version”;i:4045943;}

• This reply was modified 1 year, 7 months ago by jondaley.

memcached is using 87MB out of 256MB, so presumably the activation transient isn’t getting kicked out of the cache within seconds of being set…

enabling the writing of transients to the database doesn’t make any difference (probably because your ext_cache check, so you don’t ever use database transients if W3 is installed?)

My log messages (“none” means it is a cronjob or otherwise unauthenticated user), a (##) means a logged in user is viewing a page.

last_run_timeC means the ext_cache is true and returned that number, and then the init: is right at the top of init() and then if it prints wp_cache_set, it fell through to the ->up(), etc.

2023-04-27 15:03:26: (None) last_run_timeC: 1682607800
2023-04-27 15:03:26: (None) init: 1682607800
2023-04-27 15:03:38: (None) last_run_timeC: 1682607800
2023-04-27 15:03:38: (None) init: 1682607800
2023-04-27 15:03:44: (None) last_run_timeC: 1682607800
2023-04-27 15:03:44: (None) init: 1682607800
2023-04-27 15:03:56: (None) last_run_timeC: 1682607800
2023-04-27 15:03:56: (None) init: 1682607800
2023-04-27 15:03:57: (5) last_run_timeC:
2023-04-27 15:03:57: (5) init:
2023-04-27 15:03:57: (5) wp_cache_set
2023-04-27 15:03:57: (5) updating the events calendar
2023-04-27 15:03:57: (5) last_run_timeC:
2023-04-27 15:03:57: (5) init:
2023-04-27 15:03:57: (5) wp_cache_set
2023-04-27 15:03:57: (5) updating the events calendar

• This reply was modified 1 year, 7 months ago by jondaley.

wp_using_ext_object_cache() is true.
wp_cache_get(static::ACTIVATION_TRANSIENT)
returns false very often.

That is at least part of the problem.

• This reply was modified 1 year, 7 months ago by jondaley.

I’m curious about the ordering of line ~90 in Activation.php, where you set the transient/cache value and then erase the other. I don’t know your code or W3’s code, but it seems safer to erase and then create?

UPDATE: I swapped the order and it doesn’t make any difference to the “random” last_run_time false vs a timestamp.

• This reply was modified 1 year, 7 months ago by jondaley.