Dutch van Andel

A query that includes multiple pieces of metadata might look like…

$sql = "SELECT user_login, m1.meta_value as foo, m2.meta_value as bar 
FROM {$wpdb->users} AS u
JOIN {$wpdb->usermeta} AS m1
  ON m1.user_id = u.ID
JOIN {$wpdb->usermeta} AS m2
  ON m2.user_id = u.ID
WHERE m1.key = 'foo'
AND m2.key = 'bar';"

This query selects and returns (all at once) the username, the first meta value (which matches a field with a meta_key of ‘foo’) and the second meta value (which matches a field with a meta_key of ‘bar’). This is fairly basic SQL, but in WordPress we have to remember that the meta tables relate to their parent table by ID. Select the parent table first, since that is your canonical reference, and then filter the record by your meta keys. You also need to be aware that this will skip parent records where either metakey is not present… that’s the tradeoff for its efficiency.

At this point, you can now switch on the columns ‘user_login’, ‘foo’, and ‘bar’, the latter two we aliased in the query.

FYI, this is one of the reasons no actual queries are included in the example… the use cases are infinite.

This plugin is only an example, demonstrating to developers how to create a genuine WordPress list table. You would create your own versions of the class within your own plugin. You wouldn’t need multiple plugins unless you specifically wanted it that way.

This is because the example uses hardcoded “fake” data. There is no database content to edit or link to.

A sidenote: Since you mentioned wanting multiple pieces of metadata, you’re going to need to use joins in your query, so I’d strongly recommend updating your select statement to use specific aliased column names instead of the * wildcard.

• This reply was modified 7 years, 4 months ago by Dutch van Andel.

The class is looping through database columns for each record as a convenience. You then use the switch statement to detect which column you are in for the current loop and output.

Setting the case to meta_key means you are outputting on the wrong column, based on what you explained for your requirements. Change it to meta_value and you’ll be able to output with the data instead of the key.

I’m seeing this too, on a fresh install with no other plugins activated.

There’s a mysqli fork here…

https://github.com/soulseekah/hyperdb-mysqli

Thanks Adam.

Once I discovered that expiration was based on a cron job (as opposed to page load), I managed to figure out that wp cron wasn’t actually being executed, which meant nothing was being checked for expiration and nothing was ever expiring.

I suspect that W3 Total Cache is at fault (cached pages could possibly mean that hits aren’t reaching wp_cron()). I had to set up an actual cron job on the server to ensure that wp cron was being triggered regularly.

I’m torn as to whether this is in-scope or not.

This is the function that would achieve what you’re looking for…

add_action('wp_loaded','wp_login_redirect_logged_in_user',0);
public static function wp_login_redirect_logged_in_user(){
    global $current_user, $pagenow;

    if ( in_array($pagenow, array('wp-login.php', 'wp-register.php') ) ) {
        if( is_user_logged_in() ) {

            $profile_page = get_edit_user_link( get_current_user_id() );

            wp_safe_redirect( $profile_page );

            die();
        }
    }
}

It’s probably best to use the redirect in general.

I’m not sure why comments would show when a post is protected (the entire templating system should get skipped when the security check occurs as wp_die() is called before WordPress reaches that execution point) – but it’s most likely a quirk of the theme or a conflict with another plugin.

I do not officially provide support. But every couple months I check in to see if there’s any bugs that need fixing, and I sometimes answer questions. ??

Keep in mind, I’m not adding any major new features (I’m working on a completely new version of this plugin that has a lot of new features), but I DO still plan on fixing any bugs that are reported for this.

Thank you tazitiz, I’ve incorporated your fix into the next update.

“Add New” buttons are not part of WP_List_Table, but would be part of your page template. This plugin only covers use of WP_List_Table.

Right. Any groups you add to a parent page “trickle down” to it’s children and ancestors and Page Security only checks to see if the user is a member of at least one group assigned to a page (i.e. it performs an “OR” check – not an “AND” check).

So if all your users are in the Committees group, and that group is applied to the Committees page, then no matter what additional groups you add to ancestor pages, everyone in the Committees group will have access to everything.

To get around this, you just need to make sure your specialty pages aren’t ancestors of the Committee page. Move them off into their own top-level pages and only the groups specifically attached to them will be able to access those pages.

That should be pretty much it. I’m prepping a small patch for 4.3 so you may loose that change if you update. To ensure everything continues working for you, I added two new hooks: ‘ctxps_edit_protection_cap’ and ‘ctxps_edit_membership_cap’. You can start using them now, and when I push the update, you shouldn’t see any changes in your setup.

ctxps_edit_protection_cap is a filter that lets you set what specific capability is required to edit object permissions (attach or detach groups from objects).

ctxps_edit_membership_cap is a filter that lets you set what specific capability is required to add/remove users from groups.

Neither of these check the users relationship to the current page, however. You’d have to check that yourself against the $current_user object.