Gerard Reches

The plugin uses the pre_user_query action hook on line 231 of the file class-obenland-wp-approve-user.php

There is something going on in there that makes the unapproved users listing page to not work, and it even looks like it has to deal with some issues causing an infinite loop and the page not loading at all.

I have fixed it by adding this code to my site:

public function fix_wpau_filter( WP_User_Query $query ) {

    if ( ! is_admin() ) {
        return;
    }

    global $pagenow;

    if ( $pagenow !== 'users.php' || ! isset( $_GET['role'] ) || $_GET['role'] !== 'wpau_unapproved' ) {
        return;
    }

    $query->set( 'role', '' );
    $query->set( 'meta_query', array(
        array(
            'key'   => 'wp-approve-user',
            'value' => false
        )
    ) );
}
add_action( 'pre_get_users', 'fix_wpau_filter', 10, 1 );

With this, I can remove the plugin’s function code and the unapproved users page displays all unapproved users properly. The plugins function can be removed, but it will also work without removing it. This means that the developer should drop the use of the pre_user_query and use pre_get_users instead. He can make an adaptation of the code I’ve provided.

If you are someone experiencing this issue, just add the code I’ve provided to your functions.php, you don’t need to do anything else.

I hope the author of the plugin can fix this soon so that we don’t require this fix anymore.

+1.

The /wp-admin/users.php?role=wpau_unapproved page where all the unapproved users should be listed, is empty even though the user count says there are unapproved users. I can confirm that there are, in fact, unapproved users. I’ve tested unapproving some of them and the count increases but the list still says no users found.

From the URL you can tell that it’s trying to filter the users table by the role wpau_unapproved. However, when I check the metadata of the unapproved user, the wp_capabilities meta does not contain the wpau_unapproved role, only the subscriber role.

Since the role is not being assigned to unapproved users, they are not being displayed on the Unapproved users list.

The wp-approve-user meta is present for the user, with an empty value. I understand that the unapproved users count comes from this meta and this is the one storing the approval status.

Therefore, we need a fix for either correctly assigning the role or a different way to display the unapproved users based on the wp-approve-user meta instead of the wpau_unapproved role.

WordPress and plugins up to date. Using the plugin User Role Editor as well. PHP 8.1.

The plugin used to work, so something must have changed.

@rankmathsupport Any reason for the features of the additional plugin to not be part of the Rank Math plugin?

Thanks Benjamin, it’s already working ??

Thanks @benjamin_zekavica, I’m not using Gutenberg so the extension would be the way to go. Is this script included and registered in WordPress (as there are many other optional libraries) or would I have to download it and add it to my plugin?

Thanks @threadi .

I’ve opened a core trac ticket and provided a pull request with the patch. I hope there’s no reason not to include it.

Hi @threadi,

Thanks, that’s indeed useful in some situations.

However, I’m curious about why the content=aaaa parameter is pre-populating my meta box input (whose name isn’t ‘content’).

Also, the one I really wanted to pre-populate was the slug. I’ve tried the following parameters but they didn’t work:

• slug=my-slug
• post_name=my-slug
• name=my-slug

Is there any way to pre-populate the slug? I know it would be automatically generated from the title, so I could use a title whose sanitized version was the slug I want, but I would like to pre-populate the slug so that the users don’t fill it by themselves.

Thanks @bcworkz, very useful information!

Hi @bcworkz, that’s actually a cool idea

/**
 * Implement the admin media model for any defined file fields.
 * @see https://codex.www.ads-software.com/Javascript_Reference/wp.media
 *
 * @note Script is being added inline to avoid issues when the directory is a symlink. PHP doesn't have methods to retrieve the unresolved path.
 * @see https://bugs.php.net/bug.php?id=42516
 */
if ( apply_filters( 'append_media_script', true ) ){
    wp_add_inline_script( 'jquery', file_get_contents( trailingslashit( dirname( __FILE__ ) ) . 'wp-media-frame.js' ), 'after' );
}

This is what you meant, right?

@bcworkz The hook you are mentioning

do_action( ‘wp_print_scripts’?)

Fires before scripts in the $handles queue are printed.

https://developer.www.ads-software.com/reference/hooks/wp_print_scripts/

fires before the enqueued scripts have been printed, causing javascript errors if the manually printed script has some enqueued dependency, in this case jquery. Just tried it.

Using wp_add_inline_script( $handle, $data ), with jquery as handle since it’s a dependency for the script being added, seems to still be the best option, and now it’s starting to sound like it wasn’t a bad idea after all.

Next thing that comes to my mind is: “Ok, but we are still unable to dequeue this inline script. Not because I need to, but just in case.”

And suddenly I have this brilliant idea: “Got it! I can dequeue the script my inline script is attached to (jquery), thus removing my inline script on the process, and then just enqueue the script (jquery) again if still required!”

And that should work! I’ve tested before that dequeueing a script effectively removes its attached inline scripts.

Oh boy… Beautiful theory, but why isn’t it working?

At first I thought: “It must be because jquery is still a dependency for the other script I’m enqueueing.”

So I removed the dependency and just enqueued both scripts separately: “Still doesn’t work! Maybe there are other script that WordPress is loading that depend on jquery. Let’s change the priority of my admin_enqueue_scripts hook action to 1 so that I do these actions before anyone else.”

And no, that made no difference.

Anyway, my script shouldn’t need to be dequeued in any case, so I’ll leave it like this. All I wanted was to have that possibility, out of greed.

I wish any of this little research can help someone else in the future!

I’ve tried what I said before just for curiosity:

Now, I am wondering… Would it be possible to enqueue a script with an empty path and then use?wp_add_inline_script()?on that handle? And if it is possible to enqueue a script with empty path, does dequeueing a script remove the?wp_add_inline_script()?calls referencing to it? Because if that was possible, it would be a great solution. I wouldn’t require an absolute path and developers would still be able to manage the script handle.

Results are:

• wp_enqueue_script( ’empty-handle’ ) doesn’t register the handle in $wp_scripts->queue, which means a path is required.
• wp_enqueue_script( ’empty-handle’, ‘/fake-path’ ) registers the handle and generates a 404 HTTP request.
• wp_enqueue_script( ’empty-handle’, ‘/’ ) registers the handle and generates a 200 HTTP Request. 10.5kB and 152ms, much bigger than most WordPress scripts.
• wp_add_inline_script(’empty-handle’, $contents) does work and adds the script to the page, even if the enqueued path wasn’t real.
• wp_dequeue_script(’empty-handle’) does effectively remove the added inline script attached to the handle.

Conclusion:

Is it possible? Yes, by adding any fake or real path to wp_enqueue_script() the $handle will be registered, and dequeueing such $handle will remove the inline scripts added to it.

Should it be done? Not really, as it generates an extra HTTP request, which may be either a 404 or dodgy.

Thanks for your reply @bcworkz .

Right now I’ve changed the code to use wp_add_inline_script(), since what I had was quite messy and difficult to understand for anyone looking at the code.

final static function enqueue_admin_scripts( string $hook_suffix ): void {
    if ( self::get_page_hook_suffix() !== $hook_suffix ) {
        return;
    }

    wp_enqueue_media();

    wp_enqueue_style( 'wp-color-picker' );
    wp_enqueue_script( handle: 'wp-color-picker', deps: array( 'jquery' ) );
    wp_add_inline_script( 'wp-color-picker', 'jQuery(".color-picker").wpColorPicker();', 'after' );

    /**
     * Implement the admin media model for any defined file fields.
     * @see https://codex.www.ads-software.com/Javascript_Reference/wp.media
     *
     * @note Script is being added inline to avoid issues when the directory is a symlink. PHP doesn't have methods to retrieve the unresolved path.
     * @see https://bugs.php.net/bug.php?id=42516
     */
    wp_add_inline_script( 'jquery', file_get_contents( trailingslashit( dirname( __FILE__ ) ) . 'wp-media-frame.js' ), 'after' );
}

This is part of an abstract class which is to be extended by other developers. My scripts are basically for handling the WP Color Picker (just a short line of code) and the Media Library modal.

When it comes to the first script it’s not a bad idea to use the wp_add_inline_script() as it really is kind of expanding the native script and it’s very short as well.

Then the WP Media script, as much as I would like to give it a handle, I don’t have a clean way to deal with edge cases where the plugin is being used as a library in an unknown location and symlinks are also in use. I’m using wp_add_inline_script() as it seems to be my best bet for now.

The wp_print_scripts() action hook you are mentioning requires a handle, and I guess that would mean that I would still have to create that handle by giving a path to the file, which is where my issue arises.

Now, I am wondering… Would it be possible to enqueue a script with an empty path and then use wp_add_inline_script() on that handle? And if it is possible to enqueue a script with empty path, does dequeueing a script remove the wp_add_inline_script() calls referencing to it? Because if that was possible, it would be a great solution. I wouldn’t require an absolute path and developers would still be able to manage the script handle.

@bcworkz I seem to remember to have read before that it’s against the rules for plugins in the official repository to require the installation of other plugins. I may be wrong though.

In any case, even though it will be a standalone plugin, I still want other devs to be able to include it as a library as part of their plugin/theme. Not everyone wants to have an additional plugin cluttering their plugins list, and I get it, neither do I most of the time. On the other hand, being able to use the plugin as library inside themes/plugins means that they can use the version they want and I can continue developing without worrying much about backward compatibility.

Furthermore, all I want to require the devs to do is to require_once() the main plugin file. Everything else should work out of the box from there on. That’s why I don’t like the idea of requiring them to define a constant if they are using symlinks, so making them enqueue the script themselves is not an option unfortunately.

Right now I am thinking of using wp_add_inline_script() to add the contents of the script to the end of one of the default WordPress scripts that I’m enqueueing inside this same method (wp-color-picker). I’m not sure if this is considered a bad practice.

I sent a ticket to Elementor’s support regarding this matter and telling them that you’ve tried to reach them and to check on it. Hopefully this helps to move forward and fix this issue.