Title of Session: Improving maintenance of older default themes
Facilitator: @desrosj
Notetaker 1: @mikachan
Notetaker 2: @zoonini
From the session schedule:
Recently, there was a proposal to retire some old default themes. In response concerns were raised around how to do so. This discussion aims to explore how to maintain older default themes in more sustainable, streamlined methods.
Key Points
- Concerns raised around breaking the promise of supporting all default themes forever, just like we do for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
- Can we write an underlying framework to help support all themes?
- They’re all so different so may be difficult to build a framework to support all of them. It could be a lot of work.
- Older themes are an educational resource for theme developers. By maintaining older themes we are educating developers on how to update their own themes.
- The burden falls on the Core team to maintain themes. Original theme authors often get re-assigned or leave the project.
- How can we help spread the workload?
- Can we onboard more people to maintain themes?
- We have already tried having a default theme maintenance team. This has previously been a burden; 20xx themes are a burden to maintain.
- Why is there only a default theme lead for the last version of the year?
- Why not each release so updates can be bundled in each release?
- Used to have a Theme Wrangler for each release but this dropped off.
- More docs needed for default themes.
- Using the default theme to showcase new features makes it difficult for backwards compatibility.
- Does it have the same impact if we make all default themes blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes?
- Is there a world where we could make all default themes as light as possible?
- Default themes can be updated outside of the release cycle. Could we introduce a regular cycle of updating default themes? Theme cycle vs release cycle
- What about designing a method of testing older themes for each release?
Action Items/Next Steps:
- Explore moving default themes to GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ (with sync to SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/.)
- Pick the most critical issues from tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. to move over
- Consider having a Theme Wrangler for every release
- Explore creating style variations and patterns based on past default themes, as a way to blockify the older themes
- Explore setting up visual regression testing for default themes
- How do we improve the feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. from people building themes in GB?
- Improve default theme docs
Raw Notes
- Response to Jonathan’s post about dropping support for older default themes.
- There were concerns raised around breaking the promise of supporting all default themes forever, just like we do for Core.
- Can we write an underlying framework to help support all themes?
- They’re all so different so may be difficult to build a framework to support all of them. It could be a lot of work.
- People don’t often update their themes, so may be stuck on older themes because they still fit their purpose.
- 2010 was the first default theme for many years, was made to encourage developers to develop themes again.
- Older themes are an educational resource for theme developers. By maintaining older themes we are educating developers on how to update their own themes.
- The burden falls on the Core team to maintain themes. Original theme authors often get re-assigned or leave the project. It’s less glamorous than working on new themes.
- How can we help spread the workload?
- Can we onboard more people to maintain themes?
- We have already tried having a default theme maintenance team. This has previously been a burden; 20xx themes are a burden to maintain.
- Adding more people won’t solve it. The way we treat themes is wrong – scaling – amount of themes, complexity of themes.
- Many hosts still install old themes. We have to make themes more agile and easy to update & maintain.
- Many docs have links to older default themes and some hosting providers still install older themes by default.
- Think of how light we can make themes.
- Why is there only a default theme lead for the last version of the year?
- Why not each release so updates can be bundled in each release?
- Used to have a Theme Wrangler for each release but this dropped off.
- More docs needed for default themes.
- Using the default theme to showcase new features makes it difficult for backwards compatibility.
- Many GB regressions – e.g. class name changes, CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. conflicts between new & old features. Fear of backwards-compatible-breaking changes on existing sites.
- Do we load block-specific CSS from a certain version of WP? Which version? How should we test? Do we really need or want to do that? Do we decide that per theme?
- What about designing a method of testing older themes for each release?
- Does it have the same impact if we make all default themes block themes?
- Is there a world where we could make all default themes as light as possible?
- The quality of the block editor experience degrades with older themes. Doesn’t celebrate the new features of GB enough.
- How are all the default themes being used as parent themes? No clear data.
- Older default themes can’t be updated because they only work with the older versions of the editor.
- Default themes can be updated outside of the release cycle. Could we introduce a regular cycle of updating default themes? Theme cycle vs release cycle
- What do we mean by ‘support’?
- For pre-block editor themes, should there be pathways to upgrading to block versions of those themes. A way to recommend that in the dashboard.
- Might double the work. Why would do all this if the design is so dated visually?
- Could we have both block versions and classic versions of older themes? The base design for most default themes is simple, so should be easy to make into block themes.
- Do a trial run with one of the worst “offenders” – see if we can get feature parity. Can people migrate their site without the user having to redo too much, i.e CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. things?
- For each release, could we supply a block version of one older theme?
- Much rather have a fully working blockified theme than one that looks exactly the same as the old version.
- Could we have a separate Github repo for theme changes?
- It’s much easier for new contributors to work on themes compared to Core.
Potential solutions:
- Block theme replacements
- Block specific CSS
- Strip them down as far as possible
- Style variations and patterns based on older themes, with base theme as the editor (similar to how Create Block Theme works)
- We could build a tool that bundles the styles, patterns and templates so users can choose a theme that looks like an older default theme or mix and match the parts from multiple themes
- Convert old default themes to community themes
- Themes became as complex as plugins; themes previously were just styles
- Create a wizard to help people convert from classic to block
- Twitch streams/workshops to convert default themes to block themes
- Workshops on converting older default themes
- Decoupling repo and process from release cycle
- Improve default theme docs
- Pushing to a shared testing site / WP Playground
- Could we use the Style Book to test for regressions?
Child themes challenges:
- We don’t know how people are using default themes as parent themes
- Many generators still use older themes (should Underscores be retired?)
- Learning a new language becomes a barrier
- Additional CSS
- Customizer settings and frameworks
- Any theme that adds custom code
- Plugins relying on markup of default themes
- Non-GB editors
- Dependencies on certain code from extenders
- Backwards compatibility
- Contributor time
First steps to take to further explore:
- Explore moving default themes to Github (with sync to SVN)
- Pick the most critical issues from trac to move over
- Consider having a Theme Wrangler for every release
- Consider decoupling the theme release cycle from the Core release cycle
- Explore making default themes as light as possible
- Consider creating style variations and patterns based on past default themes, as a way to blockify older themes
- Explore setting up visual regression testing for default themes
- How do we improve the feedback loop from people building themes in GB?