WordPress.org

Forums

WordPress User Scaling Issues (12 posts)

  1. Thad Allender
    Member
    Posted 5 years ago #

    The wp_dropdown_users($args); function pulls all WordPress users into a dropdown list on posts, pages, custom post types, and even some plugins. This is problematic. With lots of users, WordPress admin stops loading when this function is called for sites with large numbers of users. Obviously, one could increase the max_execution_time and RAM in PHP to accomodate looping through all users, but it doesn't solve the underlying scaling issue WordPress appears to have.

    Aside from commenting out code in WordPress core and plugins using this function, what is a possible future-proof solution? If there is a hook/filter for this, please advise.

  2. PeterB
    Member
    Posted 4 years ago #

    Same here...
    I've got a wp3 site with thousands of users (subscribers).
    Currently they're sending me articles via email.
    When I create a new post and try to set the author from the authors' dropdown list, it takes ages, because the dropdown list is huge.
    What can be done?
    Thanks.

    P.

  3. mike503
    Member
    Posted 4 years ago #

    Yeah this is horrible. the newest version of WordPress required TWO core hacks now to break this instead of just one.

    I had to comment out the calls to wp_dropdown_users in these two files, otherwise even my (quite flexible) PHP configuration wound up sending 502 Bad Gateways off and on.

    wp-admin/includes/class-wp-posts-list-table.php
    wp-admin/includes/meta-boxes.php

    There was a ticket for this at one point. It was "fixed" but it really wasn't. Discussions about optimizing the db queries and only fetching the columns in question were the bulk of it. Really, I want something to be able to short-circuit the code from executing. I tried to hook it by removing the "authordiv" meta box, that didn't seem to help. Can't seem to find a plugin method to short-circuit or break this without returning false just to stop the function moving forward to execute the queries/etc...

  4. s_ha_dum
    Member
    Posted 4 years ago #

    Agreed. The way WordPress handles users is one of the few complaints I have about it. I've found I can't use some of the functions because of execution time issues. I really think the problem ultimately rests on a less that desirable roles/capability implementation, but that is another fight.

  5. Oleg Dudkin
    Member
    Posted 4 years ago #

    You can use "pre_user_query" filter and "debug_backtrace" to handle query.

  6. Diogo15
    Member
    Posted 4 years ago #

    HI, i would like to know How do I post under this forum???... i have an advance question...

  7. aladji
    Member
    Posted 4 years ago #

    hi evryone.I can’t login in my admin panel .I got this error message:

    Warning: Cannot modify header information – headers already sent by (output started at /home/clakup/public_html/wp-content/themes/evolve/functions.php:5261) in /home/clakup/public_html/wp-includes/pluggable.php on line 897

    It gonna be super cool if you guys will help me .
    I'm new here ,so sorry if I post in the wrong place.

  8. Diogo15
    Member
    Posted 4 years ago #

    I think you probably delete: wp_head() in header.php or wp_footer() in footer.php.

  9. aladji
    Member
    Posted 4 years ago #

    It was a empty space in the code in fontion.php .Thanks for your help anyway

  10. sobr-rf
    Member
    Posted 4 years ago #

    hey , thanks for solved

  11. J Martin
    Member
    Posted 4 years ago #

    I think that version is bad and ... I have used it in my own bussines loced in bussines strathfield

  12. mike503
    Member
    Posted 4 years ago #

    Thanks to Oleg Dudkin - for some reason all the digging I did I could not locate the pre_user_query hook.

    I wound up doing this:

    function _break_user_list(&$object) {
            global $wpdb;
            $object->query_from = 'FROM '.$wpdb->posts;
            $object->where_where = 'WHERE ID=1';
    }
    add_filter('pre_user_query', '_break_user_list');

    This forced it to only look up user ID #1, instead of every user in the database (which was the default behavior due to our role setup)

    Voila, no more hacking core!

Topic Closed

This topic has been closed to new replies.

About this Topic