Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Did you get the same error as the other two above? Because it’s clearly stated in the displayed error.

    It’s not that clear in the actual log file where it’s unformatted, unwrapped, and surrounded by lots of other lines. Who has time to search a haystack for a broken needle? ¬_¬ (Well, I guess I do because I did, and then fixed the bug too. 🤷)

    Okay, I managed to determine that the problem started with version 2.0. The only significant difference between 1.4.0 and 2.0.0 is the settings.php file, and the Apache log concurs. This is the error:

    PHP Fatal error:
    Uncaught Error:
    Call to undefined function wp_get_current_user() in
    /.../wordpress/wp-includes/capabilities.php:660
    Stack trace:
    #0 /.../wordpress/wp-admin/network/settings.php(16): current_user_can()
    #1 /.../wordpress/wp-content/plugins/phoenix-media-rename/phoenix-media-rename.php(24): include_once('/.../wordpress...')
    #2 /.../wordpress/wp-settings.php(319): include_once('/.../wordpress...')
    #3 /.../wordpress/wp-config.php(133): require_once('/.../wordpress...')
    #4 /.../wordpress/wp-load.php(37): require_once('/.../wordpress...')
    #5 /.../wordpress/wp-admin/admin.php(34): require_once('/.../wordpress...')
    #6 /.../wordpress/wp-admin/network/admin.php(13): require_once('/.../wordpress...')
    #7 /.../wordpress/wp-admin/network/update-core.php(11): require_once('/.../wordpress...')
    #8 {main}
    thrown in /.../wordpress/wp-includes/capabilities.php on line 660

    It looks like when PMR tries to include the settings.php file, it’s getting the one in wp-admin/network instead of the one in its CWD. I tried prepending the filename in the include call with the CWD: include_once(dirname(__FILE__).’pmr-settings.php’); but that didn’t work, it resulted in the admin page loading but throwing a bigger error in the page itself instead of a WSOD error page.

    The easiest solution is to simply rename settings.php to something unique like pmr-settings.php. That works just fine. 👍

    I’m not sure why it’s getting the wrong file, why the file in the network folder has a higher priority than the plugin’s own CWD, but that definitely doesn’t seem like “bad coding out of the gate”, it seems like a bizarre side-effect of PHP and/or WordPress. 😕 (I’ll probably try to look into it to find an explanation… 🤔)

    For anyone stuck in the same situation, you can use version 1.4.0 until the latest version is fixed: https://downloads.wordpress.org/plugin/phoenix-media-rename.1.4.0.zip Or you can just rename the settings file and update phoenix-media-rename.php with the new filename. It’s a pretty quick and trivial fix.

    I also figured out to how recover the enabled state of plugins from a backup in case all of your plugins got disabled: https://wordpress.stackexchange.com/questions/371602

    Now, all that’s left to do is to try to determine what got messed up when WordPress loaded with all plugins disabled… 😕

    • This reply was modified 5 months, 4 weeks ago by Synetech.
    • This reply was modified 5 months, 4 weeks ago by Synetech. Reason: Fixed formatting. (What happened to WYSIWYG? 🤨)

    I know how frustrating can be installing a plugin that causes errors … you can easily remove Phoenix Media Rename via FTP or other file management systems

    It’s not just a matter of installing a plugin that messes things up, I’ve had it installed without issue for the past few years, but the last update broke things pretty badly (so badly that we can’t even disable it form the GUI). Moreover, the “fix” isn’t easy at all and doesn’t work for two reasons:

    1) There’s no way to know that this plugin is the cause. We only end up here <i>after</i> determining it’s this plugin that caused the problem, not before. I had to rename the whole plugin folder, which caused everything to get disabled. Then I re-enabled them one at a time until I found the one that broke things. Now I have to try to figure out a way to find out which of the many plugins used to be enabled so that I can re-enable them (and hope their being disabled didn’t mess anything up). 😐

    2) Even if everything gets restored, we’re still unable to use this plugin anymore until it’s fixed. Fortunately this plugin isn’t critical, but it’s still something that’s going to have to sit on a todo list until then.

Viewing 3 replies - 1 through 3 (of 3 total)