awhig
Forum Replies Created
-
Hi,
You set your page limit on the XML Sitemaps tab to 2000-3000?
That is way to high.
Entries per page Please enter the maximum number of entries per sitemap page (defaults to 1000, you might want to lower this to prevent memory issues on some installs): Max entries per sitemap page: 3000Just to be clear, this is what you are setting to 3000?
If so, you should really only put a small number like 100. This number is how many entries the plugin will put on 1 page. This means the plugin will generate around 200 xml pages for you (2000/100), with an index xml page pointing to each one.
You might get away with a higher number, but I kept running into memory issues as well, I found 100 worked for me reliably.
Rich
Forum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsHi,
I forgot to mention that w3-total-cache/wp-content/object-cache.php has to also be updated with the new function parameters as well. This file then gets copied into the wp-content folder of the site, to activate object caching.
Rich
FYI,
If I view source, I can see xml outputted, just Chrome is not displaying it. Must be some error in the output prevent it from being recognized as xml in Chrome. Firefox will show it as one long line. It does not format it as XML like it usually did.
Rich
Forum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsThank you.
Rich
Forum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsFYI,
My code change does not implement the $force parameter, so if someone from the W3TC team decides to actually upgrade their implementation, they should probably do that as well.
I was mainly concerned with $found.
Thanks,
RichForum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsW3TC still works, in that your site will still function.
The Object cache though does not work for anything that tests the $found parameter to determine an object was actually found in the cache. Any performance gain the object cache offers is lost.
The fix is rather simple.
In lib/W3/ObjectCacheBridge.php
change the get function to (line 27):
function get($id, $group = 'default', $force = false, &$found = null) { $cache = $this->_get_engine($group); return $cache->get($id, $group, $force, $found); }In lib/W3/ObjectCache.php (line 153). I wanted to minimize code changes, so I avoided trying to rewrite this method…
function get($id, $group = 'default', $force = false, &$found = null) { if ($this->_debug) { $time_start = w3_microtime(); } $key = $this->_get_cache_key($id, $group); $internal = isset($this->cache[$key]); if ($internal) { $value = $this->cache[$key]; $found = true; } elseif ($this->_caching && !in_array($group, $this->nonpersistent_groups) && $this->_check_can_cache_runtime($group)) { $cache = $this->_get_cache(null, $group); $v = $cache->get($key); if (is_array($v) && $v['content'] != null) { $value = $v['content']; $found = true; } else $value = false; } else { $value = false; } if ($value === null) { $value = false; } if (is_object($value)) { $value = clone( $value ); } $this->cache[$key] = $value; $this->cache_total++; if ($found){ $cached = true; $this->cache_hits++; } else { $found = false; $cached = false; $this->cache_misses++; } /** * Add debug info */ if ($this->_debug) { $time = w3_microtime() - $time_start; $this->time_total += $time; if (!$group) { $group = 'default'; } $this->debug_info[] = array( 'id' => $id, 'group' => $group, 'cached' => $cached, 'internal' => $internal, 'data_size' => ($value ? strlen(serialize($value)) : ''), 'time' => $time ); } return $value; }Forum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsI’ve checked the code in the 0.9.4 release. It looks like this is still an issue. Is there any interest in fixing this?
Thanks,
RichJust to make sure, is it easy to downgrade back to 1.4.x from 1.5.x? I seem to remember seeing something somewhere that said it was not.
Thanks,
RichI’m still using version 1.4.25.
WPSEO uses very little time currently.
I’m afraid to upgrade to 1.5.x because of reports like the above.
Here is my P3 Profile using 1.4.25.
Rich
WordPress Plugin Profile Report
===========================================
Report date: March 18, 2014
Theme name: xxxx
Pages browsed: 14
Avg. load time: 0.4662 sec
Number of plugins: 11
Plugin impact: 114.07% of load time
Avg. plugin time: 0.5318 sec
Avg. core time: 0.1837 sec
Avg. theme time: 0.0676 sec
Avg. mem usage: 24.27 MB
Avg. ticks: 9,991
Avg. db queries : 57.07
Margin of error : -0.3168 secPlugin list:
===========================================
P3 (Plugin Performance Profiler) – 0.2783 sec – 52.34%
Polldaddy Polls & Ratings – 0.0047 sec – 0.88%
Regenerate Thumbnails – 0.0011 sec – 0.21%
Rvg Optimize Database – 0.0026 sec – 0.50%
Shortcode Exec PHP – 0.0007 sec – 0.13%
Sitepress Multilingual Cms – 0.1573 sec – 29.57%
W3 Total Cache – 0.0262 sec – 4.92%
Wordpress Seo – 0.0278 sec – 5.22%
WP Smush.it – 0.0006 sec – 0.11%
Wpml Translation Management – 0.0324 sec – 6.10%
Custom Meta Boxes Wp – 0.0002 sec – 0.03%Has this issue been resolved in the latest release, 1.5.2.3?
Forum: Plugins
In reply to: [W3 Total Cache] ObjectCache API is out of date. This breaks other pluginsI really think this is a big issue for W3 Object Cache. Any code that uses wp_cache_get and uses the found parameter, is totally hosed, if they are using W3TC with object caching turned on.
I’ve fixed my personal copy of w3tc ObjectCache, and I’ve reduced query usage, page load time, load on my DB, etc.
It’s a very simple update. I went to see if I could contribute my code, but did not see a way to do this.
I think everyone using W3TC would benefit from this fix!!!
I also use the WPML plugin for site translations. This plugin adds quite of bit of queries to the site, and uses the “found” parameter when caching query results in a lot of places.
Unfortunately, anyone using W3TC with object caching, is really being hurt by this bug.
Rich
Hi Simps,
I ran into this same problem yesterday. The simplest workaround for this is before scanning the files, click on the red squares for each file. This will bring up the credentials popup. You can then give permissions there and turn each file green.
After that, then do the scan, which will already have the permissions, and the issue will not come up.
I thought of fixing it in my own copy of the plugin, but this workaround was simple enough.
Rich
Out of curiosity, what does this plugin use to query WP for the list of published/unpublished posts? I’m thinking the WPML plugin is filtering something so that query is not returning the proper set of posts.
Rich
I just reverted back to version 3.0, and I’m having the same issue.
I believe, the issue is with a change in the WPML plugin as I’m running a beta version of it to fix a catastrophic bug in the latest release version has. Hopefully this will be resolved with the final release of the WPML bug.
Rich
I’ve opened a github issue for my issue.