Consider dropping Genesis init.php require from functions file

[nickcernis]

In response to this from Gary Jones on Bill Erickson's site:
https://www.billerickson.net/genesis-dont-start-engine/

We could consider dropping this line from functions.php and using a setup function hooked to genesis_setup.

require_once get_template_directory() . '/lib/init.php';

Background

WordPress loads child theme code before parent theme code.

We require init.php in child themes to ensure Genesis loads before the child theme, so that functions such as 'genesis_register_sidebar' will work in the child theme.

If you remove the init.php line at the moment, for example, function calls to genesis_ functions such as genesis_get_config and genesis_register_sidebar will cause a fatal error.

Proposed change

The article proposes dropping the init.php line and hooking setup code to genesis_setup instead, causing child theme code to run after Genesis has loaded.

Instead of pulling Genesis code ahead to load early with the init.php require, hooking code to genesis_setup pushes Genesis Sample code to load later.

Benefits

As the article outlines, this is closer to “the WordPress way”, and follows themes such as Twenty Nineteen that use a similar setup function.

There are some other minor benefits outlined (such as reducing code in global scope), but I think following the natural WordPress load order and removing a line whose purpose may not be immediately clear are the main benefits if we adopt that approach.

Downsides

Developers modifying the theme would need to know that genesis_ functions will cause fatal errors if they're used at the global level outside of action callbacks.

We should explore whether theme snippets in blog posts use genesis_ functions at the global level. There's likely to be an impact on support if snippets will break.

We also need to audit our own snippets before making any change like this.

[jb510]

+100 - we’ve always used a setup function, and we often find ourselves retrofiting SP’s child themes to use a setup function before doing customization work on them.

I’m not suggesting SP make that change to existing themes, although it’s honestly quick and easy change.

This and the age old blog.php template use are the wo things that icould never wrap my head around as a developer building Genesis child themes. They both always seemed like something intended to make things easier, but resulted in non-standard and more confusing.

Sample is the right place to make this change as it sets a new best practice for Genesis child themes going forward. I can’t think of where I’d ever use a Genesis_ functions at a global level.

[seothemes]

I'm all for this but am a bit concerned about how much responsibility it places on the average user.

Most are used to just copying and pasting code snippets to functions.php from all over the place and expecting it to work. This change would create a wave of support tickets until people have caught up. It will take a huge effort by the entire community and SP to update snippets in existing Genesis tutorials.

Really, placing custom code in functions.php should be avoided any way, either by using a customizations plugin or some other way. Maybe it would be best to educate users on how to do this at the same time, so that they can easily update their themes in the future.

That being said, I think the sooner this happens the better. It means there will be less time for people to continue making themes and tutorials using the old method.

[JiveDig]

It may be a nice option for StudioPress/Genesis to provide another small plugin for code snippets. There could be a dedicated section for "Genesis snippets" that are loaded on genesis_setup. The plugin/module thing was discussed in a recent shapers meeting and this is a perfect fit IMO.

[seothemes]

-> https://github.com/seothemes/genesis-code-snippets/

[jb510]

Admitting my ignorance... How is that not already serviced by Genesis Simple Hooks (GSH)? (disclosure, I haven't used GSH in 5+ years).

Perhaps GSH is just lacking and needs to be improved?

Kee's POC is great, but maybe that gets merged with GSH? Could there be a free form section added to GSH where PHP can be added any hook, not just genesis?

Personally, I never liked GSH because I found the UX cumbersome. I had to hunt around to find the hook in the code/visual hook guide, then hunt around to find the textarea to put code in.

I'm always conflicted on this topic though as I pretty strongly dislike code being stored in the database for performance and security reasons. That said, users do need a way effect these sorts of changes without making child theme updates potentially damaging. It seems like a band-aid for root child theme update problem.

Anyqay, it would be nice to have something universally available and might help users avoid confusion if they've been dropping code in functions.php without wrapping them in a function and hooking them to something.

[JiveDig]

Agreed on all points. GSH may be the best route, but an update to make the main snippets/code interface like a big functions.php file. "Put all your code here". Even if it's not Genesis specific it should still be fine running on genesis_setup hook 99% of the time. Then the other specific hook sections that GSH provides can be secondary for specific stuff.