I have a plug-in on my site called Airpress. The plugin adds an item to the Admin menu bar in Wordpress that is quite annoying for the many users I have on the site, none of which need it. I isolated the function in the plugin flies, but would like a better solution to disabling it, rather than just commenting out the lines. This is a temporary solution, as it is erased every time the plugin updates. I would prefer to disable the function using my theme’s “functions.php” file. Any suggestions? Here is the code for, the plugin file:
function renderDebugToggle( $wp_admin_bar ) {
$args = array(
'id' => 'airpress_debugger_toggle',
'title' => 'Toggle Airpress Debugger',
'href' => '#',
'meta' => array( 'class' => 'my-toolbar-page' )
);
$wp_admin_bar->add_node( $args ); }
You can simply remove_node by id. Write the following code in your functions.php:
add_action( 'admin_bar_menu', 'remove_airpress_debugger_toggle', 999 );
function remove_airpress_debugger_toggle( $wp_admin_bar ) {
$wp_admin_bar->remove_node( 'airpress_debugger_toggle' );
}
Related
To begin with I have created a simple plugin that contains this piece of code:
function woo_create_credit_attribute_taxonomy() {
$attributes = wc_get_attribute_taxonomies();
$slugs = wp_list_pluck( $attributes, 'remaining_credits' );
if ( ! in_array( 'remaining_creds', $slugs ) ) {
$args = array(
'slug' => 'remaining_creds',
'name' => __( 'Remaining Credits', 'bidrop-credits' ),
'type' => 'select',
'orderby' => 'menu_order',
'has_archives' => false,
);
$result = wc_create_attribute( $args );
}
}
// On Activation create the credit attribute taxonomy
add_action( 'admin_init', 'woo_create_credit_attribute_taxonomy' );
This piece of code, simply creates a new Woocommerce Product Attribute.
And in the uninstall.php file of the same plugin, I use the WPDB query below to remove it uppon uninstall.
global $wpdb;
$wpdb->query("DELETE FROM {$wpdb->prefix}woocommerce_attribute_taxonomies WHERE 1");
Notes: The Attribute is succesfully being deleted from the Database, but remains visible on front-end and when I try deleting it from the front-end it seems to be stuck there, Until I deactive and Reactivate Woocommerce.
Any ways I could adjust this code to flush_rewrite the woocommerces rules?
I have already tried the cassual flush_rewrite_rules() built-in function from wordpress. But it has no better results.
Thanks in advance for your time and effort
I am running the plugin WP Show Posts on a WP install with a custom post type (called 'trees') that has a custom post field called 'popularity' (formatted as “number”). The custom field was created by the Advanced Custom Fields plugin, the custom post type with the plugin Custom Post Type UI.
Now, I want to create a list, that only shows posts with a popularity value below the numeric value of 10.
To do so, I have followed the plugin author's instructions here and adjusted the plugin itself to allow for additional arguments.
I now use the following code, as suggested in this support article, but unfortunately, I can not get it to work. The output is the “no results message”. 🙁
This is the code I use in my functions.php:
add_filter( 'wp_show_posts_shortcode_args', function( $args, $settings ) {
if ( 4566 === $settings['list_id'] ) {
$args['meta_query'] = array(
array(
'key' => 'popularity',
'value' => 10,
'compare' => '<'
)
);
}
return $args;
}, 15, 2 );
What do I do wrong? For example, do I have to specify the custom post type (i.e. trees)?
If you really want to use this "WP Show Posts" plugin, at the moment that i'm writing this answer, you need to modify its core functionality in order to be able to modify its query.
Go to this path your site folder > wp-content > plugins > wp-show-posts, and open up wp-show-posts.php. On line 386:
Replace
$query = new WP_Query(apply_filters('wp_show_posts_shortcode_args', $args));
with this:
$query = new WP_Query(apply_filters('wp_show_posts_shortcode_args', $args, $settings));
Now you can modify the query. Use the following snippet in your functions.php file.
add_filter('wp_show_posts_shortcode_args', 'your_custom_query', 10, 2);
function your_custom_query($args, $settings)
{
$args = $args;
if (4566 === (int)$settings['list_id']) {
$args['meta_query'] = array(
array(
'key' => 'popularity',
'value' => '10',
'compare' => '<',
'type' => 'NUMERIC'
)
);
}
return $args;
}
Note:
Make sure 4566 is the id that WP Show Posts plugin gives you, otherwise it won't work.
By following these steps, you're modifying, WP Show Posts plugin core file (i.e. wp-show-posts.php) which is NOT RECOMMENDED. So on the next update of the plugin, make sure that the line you modified, stays intact, otherwise it'll break you page. So keep an eye on the updates!
Because your field type is numeric, i've added 'type' => 'NUMERIC' argument, otherwise it won't work.
Another solution using wp_query. NO EXTRA PLUGINS
This is a simple wp_query that allows you to do the job without using any third-party plugins.
$args = array(
'post_type' => 'trees',
'posts_per_page' => -1,
'meta_query' => array(
array(
'key' => 'popularity',
'value' => '10',
'compare' => '<',
'type' => 'NUMERIC'
)
)
);
$query = new WP_Query($args);
if ($query) {
while ($query->have_posts()) {
$query->the_post(); ?>
<h4><?php the_title() ?></h4>
<?php
}
} else {
echo "no post found!";
}
wp_reset_postdata();
This has been fully tested on wordpress 5.8 and works.
Hi I built a navigation widget which works and looks great, showing the logged in person from Buddypress, but obviously I want it to be hidden on the main navigation, the login pages etc..
I'm pulling my hair out here because by all purposes what I'm doing is right? - But it's simply not working, would really appreciate some assistance here! Thanks
/** Register Utility Bar Widget Areas. */
genesis_register_sidebar( array(
'id' => 'utility-bar-left',
'name' => __( 'TRN Member Utility Bar left', 'theme-prefix' ),
'description' => __( 'This is the left utility bar above the header.', 'theme-prefix' ),
) );
genesis_register_sidebar( array(
'id' => 'utility-bar-right',
'name' => __( 'TRN Member Utility Bar Right', 'theme-prefix' ),
'description' => __( 'This is the right utility bar above the header.', 'theme-prefix' ),
) );
add_action( 'genesis_before_header', 'utility_bar' );
function utility_bar() {
echo '<div class="utility-bar">';
genesis_widget_area( 'utility-bar-left', array(
'before' => '<div class="utility-bar-left">',
'after' => '</div>',
) );
genesis_widget_area( 'utility-bar-right', array(
'before' => '<div class="utility-bar-right">',
'after' => '</div>',
) );
echo '</div></div>';
}
add_action('genesis_before_header','remove_bar');
function remove_bar() {
if (is_home() || is_page(www.trnworld.com) || is_page(trn-login) || is_front_page() ) { //Replace post_type with your post type slug
remove_action( 'genesis_before_header', 'utility_bar', 5 );
remove_action( 'genesis_before_header', 'genesis_register_sidebar' );
}
}
From Wordpress documentation:
Important: To remove a hook, the $function_to_remove and $priority arguments must match when the hook was added. This goes for both filters and actions. No warning will be given on removal failure.
add_action( 'genesis_before_header', 'utility_bar' );
does not match
remove_action( 'genesis_before_header', 'utility_bar', 5 );
Additionally You have added the action for displaying the widget and the action for removing the action that displays the widget to the same hook.
From Wordpress documentation on add_action
$priority
(int) (Optional) Used to specify the order in which the functions associated with a particular action are executed. Lower numbers correspond with earlier execution, and functions with the same priority are executed in the order in which they were added to the action.
Default value: 10
You've added both actions with same default priority of 10 and since add_action( 'genesis_before_header', 'utility_bar' ); is added before add_action('genesis_before_header','remove_bar'); it is running first when the do_action function is called on genesis_before_header printing out the widget; after which the second function runs performing remove_action on an action which has already been performed.
See what happens if you change
add_action('genesis_before_header','remove_bar'); to add_action( 'genesis_before_header','remove_bar', 9 );
and
remove_action( 'genesis_before_header', 'utility_bar', 5 ); to remove_action( 'genesis_before_header', 'utility_bar' );
Unrelated note in your function utility_bar() I see 2 closing divs but only one opening. I'm guessing this will cause layout problems in one of the states of being shown.
Background
I register a custom post type and custom taxonomy inside a class. Inside the WP admin, I see both the post type, and I see the taxonomy.
Simplified Code:
class Custom_Post_Type {
function __construct($init_data) {
if ( is_admin() ) {
add_action( 'init', array( $this, 'create_ctp' ) );
add_action( 'admin_head', array( $this, 'create_ctp_icons' ) );
add_action( 'save_post', array( $this, 'save_ctp_custom_metadata' ), 1, 2 );
}
}
function create_ctp_taxonomy() {
register_taxonomy(
$post_type.'_type',
$post_type,
array(
'labels' => array(
'name' => $taxonomy_label,
'add_new_item' => 'Add New '.$taxonomy_label
),
'public' => true,
'show_ui' => true,
'show_tagcloud' => true,
'hierarchical' => true,
'show_in_nav_menus' => true,
'show_admin_column' => true
)
);
register_post_type($post_type_slug,
array(
'labels' => array(),
'public' => true,
'has_archive' => false,
'supports' => $this->supports,
'register_meta_box_cb' => array( $this, 'create_ctp_custom_metaboxes' ),
'taxonomies' => array( $taxonomy_slug ),
)
);
}
}
Again, this works inside the admin area. I can add posts, and I can see the taxonomy and add terms.
Problem
On the front end, get_taxonomies() doesn't see the new custom taxonomy, and get_terms() doesn't see the terms inside it.
I tried several examples of of register_taxonomy, and when I used it outside of the class, it appears on the front end. However, when I moved the examples into my internal create_ctp_taxonomy function, they are suddenly invisible to get_taxonomies.
Any ideas why this would be occurring?
Edit
I've been playing around with different things and I think the issue here is the timing of the init action. When I call the setup function direction from the __construct function, rather than adding an action, then things start working. Example:
class Custom_Post_Type {
function __construct($init_data) {
if ( is_admin() ) {
//add_action( 'init', array( $this, 'create_ctp' ) );
add_action( 'admin_head', array( $this, 'create_ctp_icons' ) );
add_action( 'save_post', array( $this, 'save_ctp_custom_metadata' ), 1, 2 );
}
$this->create_cpt();
}
}
By doing this, I skip using init at all. However, this seems to violate standard practice. Is there a downside that anyone knows of for doing it this way?
There are a couple of things you need to be aware of when registering taxonomies to custom post types.
Register the taxonomies first. This seems a bit counter intuitive but taxonomies are registered to post types, so they need to exist before the post type is created.
You also need to register the taxonomy to the post type using the taxonomies argument of the register_post_type function.
Eg.
register_post_type('cpt_name',array(
'taxonomies'=>array(
'taxomony_name1',
'taxomony_name2')
,other_arguments...)
);
From the docs
When registering a post type, always register your taxonomies using
the taxonomies argument. If you do not, the taxonomies and post type
will not be recognized as connected when using filters such as
parse_query or pre_get_posts. This can lead to unexpected results and
failures
Not Problems
1.) The problem isn't a race condition.
Conditionals like is_admin() still work when run from functions.php directly. This contradicts some information on the web, but as of WordPress 4.4, these do work.
2.) Calling the registration from add_action() rather than directly from __construct()
Switching to calling the registration directly had zero change. To be clear, there is no difference between:
$this->create_ctp()
add_action('init', array( $this, 'create_ctp' ) );
3.) Order of registering taxonomy vs CTP
When I moved my registration of the taxonomy in front of the CTP, it had zero change in behavior.
The Problem
I was using a conditional check of is_admin(), which I'd added previous to wrap when I added the admin dashicon. This is why my CTP was appearing on the backend, but not on the front.
I had removed it from my simplified example, so there was no way to tell from looking at the code that I'd posted.
So all I needed to do was remove the is_admin() check. A silly mistake it turns out, but useful to find the information about what things aren't actually problems.
I want to hide sub-nav in profile settings
I hide sub-nav comment "wp-content\plugins\buddypress\bp-settings\bp-settings-loader.php"
// Add General Settings nav item
$sub_nav[] = array(
'name' => __( 'General', 'buddypress' ),
'slug' => 'general',
'parent_url' => $settings_link,
'parent_slug' => $this->slug,
'screen_function' => 'bp_settings_screen_general',
'position' => 10,
'user_has_access' => bp_core_can_edit_settings()
);
What sub-nav item are you referring to? If you want to remove the Settings menu option entirely you can do this in a plugin or functions.php
function my_admin_bar_mod(){
global $wp_admin_bar;
$wp_admin_bar->remove_menu( 'my-account-settings' );
}
add_action('wp_before_admin_bar_render','my_admin_bar_mod');
To remove just the Profile option under Settings use this instead:
$wp_admin_bar->remove_menu( 'my-account-settings-profile' );
UPDATE:
The following code will remove the General tab; I believe that is what you want. Correct? This code does that but I am seeing a problem. It might be a rewrite problem on my dev site where the Settings tab causes a 4040 error. Can you try this on your site and let me know?
function mcs_bp_remove_nav() {
global $bp;
bp_core_remove_subnav_item( $bp->settings->slug, 'general' );
}
add_action( 'bp_setup_nav', 'mcs_bp_remove_nav', 99);
Finally:
This code is needed in addition to the above. It changes Settings to point to the Email tab. It was defaulting to General and since that was removed we see a 404. This hook must fire earlier than the code that removes 'general'.
function mcs_bp_change_settings() {
global $bp;
// point setting to Email page (aka 'notifications')
$args = array( 'parent_slug' => 'settings',
'screen_function' => 'bp_core_screen_notification_settings',
'subnav_slug' => 'notifications'
);
bp_core_new_nav_default( $args );
}
add_action( 'bp_setup_nav','mcs_bp_change_settingst', 5);