Child theme issue

[skipstorm]

I'm not a roots expert so I might be talking nonsense but please give me an honest opinion and if I'm right i'll post here a patch to solve or propose a solution for at least some of these issues.

• I think the editing of roots files should be discouraged and a basic child theme should be served with roots. Some parts of roots like the css in css/style.css should go in the child theme.
• Some hooks can be easily changed via remove_filter / add_filter as for excerpt_more some not. I guess pluggable functions are lighter than adding hooks and some should be added in critical points of roots code.

Some other theme framework get really slow due to too many hooks, this must be avoided.

• Someone pointed out roots must be activated before the child, i didn't check but my guess is this issue has something to do with theme options. If so I had a related problem. What if i don't want my customer to be able to mess with theme options? Or what if my child theme has his own admin panel?

One should be able to deactivate roots options panel and set his own defaults from a child theme. After all wich css framework to use is more of a developer choice rather than something you can change on the fly.

thanks for your help

[johnnypeck]

That's an interesting point and one that I would agree with for the most part. Considering how many watchers this repo has though, to remove the theme options in admin completely is not a responsible move. Perhaps it could be set up in such a way that a child theme can set a flag to disable the admin options panel, set the desired options in code and trigger the functionality that occurs during activation if they want that to happen.

I've only been using this theme to build a child theme since yesterday but I think it has a ton of potential, keeping it lean is very important though. On the lean note, my next pull request will be adding another option to the admin! It's a necessary change though regarding full width issues and sticks with the current process of how that's done.

Perhaps setting up a registry function to add css frameworks and grids would be better but that would get complicated to do it right given the way themes/child themes work at the moment in WP, at least as far as I know. Honestly, I think the entire theme system in WP needs a serious overhaul.

[johnnypeck]

Another thing regarding child themes you might be interested in, not sure is your aware but if you update to the latest version my patch yesterday added the ability to remove the widgets from within your child theme. Register your removal function with 'widgets_init' on a higher priority and the widgets are done for.

[skipstorm]

I'd like to have some opinions on this possible solution about options

the options functions will be grouped inside a singleton class, something like

class RootsOptions {
        protected static $instance;
        protected static $options;

        /* getters and setters */

        public function setDefaults(){}
        public function setOptions(){}

        public function getDefaults(){}
        public function getOptions(){}

        public function getOption($key){}

        public static function getInstance() {
            if ( !isset(self::$instance) ) {
                self::$instance = new RootsOptions();
            }
            return self::$instance;
        }
}

the reason for this is changing all

global $roots_options; $roots_css_framework = $roots_options['css_framework'];

into

$roots_css_framework = RootsOptions::getInstance()->getOption('css_framework');

it will be easy to set defaults from a child theme with RootsOptions::getInstance()->setDefaults(array());

load custom options set options from a different panel use different settings in the same site

i have some doubts on how this last part could be done

i'd like to be able to change or extend this class so that one could add/remove options or alter the options panel

some possible solutions could be:

• making all roos OO and using a variable for the options class instance, a class extending rootsOptions could take its place
• using a filter or a pluggable function to be able to include a different class with the same name (gross)

[swalkinshaw]

Roots was created without child themes in mind so it's no surprise that there isn't great support for it. I like some of your ideas @skipstorm. At a minimum Roots could definitely be architected in a more flexible manner which going OO may help with.

[skipstorm]

I do like the simplicity of roots and the way it gathers good concepts reducing maintainance cost but looks poor on the php design side. I'm wandering if there's a better and less explored by other fws approach.

[johnnypeck]

I like your ideas @skipstorm and I think moving in the direction of making Roots a baseline and encouraging it's use as a parent theme rather than altering it directly is extremely important. It's simply not maintainable to expect users to make use of it any other way and worse, currently it encourages bad practices. It has so much potential and that potential should be nurtured. I could go on for days but I digress.

I have my own qualms with static methods but I think your on the right track. Singletons have an awkward smell to me often enough but in this case it's likely the closest fit. I have to dial back my preferences when it comes to WordPress and honestly I can't wait for projects with so much heft to take the "move forward or be left behind" approach. If the hosts are the problem, let their customers deal the blow by moving to better hosts!

Anyhow, regarding setting options we have some decisions to make.

How do we recognize the situations to use different options on the same site? Does default mean the default that ships with Roots? Should the options array be something like ['roots'][{option_group}]['option']?

We could allow, for example,

$roots_css_framework = RootsOptions::getInstance()->getOption('default', 'css_framework');

and

$roots_css_framework = RootsOptions::getInstance()->setOption('my_option_group', 'css_framework');

and

$roots_css_framework = RootsOptions::getInstance()->getOptions('default');

and

$roots_css_framework = RootsOptions::getInstance()->setOptions('my_option_group', array('css_framework' => 'some_framework', ));

With such flexibility we need to filter diligently of course. It might be possible to register 'types' of content or context to realize the options that are used but I have no idea of a solution for that.

I do think it's important that we move toward documenting a "Best Practices" regarding the use of Roots and a coding standard for further development going forward.

Anyhow, it's late and sleep is way passed due.

[leoj3n]

I would love to see https://github.com/devinsays/options-framework-plugin used for the options settings. I use it all the time in child themes and it's all that more convenient when it's already installed in the parent theme (of course it can always be implemented as a standalone plugin).

When parent themes don't use it I usually just settle with having two options pages -- one for the parent theme's default settings and one for the child theme's custom settings (implemented using the options-framework-plugin).

Of the parent theme's I've used I know https://github.com/simplethemes/skeleton_wp and https://github.com/devinsays/foghorn use the options-framework-plugin. Skeleton includes the entire plugin in a sub directory of the parent theme while Foghorn does this: https://github.com/devinsays/foghorn/blob/master/extensions/options-functions.php

All the heavy lifting has been done and it's very well thought out and super easy to create new and extend existing options pages with this options-framework-plugin. Obviously for someone like me who's using many different parent themes it's nice to have a unified options pages syntax.

[skipstorm]

i think roots started well but is moving towards a bad direction some options might be good for unexperienced users but take flexibility off the whole

i've been drafting an OO modular roots sidekick and stopped when i realized a full integration will need major changes in roots very core

@johnnypeck if you're intrested i could give you more info

[retlehs]

@skipstorm can you please elaborate on 'some options might be good for unexperienced users but take flexibility off the whole'

[swalkinshaw]

@skipstorm it would be great to see your OO changes to Roots. Maybe you could put up a fork of it?

The biggest thing lacking in Roots is the general architecture of the theme and lack of OO/modularity. Considering what it started as it was just never a priority.

[retlehs]

see #230