Michelle Blanchette

FYI – An indented HEREDOC and NOWDOC closing marker became supported in PHP 7.3 which makes sense why I encountered fatal errors in 7.2 while the errors were not encountered by @properlypurple with PHP 7.4.

Understood, @properlypurple ~ Thank you for the quick and thorough response!

Hi Gerard,

Providing my entire Site Health info is certainly overkill for a simple PHP namespacing issue.

However, I can tell you that I just tested installing and uninstalling Enable Media Replace on a clean PHP 7.4 environment and experienced no issues.

The environment that I experienced the issue on was running PHP 8. I then tested installation and uninstallation on a different PHP 8 environment. It had the same issue.

Please try testing the plugin uninstallation and namespace fix on an environment running PHP 8 and let me know what you find.

Cheers!

Michelle

Hi Gerard,

I removed the plugin files from my server, re-installed the plugin, and the uninstallation script still failed.

I’ve edited the code and resolved the issue. Could you please make sure this fix is implemented into the plugin? I found that the plugin uses a namespace, yet does not properly refer to this namespace when registering the uninstall function.

Current, broken code in main plugin file:

register_uninstall_hook(__FILE__, 'emr_uninstall');

function emr_uninstall()
{
        delete_option('enable_media_replace');
}

Fixed, working code:

register_uninstall_hook(__FILE__, '\EnableMediaReplace\emr_uninstall');

function emr_uninstall()
{
        delete_option('enable_media_replace');
}

I’ve successfully uninstalled the plugin after making this change to the plugin.

Could this please be implemented so plugin uninstallation is possible for others?

Thank you!

Michelle

• This reply was modified 3 years, 5 months ago by Michelle Blanchette.

Hey @ajay

You can use this style rule (CSS) for your site:

pre.wp-block-code code {
    white-space: pre-wrap !important;
}

I just tested this on the page you linked, so you should be all set!

Cheers,

Michelle

• This reply was modified 3 years, 5 months ago by Michelle Blanchette.

Hey, everybody!

If you are comfortable with PHP coding, please see my previous explanation of how to error_log the stack backtrace to find the bug.

If you ARE NOT comfortable editing code, you may hide PHP errors by adding/editing one line in your wp-config.php file. Please look up more information on this concept if you need. In your wp-config.php file on your server, add this line of code above the “That’s all! Stop editing!” line of text:
define( 'WP_DEBUG_DISPLAY', false );

To disable debugging altogether—which I do recommend doing if you are not a developer—you can instead find the line that says:
define( 'WP_DEBUG', true );
…and change it to false:
define( 'WP_DEBUG', false );

If you are still struggling to resolve the issue, do not worry! If your site is functioning properly, this error message is nothing to worry about. If you insist on removing the error message, however, you will need to connect with a developer to assist you.

I hope this helps you all!

Michelle

Hi @joey12 ,

The backtrace print shows you where in the code you need to be looking for issues. In my case, I knew the parameters provided in the function call were incorrect and I also knew how it gets fixed. More specifically, there was an extra parameter provided to the function call. Comparing the problematic usage to the function’s documentation/source clues you in to if a function is being used properly, which helped me know, for instance, which parameter needed to be removed.

If you are struggling to understand the issue in the code and why it is throwing an error, I definitely suggest reaching out to the plugin developer and telling them what the error is. Even better, you can now tell them that you at least found the file and line that are the root of the problem!

Even if you have fixed the problem for yourself, it’s still good to notify the developer so they can implement the fix for later releases.

I hope this helps!

@juliesuccess I recommend notifying the plugin developer of the problematic code because you will have to patch it every time you update the plugin. Your fix will be replaced by all of their code if you make edits directly. (Just like editing and updating WP Core directly.)

So I recommend notifying the plugin developer, but also noting the fix yourself in case the plugin developer does not implement the fix for future releases. Also, you’ll have the fix in place immediately while waiting on the plugin developer to implement the fix on their end. ??

Hello @juliesuccess . Thank you for asking because this is probably a common issue since upgrading to WP 5.3.0 for some people.
……………………………………..

After upgrading to WordPress 5.3.0, you may notice this error notice that was added:

Notice: add_submenu_page was called incorrectly. The seventh parameter passed to add_submenu_page() should be an integer representing menu position. Please see Debugging in WordPress for more information. (This message was added in version 5.3.0.) in /var/www/html/wp-includes/functions.php on line 4903

To find out where the code is that’s originally causing the error, we can review the stacktrace of execution. PHP’s debug_backtrace is the function to call to review part of the stacktrace, https://www.php.net/manual/en/function.debug-backtrace.php.

The error notice tells us where we should put this code: /var/www/html/wp-includes/functions.php on line 4903

That line looks like this:
trigger_error( sprintf( __( '%1$s was called <strong>incorrectly</strong>. %2$s %3$s' ), $function, $message, $version ) );

After that line is where we’ll put a backtrace print to review some of the stacktrace:

debug_print_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 5 );

Once the code changes have been uploaded, you can refresh the page that is outputting the errors to now see 5 steps back of the stacktrace, which is hopefully enough for you to identify the source. Here’s what it output for me:

#0 _doing_it_wrong() called at [/var/www/html/wp-admin/includes/plugin.php:1385]
#1 add_submenu_page() called at [/var/www/html/wp-content/plugins/child-theme-generator/admin/class-child-theme-generator-admin.php:122]
#2 Ch_Th_Gen_Admin->create_menu() called at [/var/www/html/wp-includes/class-wp-hook.php:288]
#3 WP_Hook->apply_filters() called at [/var/www/html/wp-includes/class-wp-hook.php:312]
#4 WP_Hook->do_action() called at [/var/www/html/wp-includes/plugin.php:478]

If you still can’t find where the original function call was made, increase the backtrace limit integer parameter. In this case, we were looking for where the problematic add_submenu_page() was called. It shows as #1 in my backtrace.

After finding the root of the error, it’s good to remove all code changes made to WordPress Core files since they will be overwritten when updating WordPress again. It’s best to keep your WordPress install as pure as possible so that all your code changes are somewhere more manageable.

To not even edit WP Core code to begin with, you can utilize the doing_it_wrong_run action hook:

/**
 * Fires when the given function is being used incorrectly.
 *
 * @since 3.1.0
 *
 * @param string $function The function that was called.
 * @param string $message  A message explaining what has been done incorrectly.
 * @param string $version  The version of WordPress where the message was added.
 */
do_action( 'doing_it_wrong_run', $function, $message, $version );

Great! I see the change and have updated the plugin. The error is now gone.

Thank you for the super quick fix and great plugin! Cheers!

Hello Serafino,

The error is still there and I do not see any changes to that function in the code. Did you not commit your changes?

All you need to do is delete line 122: https://plugins.trac.www.ads-software.com/browser/child-theme-generator/tags/2.2.4/admin/class-child-theme-generator-admin.php#L122

Also, the changelog says v2.1.4, but the downloaded and most recent version on here is tagged 2.2.4.