Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
claytoncollie opened this issue Dec 13, 2023 · 3 comments · Fixed by #88
Closed
Assignees
Labels

Comments

@claytoncollie
Copy link

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 --> 0058af1#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
Copy link
Owner

imath commented Dec 13, 2023

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
Copy link
Author

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
Copy link
Owner

imath commented Dec 14, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants