Hot answers tagged

3

I wonder if you mean this kind of approach: add_filter( 'init', function() { $u = wp_get_current_user(); if( $u->exists() && in_array( 'banned', $u->roles, true ) ) add_filter( 'comments_open', '__return_false' ); } ); where we check if the current user has the custom banned role. If that's the case then we force all ...


2

There is no use for converting an integer to a string when you just need to display the result or for simple checking against a hardcoded known datatype value. Converting datatypes is only useful when you need to validate values strickly against a certain specific datatype. Your issue is that you do not exactly know how to test your values. 0, either an an ...


2

If you change manage_edit-post_columns to manage_posts_columns in your code snippet, then it should hide the comment column for all post types (appart from the page post type) within the WP_Posts_List_Table src. You might want to check if the column array key isset first, before unsetting it.


2

I got an alternative : This will not just hiding but disabling also function disable_comments() { $post_types = get_post_types(); foreach ($post_types as $post_type) { if(post_type_supports($post_type,'comments')) { remove_post_type_support($post_type,'comments'); remove_post_type_support($post_type,'trackbacks'); ...


1

This quite rare setup so it is hard to recommend one way or another. Having worked with comments before I would recommend to stick with WordPress API functions (wp_insert_comment() and so on) for manipulating them. While DB structure is indeed simple you don't account for all the hooks firing and other things that might be happening. For example once in ...


1

It looks like the first time the core calls wp_get_current_user() is within the WP::init() method. To better understand the context, we see that it's right after the after_setup_theme hook and just before the init hook src: do_action( 'after_setup_theme' ); // Set up current user. $GLOBALS['wp']->init(); do_action( 'init' ); where WP::init() is ...


1

Just some additional info for the main comment query: Since you mentioned the global $wp_query object, we can see that it stores: $wp_query->max_num_comment_pages = $comment_query->max_num_pages; in the main comment query in the comments template. There exists a wrapper for this, namely: get_comment_pages_count(); that's available after the ...


1

One approach is to use the cpage query variable: if ( ! empty( get_query_var( 'cpage' ) ) ) { // There is more than one page of comments. }


1

Try this, get_option( 'page_comments' ) will check if pagination is checked in options > discussion, then we compare comments per page (get_query_var( 'comments_per_page' )) to the current post's total comments found (count): function wpse231229_is_paginate_comments( $post_id = 0 ) { return get_option( 'page_comments' ) && ( $pagi = (int) ...


1

As discussed in the comments, your database prefix settings are off-kilter. Check the database prefix actually in use in your database, and make sure it's the same as the one in wp-config.php. Also make sure all of your WordPress-related tables have the same prefix. You'll also need to search through your database, particularly in the _options table, as ...



Only top voted, non community-wiki answers of a minimum length are eligible