I understand init is fired when most of the WordPress is loaded but headers are not sent and wp_loaded is fired when most of WordPress is loaded and headers are sent.
Can someone please explain with an example that what will and will not work with these hooks with a use case scenario that explains and clarifies their difference?
As per my understanding, init hook implies that WP core is loaded but 3rd party content (e.g. themes, plugins, etc.) is only starting to load. Hook wp_loaded means that core and 3rd party content is loaded.
Can someone please explain with an example that what will and will not work with these hooks with a use case scenario that explains and clarifies their difference?
I guess if you want to override 3rd party plugin, you need to use wp_loaded unless the plugin itself creates its own specific "loaded" hook.
If you want to somehow alter default styles and scripts, you need to use wp_loaded as they are not loaded when init fires.
Please see technical clarification below:
init is run before wp_loaded:
init
register_sidebar
wp_register_sidebar_widget
wp_default_scripts
wp_default_styles
admin_bar_init
add_admin_bar_menus
wp_loaded
source: WP Codex
Additional insight for init hook:
Most of WP is loaded at this stage, and the user is authenticated. WP continues to load on the ‘init’ hook that follows (e.g. widgets), and many plugins instantiate themselves on it for all sorts of reasons (e.g. they need a user, a taxonomy, etc.).
source: WP Developer
Additional insight for wp_loaded hook:
This hook is fired once WP, all plugins, and the theme are fully loaded and instantiated.
source: WP Developer
EDIT: also, bear in mind that wp_loaded is executed before admin_init (in case of admin-page request)
Related
I need a good trigger to use in my plugin to kick off changes to the website.
I've got a custom plugin that goes on all WordPress sites that I build. I've got it set up to auto-update the plugin.
Occasionally, I need to push out an update across all websites. For instance, there was a plugin that started causing issues across all sites so I wrote code in my function to deactivate it across all sites.
Now I'm writing code to remove some old users that should no longer have access to the site. To deactivate the plugin, I used the action 'plugins_loaded'. Of course the problem there is that it runs EVERY time the plugins are loaded so it runs on EVERY page load. It's pretty fast but still not the right way to do it.
I tried to find some sort of way to kick that one off only when the plugin is updated. Really, I just need these functions to run once ever.
Is there a good action I could use to make sure that happens?
I want to perform a database operation on plugin update. My current version of plugin doesn't have this hook. I added the following code in the updated version. I am using the following code, but this doesn't work.
add_action( 'upgrader_process_complete', 'init_plugin_update', 10, 2 );
function init_plugin_update( $upgrader_object, $options ) {
error_log('test123');
}
I have seen WooCommerce using the same hook. So is there something i am unaware of ? Won't the new plugin file get loaded before this action ?
The upgrader_process_complete hook, as it's stated in the Codex:
Fires when the upgrader process is complete.
But it's also stated in the Notes:
Use with caution: When you use the upgrader_process_complete action hook in your plugin and your plugin is the one which under upgrade, then this action will run the old version of your plugin.
Effectively it means, if your current version of the plugin is 1.0 and it doesn't have this hook, and you're updating the plugin to version 2.0 which has that hook - it won't get fired.
Further Problems with this and other hooks
To perform a database upgrade (in case your version 2.0 has a different table structure) you obviously can't use this hook.
There is another scenario - when your plugin is updated via FTP and not the admin interface (for example you push some file changes through GIT CI/CD pipelines) - none of the hooks will get fired.
The solution
Manually manage the database version of your plugin.
Save the current plugin version in the database with
add_option.
On init hook (or even better, on
admin_init hook, because it gets triggered only during an admin
request - the Core uses this technique) perform a check if the
current version of the plugin is equal as the saved version in the
database. Use get_option and compare that with the version hardcoded in the plugin itself
If there's a mismatch, that means that the database runs
off of the old codebase and you need to update it
I'm looking to create a tally of the number of core, theme and plugin updates performed on a given WP installation. I envisage that this would involve creating an option into which I store and int value that is incremented every time a core, theme &/or plugin update is successfully performed.
To enable this I was hoping for some hooks are called when each of these update types are performed. However, I can't seem to find any relevant hooks for plugin and theme updates.
For core updates, it looks like I can simply increment the relevant options field whenever the '_core_updated_successfully' hook is called.
Are there any relevant hooks available for plugins and themes?
Can you suggest an alternative methodology?
Thanks in advance.
You can run the upgrader_process_complete action hook. it runs when the download process for a plugin install or update finishes. It takes a type parameter for core, plugin or theme.
wonder if someone can help. I am trying to add a cart widget to the header of a woocommerce enabled site. However, when WP Super Cache is enabled, the widget doesn't update when something is added to the cart, understandably.
I am trying to add the following so the widget isn't cached:
<!--dynamic-cached-content-->
<?php echo time(); ?>
<!-- my_dynamic_content(); -->
<!--/dynamic-cached-content-->
I have just displayed the time in this case to see if I can get it working.
I have set the caching to PHP cache, with late init and dynamic caching enabled but the time still doesn't update when I'm logged out of the administrator.
I have trailed through documentation to see if there is another way to get this working but so far I have not found a way.
Can anyone point me in the right direction? Maybe I've got this completely wrong!
I just want one widget to be dynamic in the header.
Thank you in advance.
There are multiple types of cache for web applications, and WordPress has ways to take advantage of all of them.
Plugins like WP Super Cache, W3 Total Cache, and Batcache as well as server components like Varnish and Nginx implement page caching. These tools store a copy of the complete page and use that cached copy every time the same URL is requested. This is the fastest cache available, but the down side is they return the same HTML to everyone.
If you want to use a page cache but still have dynamic elements like your header widget, you'll have to render them in JavaScript.
If you've written your own theme, you can implement fragment caching by storing the rendered HTML of different sections of the page except the part you want to be dynamic. There's no plugin you can download that'll do it for you. You'll need to make your own judgement calls about what needs to be cached and for how long.
Lastly, you can just cache the data used to render pages. Look for information on WordPress persistent object caching or write code to use WordPress's Transients API. A persistent object cache plugin can automatically store the results of WordPress's queries to something like Memcached or Redis if you have that available.
The Wordpress documentation isn't clear about this: http://codex.wordpress.org/Plugin_API/Action_Reference
What I specifically need to know is whether add_action("publish_post", "myCallbackFunction") is a hook that will apply across the entire Multisite network, or simply on an individual page (or merely for admins).
What I want is that myCallbackFunction is triggered whenever any of the bloggers on the Multisite network clicks the button to publish a blog post.
Ref: http://codex.wordpress.org/Plugin_API/Action_Reference/publish_post
'publish_post' is not attached to a single page (even on a non-Multisite install).
The 'publish_post' hook is run by the WordPress core whenever a post is published. As long as this hook and the callback are part of an active theme or plugin (that exists across all multisite instances), they will run whenever a post is published.