Fifty Actions of WordPress – 50 Examples

Fifty Actions of WordPress – 50 Examples

 

Captura de pantalla 2017-04-12 a la(s) 23.16.20

Let’s begin!

WordPress has many CSS files for its back-end and front-end to use. With the wp_default_styles action, we can monkey with the default styles of WordPress.

If you’re the only one using the administration panel of your WordPress website and you’re not using Internet Explorer, there’s no need to load the IE-fixer CSS file, right?

You can use the code below to get rid of the ie.css:

Actually, I’m not even sure that WordPress needs this file anymore – after all, ie.css fixes things that looks bad on IE7 and below and as far as I know, the usage percentage of IE7 has dropped below 1%.

We should suggest a patch, don’t you think?

If you need to work with the get_footer() function, you don’t need to look any further – you can use the action with the same name, get_footer!

Let’s say you have some jQuery goodness you need to print at the footer of your web pages. You can use these bits of code to make it work:

There. We used some JavaScript code for this example but you can practically run any code to your footer.

This handy little function fires every time an admin page is visited, so it has many different uses. Get creative!

Let’s say you don’t want your subscribers to be able to visit the administration panel and you don’t have any contributors, authors or editors. To redirect all the non-admin users to homepage, you can use the code snippet below:

If you want, you can change the redirection adddress from your homepage to something else: Just delete the site_url() bit and enter the desired address with single quotes (like 'http://www.google.com/').

The inline documentation defines this action simply with these sentence: «Runs to authenticate a user when they log in.»

WordPress doesn’t allow users to log in with their email addresses – you have to remember your username. If your user base tends to forget their usernames, you can use the code snippet below and tell your users that they can log in with their email addresses, too:

Now, your users can enter their email addresses instead of their usernames.

The login_form action lets us manipulate the output of the classic WordPress login form.

In the previous example, we showed you how to let your users use their email addresses instead of usernames. If you’re not a fan of this behavior, however, you can warn your users about the fact that they can’t use their email addresses:

Of course, you can put other warnings like «Don’t click on the ‘Remember Me’ checkbox if you’re on a shared computer!» or a funny one like «If you’re under threat by a robber while you’re logging in, enter your password backwards and WordPress will automatically call the police – but wait, if you’re reading this, then the bad guy will read it too… RUN!». You can also use HTML.

Defined as «runs after the basic admin panel menu structure is in place», the admin_menu action lets us add or remove menu items (and sub-menu items) into/from the WordPress admin panel’s menu.

It’s a familiar scenario for freelance WordPress developers: A client needs access to a certain plugin’s «Options» page, but they shouldn’t be touching any settings in WordPress’ own «Options» pages.

In short, there are pages that clients need to access and there are ones that they shouldn’t access. The example below helps us remove menu items from the main admin menu:

Comment out or delete the lines you don’t want, and you’re good to go!

Let’s see what the documentation says about this action:

«Executes after the query has been parsed and post(s) loaded, but before any template execution, inside the main WordPress function wp(). Useful if you need to have access to post data but can’t use templates for output.»

In short, it fires off after the query’s been loaded. Simple, like its name.

While cron jobs are usually hooked to a plugin activation hook, we can also use the wp action to hook our cron jobs to. Let’s see the example provided by the Codex:

Notice that there’s another action named prefix_hourly_event – that action is created automatically in the same code snippet, right inside the wp_schedule_event() function, as its third parameter.

There are various hooks (actions and filters) that have «variables» in their names. The admin_head-(page_name) action is one of them, which is called in the <head> for a specific admin page which is defined in the variable.

I use a 22» monitor and since WordPress version 3.8, I’m forced to use 4-column Dashboard which is kind of annoying for me. I’m not sure why I can’t set a number of columns like I could earlier, but I found a quick solution to the issue:

Now I can change the number of columns like we used to – as long as my screen width allows. I still can’t choose over 2 columns on my laptop, but I think I can live with that.

The WordPress Toolbar, formerly Admin Bar, is a great and useful navigation element that helps us in both front-end and back-end. And the wp_before_admin_bar_render action helps us interact with it before it’s rendered.

If you want to provide a quick link for your clients to reach you, you can use these lines of code to add a link to their site’s Toolbar:

Easy, right? You can use the add_node() function again to create as many links you like.

The profile_update hook lets us fetch and work with the user data right after it’s updated in the database.

Advertisement

Let’s say that you want to inform users each time they update their profiles. With the help of our handy action and a small function, you can do it:

In my opinion, this is a simple yet effective security measure. That said, it wouldn’t be effective at all if a potential hacker changes the user’s email address, since the email will be sent to the new email address.