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);
Related
So I ran into a issue where the customizer preview doesn't fully refresh. Only when I manually refresh the page I see my changes. Some of my code to help explain below.
For my customizer settings I have code that looks something like this
$wp_customize->add_section( 'theme_layout', array(
'title' => __( 'Layout', 'theme' ),
'priority' => 30
) );
$wp_customize->add_setting( 'theme_header_layout', array(
'default' => 'default',
'transport' => 'refresh',
) );
$wp_customize->add_control( new WP_Customize_Control( $wp_customize,
'theme_header_layout', array(
'label' => __( 'Header', 'theme' ),
'section' => 'theme_layout',
'settings' => 'theme_header_layout',
'type' => 'select',
'choices' => array(
'default' => 'default',
'special_header' => 'Special Header',
)
) ) );
Now In my functions.php I have code like this
//this is the code that doesn't seem to execute when the customizer refreshes
if ( 'special_header' == get_theme_mod( 'theme_header_display' ) ):
function theme_special_header( $items ) {
$items .= do_shortcode('[special_header_shortcode]');//This shortcode exists I just didnt bother mentioning it here
}
add_action( 'wp_nav_menu_secondary-menu_items', 'theme_special_header' );//Adds shortcode to menu with id of secondary-menu
endif;
This all works great accept when I go to the customizer and select 'Special Header' the customizer refreshes and I don't see my changes until I completely refresh the page.
I had also faced similar issue earlier. Rather than adding conditional outside, I kept it inside the function and it worked. You can try similar approach for your code and it may help.
Following is not exact answer for your question but it may help to fix your problem.
function wpso_customize_menu($items, $args) {
if ( 'special_header' == get_theme_mod( 'theme_header_layout' ) ) {
if( $args->theme_location == 'menu-1' ) {
$items .= '<li>Custom Link</li>';
}
}
return $items;
}
add_filter('wp_nav_menu_items', 'wpso_customize_menu', 10, 2);
In the backend of Wordpress I use the default http://localhost/sitename/example-post/ value for creating permalinks.
For custom post types I defined a custom slug this way, here is services for example:
register_post_type( 'service',
array(
'labels' => array(
'name' => __( 'Services' ),
'singular_name' => __( 'Service' )
),
'public' => true,
'has_archive' => true,
'rewrite' => array(
'slug' => 'services',
'with_front' => true
),
'supports' => array(
'title',
'editor',
'excerpt',
'thumbnail'
),
'taxonomies' => array( 'category' ),
)
);
It creates services/post-name.
I also use this hook to create a custom page to create a custom page permalink:
function custom_base_rules() {
global $wp_rewrite;
$wp_rewrite->page_structure = $wp_rewrite->root . '/page/%pagename%/';
}
add_action( 'init', 'custom_base_rules' );
It creates page/post-name
Now the only thing I need to do is to create another custom permalink path for the normal Wordpress posts.
So the outcome world be for the post type of post:
post/post-name
I can't use the backed for this because I already defined a default way of handling the permalinks. I already managed to rewrite the paths of custom post types and pages...
How do I rewrite the normal post post type permalink path in Wordpress programmatically?
You need to do it in two steps.
First enable rewrite with 'with_front' => true for the buildin post registration
add_filter(
'register_post_type_args',
function ($args, $post_type) {
if ($post_type !== 'post') {
return $args;
}
$args['rewrite'] = [
'slug' => 'posts',
'with_front' => true,
];
return $args;
},
10,
2
);
This way urls like http://foo.example/posts/a-title work but generated links in are now wrong.
Links can be fixed by forcing custom permalink structure for the buildin posts
add_filter(
'pre_post_link',
function ($permalink, $post) {
if ($post->post_type !== 'post') {
return $permalink;
}
return '/posts/%postname%/';
},
10,
2
);
See https://github.com/WordPress/WordPress/blob/d46f9b4fb8fdf64e02a4a995c0c2ce9f014b9cb7/wp-includes/link-template.php#L166
Posts have to use the default permalink structure, they do not have a special entry in the rewrite object in the same way that pages or custom post types do. If you want to change the default structure programmatically, you can add something like this to your hook.
$wp_rewrite->permalink_structure = '/post/%postname%';
I'm not super clear what you mean when you say
I can't use the backed for this because I already defined a default way of handling the permalinks. I already managed to rewrite the paths of custom post types and pages...
It sounds as though you're overriding the default behavior for permalinks everywhere except for posts so if you changed the default it would likely only affect posts anyway.
The permalink_structure property suggested by GentlemanMax did not work for me. But I found a method that does work, set_permalink_structure(). See code example below.
function custom_permalinks() {
global $wp_rewrite;
$wp_rewrite->page_structure = $wp_rewrite->root . '/page/%pagename%/'; // custom page permalinks
$wp_rewrite->set_permalink_structure( $wp_rewrite->root . '/post/%postname%/' ); // custom post permalinks
}
add_action( 'init', 'custom_permalinks' );
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.
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' );
}
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.