imath / wp-statuses

WordPress plugin to ease Custom Post Statuses integration
GNU General Public License v2.0
161 stars 27 forks source link

Recent change to disable all functionality with `WP_DEBUG` broke backward compatibility #87

Closed claytoncollie closed 11 months ago

claytoncollie commented 11 months ago

Hi there. We are using this plugin on client sites as the default functionality. And in some cases, we are using a WordPress filter to disable this plugin's functionality since it changes the publishing workflow. All of that was fun until this commit was made and the boolean filter was replaced with a WP constant WP_DEBUG --> https://github.com/imath/wp-statuses/commit/0058af1e7d564d1a24f09b98a96057e1483f598b#diff-f210f8b70ecfd7564e9ed608af0a591ba9eba243eef6cf68f8014b62ef069324R108

I'm curious why this change was made and if it can be reverted.

Thinking off the top of my head, if this constant is set in a development environment, WP_DEBUG is true and this plugin works perfectly. But in production is WP_DEBUG is false then this plugin does not work. I'm a bit confused. Having this filter be a simple boolean would be great to rever back to.

Thanks for the additional information.

imath commented 11 months ago

Hi,

I've made this change to have the dummy default custom statuses that help me debug the plugin when working on it. Before the change, the code was looking like this:

if ( apply_filters( 'wp_statuses_use_custom_status', false ) )

Which means, the dummy statuses were never loaded unless you use add_filter( 'wp_statuses_use_custom_status', '__return_true' );

If this change is a problem, I can revert it and come back to false instead of WP_DEBUG, no problem.

PS: The only trouble I can see would be that you were using the dummy statuses in Production. If you do so, I believe it would be safer to copy the code and put it inside a /wp-content/mu-plugins/custom-statuses.php file. I can imagine I would probably edit this code for my testing need one of these days 😅

claytoncollie commented 11 months ago

Thanks for the quick reply. Really appreciate it.

From looking closer at my local environment, I can see the issue. If you are developing locally or on a lower environment with WP_DEBUG set to true, all your custom statuses will be removed in favor of the plugin's test status restricted from core/custom/php. Once we go to production, the problem will go away since WP_DEBUG will be set to false. But that still leaves all of the lower environments broken and the client asking what happened.

If you have the time to revert this change it would be much appreciated. I understand you are trying to make your testing environment more streamlined but it hurts testing locally for other users. Thanks for hearing us out!

imath commented 11 months ago

Sure no problem, I'll revert the change asap.