zamba

I’ve been using 2.7.4 without issue until the last WP upgrade (3.5). I have NOT upgraded yet (now on 3.4.2) but did upgrade SI Captcha to the latest version (2.7.6.1) . I am running multisite under a single domain with 28 sub-blogs in folders; the theme is lifestyle on Genesis. The immediate result was that ALL attempted comments gave the ERROR Possible Spam Bot message and failed.

I restored 2.7.4 and all appeared well again. Hope this is of some use, I’ll follow this thread and inform of any developments.

Tony

Everything seems to be working fine so far! Personally I liked the button in your old position on the left, but the half-on on picture hover/fully-on with ghosted image on button hover is an interesting approach and quite effective. I’ll keep you informed of any issues we come across as it rolls out. Great work!

Great news, Sean, look forward to it!

Can you tell us when the next update will be released? If I can’t solve the extra div problem I’ll have to switch, which would be a pity because I thought your plugin worked and looked the best!

Yes, the sitemap generator is working fine. As I don’t make much money from these links I’m tempted just to remove them as the error messages irritate me, but as you rightly say, it would be nice to sort the problem out!

Sorry to come in late, but I’m having this problem. The links shown as errors are from CJ but do not appear in my sitemaps AFAICS. Perhaps I’m being a bit thick here, but I’m not sure what you mean by ” You can’t see it on the page, but the sitemap generator picks it up.”

I can’t see why WMT has this problem, as the link is not in the sitemap but on a page in the sitemap. My robots.txt is unexceptional, and I can’t see any rule that would cover this.

You’re welcome, good luck!

Yes. I have a multisite set-up under a single domain with 26 sub-blogs in sub-folders; I use both Super Cache and Ron’s sitewidetags plugin. You have to activate Super Cache on each individual network blog.

I find Super Cache a big help in speeding up my site, but recently I’m having a few doubts as to whether the preloading function is operating consistently. Occasionally I have found a blog where it’s not operating and have to manually start the preload. I see a few issues like this on the forum, so maybe this needs looking at more closely.

Site is travelsignposts.com if you want to check it out. If you look at the code and see a page that’s not super-cached, please let me know!

Tony

Well, that’s a relief! As I have 24 different sub-blogs in this multisite set-up, setting it up so the preloads don’t overlap is a little challenging. Unfortunately although I always get the start email, I haven’t been getting the complete email of late, consequently it’s a litle hard to work out how long the preloads are taking. Have you heard of this happening before – I couldn’t find anyone else mentioning it specifically.

Thanks a lot for clarifying things, Donncha, that’s a real help. But I’m unclear about your comment in (4), “the plugin uses the same filenames to keep track of where the preload is”. Could I ask you which filenames you are referring to? I suspect that might be a cause of my results, as I virtually never (but sometimes I do) get an email confirming the completion of a preload. Perhaps the overlapping of the preloads is screwing things up a bit.

I’ve been quiet because I thought I’d solved this, but apparently not.
Here is the current state of the play:

SERVER: Centos+Litespeed VPS, WordPress 3.1.3

DOMAIN: https://www.travelsignposts.com

WordPress multisite network of 26 blogs (1 main site, 25 sub-blogs in sub-folders, including one prototype blog).
There is a separate WordPress blog on the same server under the same domain in a sub-folder using a different database.
The Super Cache plugin is network activated on multisite, and each sub-blog configured. Htaccess method is used, but an earlier trial of using php made no apparent difference to the non-serving of supercached files.

Garbage collection is set at 172800 secs.
Preload is set at 43200 minutes

sample URL of sub-blog: https://www.travelsignposts.com/Germany

sample RL of sub-blog post: https://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food

sample URL of sub-blog page: https://www.travelsignposts.com/Germany/map

URL of separate blog: https://www.travelsignposts.com/wordpress

Sample URL of separate blog post: https://www.travelsignposts.com/wordpress/classical-music-and-operas/passau-music-festival

CURRENT POSITION:

This position is the same as that prior to my pre-load activities listed under “Recently”.

All posts and pages are supercached.
All blog index pages are served from supercache.
The multisite blog network Super Cache uses .htaccess to serve its files

Main blog: Index page and pages supercached (posts pulled from sub-blogs redirect to respective sub-blog posts as designed: SiteWideTags plugin).

Sub-blogs: Index page served from supercache. Posts and Pages not served from supercache (supercached file not found so new one created).

Separate blog: Supercache functions as normal, all posts and pages served from supercache. Supercache uses php to serve its files.

RECENTLY:

The position was the same as outlined above, when I tried pre-loading all sites in the main network one by one. This resulted in the supercached files suddenly being served as they should be.

However, a few hours after all the sites had been pre-loaded (around 12,000 files, three days later), Supercache stopped serving files from the supercache and the position regressed to the current position. This resulte in an approximately threefold increase in CPU load.

COMMENTS:

It has been noted that the url used in the supercache directory uses a lower case as opposed to the upper case in the WordPress file, i.e.
Actual URL: https://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food
Supercache URL: /home/MYACCOUNT/public_html/wp-content/cache/supercache/www.travelsignposts.com/germany/food/steckerlfisch-oktoberfest-food/index.html

The argument against this is that the blog index pages (which are served from the supercache) also have the upper case country name in them, and a corresponding lowercase URL. Similarly, prototype blog has a lower case folder name and exhibits exactly the same behaviour as those with an upper case name.

So, that’s where I am at the moment. If anyone’s got any ideas I’d be pleased to hear them, as I’m struggling a bit. Having had an albeit brief experience of the promised land when supercaching worked, I’m determined to get it running…

I just asked Wiredtree’s support about that, and they said that “For the most part Litespeed is seamless with Apache rewrite rules”. So there’s a possibility there. But when I used PHP it didn’t appear to make any difference, so who knows? I’ll keep working on this.

Hey, Donncha, did I hear you say Supercache htaccess rules only work with Apache? Does that mean they won’t work with a Litespeed server?

No, all lower case and pretty normal, /home/xxxxxx/public_html/
One thing happened: yesterday out of the blue supercached files were served. I did check the urls I have been checking and they DID serve the supercache files, as evidenced by the <!– super cache –>. Unfortunately, today the situation has regressed to the prior situation. I have altered nothing in the various blogs I checked, only a couple of entries have been made in different blogs.
I really appreciate your help with this, I’m determined to get things working.

Oops, sorry about that, I was unfamiliar with using pastebin, but I have now sorted it and so here is the debug log for 2x loads of an index page and post showing the problem (Super Cache issue):
https://pastebin.com/iD97iysp