quartzimodo

I’m glad that I’m not alone with the admin panel comment editing problem after upgrading to the earliest version of WP 2.8. As I hadn’t been posting new entries in my watch blog since last April, I didn’t notice any problems until very recently.

I did not realize that DB Cache was incompatible with version 2.8 upwards, thinking it was a quirk of WP 2.8. Currently I’m running WP 2.8.4 and after seeing that the comment editing and tagging problems persistent, I Googled for an answer and found a post stating that DB Cache was the culprit.

I disabled DB Cache and tried to edit one of my readers’ comments. It worked flawlessly. When I re-enabled DB Cache, the symptoms returned. I later found out that the author of DB Cache has yet to update this plugin to work with WP 2.8.x.

IMO, my blog appears to perform faster with DB Cache enabled (along with WP Super-Cache), therefore while waiting for DB Cache to be updated for compatibility with WP 2.8 all I have to do is to temporarily disable it when I have to edit comments and turn it back on when I’m done.

I know it’s not an elegant workaround but I’m already addicted to DB Cache until I find something equivalent or better. ??

On an unrelated note, I also discovered that the automatic upgrade of WP core files within the admin panel usually fails unless I manually disable all active plugins. While the instructions tell you to back up your databases before upgrading (of course I do backup my WP database before performing the auto upgrade), WP unfortunately doesn’t tell you to disable your plugins first.

I assumed that the upgrade job will take care of that for you (for example, upgrading an individual plugin within the admin panel will automatically disable the current plugin first), but it looks like WP doesn’t disable all of your plugins.

You have to remember to disable all active plugins first before performing the automatic WP version upgrade and go through the list of plugins that require manual enabling after upgrading to the latest WP version. A good example is the WP Super Cache plugin, which always defaults to “OFF” whenever it is disabled albeit temporarily.

I started using this plugin and really liked the stats. Then I noticed I had a performance issue (15 seconds to serve a page, but sub second to render it). When I disabled [Plugin: StatPress Reloaded] my time to serve went back to sub second.

I’m afraid I am in total agreement with “ed4becky” with regards to performance issues. I used the original StatPress (not StatPress Reloaded) since early 2008 without any problems whatsoever.

When the original author discontinued support for the StatPress plugin, StatPress Reloaded (SP-R) was born. Needlessly I installed SP-R, hoping that it would be a marked improvement over the original.

While SP-R had better reporting features, unfortunately it resulted in massively slowing down my blog (it’s at load times. Even access to my WP Dashboard was crawling at a snail’s pace.

What eventually happened was, my web host provider, Bluehost.com first yanked my site offline without informing me in advance last December.

The tech support whom I chatted with told me that SP-R resulted in a huge MySQL file size (110 MB) which he claimed degraded the shared server my site was hosted.

He allowed me to make amends and empty the SP-R tables and all went well. I continued to use SP-R diligently, making sure that it purged records over 30 days and disabled visits by web crawlers and bots.

Today Bluehost.com suspended my site again, much to my disgust! An irate tech support guy whom I chatted with just copy & pasted my SQL database structure and sent it via the chat box.

I submitted a support ticket asking my site to be reinstated but there was no response. Fortunately many hours later I managed to reason with a different tech support guy and he just bluntly asked me “How are you going to fix it?”. He knew what was wrong but was just testing me if I was clueless.

I told him that I via FTP I had deleted the offending plugin – “StatPress Reloaded”, it should not degrade the shared server and pleaded him to reinstate my site. Luckily for me he relented and my site is up and running again.

It seems that I’ve found this equation: Bluehost.com + StatPress Reloaded = DISASTER!!!

My site generates less than 1,000 visitors a day. So it wasn’t a bandwidth issue nor was it a disk space quota issue. It was not even the size of the MySQL database (which was 40 MB at the time my site was suspended).

The problem is that SP-R chews a lot of CPU cycles and overloads the server with a lot (and I mean a lot) of SQL queries each time my site is viewed.

I have even set up WP-Super Cache and CSS and Javascript compressors to lighten the load on my site.

Needless to say, I signed up with another web host provider and will be migrating my site soon. I can’t afford to have my site down for the third time due to SP-R and I’m sorry to say that I won’t be using this plugin again. (There’s always the AW Stats service on the web host to check my visitor info).

Nevertheless, I’d like to thank the author of StatPress Reloaded for his hard work and diligence in continuing the work of the original programmer.

Therefore if your WP blog is hosted with Bluehost.com I would strongly discourage you from installing StatPress Reloaded.