KirkM

I’m also using AIOSEO with 2.7 without a problem. Sounds like your error when attempting to activate AIOSEO is most likely due to incompatibility with another one of your plugins that is also calling the pclzip libraries.

Try deactivating all your plugins (except for Akismet if you’re using it) and then activate AIOSEO. If it activates with no problem then reactivate your other plugins one by one. When you activate the conflicting plugin you should get another error. Basic troubleshooting and all that.

WP-Sticky is no longer needed since the function is already built into 2.7 (in the publishing module in TinyMCE and the “Quick Edit” feature for posts.

For Twitme, check the 2.7 plugin compatibility list to see if it’s listed and what the problem might be and there also might be similar compatible plugin listed there as well. I know there are other similar plugins for Twitter that are compatible with 2.7. Use 2.7’s “Add New” feature under “Plugins” to search one out.

I tend to agree after working with the problem that it’s not a WP 2.7 problem specifically.

Just by long habit I checked my “wp-config.php” file for “define( ‘WP_CACHE’, true );” while experiencing the problem and it was there. Now that I think about it, I regularly turn off caching if I’m working on the sidebar content or other items that need caching to be off while viewing any changes made. I’ve always been able to turn caching back on and have it just start working successfully without having to check “wp-config.php” for the entry.

Super Cache has always been well behaved in the past. Turn it on/turn it off/deactivate it/reactivate it…no problems. Pretty amazing considering what it does (nice job that one).

Was it after you upgraded to the latest version that the problems started?

It seems so, at least in my case. The funny thing was that I had two sites both running the same versions of 2.7, upgraded at the same time (nightly builds) and the only thing that changed the day Super Cache stopped working was updating to Super Cache 0.8.5 from 0.8.4

Strangely enough, 0.8.5 was working fine all morning on both sites (then at RC1 beta3-almost RC1-almost), I went to lunch, came back, checked the sites, and both sites were no longer being cached. The next morning, both sites were being cached but no more than an hour later–no caching. Upgrading to 0.8.5 was all that changed over that period of time.

Currently, only the site running WP 2.6.5 is not being cached. The other two 2.7 RC1 sites are currently being cached properly with 0.8.5 (go figure).

Oh yeah, I see that 0.8.6 has been released. I’ll give it a try. I’ve got 3 sites that are running 2.7 RC1 to test it out on. .htaccess Rules can stay the same I’m assuming?

Sorry for the long replies. I have a bad habit of being too wordy.

I’m on a Bluehost shared server and Super Cache was working fine with all previous versions of WP back into the 2.5 series all the way through the 2.7 trunk builds until a few days ago when the cached pages stopped being served altogether. Nothing changed on my server with the exception of the MySQL database being upgraded from 5.0.45-community to 5.0.67-community and I really don’t think that was the problem.

I’ve been running PHP 5.2.6 (fastcgi) with no problem either until the last few trunk builds (via the “Stay Updated” link) prior to RC1 when the plugin simply stopped working. At RC1, I enabled “compression” on Super Cache’s settings page and the plugin started working again. This makes no sense to me.

Yesterday, I upgraded a client’s site from 2.6.3 to 2.6.5 and Super Cache simply stopped working for her as well and enabling compression, uninstalling and reinstalling Super Cache, re-entering the .htaccess rules had no effect. I just left the plugin activated and logged out since her site was still loading fast enough (.55* average). She’s running the same MySQL and PHP versions as I am on a different Bluehost server entirely.

Just on a whim I checked her site’s source code this morning and there was the Super Cache entry at the bottom just like it should be and just like it wasn’t the day before. Nothing changed at all overnight.

No errors in the error logs. No errors in the Apache logs. Nothing to give me a clue as to what went wrong. Paleo Pat and the others who had problems do not run on Bluehost that I know of and most likely have different set ups then myself and my client. Some folks are having problems and some are not (all running either 2.6.5 or 2.7 trunk or RC1)

Ghost in the machine?

And many thanks for this most excellent plugin. Us shared server bloggers would be lost without it.

Otis,

Seems like the speed of your site is better or at least it is from my end. Doesn’t seem sluggish any longer.

Anyway

Since they upgraded all their servers I, my wife and several fellow WP bloggers have had good performance with Bluehost. Others have good luck with Dreamhost and of course there’s always the ones who have the same type of complaints about both. IMHO for a personal type blog with a fair amount of traffic I recommend either one.

Here’s my experience with the Google XML Sitemaps plugin and upgrading from 2.3.3 to 2.5 and now to 2.5.1. Basically I’ve had no problems with the plugin at all so here’s some info in hopes that it might help the folks who might be having memory problems

For me: The debug information comes through with no errors, I can rebuild the sitemap successfully (actually turn around time to page refresh was about 12 seconds):

The building process took about 2.76 seconds to complete and used 20.25 MB of memory.

Checking with Google’s Webmaster Tools, my submitted sitemaps show no errors, my site is correctly indexed in accordance with my sitemap and “robots.txt”. No errors.

I ran a test post to try and duplicate some of the problems of publishing taking over 50 seconds for some folks and from time I hit the “Publish” button to the actual moment the post was published was Approximately 11 seconds. The sitemap rebuilt normally at time of publish:

The building process took about 6.37 seconds to complete and used 20.25 MB of memory.

One of the things I did quite awhile ago was to stick a “php.ini” file (normally found in your root directory…I made a copy of mine) into my “plugins” folder where I was concerned about script functions that took more than the default 8 or 16 MB’s of memory to execute. Also, after a major upgrade, it’s not uncommon for certain scripts which ran fine before to require more memory to execute the first few times. I don’t know why this is exactly but I’ve encountered it more than once.

Here’s a couple things you can try:

1. in the Google XML plugins settings, set memory limit to 32 and save your settings. Then try rebuilding again. If successful then try another post and see what happens.

or

2. In any WordPress install, your host should have put a “php.ini” file in your root directory. Bring this file up in your favorite editor and look for a section called “Memory Resources” or the equivalent. It should have a couple of lines that look like this:

max_execution_time = 30 ; Maximum execution time of each script, in seconds
memory_limit = 32 ; Maximum amount of memory a script may consume (8MB)

If memory limit isn’t equal to 32 (it might be set to 16 for example) then change the number to 32. You might also want to make sure that the “max_execution_time is set to a minimum of 30 also. Once that’s done, save it back to your root directory on your server. Now try to rebuild your sitemap.

If you encounter the same problem then make a copy of that “php.ini” file and drop it right into your “wp-content/plugins” directory and try rebuilding once more. I’d be surprised if one of these solutions didn’t solve your problem.

HTH

Okay, why would the plugin work for me and not for others? The debug information comes through with no errors, I can rebuild the sitemap successfully (actually turn around time to page refresh was about 12 seconds):

The building process took about 2.76 seconds to complete and used 20.25 MB of memory.

I ran a test post to try and duplicate the problem and from time I hit the “Publish” button to the actual moment the post was published was Approximately 11 seconds. The sitemap rebuilt normally at time of publish:

The building process took about 6.37 seconds to complete and used 20.25 MB of memory.

One of the things I did quite awhile ago was to stick a “php.ini” file (normally found in your root directory…I made a copy of mine) into my “plugins” folder where I was concerned about script functions that took more than the default 8 or 16 MB’s of memory to execute. Also, after a major upgrade, it’s not uncommon for certain scripts which ran fine before to require more memory to execute the first few times. I don’t know why this is exactly but I’ve encountered it more than once.

Here’s a couple things you can try:

1. in the Google XML plugins settings, set memory limit to 32 and save your settings. Then try rebuilding again. If successful then try another post and see what happens.

or

2. In any WordPress install, your host should have put a “php.ini” file in your root directory. Bring this file up in your favorite editor and look for a section called “Memory Resources” or the equivalent. It should have a couple of lines that look like this:

max_execution_time = 30 ; Maximum execution time of each script, in seconds
memory_limit = 32 ; Maximum amount of memory a script may consume (8MB)

If memory limit isn’t equal to 32 (it might be set to 16 for example) then change the number to 32. You might also want to make sure that the “max_execution_time is set to a minimum of 30 also. Once that’s done, save it back to your root directory on your server. Now try to rebuild your sitemap.

If you encounter the same problem then make a copy of that “php.ini” file and drop it right into your “wp-content/plugins” directory and try rebuilding once more. I’d be surprised if one of these solutions didn’t solve your problem.

HTH

Upgrading to WP 2.5 seems to have solved this problem or at least I haven’t seen it for awhile now. I also eliminated all but one plugin that was not hosted on the www.remarpro.com plugin directory. The one plugin that is not hosted on the directory is the old Favicon Manager which has never caused a problem.

Anybody on WP 2.5 that’s still experiencing the problem?

oTis,

Who is your hosting company? Wouldn’t want to recommend another hosting company that you might already be using. ??

Thanks Kafkaesqui! Looks like this is the answer. And me being someone who Googles just about everything like this didn’t even think about it this time around. Go figure. I’ll try it out in the morning.

Perhaps this is also the reason for the 2.3.2 disappearing posts that some folks are having.

Thanks again and I’ll post back on the results.

Nokao,

Just another “shot in the dark” question. Is your customer by any chance, using the “WordPress Mobile Edition” plugin to enable viewing of their site on a mobile device? If they are and haven’t put the mobile “theme” that’s bundled with the plugin into the “themes” directory then every time someone tries to access your customer’s site with a mobile device, WordPress won’t find it and will revert to the Default theme.

It’s a long shot but it’s surprising how many people with just your problem come back and say “that was it!”.

It probably means your host started verifying that the sending email address actually belonged to your site which means if you use an off site email address such as your local email address, Gmail, Hotmail etc, the mail doesn’t get through. I posted about this awhile back and there’s a small plugin that was worked up by a WordPress developer to work around the problem. Works for me just fine and you can download the zipped up plugin from my site (I got it from WordPress Trac). This will enable you to continue to use a non-site related email address for notifications.

https://just-thinkin.net/2007/11/wordpress-231-no-email-notification-fix/

Also, you can solve this problem by going into your hosts cPanel (or whatever) and creating a new email address like this: “wordpress@(yoursitename.com/net/???)” and use that one for notifications instead that way no plugin is required.

Hope this helps.

@mlanger,

If you’re still having problems, I wrote a post about a solution that might work for you. It did for me. Here’s the link for it:

https://just-thinkin.net/2007/11/wordpress-231-no-email-notification-fix/

You’re very welcome. There’s always a chance that a single download might be corrupted, uploading to your install might drop a bit or two on the way or (usually) an overwrite just doesn’t work properly. It’s always wise during an upgrade to backup up your database first and then delete those 2 directories I mentioned before uploading the new ones. Overwriting the root files with the new updated ones is safe enough but trying to overwrite the “wp-admin” and “wp-includes” directories is always asking for problems.

And to mark a topic resolved is easy (you have to be logged in of course). If you began the thread, like you did this one, at the top of the thread in the information box that contains your title you’ll see a drop down menu that has “This topic is” to the left of it. Just select “Resolved” from the drop down list and then hit the “Change” button.

Happy blogging then…

You’re very welcome!