How to hide prices, and almost anything else, in WooCommerce • WordPress Help

Yesterday talking to a friend who has an NGO raised the issue of how ugly it is sometimes to see the prices and ranges of prices in the pages of WooCommerce so I got down to work to see how to hide them and, of course, share it with you so that you also learn to do it.

And look where It is not difficult, and we have a few possibilities.

Ready to become a WooCommerce ninja?

Hide prices only in store

If you only want to remove prices on the store page, add this code to the functions.php file of the active theme (child):

Here you have the before and after …

Hide prices everywhere except in the cart, the final purchase page and product

] For obvious reasons it does not make sense that the prices do not appear in the cart and in the page where the purchase is finalized, where it is paid, but in the rest of the pages. Simply use this other code if you want to hide the prices in the store and in the category pages:

Hide prices on the product page

But there's more, because you may not want the price list, or variations, on the same page of the products, or anywhere a simple product appears, such as linked products for example.

If this is the case, the code to be used will be this one:

And this is the difference …

Hide prices on all parts

A mix of all the above would be this code, with which we hide the prices everywhere except the cart and the payment page:

Hide more things from WooCommerce

Ah buddy, you got the bug, huh? Well you should know that you can remove practically almost anything from WooCommerce, you just have to know which ones are available and remove the hook.

A visual guide of the actions of a WooCommerce product page would be this: [19659003]

Now with the previous reference, you only have to decide which actions you are going to remove. To do this, you just have to choose what you want to hide from the following list of actions and change add_action by remove_action and add the chosen line to the file functions.php of the subject ( son ​​please ) active.

The list is this:

So if, for example, you do not want to display the list of categories and labels on the product page etas, the elements meta you would add this to your functions or file plugin functions.php :

which is not difficult?

The limit is your imagination, and the clear WooCommerce API . Maybe you'll think about " and there is not a plugin that does these things? ", and yes, there is something out there, but are sooooo limited, that you will not have all the freedom that the code gives you, so you still have to install 4 or 5 plugins to achieve what you would achieve with only 3 lines of code.

And, besides, it never hurts to dare with a little bit of code and step learn, grow do not you think?

A jugarrr and customize!

Loading …

That may also help you:

Plugins children or dependents? – The correct way to customize plugins

One of the most common development tasks for the WordPress programmer is the modification and customization of plugins to create applications adapted to the needs of the client but there are many ways to do it wrong and many to do it well .

The most usual way to do it wrong is any variation of modify the plugin " bareback " add, delete, modify the plugin code and give it to your client as is.

And yes, the beauty of open source, Open Source, and that WordPress is GPL is that you always have the code there to modify it, but the problem is that if you modify the plugin and give it tuned to a client you will deny the updates of the original plugin generating ole a security problem and another of loss of future functionalities.

It is good that you can always do your plugin maintenance, for a small fee, but even for you the updates will be hell, because you will have to do them manually, reviewing each line of code, the dependencies with your modifications, etc., etc.

Are we talking about child plugins?

 son ​​plugins and plugins father

Plugins children ?

There is the concept and development of child themes but, in principle, the same concept does not exist for plugins so there is no such thing as what we might call a child plugin or a structured and unified mode of do what. It has been proposed but has not prospered so far.

Perhaps the most promising advance came from the part of Plugin Dependencies a meta-plugin that even offers an interface from the than checking the dependencies of a child plug-in on a parent, even using this terminology. The plugin warns of the dependencies when activated and even allows to deactivate father and son in unison.

An example of use they show it in the same page of the plugin …

What does this child plugin do?

  • Prevents BuddyPress Debug from being activated if BuddyPress and Debug Bar are not active before.
  • When either BuddyPress or Debug Bar is deactivated, BuddyPress Debug will also be disabled.

The problem is that few plugins include dependency information, but the idea is good, and maybe one day it will develop.

However, it is not as simple as the son themes, because they all have a similar structure, while the plugins are each of his father and his mother.

So how do we do it? It is more can you?

Yes, and there are several ways to customize plugins let's see them …

Contact the developer

From obvious to very few people it occurs to you that there is no simpler way to customize a plugin than to contact the developer, suggest your modifications and incorporate them into a new version, even with your help.

Do a fork

Another possibility, which can, and should, previously pass through the previous method, is to make your own version of the plugin, a fork that includes those modifications that you have detected and want to add.

good thing about this method is that if you upload your fork to the official directory of plugins other users will enjoy your good ideas and work. In step you gain prestige in the community and to your present and future customers.

The bad thing about this method is that you acquire a commitment to its maintenance, something not always possible.

Create a dependent plugin with hooks

We have finally arrived at something viable and correct!

The correct way to customize a plugin is to create another plugin child dependent on parent that, using [19659037] custom hooks use the functions of the parent extending or modifying its functionalities.

And, as you already know, there are two types of hooks or hooks : action hooks and filter hooks . Are we going to it?

What are action hooks and filter hooks?

You've seen, and even used, many of them. Whenever we see a mode of customize WordPress without modifying the files core we do it using action hooks and filter hooks.

Yes, I I refer to all the modifications and customizations that we make using our utilities plugin or adding custom functions to the file functions.php of the topic .

So if the developer of the plugin already included in his code personalized hooks you are in luck. It is a good practice for good developers, although not all of them still use it.

Extending a plugin with hooks

All you need to do is create a separate plugin that runs in conjunction with the plugin you want to customize, and record the callbacks for the custom hooks offered by the original plugin .

Extending plugins with action hooks

The actions are hooks (or hooks if you prefer) that launches the WordPress kernel at specific points of its execution, or when something happens. They are PHP functions that are executed in these execution points, either in WordPress, plugins or themes, and allow you to customize their behavior.


With this we can already interact with the function and use its arguments ($ args1, $ args2) using the hook 'Name- De-tu-Action-Hook '. For example:

Extending plugins with filter hooks

Filters are hooks which launches WordPres to modify text or others elements before adding them to the database or sending them to the browser. Your plugin can specify that one or more of its PHP functions modify specific types of text.

Let's look at an example again:

And, as in the previous case , we can do things with that function, filter the $ output and use its arguments ($ args1, $ args2) using your hook 'Name-Of-Your-Filter-Hook'. So …

Registering callbacks

Surely you have noticed that in the methods seen we are registering callbacks that replace the of the original plugin and replace them with ours.

Then, in our callbacks we call the functions of the other plugin, the father, that we need to recreate the parts of its functions that we want to expand or modify, and we avoid the parts we do not need.


 father son

As you will see, although the concept of child plugins does not exist as such, it is totally feasible to take advantage of the functionalities of an original plugin and expand them with our own plugin that, half nte hooks, take advantage of its base functionalities and add or replace those that we want to modify.

In this way we will have our custom plugin son ​​dependent on the original plugin father which our client will be able to update normally without losing the customizations that we have added.

We just have to clearly indicate in the documentation the dependency, so that no one can think of uninstalling the plugin father as it is Logically, or will also stop working our customizations, not being an independent plugin, but dependent.


Fortunately there are many good examples that we can learn this type of techniques, here are some dependent plugins:

References for further knowledge:

NOTICE : This publication is from two years ago or more. If it's a code or a plugin it might not work in the latest versions of WordPress, and if it's a news story it might be obsolete. Then do not say we have not warned you.

Loading …

That may also help you: