Patch successful but WSOD

Hi, just tried to reverse the patch (again seemed to be successful)

$ patch -p0 -R < sites/all/modules/coresearches/DRUPAL-6-4.patch
(Stripping trailing CRs from patch.)
patching file modules/node/node.module
Hunk #2 succeeded at 971 (offset -1 lines).
Hunk #3 succeeded at 1135 (offset -1 lines).
Hunk #4 succeeded at 1312 (offset -1 lines).
Hunk #5 succeeded at 1786 (offset 14 lines).
(Stripping trailing CRs from patch.)
patching file modules/search/search.module
Hunk #1 succeeded at 1081 with fuzz 1 (offset 3 lines).
Hunk #2 succeeded at 1141 (offset 3 lines).
(Stripping trailing CRs from patch.)
patching file modules/search/search.pages.inc
Hunk #2 succeeded at 122 (offset -2 lines).
(Stripping trailing CRs from patch.)
patching file modules/user/user.module
Hunk #1 succeeded at 559 (offset 2 lines).

...but same Fatal Error message continues!
Everything was working fine before applying the patch!

If you have a WSOD, first check server error logs. It might, just might, be something else.

I applied the patch to 6.10. The patch succeeded, but my searches stopped returning any results. I put back the original files, including the .inc file, which leaves no .orig behind, but I always keep backups of all my stuff.

Once I put the files back in place, the results returned.

I am assuming you are referring to the "Recent Log Entries"? In which case cant see any error reported at all!
I replaced the node.module, search.module, search.pages and user.module files and now all works well. Just a shame I cant use Core Searches cos it would be extremely useful :(

Actually, I mean your httpd server error logs, usually located on your server at /var/log/httpd/error.log or something like that. Depending on your host, might be available through a UI provded by your ISP, might be something you can check via command line. You will get a message like

PHP Parse error: syntax error, unexpected ')' in /www/mydrupalsite.com/sites/all/themes/mytheme/node-story.tpl.php on line 21, referrer: http://mydrupalsite.com/node/1

One PHP syntax error will WSOD your site, which is why a dev system is so important for testing before putting things on a live site.

A WSOD is either a PHP error, which has to be tracked via httpd server logs, or it is the result of a timeout of a process like a cron or a massive batch process (like as I've found batch publishing hundreds of nodes in one shot times out without completing the job)

The difference is that the former means your site is completely inaccessible, the latter just means the one process timed out but that the rest of the site can be seen as usual.

Thanks for your time on this.
Fortunately my site is not on-line as I am still building it.
I cant see any errors in the Apache or MySQL error logs for that day.

I'm having a hard time imagining why user_load would be affected. Can you open up user.module and do some rudimentary inspection? Are there PHP syntax errors? Is the function user_load there?

Sorry, suffering from a distinct lack of ability here but am desperate to help in any way I can as really need this patch.

I re-applied the patch (successfully) which resulted in the same error.

I ran a syntax check at ( http://www.meandeviation.com/tutorials/learnphp/php-syntax-check/do-synt...) on the user.module file after the patch and this checked out ok.

The function user_load is definitely there and looks much the same as it did before the patch was applied.

Please let me know if there is anything else I can do. Would really like to fix this.

mmm...now I seem to have a bigger problem. I have tried reversing the patch (no effect) and I've tried replacing the respecitive files but nothing gets rid of the WSOD! I thought that maybe I needed to run update.php but obviously cant get to it thro the interface and, for some reason, settings file wont let me change FALSE to TRUE!
Now I REALLY do need help!

Oh and it seems that it isnt just a problem with that one function. Trying to get into the site from the localhost afresh results in
Fatal error: Call to undefined function user_access() in C:\wamp\www\drupal2\includes\menu.inc on line 449

Sorry about this but when I try to run update.php from the address bar I get

Fatal error: Call to undefined function node_get_types() in C:\wamp\www\drupal2\includes\theme.inc on line 923

Seems all the functions in the files updated by the patch are no longer 'defined'. Having replaced the patched files with original ones I'm guessing I somehow need to have the system 're-examine' these files but I dont know how!

I am also guessing that maybe if I could have had the system 're-examine' these files (and so 're-define' the functions) following the patch then it might have worked?

Have checked the system table and status is set to 1 for these modules and paths look correct!

At this point you need to do the following:

1) Remove any files that came with core searches
2) Replace your core Drupal files with the latest release (this might be complicated if you've applied other patches that you depend on - you'll have to reapply them)
3) Guarantee that your site runs normal.

Then we can get back to reapplying the patches. Some questions:
1) are you using an op-code cache (APC, XCache, PHP Accelerator)? If, does it stat the files or have you perhaps turned that feature off to increase performance?
2) The core searches is patches and two modules. Were the modules enabled or disabled when these errors happened? Not that it should make a difference... they're designed to be optional, and to leave core in a working state.
3) ... there is no 3 :(

Hi Robert, thanks so much for your help. Cant tell you how many beers I owe you. Let me know when you are next in London and you wont be putting your hand in your pocket!

I cleared up all the files that even had a passing reference to Coresearches, backed up my DB and then installed 6.12.
I got a whole bunch of error messages saying there were problems with the User, Search and Node modules and that permisssion had been denied by bootstrap.inc.

I checked the bootstrap status of these modules and they were all set to 0 in the System Table. I went out on a limb a bit and changed the Node module bootstrap status to 1 thinking that this might at least clear up the error messages associated with Node. It cleared up ALL the error messages. Now I am thinking I should change the bootstrap status of the other modules also?

Am I right in thinking that the bootstrap process is like a normal boot process which loads a bunch of modules (and their associated functions etc)? In which case could it be that the patch somehow excluded the three modules from this process and so the functions they contained were left undefined? If so, is there somewhere I can find exactly which modules should be included in the bootstrap process so I can check that their Status is also set to 1? Or am I talking nonsense?

PART II Qu1 is entirely unintelligible to me, I'm afraid, so I'm guessing I'm not using any of those things!! :)

As for the two Coresearches modules I can say that they were certainly DIS-abled when I applied the patch.

Thanks again for your time on this.

ok, you've now found the problem. Node module should never be disabled (0 in system table) on any Drupal site ever. Same with user. If you want to post the results of SELECT name, status FROM system here I'll tell you if there are any others that you're missing, but if the errors are gone, then you should be good.

Just a note on Core Searches: it removes part of the node module and part of the user module and sticks them in new, optional modules. You still absolutely need the node and user modules, though, even after patching. So if you try to go through this again just make sure they stay enabled (usually they're required and can't be turned off...)

Hi Robert,
please note that the STATUS of these modules was NEVER set to 0 it was ALWAYS set to 1 but the BOOTSTRAP column was set to 0 (and still is in the case of the User and Search modules).

Are you saying I need to reset these to 1 also?

Ah, sorry I misunderstood.