Bug Notes |
|
|
Well, this is confirmed. These are notices. If we wanted to have them all fixed, code will be probably huge, what may result into more longer parsing time. However, I will see if it is possible to eliminate such notices, or it is very difficult goal. |
|
|
|
Some error_reporting() calls were added into phpMyEdit for preventing before notices reporting. Can you confirm, that these warnings do not occur anymore? |
|
|
anonymous
|
2003-07-13 18:01
|
|
|
|
|
Yeah, this note really helps me! :-/
Could you at least tell me what version you are using? Did error_reporting() call in core class solve this problem? |
|
|
hbernard
|
2004-04-17 12:22
|
|
(I went on this when looking on #227)
this bug can be closed in two ways
1. Have a real deactivation of E_NOTICE
current PME tried to deactivate E_NOTICE, but wasn't successful.
Surprisingly, when prefixed by @, function error_reporting doesn't seem to do anything but retrieving current level.
Uploaded error_report.diff patch fixes this.
2. Fix all occurences of E_NOTICE
As you said in a note above, this is lot of work.
However, I made a ten minutes patch which is a start of such clean up. It fixes immediate notices when using basic options.
(uploaded notices.diff)
I don't think this will make PME much slower.
So, nepto, which way do you prefer ?
1. => apply patch error_report.diff, resolve this bug. PME won't care anymore about E_NOTICE
2. => apply patch notices.diff, tell PME to output E_NOTICES, keep this bug open some time to see what was missed in this patch.
because #227 is about E_Warning, it has to be handled specifically.
I got no opinions on this. Both solutions are OK for me. I'm only sure we can fix it quickly, depending on the way you want. |
|
|
|
I think we can simply go with [1].
It is really strange, that @ before error_reporting() makes this function do nothing... |
|
|
|
Simplier version commited into CVS.
Please reopen this bug-report when needed. |
|