[support] turn debug on?

[Heine Deelstra]

sander-martijn wrote:
> Yeah I found that this morning - I've tried the long list of possible 
> solutions - deleting references from the systems and variables tables, 
> deleting the devel tables, empty cache tables, run cron.php.  still not 
> working.

If deleting the dev_query variable doesn't help, I doubt you are experiencing this
particular issue. To be sure, manually remove the debug_backtrace from the relevant
database.??.inc file ($bt = debug_backtrace();).

> Honestly the attitude of the maintainers of this module is pretty awful.
>   They're claiming that a warning on the main page is all that is needed
> and that they shouldn't have to fix the module since it's a bug in zend.
>   Well I was under a crunch last night and quickly and wrongly assumed
> it was a zend related module - knowing that i had installed no such
> module I went forward.

If I get this right; you read the warning, then decided to go ahead anyway?

Zend Optimizer is a Zend (the PHP company) related module and the cause for a lot of pain
through the years, but still in use on many hosts.

>  This module should not allow itself to be
> installed if the wrong version of zend is present, or as some suggested
> should disable the buggy functionality.  now my site is hosed and none
> of the prescribed solutions are helping.

The wrong version of Zend is a subtle issue and depends on the PHP version you are on. I
am with the module maintainers that they should not step in this sorry mess.

Or, in the words of PHP.net, "Always disable any Zend or other 3rd party extensions (Turck
MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug."

> The only positive thing about this is that I have a dev environment and 
> installed it on there.  I feel really bad for those that are like me 
> only days from launch, install this to debug a problem with a module 
> someone else has stopped maintaining but only have one instance so lose 
> everything.  always run at least two (preferably 3) instances of any 
> site in development.

It's painful I'm sure, though I'm not yet convinced your site is unrecoverable, or that
you've exhausted investigative possibilities. Of course, sometimes it's much quicker to
revert to a backup / different site that to satisfy ones curiosity.

Heine

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/support/attachments/20070927/670a7c80/attachment.pgp