PHP error

[ozzy47]

Originally Posted by Snowhog

We were also getting php errors concerning preg_replace() /e being depricated and to use preg_replace_callback() instead. For each reported occurrence, I made the change in the affected .php file. Would I not have had to do that with this fix??

Probably a error with a mod, see if you can find out which one.

[Snowhog]

ozzy47 -

We are now running 4.2.3 Beta 3. Should I undo the fixes identified and made in this thread?

[ozzy47]

You can try, I am not sure if they are needed or not, as I have not upgraded any of my sites to 4.2.3 just yet.

[Snowhog]

I guess my real question should have been, is it necessary to undo the changes? So far, everything is working as expected. Rule of thumb is, "If it ain't broke, don't fix it." As nothing is presenting as broke, I wont 'fix' the 'fixes' I fixed.

[ozzy47]

Well the change I told you to do in post #2 would have been overwritten when you loaded the new files to the server. As well as any other changes you made to the core files.

[Paul M]

Originally Posted by ozzy47

In includes/class_core.php locate lines 5683-5685 which should be this.

 case E_NOTICE:    
        // Just ignore these completely //    
    break;

And change it to this.

case E_NOTICE: 
   case E_STRICT;     
   case E_DEPRECATED;        
    // Just ignore these completely //  
break;

This is/was completely unnecessary.

To turn off the extra warning/error reporting in 4.2.2 use SKIP_DS_ERRORS - see this post.

Its already fixed in 4.2.3.

[ozzy47]

While it may be unnecessary, I prefer not doing the hiding of all the warnings if at all possible.

[Snowhog]

Ah, true. I like that even better, as that means that all is working as it should. No bandaids. Cool.

[Paul M]

Um, you do realise thats exactly what your change did, just by an unnecessary edit to a core file rather than by the designed method.

[ozzy47]

Yes, but that was for one error only, or did that disable all of them as well?