Roots rebuild: discussion and ideas

[swalkinshaw]

It's time for Roots to be rebuilt using proper PHP and OOP practices. The goals behind Roots won't change: implementing HTML5 (specifically HTML5 Boilerplate) properly, cleaning up WordPress' output, and making it easier to develop sites among others. We just want go about those goals in a better way for users of the theme and push forward WordPress themes.

A few things definitely need to happen:

1. Roots will only support PHP 5.3 (it was released in 2009) to use features such as anonymous functions.
2. Roots will be rewritten in an object-oriented way.
3. Templates shouldn't have duplication and HTML elements shouldn't be spanned across files.
4. In general, better template handling. I'd personally like all moved into a separate folder to allow for the possibility of separating out presentation logic (see Ginger Roots - Roots with Mustache #222).

Some resources I've come across about templates:

• http://scribu.net/wordpress/theme-wrappers.html
• template_include_filter: http://www.jaredatchison.com/2011/10/02/taking-advantage-of-the-template_include-filter/
• Modular themes: https://core.trac.wordpress.org/ticket/12877, http://wp.me/pS0xt-1f, http://wp.me/pS0xt-30

I'm sure a lot of Roots users have thoughts on this and what we could do better so let's use this issue as a place of discussion. And don't worry, we know Roots isn't the pinnacle of PHP so we won't be offended by your comments.

Also, feel free to dump links in here for references.

[gingerlime]

Great initiative! I think this is one of the things that can really push the boundaries and make wordpress theme users and designers happier and more productive.

Template access, organisation and clarity is I believe the most important aspect, and perhaps the most neglected and confusing parts of wordpress currently. I always find myself pondering which template is used on a current page, and what impact it will have if I change it. Code and HTML duplication is also commonplace. That said, one of the strengths of wordpress is in its popularity, which means you're expecting certain things to be at a specific place when you look at any existing wordpress setup.

Looks like Roots is primarily geared towards people developing new sites from scratch, so that might not be such a huge problem. As long as things make sense and the learning-curve is short. I don't have any particular preference, and I'm not even sure I fully understand that subtleties of each of those suggestions. My gut feeling is to follow something that works well in other frameworks. Be it rails, django or anything that makes it clear and easy to work and extend. Naturally, I would prefer something that will fit with Ginger Roots and allow easy Mustache integration, or perhaps even a pluggable template engine (I guess I am going too far with this now...).

As for your specific points

1. Agree, and I'm definitely for it. Although it's surprising how many hosting providers still provide PHP 5.2 by default (most cases you can upgrade, but it requires manual intervention). With Roots targeting more serious developers, I guess that's not a problem and they'd know how to upgrade and make sure the environment is running fine.
2. Not sure I fully agree on this. Wordpress is not object oriented, and just provides a bunch of functions. Whilst there are some plugins and extensions which are, I don't think it gives any particular advantage. My experience with php and wordpress is still rather limited though, so I don't feel I can speak with much authority on this.
   3,4 - totally agree and as said, I think that's the key to making a real positive impact.

[swalkinshaw]

Regarding #2:

Roots shouldn't be object oriented just for the sake of it. The way I envision it, it will make it much easier to extend Roots. Child theme's are confusing in WordPress, and adding hooks/filters in every function is really messy. The only way to "overwrite" functions in PHP is using classes.

So a child theme could include the base Roots class, then extend it with their own and overwrite whatever methods they want and even call parent::function() calls. I'd rather people understand how to properly extend Roots via a class rather than trying to figure out some WordPress magic.

edit: I haven't completely thought this through, but it might even be a good idea to actually not use WordPress Child Themes as we know them. They don't really provide much benefit. It might be better to just create a new theme, include Roots, then create a new instance in your functions.php and overwrite whatever you want.

[gingerlime]

That makes more sense. I'm still not convinced though, especially if wordpress itself isn't built this way and you are still pretty much stuck with the existing mechanisms. Some are not that bad to be fair.

As far as child themes. Perhaps again I'm showing lack of experience, as I didn't use it extensively, but I find it hard to buy into the whole concept. On the few occasions that I did modify a theme, eventually it was almost unrecognizable from the parent. Even with the best OO practices, I'd be very hesitant to upgrade the parent theme as it would be very likely to break things badly on the child theme. That's why I think overriding a theme is actually more practical, and with capabilities such as git merge, it's safer to merge changes into your theme than rely on classes and inheritance.

But that's just my view, and it's not something I'm too bothered about either way. Generally speaking I am in favour of any structured change that would make things easier, clearer and more organised.

[Okeanos]

Using child themes the way Wordpress provides them is okay really – as long as it is just that, a child theme. Which means changing way less than half of the original in my opinion (I'd say maybe around 1/3). Otherwise doing what you suggested is actually more feasible I suppose. If you are worried about breaking the child when updating the parent, using a child isn't the correct choice anymore.

1. Enforcing PHP 5.3 – essentially a good step. However proper information (and where feasible/necessary support) for then legacy versions should be provided. Just to not upset users who can't / won't update but still would like to use roots.
2. The OOP approach is interesting. I'd really wonder how it would mesh with Wordpress though. Especially considering people using Wordpress (and modifying/creating themes) aren't always the most versatile and well read given its popularity.
3. Why yes, this sounds awesome!
4. Separating out logic (MVC-like approach I guess?) sounds good to me. Would make it easier for non devs to change the looks without having to worry too much about messing up the code.

[swalkinshaw]

OOP code has no inherent issues integrating with non OOP code. WordPress is also becoming increasingly object-oriented. I doubt it will ever get all the way there, but there's definitely been a shift. Lots of themes and plugins have been object-oriented for a while as well.

Here's an example of recent OOP improvements in WP core: http://scribu.net/wordpress/the-magic-of-wp_user.html

[gingerlime]

Just to clarify, I'm not against OO code in general or with Wordpress, but I feel it is far less important than, say, much sexier things like simply making sure you don't use echo (or use functions that echo stuff out) in your functions. If you do that, and lots of stuff in WP does, then it's nearly impossible to extend this code, OO or not. You're pretty much stuck with output buffering or overwriting it. In which case, it's easier to hack the code directly and then deal with merges upstream.

@swalkinshaw - can you suggest how to resolve, say, some of the issues with W3TC mentioned on #112 using OO techniques? W3TC is an object-oriented plugin as far as I'm aware. I'm not just asking to prove a point. I'm genuinely interested to learn how this can be used more effectively within wordpress.

As for child-themes, the whole concept is wrong in my opinion. If you're a novice user, chances are you won't even know what a child-theme is or how to use it anyway. If you're slightly more experienced, you'd be better off using diff/merge since you would hack it more than a little anyway. For a theme developer, and particularly if trying to make some conceptual leaps, child-theme support seems more like a burden than a feature that gives you any real value.

[swalkinshaw]

@gingerlime I took a quick look at modifying W3TC. Here's what you could do:

1. Download W3TC plugin but don't activate it
2. Create your own W3TC plugin
3. load/require W3TC just like it does in w3-total-cache.php
4. Create a new class that extends W3_Plugin_TotalCache (found in lib/W3/Plugin/TotalCache.php)
5. Define the function ob_callback() that's the same as W3TC.
6. Modify your new ob_callback to remove that string from the $buffer.
7. Or you could just do $buffer = parent::ob_callback() and then strip out that specific string to avoid duplicating the entire function.

There's a few caveats to this:

1. I haven't actually tried this
2. I'm not even that familiar with PHP OOP or the internals of the W3TC plugin

However, this is how classes work in general. Extend, then overwrite the function. Yeah, it's a lot harder than just modifying the W3TC source code. But the benefit is the plugin stays intact as is, and you can easily follow this pattern to extend/modify other functionality.

It's almost like a child plugin! Although if you don't like child themes I'm not sure you'll like this solution either.

[gingerlime]

Thanks @swalkinshaw. Much appreciated. I'd like to give it a try some time. I wonder however if you can extend a plugin (W3TC in this case) after it's already installed. Otherwise, the first item (installing without activating) makes such use-case very limited and then it's much easier and more practical to patch the code and merge in any updates. Also, what happens when the core plugin gets updated by its author? There's still a risk that the upstream changes will break things. The plugin author does not care or even know about other code that depends on it.

In any case, I don't want to drag this discussion into how to adapt other plugins, or into the merits of OOP since this is not what the thread was about. As I said, I'm not opposed to using OOP in general or for Roots. I still have my doubts whether it's that important or useful (particularly compared to other aspects you mentioned, which in my view make a much bigger impact)

[leoj3n]

My 2 cents is that Roots needs to be as bare bones as possible. I think the theme needs to stick to the core value of cleaning up after WP and making it unrecognizable as a WP website to the end user.

Bare Bones:
For instance, having the google analytics tracking code built into the theme's options page as I believe it is now goes too far imho. I suggest leaving anything that can be done by a plugin up to a plugin. Don't bog Roots down with built-in sliders, analytics, etc.

This even goes back to my suggestion that the theme options page itself be managed by the theme-options-plugin. Roots should focus on the core value mentioned above. That's how I really see it as being useful to me at least. Too often I am stripping sub-par functionality out of themes just to replace that functionality with a high quality plugin. The theme options plugin is flawless in my opinion. It has been through the wringer and has a lot of supporters on GitHub. Why re-invent the wheel when they've done it through that plugin already. This would give the people working on Roots time to focus on what really matters--the core value mentioned above.

As far as OOP-ing the code, of course that's a no-brainer.

Other thoughts:
Some serious thought needs to be put into how child themes modify the parent. As I've illustrated in a pull request already, Roots currently lacks some essential hooks. I continue to urge you to check out StartBox (by Brian Richards) as I think he did a great job of naming and implementing hooks in his theme. Unfortunately I feel it's bogged down by extra features which are already accomplished better by plugins. The selling point of his theme used to be that it had a theme options page that could be extended by the child theme. This was revolutionary at the time but soon after the theme-options-plugin came on the scene and did a way better job of it (because it's all that plugin was concerned with unlike Brian's theme where he was obviously having to divide development time between many different objectives as is the case when making such a robust, eventually bloated, theme).

All I am saying is I have been around long enough to see how these things turn out. Other open source projects have already done the hard thinking and continue to be updated -- more so than Roots theme options would be if you tried tackling it yourself. I think it's best to modularize it and really focus on doing some specific things really really well.

[retlehs]

chiming in real quick to say that i originally wanted to use the options framework (see #5) but it just came down to that i didn't want people to have to install an additional plugin just to use the theme options.

and on google analytics.. my biggest goal with roots is to have 100% of h5bp in wordpress (including the build script one day). that means the google analytics snippet from h5bp is included.. i've yet to see a plugin that implements GA using the same h5bp method.

on hooks.. should we be adding more or just figuring out a way to not have to use them at all?

[leoj3n]

On GA: OK it's more acceptable if it's part of h5bp (but I still stick to my point that you shouldn't start introducing button shortcodes, sliders, robust SEO options, etc).

On theme options: you can bundle the plugin with the theme. Or you can check if the plugin is installed and use it if so, else falling back on a built-in TO page.

I don't see the big problem with hooks. I really like hooks, and filters. It's one thing that makes WP stand out to me. Pretty much every parent theme ever has hooks and filters. Documenting them and giving examples of how to use them makes for quick and easy child theme development.

[swalkinshaw]

@gingerlime I actually mostly agree with you. If I was personally managing a WordPress site, I'd just modify W3TC or Roots source and manually merge in wanted updates. Most people in the WordPress community don't seem to share that opinion though.

[aboutaaron]

The Chicago Tribune News Apps Team turned WordPress into an MVC framework a la Django.

Not saying this is where Roots should go, but it's an interesting look at how WP devs are trying to extend WP's functionality and modular use.

https://github.com/newsapps/wordpress-mtv

[swalkinshaw]

@aboutaaron that's really interesting. Some of their choices are a bit strange to me but overall it's a cool project.

[aanomm]

I just wanted to add a vote for ensuring that Roots DOES support WordPress Child themes. Although Child Themes are not perfect, they are powerful and very efficient.

You can have a single copy of Roots in a WordPress MultiSite installation that powers 100 or 1000 websites that are all child themes of Roots. And when Roots rolls out a new version, you only update the single Roots folder (parent theme) and all 100 or 1000 website are running the newest version of Roots..

However, updating the already-built sites becomes virtually impossible with @swalkinshaw's proposal.

[swalkinshaw]

@TheLoneCuber It wouldn't really change the upgrade path at all actually. You'd still have the base Roots theme and then a bunch of "child" themes that extend it. The only difference is the technical details of how it extends it.

[benklocek]

I'll +1 for WP standard child theme implementation. I'm also a fan of hooks and filters, but agree that it does tend to make the parent theme less boilerplate/delete-key friendly.

I would be interested in @swalkinshaw's thoughts on how extending a child theme with OOP would be preferable to the hooks and filters system. It's fine to extend the Roots class, but I'd rather not have to rewrite a whole function when a simple filter or hook into a certain part of it would be sufficient.

[leoj3n]

There's a reason WordPress uses hooks/filters extensively internally. The best solution will most likely involve using extendable/replaceable classes in combination with hooks/filters, depending on what you're trying to do.

[iagdotme]

Great ideas!

@swalkinshaw could you elaborate your thoughts on your initial points (3) and (4)? There is a discussion on the Roots mailing list about how best to keep the core Roots files up to date when using it as a base theme. Yes, we could use child themes, but my feeling is that Roots is a base or starter theme. I've not delved much into the delights of child themes yet, so perhaps I am missing something, but I use Roots primarily as a starter theme and then develop from that. The problem is, after developing a dozen or so sites based on Roots is that they'll all potentially be using different versions of Roots and so be difficult to manage and keep up to date with latest developments. If there is a way to make Roots more "upgradable" by separating out the "Roots" bits from the content then I'd be definitely in favour!

[swalkinshaw]

@baritoneuk

3. Look at any Roots template besides the loops. They all repeat the full page structure including header/footer. If you want to change the markup of your theme, you're going to have to edit a lot of files. This is the way virtually all WordPress themes do it, but it's wrong and not DRY at all. You should only have to edit it in one place.

4. Moving the template files is just about better organization. Keeping them in a separate folder rather than mixing them with other files in the theme root. In terms of separating out presentation logic, check out https://github.com/gingerlime/ginger-roots for an example of this. He's using mustache templates which are logic-less.

[swalkinshaw]

I've created an experimental theme that contains a lot of the ideas I talked about previously in this thread. Check it out here: https://github.com/swalkinshaw/radicle

I won't say too much about it in here because the README explains most of it. And I'm not going to say this theme is great or how everyone should be doing things. Although it will actually be in production soon as a mobile theme for a high traffic site using WPMU. Our needs were pretty simple so in this case it works. As of right now it's completely missing usual things like hooks/filters and child theme support.

@gingerlime you should take a look at this and give me your thoughts.

[gingerlime]

Nice work @swalkinshaw. I just had a glance at (parts of) the code, and it looks very clean and nicely organized. That's already a major step forward in my opinion. I can't say I'm a huge fan of object-orient'ing wordpress, but your work shows a great deal of elegance, which must have something to do with using OO. I've never used twig before, but am well familiar with django (native) templates and jinja, and whilst they are nice template languages, logic very easily creeps in with those. Looks like replacing twig with another template engine is possible, or maybe even easy, so I wonder how/if Mustache can fit in somehow...

I wish I had more time to play with this stuff, but currently mostly using rails/django and only occasionally get to touch wordpress these days.

In any case, it looks like a very nice piece of work. Great to see those kind of initiative floating around, shaking the foundation of wordpress and making it better. Keep it up!

[swalkinshaw]

It shouldn't be too difficult to switch to another templating language. I've creating an API for view rendering so switching to something else should mostly be straightforward. Using something like Mustache just didn't really fit for this project, and would have taken longer.

I'm actually in the same boat as you, basically doing Rails coding full time. Which is a good thing, because without that experience I wouldn't have really known how to create this theme.

[retlehs]

closing after implementing a theme wrapper: db41099