Uncategorized WordPress

The Twenty Fifteen Theme

Since the decision was made to update the WordPress default theme every year, I’ve contributed to all five new WordPress default themes. My contributions have varied from inline documentation, to accessibility testing, to refactoring PHP to cleaning up some JavaScript (and many things in between). Since Twenty Fourteen had it’s spectacular debut, the talk has already begun on the next one.

Konstantin Obenland proposed the idea that Twenty Fifteen should be a simple theme. Take _s and just add CSS. While that is a noble idea, I think we could also challenge ourselves to rethink themes completely for Twenty Fifteen. Since Twenty Fourteen was released early (Before we even hit Twenty Fourteen!), we have plenty of time to be experimental.

I would like to propose that Twenty Fifteen be a single page app largely done in JavaScript. This will require the addition of the Rest API the WP API team is building, but would enable us to demonstrate what is possible for a theme with almost no PHP. Imagine a theme where the only PHP is functions.php and index.php.

Maybe this is just a crazy idea. I don’t know. But I do know that we as a community can challenge ourselves to build something amazing.

9 replies on “The Twenty Fifteen Theme”

Nice idea Aaron. But I thought the purpose of the DEFAULT theme was so that the majority of the WordPress community – who are not developers, but more along the lines of users – could have a nice theme they could potentially use as a blog OR simple site. And heck maybe those who just want to peak under the hood – which is hard enough with PHP and CSS. While things can change alot in a year (or more in this case) i’m not sure the majority will want what you are describing “out of the box”. They could go back and use the 2012 or 2013 themes I guess, but with 2014 being a “magazine theme” (which is already causing some minor grumbling) I haven’t decided how i feel about what you’re described.

THAT being said, I love the concept you are talking about. I’m all for it, since not as a default theme IMO ( at least at this time).

I think the default theme serves a couple of purposes. It is a theme for the community. Not necessarily the majority of the community, but one that a large percent of the community can be proud to use. For example, I don’t think the majority of users need a magazine theme like Twenty Fourteen. Each theme though has tended to try and serve a niche that wasn’t being met by a current default theme.

The other purpose is to demonstrate what a theme can do. It serves as a learning tool for theme developers. It’s why they are so well commented and aim to always incorporate best practices.

Of course thoughts and feeling on default themes vary depending on what you think a default theme should be.

I see your point as valid, but regardless of it’s purpose a theme has been and always should be something easy to customize and build off of. Someone who’s installing WordPress for the first time should be able to customize and expand on it to a certain degree without having developer creds. All of this has been possible up to and include in the 2014 theme. There’s a balance here between showing off what WordPress can do (and showing best practices) and making this something the majority can still have the option to use. I look forward to further debate as other’s throw their $0.02 in.

I think you’re underestimating how much developer creds are needed right now to customize and expand a theme and also overestimating the learning curve of JavaScript. In a JS based theme, you would still be able to make CSS based changes in exactly the same way as you are right now.

Even if this does get kiboshed as too outlandish for a core theme, I’d *love* to see it done anyway as a proof of concept for the new API functionality.

I’m saying this, in part, because I like Konstantin’s idea of skinning _s 😉

Less on the topic of Twenty Fifteen and more on the topic of single-page JavaScript-driven websites…

My biggest gripe with single-page JavaScript-web-appy things is they push all of the work to the browser. Why don’t you just let the server serve up HTML and use JavaScript to prefetch it, pull out the relevant chunk that you want, and then insert it into the DOM? The cool kids are calling this PJAX

This makes so much more sense to me for content focused sites like a blog or a news site or pretty much most of the web. It’s less taxing than having JavaScript loop over the data to spit out HTML and everything still works if you disable JavaScript/JavaScript breaks for whatever reason/Google.

So why is everyone so gung ho on things like Backbone/Angular/Ember?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.