petercasier

Also check if you are on gridhosting. As said, does not cost you anything, and the performance is slightly more stable.

If none of that works, and you can not move from Godaddy, then the only thing to do involves manual work:
– put the preload to 0 after a full preload cycle.
– put the expiration time to 0
– if you modify a page, manually delete that page from the cache files directory
– when not logged onto WP, go to to that page, so the cache is generated.

but that is all pretty far fetched.

Peter

$3.74/month… ?? did you read the link I posted? “Share hosting: pay peanuts, get monkeys”, which tells my story with Godaddy. “Can not recreate the issue” is all to familiar to me.

I honestly believe that a slow/erratic site is worse than no site, certainly as in your case, you want it to be business card for your company…

You would not print paper business cards on oily stained ragged paper neither, would you? ;-)))

James,

my take on it: If Godaddy already times out with a 500 error on a single non-cached page load, then imagine what it will do if it has to (pre)load 232 pages every 30 or 60 minutes… It will take a long time. So my bet is that the preloading cycle does not finish regularly, thus you always have a lot of uncached pages.

I am not sure but think that when preloading, Supercache first deletes the previously loaded pages and then the preloading starts. So if preloading is that slow, there is a good chance you will hit a non-cached page.

So the task to do is to watch the progress of the preloading. If you see indeed the preloading going very slow, not finishing in its cycle, then that is the problem you saw to start with “Why am i seeing so many noncached pages”…

On Godaddy, the only thing that could help you a bit, is to go to gridhosting (does not cost you anything, and is done for free, automatic and conversion is done pretty fast). Grid shared hosting is emmm.. less unreliable.

Since I left Godaddy for Hostgator, my life took a turn for the better. (I went pretty far, and went for VPS hosting, so I could control the whole server setup… Night and day difference.)

PS: I still have several test servers on GoDaddy I use to design new blogs. On several of them, with 200 posts content, I have caching running to test things out. I often get an automated email from supercache that the preloading stalled. So there you go.

Peter

Godaddy, right? If so, then the 500 error has nothing to do with you. A typical Godaddy error.

James,

Nice clean site, well done.

For as far as I can see, your site is running on Godaddy, probably shared hosting. Their speed is pretty uncontrolled (and according to my 3 years experience not worth a penny), so you will immediately see the difference between a cached and a non-cached page. (as you noticed) The non-cached pages were very slow, even though they did not have a lot of data.

A site like yours is – as you described – ideal for pre-loading.

Now maybe you are still working on the site, but I saw that most pages were not cached until I visited them for the first time. After that, they remained cached, and loaded faster on a re-visit.

Do you have the preload on at the moment?

PS: you can always check which pages/posts are cached, by checking the cache files in /wp-content/cache/supercache/yourdomain/*… If you delete your cache, and then preload the cache manually, there should a be folder for every single page or post you have (after the preloading finished)…
I think there is a problem in preloading (if at this very moment you had it all preloaded).. What is the number of posts/pages does the preload tabs shows?

Peter

“too many cached pages to show content”, is just a notice for the dashboard. The pages are actually cached, but there are too many to show the individual cached pages/posts on the “content” tab.

For as far as I understood, the GC has no influence on the expiration of preloaded pages (Donncha to correct me if I am wrong).

If you set preloading to 60, and have “preload mode” enabled, then all pages/posts will be pre-cached every 60 minutes, so 60 minutes will be your expiration. If in the mean time you would have created new pages, in between preload cycles, the normal cache mechanism would cache the page (if visited), and those would expire with the GC value.

So in your case, you have two options:
– preload to a high value (even more than 60), but manually delete the cache and manually reload when you update a post/page for force the caching.
– preload to a low value, and know that updated pages will be automatically recached at the next cycle (thus no manual work).

If you give me the URL to the site, i can see if the cache is actually working on the different posts/pages.

Peter

Are you talking about “pages” or “posts”? If you want posts to never expire, just put the GC to “0”.

Double check at the bottom of the source, of the slow loading pages/posts if the pages/posts are actually cached.

Note that if you set “Clear all cache files when a post/page is published”, indeed, the cache will be flushed. If you do that, then it is good to manually preload (otherwise you will have to wait until the next preload cycle – 60 min in your case), for all pages/posts to be cached again (except those pages/posts that get visited in the mean time).

Donncha to correct me if I am wrong.

Peter

I seem to be mostly talking to myself here, but this is the workaround I found:

At the very top of the /plugins/wp-mobile-detector/functions.php replace the following:

<?php
/*
Validate the mobile theme
*/

with

<?php
error_reporting(E_ERROR | E_PARSE);
/*
Validate the mobile theme
*/

This avoids PHP “warning” errors to be logged into the error_log

** The best solution however would be to actually embed functions.php line 213 with (error off) and (error on) as it reads the HTML code. Most bloggers won’t have access/control over some errors, and it is not a good idea to have PHP warnings logged each time a mobile page is loaded.

P.

Hmmm.. allow me to answer my own query :-S

There seem to be a whole series of repetitive errors:

Unexpected end tag : p in Entity, line: 109
ID searchform already defined in Entity, line: 111
ID search already defined in Entity, line: 112
Attribute class redefined in Entity, line: 141
htmlParseEntityRef: expecting ‘;’ in Entity, line: 148

It seems these are parse errors which are generated when reading the original HTML file.

The “ID searchform” and “ID search” were generated as the mobile theme “Jester” by default defined a search form, and I had already a search form in the side column too, so it found a duplicate.

I guess I now have to look for an end tag p without a begin tag and which %%% attribute class has been redefined.

Is there any way to define the PHP warnings NOT to be logged when the mobile theme is loaded? I don’t want my disk to clog up with HTML parsing problems (apart from the fact that it slows down the loading of the blog on mobiles).

.. or even better, check if the homepage is flagged to be cached or not, and if so, cache tester might check an archive page, or the first blogpost etc…

By the way, in PHP 5.3.2 the issue is easily resolved, actually:

look at /usr/local/lib/php.ini

look for something like this

extension=pdo_sqlite.so
extension=sqlite.so

Just comment it out:

;;extension=pdo_sqlite.so
;;extension=sqlite.so

Brought the permalinks settings page back to me. ??

Donncha,

Had the same issue as @sollars on a development site https://petercasier.be/dapablog

Tried the development version, and issue was resolved.

Thanks!

Peter

BTW ran into this problem on HostGator (who runs PHP 5.3.2 on their VPS servers).

This resulted in the permalinks settings page giving me a blank page. While the permalinks actually work, you can’t change the settings anymore through the admin menu…

Caught the error in the PHP error log.

(sad-face)

@frederick,

unfortunately not… I disable all caching except page caching (lifetime 1800) but the cache does not refresh for days.
I had to disable the caching.

As the content for the entire site consists almost solely of RSS feeds, I think it generates something uniquely conflicting with the caching algorithm…

It is a pity as the W3 caching, did significantly improve the presentation of each page…

Peter

thanks, will do that.