Use Flynt as parent theme

[utoppo]

First of all thanks for the great starter theme! I really like the component-based approach with less bloat, less spaghetticode and better extendability + maintainability.

I would like to not use Flynt as boilerplate code, but as a parent theme. That way:

• Flynt parent theme could be easily updated without affecting the child theme's custom code
• Flynt "base components" could be loaded or not, without touching Flynt
• developing a custom theme with own components would involve less boilerplate code
• custom frontend pipeline for components could be implemented more easily

I forked the repository and started implementing the feature, based on the current next-branch.
https://github.com/utoppo/flynt/tree/nextFeatureEnableChildThemeUsage

I also created a POC child-theme:
https://github.com/utoppo/flynt-child

As Flynt makes heavy usage of get_template_directory and get_template_directory_urifunctions, which point to the parent theme, a lot of code had to be changed. Much of the component related stuff went from from ComponentManager-Class to an own Component-class. There still has some work to be done, but base functionality is working so far.

I would like to do a pull request, when finished. But before, I wanted to get some feedback on this… What do you think?

Thanks, and greetings to my old hometown!

[timohubois]

@utoppo thanks for the feedback and publishing your approach!

At the beginning as I started to use Flynt, I was thinking the same way, but after a while I figured out that a child theme is - for the projects - not needed.

Installing new dependencies or updating existing ones, means that components may need to get adjusted and the inc folder is a nice approach instead of implementing customizations directly inside functions.php which can grow fast. Using css inside a child theme and bundle it with the parent, is may also a little confusing.

Maybe my thinking is wrong and I would be happy to learn what’s in your opinion the biggest downfalls, when using Flynt as a boilerplate instead of a child theme? And where do you see other downfalls with the current approach or rather where do you the biggest advantages when using a child theme?

[utoppo]

@timohubois thank you very much for your quick and thoughtful reply!

I think there could be some advantages, with the child/parent theme-approach:

• Smaller codebase for Flynt-based themes
• It could be easier to get started with Flynt-based custom theme development
• Also, it could be easier to follow along Flynt's progress. No need to merge Flynt-repository-code into custom theme at specific point(s) in time. Instead:
  • Update parent theme to other/any/latest Flynt version (eg. git pull)
  • If necessary: adjust child theme to work with the now "up-to-date" Flynt
  • If that turns out that impracticable: Easily revert to former state of Flynt inside parent-theme-repository
• It could be easier to advance the Flynt-code itself while working on real-life-projects
• It could be done in an opt-in way, so nobody would be forced to take the child-theme route

Of course, this assumes that all of Flynt's features, including the frontend stuff, can be easily used from the child theme without much effort. And without adding too much unnecessary redundancy and complexity. But I would like to pursue this further…

What do you think?

[timohubois]

@utoppo nice to read from you! I will raise the issue at our next meeting and discuss it with the team.

[utoppo]

@timohubois Thank you very much, that sounds great!

I have now implemented the following: "Override templates" (eg. templates/404.twig) plus "override PHP-files" from inc-folder.
https://github.com/utoppo/flynt/tree/nextFeatureEnableChildThemeUsage
https://github.com/utoppo/flynt-child

Hopefully I will find some time next week to have a look at how to adapt/adjust the frontend build/dev-process from within the child theme. I think this could be the hardest part.

Best regards and have a nice weekend!

[pgnd]

@timohubois

have u had opportunity to discuss this with team?

Flynt's really quite nice. But lack of parent/child separation makes production adoption -- here, anyway -- sketchy.
imo, @utoppo 's suggestions/arguments for parent theme support are spot on , and work to date looks promising

with timber2's timber/starter-theme development slowed until timer2 release (probably?), a Flynt child, with 'premium' plugin support, gets really interesting!

[timohubois]

Firstly, thanks to all for the feedback and also the work you have invested!

Updating Flynt to a new version can be a bit tricky, even when using a child theme. We discussed the pros and cons inside the team and decided not to implement child theme support in the core for the time being.

This does not mean that this feature will never be implemented, but we would like to focus on the release of the new version first and not implement such a deep feature in it.

We are always happy to hear new ideas and we look forward to receiving them in the future 🚀

[utoppo]

Thanks @pgnd I appreciate your input and share your opinion,
and also, hey @timohubois,

thank you very much for your reply! I am very happy that you and the team took the time and resources to discuss the idea.

1. Why "resolved"?
I am a little disappointed that the idea was pushed aside, before I could find out if it could work at all. There seemed to be some positive resonance from the community towards the child-theme approach. Now that it is closed, the thread became almost invisible. I was still planning on "R&Ding" the frontend part and sharing my experiences here.

2. Could you elaborate a bit on the reasons?

"Updating Flynt to a new version can be a bit tricky, even when using a child theme"

• No one would be forced to update Flynt, even with a child-theme approach.
• The opt-in nature of the feature would make this argument irrelevant anyway.

I really would like to know a bit more. Is it really only that updating Flynt is tricky anyway? I would love to hear your thoughts on the bullet points from the list in #489 (reply in thread)

There seem to be frequent users of Flynt, who created heavily customized starters for themselves, based on some past Flynt boilerplate code. Now they have to ask themselves if they stick to their old custom theme, or update to the next Flynt version, loosing their custom code. Migrating could become easier for them with the child theme approach, where code probably could be moved over in small portions, without breaking Flynt itself.
See #458
@aaronmeder : Maybe you could share your thougths on that? thanks!

3. Implementation(s) by bleech only?

"…decided not to implement child theme support in the core for the time being."

Perhaps there is a misunderstanding here. Is the active contribution of code by the community desired by bleech? Then it would not necessarily be up to bleech to implement this feature. Or is it about gathering ideas, with feature-implementation done by bleech only?

I am happy to hear your answers, thank you very much in advance!

[timohubois]

@utoppo

1. Reopened the thread, closing it early was my fault!
2. There are many things that need to be clarified and defined so that a child theme can be used properly. One example is the compilation of the assets or what should happen where and how, if additional Composer or NPM packages are installed?
3. An active contribution to the code is always welcome, and we are always happy and open to new ideas, improvements or optimisations.

[utoppo]

@timohubois

Thank you very much for your quick reply. I really appreciate your open and straightforward communication.

1. Reopened the thread, closing it early was my fault!

Thanks a lot!

2. There are many things that need to be clarified and defined so that a child theme can be used properly. One example is the compilation of the assets or what should happen where and how, if additional Composer or NPM packages are installed?

I figured there were some very difficult things coming. Finding a solution to these points would be all the more satisfying. I intend to give it a try. If it doesn't work out, it will have been still an educational experiment for me.

3. An active contribution to the code is always welcome, and we are always happy and open to new ideas, improvements or optimisations.

Sounds great! Having ideas is nice, contributing code to a nice project is also nice ;)

[aaronmeder]

@utoppo regarding your question:

With the newest sites we have created we actually tried to give it a practical shot of getting rid of our boilerplate and sticking close to Flynt/Bleech's approaches of setting up things - which is quite smart quite often 😅 So it would resolve that need and we're going to see with a few more projects done how that strategy pays out.

Our own (Flynt based) starter theme would have replaced the whole CSS and modified bits and pieces in almost every component, so they weren't instantly compatible (though relatively quickly adaptable) which could not easily be solved by a parent/child setup.

I think one big plus of Flynt for us is how simple it keeps things. It doesn't to that much - and that is a very good think which makes it a stable base for building custom sites, imo. Not having parent/child means no dependencies / compatibility issues in that question. I totally understand the wish for child theme support (and also had it when we started using Flynt) but I actually can't remember coming into a situation were it would have been a huge benefit over the last three years.

[utoppo]

Hey @aaronmeder

thank you very much for your response and giving such valuable insights into experiences with Flynt.

With the newest sites we have created we actually tried to give it a practical shot of getting rid of our boilerplate and sticking close to Flynt/Bleech's approaches of setting up things - which is quite smart quite often 😅 So it would resolve that need and we're going to see with a few more projects done how that strategy pays out.

Did you use the current next branch for these projects? How would you follow updates on the branch?

If you have multiple projects, over the course of a few years, whose theme-code differs slightly due to specific project requirements, how do you keep track of maintenance and reuse of features and components across project boundaries?

Our own (Flynt based) starter theme would have replaced the whole CSS and modified bits and pieces in almost every component, so they weren't instantly compatible (though relatively quickly adaptable) which could not easily be solved by a parent/child setup.

Do you think you will end up with such a custom (Flynt next based) boilerplate theme again? But now based on the current next branch? If yes, would you try to stay in sync with changes on the Flynt-next branch?

I think one big plus of Flynt for us is how simple it keeps things. It doesn't to that much - and that is a very good think which makes it a stable base for building custom sites, imo.

Would you say because Flynt doesn't do that much that it's practical to not have a simple update path?

Not having parent/child means no dependencies / compatibility issues in that question. I totally understand the wish for child theme support (and also had it when we started using Flynt) but I actually can't remember coming into a situation were it would have been a huge benefit over the last three years.

It could be that I only have the wish because I just start with the theme and later realize that it was not necessary. Nevertheless, I would like to test whether the approach is possible and whether it might not bring some advantages.

Thank you very much again for your great response!

[pgnd]

@timohubois

thx for the reply.

a shame -- Flynt's otherwise just about the right fit here -- but certainly understood about project priorities; same here.

will hopefully revisit if/when this changes.

thx agn o/

[thomasnavarro]

Hi,

For a website factory project, I'm using a parent-child theme architecture. First of all, a big thanks to @utoppo for investigating the setup of a child theme with Flynt – it saved me a lot of time 👍.

What would be the best strategy for managing assets in the child theme?

• Duplicate the ViteJS configuration within the child theme and have two stylesheets to load on the frontend (parent.css and child.css)?
• Or, only load the child theme's stylesheet on the frontend, including the parent theme's styles in the child theme's main.scss (@import '../../parent-theme/assets/main.scss')?

Thanks for your responses!

[LuisSR]

Supporting child themes would imply a deep philosophy change to the theme itself, as Flynt is not meant to follow a linear updating path.

I hardly see any benefit from removing a component or modifying styles or templates in a child theme rather than the codebase itself. It might be easier to do minor updates with a parent/child architecture, but as soon as a site-breaking update, whether it's from Flynt itself or a dependency, is pushed upon, it won't make any difference at all. And it adds an unneeded layer of complexity: inheritance, override, etcetera.

I also guess that introducing such a change now that v2 has been released or ensuring backwards compatibility from now on would mean less resources for cutting-edge stuff in the future.

This is highly opinionated, of course. I love to read all your thoughts and needs.

@timohubois, may I ask how much of the styling codebase is inherited, as a gross estimation, for an average corporate site? I have detected small styling issues here and there, but I'm not sure if you intend the base styles to be relevant at all. Shall I open an issue? Maybe a separate discussion? None at all? Thanks!

[timohubois]

@LuisSR thanks for your Feedback, we are always happy to get other opinions.

In relation to the Base Style: Creating an issue or a PR with your adjustments would be perfect ✌️