openmindculture/wp-incompatibility-status

WordPress plugin to show incompatible settings in dashboard widget in WP-Admin

wp-incompatibility-status's Issues

verify and claim compatibility with WordPress 6.3

• Install a WordPress 6.3 beta or release candidate.
• Prove that the plugin still work without errors.
• update the "tested up to" meta information everywhere.
• optionally also verify using the latest PHP version
• optionally add a note (in README? as there is no official "tested up to PHP version" field) about latest tested PHP version
• optionally update or add checks for known issues

Configure local WP Code Sniffer

Configure a local WordPress Code Sniffer to validate the code in the IDE before submitting to the WordPress plugin repository, to avoid errors and unnecessary refinement loops to speed up development.

See

• https://packagist.org/packages/wp-coding-standards/wpcs
• https://www.jetbrains.com/help/idea/using-php-code-sniffer.html#installing-configuring-code-sniffer

add inspections

• fse
• actually using any block?
• elementor, divi, beaver, bakery etc vs fse
• woocommerce, woof, Germanized, prod img flippers, paypal
• how to update outdated false positives?

Add Plugin to WordPress.org

Test the plugin

• on localhost (WordPress Docker)
• at www.open-mind-culture.org (using a classic editor)

https://wordpress.org/plugins/developers/add/

• I have read the Frequently Asked Questions.
• This plugin complies with all of the Plugin Developer Guidelines.
• I have permission to upload this plugin to WordPress.org for others to use and share.
• This plugin, all included libraries, and any other included assets are licenced as GPL or are under a GPL compatible license.

HOW LONG WILL THE REVIEW PROCESS TAKE?

This is in the Developer FAQ. It takes anywhere between 1 and 10 days. We attempt to review all plugins within 5 business days of submission, but the process takes as long as it takes, depending on the complexity of your plugin.

WordPress Code Review Refinements

Issues after "improving" the code for release candidate 3 (#2):

• Instead of using inline CSS with <<<HEREDOC, and failing to find a proper escape function, I decided to include a CSS file but forgot to use wp_enqueue instead of a regular <link> element to load the external CSS file.

• Based on the SonarLint warnings about snake_case namings, I changed the function and variable names, removing prefixes where I thought it safe for a seemingly local function. While those seemed to be correct (how can we know if there is no local version of their linter available for my IDE?), the automatic code sniffer complained about the names where I only removed the underscore between prefix and the rest of the identifier, like openmindcultureWpstatusDashboardWidgets instead of openmindculture_wpstatus_dashboarddidgets. Hopefully openmindculture_wpstatusDashboardWidgets will do (again, how are we to know without a local code sniffer?) and so we will have to disable the SonarLint S100 rule for the whole project.

• use wp_enqueue commands

  • If you're trying to enqueue on the admin pages you'll want to use the admin enqueued
    https://developer.wordpress.org/reference/hooks/admin_print_styles/

• avoid generic function/class/define/namespace names

  • use a prefix
  • Namespace

New target version: release candidate 4 (1.0.0-rc4).

---

There is still an issues

Please use wp_enqueue commands

Your plugin is not correctly including JS and/or CSS. You should be using the built in functions for this:

• https://developer.wordpress.org/reference/functions/wp_enqueue_script/
• https://developer.wordpress.org/reference/functions/wp_enqueue_style/

And remember you can use this function to add inline javascript:

• https://developer.wordpress.org/reference/functions/wp_add_inline_script/

As of WordPress 5.7, you can pass attributes like async, nonce, and type by using new functions and filters:

• https://make.wordpress.org/core/2021/02/23/introducing-script-attributes-related-functions-in-wordpress-5-7/

If you're trying to enqueue on the admin pages you'll want to use the admin enqueues

• https://developer.wordpress.org/reference/hooks/admin_enqueue_scripts/
• https://developer.wordpress.org/reference/hooks/admin_print_scripts/
• https://developer.wordpress.org/reference/hooks/admin_print_styles/

Example(s) from your plugin:

1.0.0/incompatibility-status.php:138: echo '<link rel="stylesheet" href="'. plugin_dir_url(__FILE__) . 'styles.css">';

Generic function/class/define/namespace names

All plugins must have unique function names, namespaces, defines, and class names. This prevents your plugin from conflicting with other plugins or themes. We need you to update your plugin to use more unique and distinct names.

A good way to do this is with a prefix. For example, if your plugin is called "Easy Custom Post Types" then you could use names like these:

• function ecpt_save_post()
• define( ‘ECPT_LICENSE’, true );
• class ECPT_Admin{}
• namespace EasyCustomPostTypes;

Don't try to use two (2) or three (3) letter prefixes anymore. We host nearly 100-thousand plugins on WordPress.org alone. There are tens of thousands more outside our servers. Believe us, you’re going to run into conflicts.

You also need to avoid the use of __ (double underscores), wp_ , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please remember, if you're using _n() or __() for translation, that's fine. We're only talking about functions you've created for your plugin, not the core functions from WordPress. In fact, those core features are why you need to not use those prefixes in your own plugin! You don't want to break WordPress for your users.

Related to this, using if (!function_exists(‘NAME ‘)) { around all your functions and classes sounds like a great idea until you realize the fatal flaw. If something else has a function with the same name and their code loads first, your plugin will break. Using if-exists should be reserved for shared libraries only.

Remember: Good prefix names are unique and distinct to your plugin. This will help you and the next person in debugging, as well as prevent conflicts.

Example(s) from your plugin:

1.0.0/incompatibility-status.php:24: function openmindcultureWpstatusDashboardWidgets()
1.0.0/incompatibility-status.php:29: function openmindcultureWpstatusContent()
1.0.0/incompatibility-status.php:136: function openmindcultureWpstatusPrintStyles()

UX Writing: less "alarming" dashboard widget title

Current dashboard widget title "Incompatibility warnings" might suggest that there are warnings, even if there are none. The more neutral "incompatibility status" wording might still mislead some users that there might be an incompatibility.

Possible solution: change the widget title to "Compatibility Status".

Although this does not match the plugin name anymore, but that's common practice, and there is still a footer line making it perfectly clear which plugin generated the status widget.

WordPress Code Style Sniffer throwing error

see previous issue