Cleared the cache then site won't load properly

The cache clearing facility doesn't work on Admin so I resorted to clearing it manually using shell. My D7 site does not load properly henceforth. What are the cache files that I need to modify to get my site running smoothly again?

If no fix is available for this issue, I am thinking of the resolve of installing a fresh D7 on another folder and migrating all data (including custom fields). Any suggestions?

I ran into this the first couple days I played with Dolphin7.  Never sure what caused it so I re-installed by: clearing the cache, re-uploading the /install/ folder and accessing domain.com/install/index.php.  Just needed a couple tweaks afterward to get things back to normal.

Since then, I've got a backup running regularly to back up the files & database just in case it ever happens again.  Also, before I make a major change that I think may mess things up in that way again (where even deleting cache fails to recover), I back up the cache & cache_public folders to my local workstation before & upload them again if the problem is triggered - but that's only a temporary solution to help figure out the issue because ultimately the problem will re-appear if I don't figure out the issue.

The only other time I ran into this was when after about 1/2 day of investigation, I introduced a typo into one of the PHP files I changed, which was enough to cause PHP loading of the core code to fail & subsequently just displayed a blank white page.  Double-check any files you edited recently and look for typos (especially typos that would cause PHP execution to file) in your edits.

Check your permissions too. For instance, your cache folders should be set to 755.

I think this may be my problem as well, just don't know how to fix it, and can't seem to find anybody who has the time to do it.  Whenever I use the builder, it changes my file in the inc/cb_cached/pageview.php , so that listings in my business directory mod do not work. 

Set CHMOD to 755 and still the same.

JBFB, I'll keep your tip in mind regarding backup, much appreciated. I agree, my problem might all begun with a misprogrammed PHP file... introduced by a free mod I installed the other day.

Is your site running PHP with Apache Module or is it running suPHP?

suPHP set the cache/ & cache_public/ directories to 755

If your running PHP with Apache Module please set your cache/ & cache_public/ directories to 777

Your host can tell you which version your running if you don't know.  If the site was running correctly and then started erring and you we're able to CHMOD the files to 755 then I'll guess you have PHP with Apache Module and they need to be at 777, where they were.

Thanks mydatery, running with PHP 5.2.6 with Apache so it should be back at 777.

JBFB, your input on backing up and restoring cache was very useful and my site's running. But still, I can't find what went wrong with my PHP file edits.

The way I see it at the moment, everytime I perform an Add/remove module I have to restore cache otherwise my site won't work.

i had the same issue.  I had to delete all the files from  httpdocs/cache.  After that I was able to use the site.

The problem seems to be that the cache is in progress; hence site become ****very slow********.

I think there is a bug in php 5.2.6.  I think the issue is fixed in 5.3

Yes, sometimes it's hard to tell if the problem doesn't appear right away.

Because of the way D7 caches code/templates, an update isn't immediately apparent until you're sure a full flush of the cache has been done (that means both clicking the cache-clearing options in Admin as well as manually removing remaining cache files via FTP or shell access to the site).

Since then, any time I change even minor things with the templates or code, I flush flush flush the cache folders.  I also only make one minor change at a time.  That way if there is an issue, I know what probably caused it.  It makes the modification process slower, but not as slow as it would be if I have to chase down a bug.

jelaiz, although that temporary fix will keep you "going" eventually it will all break apart because by restoring the cache, you're just delaying the site from inevitiably breaking when the latest code is compiled in & executed from the cache.  It may *appear* fine when you do this but chances are some of the features of the things you've added/changed will not fully function as intended.

Personally, I think the Boonex method of code caching is a poor design.  The main reason is because unless you run a totally dead site there is always someone who loads a page between the time you go to clear the cache & finish clearing the cache.  So, the safest way to handle the process for a live site is to temporarily password the whole site, clear the cache, then re-enable access.  That is obviously a VERY BAD method.  Instead, I will choose to enable my own cache-clearing code outside of D7 so that such issues are minimized.

So try that method the next time you do an update.  You may also consider using a temporary Apache rewrite as a means to display a 503 Server Busy response "We're updating the site, we'll be back in a moment" message rather than passwording things during an upgrade.  I do that whenever I have to upgrade large sites.  It doesn't confuse site visitors and by sending search engines a 503 Server Busy response header, it saves me from possibly mucking up my organic listings.

As to why the Boonex code caching is a poor design, it's pretty simple.  It doesn't do a timestamp or CRC check/lookup to determine whether to use items from the cache or to refresh those items.  It depends on a client-side action and, in the meantime, a huge cache is being built up which would get into disarray whenever someone either uploaded new code and/or was in the middle of clearing the cache.

The proper way to handle code caching is to maintain lookup files that allow it to track whether there is new code to be cached (or re-cached) and immediately updating the cache to support it.  That way, as soon as something new is uploaded, the changes propagate to the affected files.  I run huge sites where I use my own CMS that handles this sort of logic and it saves me from ever having to do anything with the code or page cache while ensuring changes are immediate and free from defect during a transition.

Are you running on a Shared, VPS or Dedicated Machine?  I ran PHP 5.2.6 while on VPS and upgraded to 5.2.9 when I went to my Deds, and I've never had a problem on this with either.  I'm thinking this is more of an issue.  Granted, while running 5.2.6 I was running D 6.1.4, on the 5.2.9 I run both 6.1.6 and D7.0, both in Apache with CGI & suPHP is enabled.  Yes, I have it enabled on the server but still run in an Apache environment.  This allows the best of both worlds for me.

Perhaps you need to check the settings on your PHP Version or consider upgrading it to 5.2.9.  5.3 is also a possibilty, I see alot of people running it, never have myself.

JBFB, yeah I've read some reviews from other sites on the same view of Boonex so I'm doing my best now to work around flaws like this I'm affected. My site has 2,500 members and the situation is that re-caching doesn't finish at all. If there a way to expedite the process, like a shell runnable script or other shortcuts? Thanks for that valuable tip on the Apache error message.

jvd, mydatery

I'll consider upgrade to version 5.3 and advise you how it goes.

mydatery, answer to hosting type is that I'm on dedicated virtual.

I've heard from Boonex people that the cache clearing links in the Admin area may not fully clear the cache in the cache folders due to permissions issues not being set right on the server or some PHP INI type settings not being set right - which can be fixed with a PHP.INI file or with an edit to htaccess.  I don't like either method since it adds more layers I'd have to keep track of if I need to migrate the site to a different server so I just coded my own cache-clearing Perl script and modified the Admin cache block to have a link to it.

#!/usr/bin/perl
print "Content-type: text/html\n\n";
my $Account = 'xxxxxxxx';
my @CLEANPATH = (
"/home/$Account/public_html/cache/",
"/home/$Account/public_html/cache_public/",
);
for my $DIR (@CLEANPATH) {
opendir(DIR, $DIR);
my $COUNT;
while (my $FILE = readdir(DIR)) {
unlink("$DIR$FILE") unless ((-d "$DIR$FILE") || ($FILE =~ m/\.htaccess$/i));
$COUNT++;
}
print "Deleted $COUNT files from $DIR<br />\n";
closedir(DIR);
}

EDIT:

So now apparently Boonex requires a paid account to post or reply on their forums. There's something not right about that. Testing to see if I can at least edit my already-made posts...

Sorry for this really elemental question, but when chmodding those cache folders, check or un-check recurse to all files?