functions.php

radicle
1

Where should I put content that was previously in functions.php? I believe that file is missing in radicle without any migration notes.

2

What were you using functions.php for previously? If you’re a Sage user, functions.php hasn’t really had anything in it since 2012

You’d likely want to create a service provider, or a plugin, or a mu-plugin

3

What were you using functions.php for previously

Add filters to REST interface, make /search urls more readable, tweak random plugin settings. Didn’t seem quite right for the places you listed, am I wrong?

4

The functions.php file for a theme is not the appropriate place for that type of code

If you don’t want to setup service providers, I recommend just creating single mu-plugins for this type of thing.

For example:

  • mu-plugins/search-urls.php with your search URL code
  • mu-plugins/plugin-name.php with plugin-name specific code

Wrap everything in those files in a hook like init:

add_action('init', function () {
    // Your code here
});
4 Likes
5

Thank you. Are we still calling Radicle a theme when it resurfaces this much of a wp install?

6

The functions.php file in a theme should never be used for the functionality that you’re describing on any type of WordPress setup

1 Like
7

This makes total sense after reading a lot of the documentation, but I think you’ll find a lot of WordPress websites using the traditional structure will have functions.php files loaded with filters, actions, etc.

For example, themes like _s uses it to do a bunch of random little tweaks here and there. Most of them are taken care of by the App\Providers\ThemeServiceProvider, but what about random helper functions?

When I downloaded Radicle earlier today, I just wanted to modify the acf-json directory location, but I couldn’t figure out where to put the filter lol. Based on what you’re recommending, that should be in an mu-plugin called advanced-custom-fields-pro.php and wrapped by init. Now that I’ve written this out, that actually makes a LOT of sense.

Regarding service providers, am I correct in assuming we should use Acorn to create a new service provider? What would you suggest service providers should be used for vs individual mu-plugins like you described in the accepted solution?

8

WordPress tutorials that suggest using using the theme functions.php file as a dumping ground for everything are doing it wrong, IMO. They’re likely geared towards the typical WP dev/beginners as opposed to someone who wants to have better organization of their codebase.

The functions.php file from Underscores isn’t that bad. They at least have lots of separate files from the inc/ directory that they load. All of it is theme-specific functionality as well.

There’s app/helpers.php that you can use for this

Yes :+1: wp acorn make:provider

I think it depends on the scenario

1 Like
9

Thanks for the responses Ben! I haven’t used Laravel in a real world application, so a lot of these concepts are new to me. Every time I see a new concept in Radicle, if I can’t find anything in the docs, I’ll generally look at the Laravel docs and that tends to explain it fairly well.

2 Likes
10

Thank you @Matt_Neal and @ben for teasing out the best practices for the rest of us.

Using a service provider seems like the appropriate path for more complicated bits like plugin template overrides, but there’s a lot of Laravel-specific knowledge to learn first - a big jump away from requireing files from functions.php. Laravel docs definitely required reading.

I also sound this useful, for those on a similar journey: Laravel Service Container and Service Providers Explained - DEV Community

3 Likes