You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copying in the details from Slack for those who don't (or choose not to) have access:
Thursday, June 7th
mikeschinkel [5:20 PM]
Here is a thread about showcasing WP_DEBUG issues I started on #meta. They pointed me back to #tide as a solution and suggested I propose it here, although it sounds like maybe you are already planning something like this?
In a nutshell it would be great if a plugin could be marked as having been developed with WP_DEBUG or not by virtual of it not throwing warnings and errors when WP_DEBUG==true.
Having a nice big red "X" would be great incentive to get plugin developers to learn about WP_DEBUG and to start using it. Too many don't because too many plugins don't; it's a vicious cycle. (edited)
mikeschinkel
Lately one of my biggest issues is trying to work with plugins where setting WP_DEBUG generates a stream of errors. Seems to me this should be a minimum requirement for entry into the WordPress plugin repository.
One way to address it would be give a way for the community to report issues with a plugin when WP_DEBUG is not set and then give plugin developers 10 days to response after which the plugins would be temporarily delisted until the issue is resolved.
Is there any will among the wp.org team to consider addressing this?
Posted in #meta Jun 7th
@mikeschinkel commented on Wed Jun 13 2018
For reference see the mention in Slack.
@jeffpaul commented on Wed Jun 13 2018
Copying in the details from Slack for those who don't (or choose not to) have access:
Thursday, June 7th
mikeschinkel [5:20 PM]
Here is a thread about showcasing
WP_DEBUG
issues I started on #meta. They pointed me back to #tide as a solution and suggested I propose it here, although it sounds like maybe you are already planning something like this?In a nutshell it would be great if a plugin could be marked as having been developed with
WP_DEBUG
or not by virtual of it not throwing warnings and errors whenWP_DEBUG==true
.Having a nice big red "X" would be great incentive to get plugin developers to learn about
WP_DEBUG
and to start using it. Too many don't because too many plugins don't; it's a vicious cycle. (edited)mikeschinkel
Lately one of my biggest issues is trying to work with plugins where setting
WP_DEBUG
generates a stream of errors. Seems to me this should be a minimum requirement for entry into the WordPress plugin repository.One way to address it would be give a way for the community to report issues with a plugin when
WP_DEBUG
is not set and then give plugin developers 10 days to response after which the plugins would be temporarily delisted until the issue is resolved.Is there any will among the wp.org team to consider addressing this?
Posted in #meta Jun 7th
@hellofromtonya commented on Thu Jun 14 2018
Hmm, @mikeschinkel is right. Catching the PHP thrown warnings and notices while in
WP_DEBUG
mode is an indicator of quality.The questions then become:
Exercising the code will reveal the notices/warnings when the control flows through the code where the problem lives.
Therefore, the challenge comes in running all the control paths. We all have that challenge in designing our test suites.
Hmm, interesting challenge for us to solve.
@jeffpaul commented on Tue Aug 28 2018
Per bugscrub today, we're moving this to
Future Release
.@jrfnl commented on Tue Sep 04 2018
Loosely related to: #138
The text was updated successfully, but these errors were encountered: