Closed ttodua closed 4 years ago
I am wondering what other people decide their theme ought to be? I personally like the use of hooks within WooCommerce as it helps tidy stuff up.
But will it be necessary to do so with a theme?
I don't remember a site I've build, and there wasn't a need to place a custom function somewhere in a there. So, we had always to "modify" the current theme code to inject one line codes of "do_action" in different parts. All themes should have it, why only woocommerce? what if we want to change other themes too?
I'm more used to seeing hooks in plugins than in themes but I guess I don't mind having them in a theme 😄
There was a previous pull request https://github.com/Automattic/_s/pull/671 to add the support for "Theme Hook Alliance". It was decided again merging those hooks.
As _s
is meant to be adapted and not necessarily extended I don't think the hooks are needed.
I would rather see core support a standard set of the hooks https://core.trac.wordpress.org/ticket/21506
As most templates are small then can be easily be overridden with causing too much code to duplicated.
There is not need for the _s_*_bloginfo
filters as instead the core bloginfo
should be used.
I have not mentioned about functions like _s_*_bloginfo
for bloginfo
. This is too irrelative to the original post.
This might be my last comment, that you are doing wrong. Everywhere _s
is declared to be a boilerplate, the starter theme, and actually _s theme should be a guide for fellow theme developers. Telling that "this is not Genesis theme" doesn't win argument. Theme is meant to be a theme, a main part of website, and that needs to be as much decent area, as possible, and the hooks will do it's regular job (because almost all development depend on hooks).
If something is for programmers, it should be for programmers. Theme development and coding is for programmers, and not for Clients. So, "leaness" should not be aim, instead adoption and usage. But _s
is heading the opposite way (even more, I can't see any reason what was disadvantages of implementing it, just 1 or 2 line in each .php file).
So, thousands of theme developers are brought up by such "boilerplate" and then they produce themes, which makes headaches to plugin developers.
Almost on all websites (probably have built up to 100) I had to modify hardcoded lines in themes to add some hooks there or here.
Well, very bad.. We'll surely avoid any recommendation to _s
theme to our clients and blog-readers. We are intensively developing bunch of plugins, so we needed to have a theme that meets standards.
@ttodua Thanks for your PR and your input. While you make a good argument for hooks, @grappler is right in that _s
 isn't meant to be extended, but adapted. Underscores is more of a foundation than a theme system.
We've been holding off on some of the more advanced theme building techniques (eg: SASS only, requiring build tools, adding action hooks, etc) in the interest of keeping the theme easier for people who are just getting into building their own theme. We also use it as the base for most of the themes we build at Automattic.
That isn't to say that our way is best. When you look at how different themes are built, there are as many methods as there are developers. If you use hooks in all of your themes, that's great! I'd highly encourage you to fork _s
and make it your own, then share that with your audience rather than abandoning it completely.
Thanks again for your input.
Changes proposed in this Pull Request:
I was initially surprised how Automattic missed the most important & educational parts of any theme/plugin. Hooks - that's what everything should use. So, it's quite negatively affected, when theme/plugin developers are not educated or encourage to implement hooks everywhere. So, let's do that.
Related issue(s):
Missing hooks everywhere.