New answers tagged

0

previous_post_link() and next_post_link() should work inside the the_content filter. There is nothing wrong with your code except you must return the value inside the filter instead of print. Otherwise I believe post link should be there at the beginning of content. previous_post_link() and next_post_link() print the output so consider using ...


0

There are various ways to do that, e.g. by moving the add_action for method b inside a class AwesomeClass{ private storedResult; private __construct(){ add_action( 'set_logged_in_cookie', array($this, 'a'),10,1); } Function a(p1){ //some interesting process with p1 // UPDATE $this->storedResult ...


1

I think a better implementation would be a "message" class e.g.: class WPSE_224485_Message { private $_message; function __construct( $message ) { $this->_message = $message; add_action( 'admin_notices', array( $this, 'render' ) ); } function render() { printf( '<div class="updated">%s</div>', ...


0

Not sure what you're looking for here, but it sounds like you don't want to use classes and this has to be supported by PHP 5.2. Another approach, within these restrictions, might be to apply a custom filter within your admin_notices callback, e.g. $value = apply_filters( 'wpse_notice_value', 'some default value' ); where you would hook into the ...


-1

Another solution for this is to initialize a global variable which will be visible inside the hooks too. Change its value with the affected rows and use it after do_action()


4

The cool thing is a filter is the same as an action, only it returns a value, so just set it up as a filter instead: add_filter( 'myplugin_clean_logs', array( 'MyPlugin_Logs', 'clean_logs' ) ); Then something like: $affected_rows = ''; $affected_rows = apply_filters( 'myplugin_clean_logs', $affected_rows ); should pass $affected_rows to clean_logs() ...


0

I am not sure what is exactly do you need but you can re declare same function and definition in your plugin file or theme function.php as your requirement. I think do you not need to change core functions bcz wordpress also provide developer can override function as own requirement. In pluggable.php file have wp_set_auth_cookie function if ( ...


0

action attribute specifies a form processing agent. When the values of action is empty, data is submitted to the the file containing the form and it will be processed inside that file. The $wpSubmitFromFEObj object is in global space. So it is available anywhere, anytime you call it. As you can see in the handleFrontEndForm(): The isFormSubmitted() ...


0

By default no action url will mean that the form will be sent to the URL the page was loaded from. Once it is done, the code evaluating the shortcode is checking in the form was submitted and process it. This is not not a great way to write a from processing code, as the evaluation of shortcodes happens too late for doing something like redirect on success. ...


0

Provided you've confirmed that WP's native 'suggest' script is actually being rendered on the page properly (ie. you're using the correct template for home vs front-page), sometimes to avoid script conflicts on the page, you need to wrap your script in an anonymous function. So something like: <script> (function($) { ...


0

This shows a more readable list of filters function print_filters_for( $hook = '' ) { global $wp_filter; if( empty( $hook ) || !isset( $wp_filter[$hook] ) ) return; $ret=''; foreach($wp_filter[$hook] as $priority => $realhook){ foreach($realhook as $hook_k => $hook_v){ ...


0

In your child theme's 'functions.php' file, you need to use the 'remove_action( 'widgets_init', '$name' ); script. For instance, in your twentytwelve-child theme's 'functions.php' file, use: remove_action( 'widgets_init', 'twentytwelve_widgets_init' ); //necessary to replace parent theme's code and then hook your new widget in your child theme's function ...


0

Unless you're passing $force_delete as true when calling wp_delete_comment(), the delete_comment hook doesn't fire. This is because WordPress calls wp_trash_comment() at the beginning of wp_delete_comment() if $force_delete isn't set true. Try hooking into the trash_comment action hook: function _dbdb_delete_comment( $comment_id ){ $filter = ...


2

You can call add_settings_section and add_settings_field any time before you do_settings_sections: add_action( 'my_plugin_add_settings_sections', function() { wp_remote_get( ... ); add_settings_section( ... ); add_settings_field( ... ); }); // On the plugin settings page output do_action( 'my_plugin_add_settings_sections' ); ...


0

More importantly you should notice what link is produced by get_delete_post_link(). It's an admin link is_admin() check will be always true. Instead you need something else that helps match the request. Try adding and query arg to your delete link. add_query_arg( 'origin', 'fe', get_delete_post_link( get_the_ID() ) ); then in the action ...


0

To answer your this query @sumit Are you sure about that? One of my friend said that if today it happens in 1.20 a.m next day it will happen after 1.20 a.m, not the 12 a.m. How it works: You schedule an event using current time stamp i.e. 12:00 AM on Monday wp_schedule_event(time(), 'daily', 'my_schedule_hook'); Someone visited the site on Monday ...


2

wp-cron is often called a pseudo-cron, because it doesn't run on a strict schedule. If nobody visits the site, it doesn't run. If you schedule a wp-cron event to run, say, every 12 hours, it will run at most every 12 hours. But, if your site has very little traffic, there could be far more than 12 hours between runs. If you need an event to happen every 12 ...


2

You're adding the action on comment_form_before_fields in comment_form_logged_in_after. The latter is called only when the user is logged in, and the former is only called when the user is not logged in. You can add WordPress actions and filters at any time after WordPress is initialized. If you're adding the action in a plugin, add it on init or even when ...



Top 50 recent answers are included