You simply need to run your code on a higher priority than what the parent theme is, the default on add_action function is 10 so you can use: function s157343_unregister_widgets() { unregister_widget( ‘Chocolat_Widget_New_Entrys’ ); } add_action( ‘widgets_init’, ‘s157343_unregister_widgets’, 20 ); This will unregister that widget. Of course, you can still create a new class that … Read more
It looks like the plugin doesn’t want you do access the APP_Registration instance, so you can try this: add_filter( ‘register_url’, function( $url ) { // Adjust this to your needs $url = site_url( ‘wp-login.php?action=register’, ‘login’ ); return $url; }, 11 ); to override the plugin’s modifications, where we use a priority > 10.
It depends entirely on a) what functions and template files you’re talking about, and b) how those functions are defined, or template files are called, in the Parent Theme. If the Parent Theme uses get_template_part(), then you’re golden. If the Parent Theme uses get_stylesheet_directory_uri() or STYLESHEETPATH, then you can override, with caveats. If the Parent … Read more
Not really, no. You can override built-in PHP functions, but not user-defined functions. However, all this function does is define a meta box. Why not define your own? Once you’ve got your own meta box defined and added, you can call remove_meta_box to remove the standard one: remove_meta_box( ‘add-POSTTYPENAME’, ‘nav-menus’, ‘side’); The meta box is … Read more
I have the same problem on WP 3.2.1. There was a filter conflict because a plugin (User Access Manager) calls manage_users_custom_column filter too. I change priority and it solved the problem : add_filter( ‘manage_users_custom_column’, ‘custom_user_column_value’, 15, 3 ); Hope that helps 🙂
Directly from source for pluggable.php: <?php /** * These functions can be replaced via plugins. If plugins do not redefine these * functions, then these will be used instead. * * @package WordPress */ ?> So, there’s your answer, the functions in pluggable.php are intended to be overridden by Plugins. Re: load order: See this … Read more
Both the header and background image features setup some globals in order to work, unsetting those globals seems to have some effect, and at the least removes them from the administration side. add_action(‘after_setup_theme’, ‘remove_theme_features’, 11 ); function remove_theme_features() { $GLOBALS[‘custom_background’] = ‘kill_theme_features’; $GLOBALS[‘custom_image_header’] = ‘kill_theme_features’; } class kill_theme_features { function init() { return false; } … Read more
Generic Pluggable Approach for WordPress < 4.6 (See @birgire’s Answer for > 4.6) Pluggable functions are one of the more depressing relics of WordPress’s past and come with a slew of intricacies. That directly modifying the core file (which is entirely inadvisable, as @Jarmerson mentioned in the comments) did not work makes me suspect that … Read more
If you have a look at the Action Reference, you’ll see all of the actions executed before pre_get_posts. The two you’ll probably want to investigate are parse_request and parse_query (yes, those are lacking in documentation). The part you’re probably most interested in is parse_request, where rewrite rules are matched against the requested URI. You can … Read more
You’re on the right track with creating the plugin. All your assumptions are correct. To avoid errors on activation you’ll want to wrap the functions that you are redefining in function_exists blocks, as on activation those functions will already be defined: if ( ! function_exists( ‘wp_hash_password’ ) ) : function wp_hash_password( $password ) { return … Read more