1. Christopher Simmons

    Our solution for now in the publishing and B2B areas (using WP since 2004/5), has been to build our own ‘framework’ to work more like classic SHTML with SSI, which was our old preferred method – keeping the core WP functions and hooks for plugins, but adding ability to drop in snippets ‘anywhere’ from external file, simple stuff like dropping in ‘current date’ or ‘last date updated’ in middle of paragraph. We chose to hook into using Bootstrap, then remove un-used code to trim to fit. We also chose NOT to use the new box model for WP, and roll our own code using Bootstrap where pages can be built as raw HTML (ala SHTML practice). But, with templates and includes — like, why not have static drop down menu for B2B site vs bunch of queries for every page every load ? Why not have simple “duplicate page” function like us old skoolers are used to. I realize I’m a web dinosaur, but we found mixing the old methods with WP core, and turning off what we don’t want to work more like CMS vs blogger platform, has always been best course. I won’t use any more theme builders, custom themes, ‘the customizer’ and all that, which will cause my sites to become a wreck in a few years. And screw Jquery and the horse it rode in on. :-) (sorry, bit of a rant … ) My point is, WP should have ‘use containers’ where you can select a way to work from multiple theologies – default, parent, stacks, raw, which don’t blow up in 3 years killing an active site.


  2. WPezDeveloper

    “WordPress needs a solid front-end design framework.”

    In theory, maybe. The reality is, Gutenberg (for example) is so fraught with inconsistencies, quirks and whatnots, that the idea of the same process (and similar team members?) doing the same for the front-end – for 30%+ of the internet?!?!? – is an extremely difficult elephant to get your head wrapped around.

    Perhaps it would be better for WP to adopt an already proven and established framework and design system? What’s better about going this route is it doesn’t have to happen top-down. Theme studios such as yourself can form a “pact” and then pick your defacto standard. Others will follow; as following is what most of the WP community does best ;)


  3. David McCan

    I recalled that the 2012 theme was often used as a starter theme and was hopeful that 2020 would play the same role. It seems though that 2020 was stripped down from its inspiration. There were probably good reasons for that but …

    @Justin Tadlock, why not have a core theme that includes a fair number of Customizer options, hooks, and “canvas” templates for landing pages? People could then create child themes or use it as a base for a fork.

    An optional standard base seems like it makes sense.


  4. Robert DeVore

    The underscores theme comes to mind. It’s already used as a base for so many themes out there, why not upgrade it into a master theme?

    I, for one would welcome it and think from a business standpoint, it’s the smart move for Automattic.

    The removal of friction that users experience when a theme/plugins don’t play right because of design decisions would be a huge benefit.


  5. Philip Arthur Moore

    Having worked on _s since its birth, I think “starter themes” or “frameworks” or whatever you want to call them aren’t a great idea unless you’re prepared to maintain them, nurture active discussions around them, and also keep them updated.

    I also do not believe that a one-size-fits-all parent theme will ever exist because themers push boundaries and are incredible designers – new becomes old quickly. As far as a component library on the front end goes, sure, but a ton of those exist already.

    Best practices and standards are a moving goal post and every year default themes push those forward. Disparity between all default themes, a “master” theme, other starter themes on the market, and innovators who like to push boundaries will continue to happen to a degree.

    I also believe that headless approaches to site building, where people can do whatever they want in something like Gatsby, on their own terms, while pulling in content from WordPress will become more popular. I’ve certainly found myself enjoying building headless themes and sites lately with a WordPress-as-content only approach.

    If given the choice between developing with a master WordPress theme (or set of components that a group of devs will create) or spinning my own stack up that I’m comfortable with, I’d probably go with the latter.

    I do think that theme developers have been a ridiculously undervalued asset in the WordPress ecosystem since long before premium themes, frameworks, starter themes, and Gutenberg existed. It wouldn’t shock me if they continue to be pushed aside for the betterment of non-theme Core, even if that means ending up with CSS classes that read like college essays.


    • William Patton

      As much as I hate to be the person that does this I’m just going to +1 this comment.

      It is not quite exactly in line with my own thoughts (not certain I’d spin up an alternative stack all the time nor that the future will be CSS only) but it is very close.


  6. Titus

    I am an WordPress user absolutely no design or programming knowledge. What would the best option be in the long term. I have been using one theme from one designer for seven or eight years. The theme is being retired with no up dates for the last 4 years. I have 5 sites and around 1500 Post with videos in the featured embed code custom field created by the theme. I now have to move the video shortcode or embed code out of each post and put it on the top of the post. It would have been alot easier if I could have just changed the theme without going through the long process.


  7. Ari Stathopoulos

    I think it’s an interesting idea, and one that most theme-developers would welcome with open arms.
    Anyone who has ever built more than 1-2 themes knows that at their core, all themes are the same. They all have the same components. It’s just a matter of how you tie these components together and how you style them. Currently these components don’t exist, we have to create them again and again and again – each time just copy-pasting code we’ve already written – and tweaking details when needed. Every time we build a theme there’s a little voice in our head that says “I’ll just call this div `.blog-layout-whatever-because-why-not`”.
    A consistent unopinionated base that would set the foundation for everything else would be a lifesaver both for themes and plugins.
    Frameworks are good, but I always reach a point where I start stripping stuff out of them. They try to accommodate all cases and therefore by necessity include things that most people will never use. If on the other hand WP-Core had a consistent method for naming things, then everyone could just use those and there would be no conflicts between themes and plugins – provided of course they both respect their role (themes take care of appearance, plugins functionality).


  8. Steven Gliebe

    It’d be a dream to design themes mainly with CSS. We could go back to the days when theme shops promised two new releases monthly. ;)


  9. Jon Brown

    “WordPress needs a solid front-end design framework.” heck yes…

    Midway through Gutenberg development I asked “What’s the wrapper model for blocks”? Where are the standardized hooks like we had for widgets? Something like theme hook alliance in core.

    What we have now is yet another freaking _mess_ because no one seemed to think ahead that themes might benefit from a standardized wrapper for eery block such that themes (and parent blocks) could predictably control layout.

    The mythical future where themes are “skins” is predicated on the idea that blocks are classed predictably and consistently.

    Heck there are now a dozen plugins just to create “Gutenberg buttons”. Each starting from scratch, none of them even attempting to extend the core button block. Every single one using completely different HTML. As a theme developer that means I _can’t_ insure that the margin around each is consistent, I can’t insure that each inherits the right font… It’s a mess where users are left confused and ask theme developers “you said this theme was Gutenberg compatible but it’s not because these Gutenberg Blocks from plugin X don’t look like the rest of the theme”.


    • Jon Brown

      If WordPress really wants to be “the operating system for the web”, it better spend a lot more time figuring out being _internally_ predictable and interoperable (then maybe work on the dream of being _externally) so)


  10. Mike Schinkel

    This is an interesting post.

    It touches on aspects of WordPress theming I have contemplated over the past decade. But my thoughts differ from Justin’s because — unlike Justin — I am not a designer nor am I a themer.

    But as I was writing my comment I realized I had so much to say on the topic that I felt it was best to repurpose as a blog post instead.

    So — as a teaser — I’ll just include the link to the post, and then the first half of the pull quote:

    Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and instead…(read more)


  11. David Vongries

    Having a blueprint parent theme and/or a standardized frontend framework would be a good idea. At least in theory.

    The problem I believe is where we are at right now.

    From a theme-developing standpoint – now with Gutenberg – we’re in this weird state where (at least some) blocks don’t provide the necessary customization options so the theme must apply its own default styling for the blocks to not feel out of place.

    Integrating with G is not easy either with the CSS class inconsistencies, etc.

    It’s this back and forth that every. single. theme. would have to go through because there’s no standard.

    In general, Guternberg is not an isolated design system like page builders are and kind of blends in with the theme.

    If we’d be able to style all the aspects of the block in Gutenberg – great.
    If Gutenberg blocks came with no styling at all and the theme would take care of things – great (well, not great and unrealistic – but in theory it would at least make sense).

    Currently, we’re right inbetween which leads to a lot of inconsitencies.


  12. Nollind Whachell

    Squarespace worked this way up until the launch of Version 6 in 2012. A standardized XHTML template (for all templates) really made it easy to stylize any theme (called a “Template”) and its associated custom “Styles” (as children of it).

    Squarespace “Style Your Site” Help Guide (V5) (includes video)
    Squarespace Code Library (and XHTML Site Structure Diagram)

    This really made it easy for the end user to stylize their site. The only thing they were missing was the full site manipulation of blocks for layout positioning which is where WordPress is going now.

    With Squarespace Version 6, a lot of this template / style capability and flexibility was lost (including the ability to easily export and share a template / style as an XML file). While a designer could still customize their site to a certain degree, the tools to do so were severely limited to “make things easier”. Therefore doing any major customizations now on Squarespace requires you to be a full blown developer. It’s one of the reasons why I left the platform and love seeing where WordPress is headed now.


  13. Joseph Dickson

    Customizing WordPress takes a lot of time and determination. If the future means we could build unique sites by only editing CSS or some other simple markup. I’m all in.


  14. Sallie Goetsch (rhymes with 'sketch')

    This is a picayune correction, but I’m pretty sure the developers you’re talking about have gigaBIT internet connections. (I, alas, am not one of them.)


Comments are closed.

%d bloggers like this: