All WordPress themes must have a file called functions.php. Traditionally, this is the file that contained all the set up of the theme and all the customizations. However, as WordPress has evolved, more and more of that functionality has moved out of functions.php and into other files.
In WP Rig, we’ve taken that to the extreme by removing all functionality from functions.php, and just letting this file control the function of WP Rig itself, so that all the modularity works.
That means, as you create new functions for your own custom themes with WP Rig, you never touch functions.php itself. This file is no longer where you place any functionality. All custom functionality lives inside the “/inc” folder under different php modules.
This also introduces a new way of doing things where custom functions are concerned, and here is an example showing how.
If we go to sidebar.php, the template file that generates the sidebar, you’ll see a conditional statement that says, “if not WP Rig is primary sidebar active.” The operative function here is this one, is is_primary_sidebar_active().
But then. it’s prefixed by the wp_rig() function, and if you hover over it, it says, “provides access to all available template tags of the theme.” This function was introduced in WP Rig to ensure that you stay within the namespace of the theme. In very simple terms, it just means you can’t call this function from outside the theme, and this function will never collide with anything that happens in WordPress itself.
This setup looks different from how a traditional theme would do it. You’ll notice there is no theme name prefix in front of this custom function but it works much the same way. So instead of the theme prefix, you have this custom wp_rig() function, which handles that functionality for you.
We see this again and again here. We have wp_rig()-> is_primary_sidebar_active(). Then, we have wp_rig() -> print_styles(), which adds the style sheets, and further down you see wp_rig() -> display_primary_sidebar().
So what are these functions: is_primary_sidebar_active() and display_primary_sidebar()?
Well, if we go to the sidebar component, we can find these functions declared. So let’s start from the top and see how all this is strung together. First, we declare a new constant called PRIMARY_SIDEBAR_SLUG, and this will be the slug that’s used for the sidebar:
This is what we target anytime we are working with the sidebar.
Scrolling further down, we set up the template tags that will be available to the theme. And those template tags are: is primary sidebar active and display primary sidebar
They point at functions that sit inside this particular file, is primary sidebar active and display primary sidebar. So this is how the new object orientation takes an existing function inside a component and lifts it up so it becomes available to the rest of the theme. Then we register a sidebar just like we normally would in a WordPress theme only we use the ID static:: PRIMARY_SIDEBAR_SLUG. (It’s the slug that was defined up at line 30.)
Then when we scroll to the bottom, we find these two custom functions that were used in sidebar.php: is_primary_sidebar_active() and display_primary_sidebar(). And as you can see, these functions wrap standard WordPress functions, so we have is_active_sidebar() inside is_primary_sidebar_active(). Likewise, you can see dynamic_sidebar() inside display_primary_sidebar().
What’s happening here is that WP Rig is wrapping WordPress functionality in new custom functionality to provide tighter control over exactly what happens. Instead of calling dynamic_sidebar() directly from sidebar.php, we call this custom functionality in the component. That means we can filter the output and change the output into whatever we want before it gets passed on to WordPress.
Like we mentioned earlier, this is different from how WordPress themes have operated until this point. But, this is how PHP is written as of right now. It’s a different way of approaching things, and it gives you far more control once you see what’s going on.