Welcome to the Post Status Draft podcast, which you can find on iTunes and via RSS for your favorite podcatcher. Brian and his co-host, Joe Hoyle, a co-founder and the CTO of Human Made, discuss some of today’s hottest, current WordPress news.
In this episode of Draft, Joe and Brian discuss a popular site’s redesign, and how the developers viewed WordPress’s shortcomings. They also talk about WordPress’s chops generally for complex sites and applications.
Topics:
An outside look at WordPress
- WordPress shortcomings, from developers that prefer other software
- Redesigning The Toast
- Timber, Twig templating for WordPress
- WordPress MTV
- Advanced Custom Fields
- CMB2
Partway through this podcast, I could hear both of you roll your eyes when referring to Advanced Custom Fields usage. Any chance you guys could elaborate and/or point us to more information on why you feel this way? ACF is something that I use on every site I build and I’d love to hear more about your thoughts/opinions on this topic. 🙂 Thanks!
I think their point was that ACF stuffs everything in the post meta table and that information might be better served in a more organized way in terms of being in the database and it’s ability to be queried.
I’d like to follow up on Twig templating, and Timber’s extensions/adapters for WordPress.
We’ve been using Twig for a large multi-site (not Multisite™) client project at XWP. Having a templating language was a key requirement for the client. One big reason was that they needed to be able to empower their frontend developers to be able make template changes. Twig facilitates this not only because straight PHP logic is not allowed (both good architecturally for separation-of-concerns, but also security-wise so they can’t accidentally do something bad) but also with
autoescapethey can output variables safely by default without having to do theecho esc_html(…)dance over and over again. This can greatly reduce the amount of code review needed for frontend developer work since Twig will force them to do the right thing (usually). Additionally, the sites we’re developing are running on WordPress.com VIP and so it is especially important that frontend developers who are unaware of all the WordPress best practices and PHP security considerations to be able to hack on templates without their code getting rejected during review, and thus delay a deployment.Also, Twig is not just some syntactic sugar that can translate 1-to-1 into PHP equivalents. You can’t do the same in WordPress templates with
get_template_part()as you can do in Twig with its model of template embedding and extending. The way I think of it, WordPress templates require you to do a top-down template include pattern, whereas Twig allows you to build templates from the bottom-up.Since Twig is not just some syntactic sugar but a full templating engine, the concern raised about coming up against a roadblock when wanting to do something the Twig language doesn’t support isn’t really valid. Twig is extensible and new language features can be added. So if it isn’t in Twig it can be added in Timber, if not in Timber then you can add another extension. Not only can new functions and filters be added, but entirely new language constructs can be introduced in Twig as it allows you to hook into the compiler.
By the way, we’re not using Timber at all. Given the constraints of VIP, we can up with our own wrapper plugin called VIP Twig which facilitates using Twig in that environment (we have more work to do there, however). There is a lot of code in Timber, and so it’s too heavy for our purposes and for the purpose of getting reviewed for VIP; we have a client-internal plugin called “Twig Integration” that implements any custom functions or filters that the frontend developers need to use Twig in WordPress effectively.
One thing holds me back from fully getting excited about Twig is that it is a PHP-specific framework. There is a JS implementation, but it is far from complete. I’d really want to be able to render templates on the server as well as the client, but Twig isn’t really there yet.
Anyway, all of this to say that Twig can be a great choice for large projects that have complicated templates and many contributing frontend developers maintaining them.
I was already thinking about the lack of support themes usually have for editor styles when listening to the podcast but I came up with an automated way to produce them with no maintenance.
I think because you can use the editor without extra styling them often become optional but if you want to make a good experience for your user then it should actually be quite high on the list.
Anyway – here’s the approach I take: http://stomptheweb.co.uk/2015/10/automatically-generate-editor-styles-in-wordpress/