The Toast is a popular blog that recently underwent a redesign, and includes an in-depth series on the Responsive Web Design blog going over many of the implementation and process details. The series doesn’t speak particularly highly (or accurately) about WordPress.
I’ve read the post covering creating The Toast backend three times today, as well as the references to WordPress in the other posts in the series. It takes most of my energy not to just close it and forget it forever because I’m upset that the author is both misinformed and indignant toward the CMS — but there are some good lessons in the post.
There are many things to dislike about the writeup. Prepare yourself to be bombarded with lowercase Ps, references to Automattic as being behind WordPress, and notes about WordPress’s place — and how it should stay — as a blogging platform. But there is also plenty we can take away, to get a better idea for what frustrates developers accustomed to other systems (in this case, Drupal).
Theming
Templating stands out more than anything, and for at least somewhat good reason. Theming is not that complicated for anyone with some experience theming specifically for WordPress, but theming in WordPress vexes many developers that are accustomed to more separation between the PHP and the HTML. The authors of The Toast series constantly sing the praises of Timber (I also linked it here back in August), a Twig engine for WordPress theming by Upstatement.
Timber seems neat, and I totally see why some folks want to use it, especially shops that make websites across a number of CMSs. I think it would be good for the WordPress world, especially at a high level — core developers and developers with a lot of enterprise or big media experience — to discuss how WordPress theming could be improved for more complex applications, and for lowering the barrier to entry for developers that aren’t accustomed to the “WordPress way.”
It’s tempting to tell these folks to just use the REST API and do whatever they want. But in this scenario, we are asking them to fully abandon the WordPress front-end helpers and many things that are nice to have. There seems to be room for a middle ground, and I’d like to see some folks smarter than me help start that conversation.
I’d also like to see more resources for making quality WordPress themes and companion plugins to enable complex layouts and weaving the intersection of content architecture and templating.
Customizing the editing experience
Straight from the article, as this part I actually completely agree with:
Developers (and content strategists) have always had a contentious relationship with the friendly, point-and-click WYSIWYG editors that writers and editors love to use. They often bury writers in options, and make it easy to create tangled, ugly markup that breaks carefully designed templates.
We trimmed the fat from WordPressâs WYSIWYG editor, turning off options that The Toastâs writers and editors never used. We overrode WordPressâs default media embedding shortcodes, ensuring that images and videos dropped into articles would have cleaner markup that worked with our responsive layout. We added support for a number of âhouse stylesâ like pull quotes and editorsâ notes, and added CSS rules for them to more accurately reflect the siteâs styling in the WYSIWYG editor itselfâhelping The Toast team edit more confidently.
The result is a faster, simpler WYSIWYG editor whose options match the styling that The Toast actually needs.
I would love if customizing the editor (and for the whole post edit experience, not just TinyMCE itself) to be catered for a particular site’s style and content guidelines, and I would love it were significantly easier than it is today. I would also love if there was more emphasis on global settings, versus local ones (for instance, with the visibility and location of metaboxes).
Currently, moving metaboxes around, customizing/adding/removing editor buttons and other post inputs, and generally getting creative with the WordPress posting experience is too difficult.
…thereâs no good way to generate user input forms or to modify the operation of existing ones. That makes customizing the WordPress administration screens, especially the post editing form, an exercise in frustration.
And more importantly, making the experience better and well catered to a particular site owner is too often ignored by developers. We should be thinking a significant amount — on every project, and beyond meta data — about how the site owner will interact with the posting interface.
WordPress iteration is going the right direction
I’m more confident in WordPress’s ability to solve problems for all sorts of websites than I’ve ever been. I don’t highlight this post, and expand on the points I chose, because I think WordPress cannot be the right CMS for a project like The Toast. I actually think it’s an ideal CMS for such a project.
I love many of the changes to WordPress core in the last several years, and I think current projects (like the Fields API, the REST API, and more) will continue to give the CMS power that will be dynamite aligned with WordPress’s far superior (to the enterprise CMS competition, especially) user experience.
However, I think sometimes WordPress core can be hamstrung by the rule of the majority.
Under the Clean, Lean, and Mean section of WordPress’s core philosophies:
The core of WordPress will always provide a solid array of basic features. Itâs designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isnât X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think theyâll never use, then weâve blown it. If we stick to the 80% principle then this should never happen.
We are able to do this because we have a very capable theme and plugin system and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
I think this mindset and constant question of, “Will this benefit 80% of users?” is an excellent one; but perhaps sometimes we take it too literally. I think it’s possible for a feature to benefit 80% of users, even if they never ever know it exists.
A continued commitment to creating, and iterating on core level tools and APIs, to enable plugin and theme developers to do more powerful customizations, while jumping through fewer hoops, will help WordPress make that jump from powering 25% of the web to 50%. The road to 50% includes making it both simpler to use and more powerful to extend. That’s our challenge, and that’s something I think we can do.
