Patrick Lumumba

Hello @jnewell123,

The issue here is that your site has lost its styling. If you didn’t delete anything, then the issue is likely being caused by a caching plugin.

I can see that you are using WP Rocket plugin.

Try clearing the cache to see if that fixes it. If it doesn’t disable WP Rocket, then check if that fixes it.

Here is a guide on how to clear cache in WP Rocket: https://docs.wp-rocket.me/article/53-clear-wp-rocket-cache

I hope that helps.

Patrick.

Hello @georgeogorman

This has port conflict between Local and XAMPP written all over it.

Both XAMPP and Local WP are fighting over MySQL port 3306, causing login failures and broken email resets.

The easiest fix would be to stop XAMPP’s MySQL before running Local (or vice versa). The idea is not to run both at the same time.

If you need both, then I suggest you change XAMPP’s MySQL port to some thing different from 3306. You can do this in its my.ini config file.

Finally, you can reset your password without email. To do this, use WP-CLI in Local’s site shell. Run this command: wp user update [email protected] --user_pass=newpassword

Here are some guides I believe can help you:

https://developer.ww.wp.xz.cn/cli/commands/user/reset-password/

https://localwp.com/help-docs/troubleshooting/reset-a-local-sites-wordpress-admin-password/

Hello @evonox

That’s a good question.

You can use PSR-12 for your own framework’s internal code, but for WordPress Plugin Repository submission, WordPress Coding Standards compliance is expected for the plugin’s WordPress-facing code.

So, you may want to consider this.

Also, be sure to make use of the Plugin Check (PCP) to help you with coming up with a plugin free of issues and ready for w.org submission.

• This reply was modified 2 months, 3 weeks ago by Patrick Lumumba.

Hi there,

Let us start with the critical error issue.

You must have received an email with the error details (including the Stack Trace). It is from the error details that we can be able to know what is causing the error. Most probably, it’s a conflict between the plugins.

I believe the same conflict is causing the menu-loading issue.

Here is what I’d recommend you do. Get the error details from the email. Share it here so we can have a clear picture of where it’s coming from.

If you didn’t receive an email with the error details, enable debugging on your site, then repeat the same steps that led to the critical error the first time. Check the debug.log for the error details.

Here is a tutorial on how to enable debugging: https://learn.ww.wp.xz.cn/lesson/the-built-in-wordpress-debugging-options/

• This reply was modified 2 months, 3 weeks ago by Patrick Lumumba.

Hi @hupe13, you’ve diagnosed this correctly. It’s a bug.

opcache_get_status() intentionally returns false in file_cache_only mode (PHP documents this). So when only file-based opcache is active, WordPress incorrectly reports it as disabled.

The fix is to fall back to opcache_get_configuration(), which does work in file-cache-only mode, and check for opcache.enable, opcache.file_cache, and opcache.file_cache_only being set. Worth opening a Trac ticket.