Library of common child theme partials

[benlk]

For WE-55, we're discussing where it would make sense to store a bunch of PHP, JS, LESS, CSS and associated documentation (.md) for common UI elements that aren't in Largo, but are used frequently in child themes.

Questions to answer:

• Where would these files be stored? In Largo or in a separate repo?
• How would the files be added to child themes?
• How would the files in the library be updated, and how would the storage and addition methods affect updating child themes?
• What other considerations should we take into account when proposing solutions?

This is open for general discussion, and all proposals are welcome.

[benlk]

One solution, which I'll call "Store it in Largo":

Files stored in Largo, with documentation and LESS files, but not included in Largo's LESS or in Largo's PHP include functions.

PHP files would be added to child themes by include()ing the files from get_template_directory(), according to documentation, or using add_action('hook', 'largo_default_newsletter_signup') as appropriate.

LESS files would be included similarly, though this would be a .. chain of ../../largo-dev/components/newsletter/less/newsletter.less.

Updating the files in Largo would therefore update the files in the child themes.

[benlk]

The "Submodule hell" option:

Create a parent repository, to track stable versions of components. Components are kept as separate repositories, logged in the parent repository as submodules. Child themes would include the components as submodules, and treat them normally as part of their own theme.

Updating the component's files in the component's repository would do nothing in the child themes. We'd need to update each child theme's submodule commits. The parent repository would have no function except to track the "master" versions of submodules, and to serve as an index that tracks which submodules are used in which themes.

[benlk]

A side effect of the "Store it in Largo" option is that we'd need to settle on common variable names for things such as colors, and use those across all child themes. @brandprimary, @graymed, @font-family-sans and so on.

[benlk]

A note on "Store it in Largo" and the Mailchimp signup form in the header:

In Largo:

• add an action in Largo in the header that is suited for placing the form

In the component folder:

• Readme.md that explains:
  • how to include this in a child theme
  • how to get the signup form from Mailchimp
  • how to paste that signup form in a text widget in the appropriate sidebar
• default styles for the code that Mailchimp provides by default, which includes a lot of divs and some elements that really should have the .visuallyhidden class but don't
• create the header signup form component functions file, which:
  • creates a sidebar named for this purpose
  • adds an action on the header that outputs the sidebar

[benlk]

I'm trying to think why there should be an action in the header instead of just a sidebar, and the conclusion I keep coming back to is:

• add actions
• add a theme-option-controlled sidebar in this area, probably just via a hooked function that checks if the theme option is enabled and then outputs the sidebar.

[benlk]

"Library of common theme partials" becomes more like "Constellation of widgets implementing plugins".