The vast majority of developers will cringe a bit when they hear the recommendation against using curly brackets, {}, but I believe very strongly that when writing template files, in both themes and plugins, you should strictly avoid using brackets. The reason being that template files should be written for clarity, both for developers and non-developers.
Template files are designed so that the layout and presentation of data can be manipulated, without actually touching or modifying the way the data is “created”. For example, take a look at the index.php file from the Twenty Thirteen theme:
<?php /** * The main template file. * * This is the most generic template file in a WordPress theme and one of the * two required files for a theme (the other being style.css). * It is used to display a page when nothing more specific matches a query. * For example, it puts together the home page when no home.php file exists. * * Learn more: http://codex.wordpress.org/Template_Hierarchy * * @package WordPress * @subpackage Twenty_Thirteen * @since Twenty Thirteen 1.0 */ get_header(); ?> <div id="primary" class="content-area"> <div id="content" class="site-content" role="main"> <?php if ( have_posts() ) : ?> <?php /* The loop */ ?> <?php while ( have_posts() ) : the_post(); ?> <?php get_template_part( 'content', get_post_format() ); ?> <?php endwhile; ?> <?php twentythirteen_paging_nav(); ?> <?php else : ?> <?php get_template_part( 'content', 'none' ); ?> <?php endif; ?> </div><!-- #content --> </div><!-- #primary --> <?php get_sidebar(); ?> <?php get_footer(); ?> |
The template file clearly sets up the HTML structure of the main content section of the site. One of the most important points to notice about this template file is that it is semantically easy to understand. Let me translate for you:
GET HEADER HTML IF WE HAVE POSTS FOR EACH OF THE POSTS WE HAVE HTML END FOR EACH POST SECTION END THE IF WE HAVE POSTS SECTION HTML GET SIDEBAR GET FOOTER
A user that doesn’t understand a single bit of PHP, and perhaps just minimal HTML, can clearly read my translation above and understand what is happening.
Notice that the template file is using the following conditional / loop notation:
if( something ) : while( something ) : endwhile; else : endif;
While most developers really do not like this, it is very semantically clear. In English, it says:
IF CONDITION WHILE CONDITION END WHILE CONDITION END IF CONDITION
Developers usually prefer this method:
if( something ) {
while( something ) {
}
} else {
}
There are several reasons developers prefer working with this latter style of notation:
1. It’s shorter
When you write a lot of code, less can often be better. Bracket notation takes much less time to write than the alternative.
2. Syntax highlighting
Any decent code editor will automatically highlight opening and closing brackets when you select one, which makes it exceptionally easy to see where a conditional or loop starts and where it ends. This is especially useful when working with nested conditionals that go three, four, even five levels deep.
Very few code editors, however, support syntax highlighting for the longhand notation.
3. It’s more “standard”
The majority of coding standard guides will recommend the use of bracket notation, so for those of us that believe strongly in keeping with standards, this is really important. Note that the WordPress coding standards handbook instructs developers to use brackets.
There are all three very good reasons to use brackets, so why am I strongly advocating against the use of brackets in template files? It’s all about the users, not the developers.
Templates files should be built for users
A template file is built so that the layout and presentation of data can be controlled, with minimal interaction with the code that actually retrieves the data. Look back to the Twenty Thirteen index.php again. Do you see any direct calls to the database? Or any calls to functions like wp_list_pluck()? Or any PHP arrays? No, all you see is a set of very semantic functions for have_posts() and the_post(). There are others as well, such as get_template_part(), but they are not important for this discussion.
One of the single most important aspects of user-friendly template files is semantics. A file that is easy to understand in English (or whatever your language – simply spoken/written word) will always be easier to understand and modify.
Brackets are not semantic, not even remotely.
Where, except perhaps advanced math or science, have you seen brackets that mean “start something” and “end something”? I champion you to try and think of a single example that the daily user encounters frequently, and frequently enough to the point where comprehending the meaning doesn’t take any thought effort at all.
IF — this is semantically easy to understand.
ENDIF — this is semantically easy to understand.
IF { — this is . . . wait, what’s that squiggly thing?
} — this is . . . WTF is that curly thing doing just sitting there?!
There is nothing inherently semantic or easy to understand about brackets for non developers.
Remember what non-developers don’t know
Users often want to make minor tweaks to template files, sometimes in order to add an image, add some text, or a variety of other small modifications.
As developers we often take it for granted what makes sense to us. We (developers) have no problem following something like this:
$protocal = is_ssl() ? 'https://' : 'http://';
A non developer will look at this and maybe understand that there is some sort of conditional check going on, but a complete grasp of exactly how this works is usually beyond someone that is not a developer. That’s not to say non-developers don’t have the capacity to understand this, it simply means this sort of syntax has not been introduced to them.
A non developer, however, will have very little difficulty understanding the general concept of this:
if( is_ssl() ) : $protocal = 'https://'; else : $protocal = 'http://'; endif;
It is very clear what is going on. A user doesn’t even need to understand what a variable is, or how to set one up, to understand that there is a conditional check happening for SSL.
Now, let’s be clear: code like this (checks for the protocol and such) should never exist in a template file, if at all possible.
Developers can use both notations
While developers have no difficulty reading / writing both forms of notation (even if begrudgingly), non-developers on the other hand struggle immensely with bracket notation. Even if (the person) reading this is a non-developer and you have no problem understanding bracket notation, I assure you that you are in the minority. I love that you understand them, but very few non-developers have your level of understanding in this area.
Template files are the first place non-developers experience code
The very first experience a non-developer will have with code, whether it be HTML, CSS, PHP, Javascript, or any other, is usually a theme’s template file, at least in the realm of WordPress. As a user, they download a theme, install it, then decide they wish to modify a few parts of it. They will do this in a variety of ways:
- Start by just opening the template files and exploring (brave user!)
- Ask the theme developer how to do it and then open single.php (for example) upon instruction by the theme developer
- Open a template file after reading online a basic guide about how to tweak a theme
We can help users have a better experience with their first code experience by writing our template files in a semantic, easy to understand / follow (for users!) method.
[divider]
Aside from preferring brackets, one of the primary arguments I hear from developers on why brackets should be used in template files (at least for WordPress) is because the WordPress coding standards instruct us to use brackets. All of WordPress core is written with brackets, and all guides about how to follow the WordPress coding standards say to use brackets.
Well, that’s not entirely true. Not all of WordPress core uses brackets. All of the default theme actually avoid the use of brackets entirely inside of template files. Do you think this is an accident? Perhaps just an inconsistency that needs to be corrected? If you do, I’d strongly suggest you think about it a little longer.
The WordPress core team takes standards very seriously and decisions about formatting, notation, etc, are not taken lightly. It was a completely intentional and well thought out decision that resulted in the default theme template files using non-bracket notation for loops and conditionals.
I’m a developer and I approve of the use of endif, endwhile, etc, in template files.
Update
Ultimately disagreement about what is easier and better is completely fine. The important thing is that you (speaking generally) as a developer consider very seriously what is and what is not best for the users, both those that have development experience and those that do not.
Brackets with the correct commenting is the same as using endifs, except you still benefit from the features above.
New proposed commit removes endifs from the 2010, 2011, 2012, and 2013 themes. Will be turned into proper diff/patch and submitted to Trac tomorrow.
https://github.com/chriscct7/WordPress/commit/c3cbe6c0b93d08d9861112da32c2a1ff4a13ac57
Uh oh. Looks like we need some
word-wrap: break-word;up in here…Agreed. I’ll alert Pippin.
Trac ticket: http://core.trac.wordpress.org/ticket/24549
How did I know this was coming? 🙂
As sure as you are about it, this is a tough one for me to accept. For me, it doesn’t have anything to do with WordPress’ influence at all. It was about familiarity for me.
I mentioned to you on Twitter that I understood conditionals already from some basic CIS classes I took some years back. By the time I got to PHP, specifically in WordPress, I was knee-deep in front-end development. I was writing HTML and CSS heavily.
You mentioned that a non-developers first exposure to all of the code is usually in a template file. You have a lot more experience with users than I do so I’ll just assume you know some things I don’t know about how noobs interact with WP. But I would suspect CSS is their initial exposure. Most noobs I’ve seen don’t even understand the concept of content structure and are usually focused on link colors and the like.
With that being said, the CSS Selector { property: value } format is not too difficult to get used to. Though that’s not the exact same format as bracketed conditionals in PHP, I think it’s familiar to them. Again, though, this is based on my belief that they step into CSS before they do template files.
I was so deep into CSS when I finally started playing with PHP in WP templates that the brackets made more sense to me than the format you prefer.
Likewise, syntax is always the most intimidating thing when I see a language I don’t know how to write. For me, it’s not about the wording really. In most languages, it’s not hard to tell what’s being said. It’s the use of colons, semicolons, question marks, less than and greater than signs, etc. You referenced a ternary operator in your article. For me, what the ? and the : meant was beyond me. It wasn’t intuitive at all. The question mark maybe implies a little about the preceding text, but knowing what happens next wasn’t natural for me.
So in the form you prefer, the colons threw me off. I didn’t know if they were part of the actual condition syntax or if it meant what I now know it means. I didn’t have that problem with brackets… CSS taught me that code inside of the brackets only matters if the stuff before the brackets applies.
Also, one of the first things I learned in PHP was how to write a basic function. So again, function foo() { bar } was familiar by the time I graduated to writing conditionals.
Now I know… I know… we’re talking about non-devs who just want to move post meta above the title… not learn how to write PHP. But I think it depends on “where they’ve been” before getting to that template file. And as I mentioned, I just can’t imagine a template file coming before a CSS file in the order of operations.
Good read and definitely something for me to think about as I treat my template files differently than my core files too (lots more PHP escaping).
+1. Love this.
I agree with Sean. In my experience, my own and other developers I work with, CSS has usually been the entry point into altering wordpress files and leading into deeper development.
In the past year I’ve worked with 2 noobs to help “train” them on WordPress and for both of them the colons in the loop were more confusing than the brackets of a function. I think Sean makes a great point that the brackets in CSS are easy for non-developers to understand and that makes it easy for them to make the connection in PHP.
Another front-end developer I worked with was good at HTML, CSS and jQuery but was always nervous to try his hand in PHP, but when he realized the syntax of writing a function and an if/else statement was the same as jQuery he picked it up quick.
I suppose its all about where you came from, and if a template file is indeed your first exposure, it might be slightly easier to grasp initially, but then when you open up the functions.php and all is brackets again, you’ll end up more confused, thinking there’s some special hidden difference between the brackets and the colons, etc. . .
I personally favor the brackets for so many reasons. . .consistency, easier to type, syntax highlighting, etc. . .
Well said Sean! When i started with WP years ago, it was all about CSS and jQuery for me. So when i finally started messing with the php-side of WP, the {} was already a familiar concept.
Those are very valid points. I don’t completely disagree, except on part of it: I really don’t think brackets in CSS carry over to PHP, except perhaps in them being a familiar character.
I’d argue that beginners modifying CSS don’t usually grasp what the brackets really mean, except perhaps as far as “stuff goes between these”. Non developer users making tweaks to CSS are changing colors primarily, so they find the color code and change it. That’s it. Just because they can do that doesn’t mean they understand why or how the brackets are used.
I think we ought to be careful about delineating between beginning CSS developers and non-developers that are attempting to modify CSS. They’re two very different types of people.
If you want to have non-devs modify the code, you
a. have a lot of faith in humanity that they want to or even are able to do this themselves
b. you’re getting a mail/phonecall from them and you end up fixing code way worse than ‘it has brackets in them”
I get your pov, but really, this is not gonna make it easier for people to modify their theme imho.
And the use-case is pretty minimal too I might add..
Plus: it’s also easier for them to see where a IF-clause starts and ends imho..
There are tons of non-developers that modify template files every single day, and many that do it quite successfully.
Hi Sean.
You’re the man! I started with CSS first. That’s how I’ve learned the brackets meaning.
Now I write complex plugins to force other’s complex frameworks to support even more complex plugins and API calls… And I still have huge troubles with reading the IFs followed by semicolons in Twenty X templates.
That’s great advice and very timely. I totally agree with you that curly brackets are less clean. As part of my job I often study code in different plugins. I think any thing that makes code clean and easy to understand should always be preferred over easy and quick code. I think commenting can make it easier to understand whats happening in next lines of code but not how it’s been done. The new users studying the code want to learn how it is done and how they can use the same technique in their templates or code. Cleaner code is a win win for all.
Note that I”m only advocating for this inside of template files where you have the HTML as well. In all other php files that are part of a theme or plugin, brackets are usually a better choice.
I *hate* that style of Loop. Not the brackets vs endif thing, that’s a matter of choice.
No, what bugs me is that every single line in that Loop starts with [?php and ends with closing ?]. The indentations are pointless output, ignored by the HTML.
The whole thing should have the php wrappers removed and wrapped around the section as a whole, with the indents removed from the HTML-space and put into the PHP-space instead. It’s a lot more clear when you get rid of the unneeded stuff, brackets or no brackets.
YES!! This drives me insane as well! Seeing opening and closing php tags on every single line. If it’s all php, then just use the one set of tags around the whole block of code! As Otto said, it makes it so much easier to read.
As far as using curly brackets or not, I agree with Sean, above. I tend to think that the majority of non-developers are more likely to experience their first bit “code” when looking through CSS files, so their first experience is with the use of curly brackets, than not. Personally, I think it’s a hundred times easier to read, seeing what’s enclose in the brackets, than trying to read something that isn’t.
Very interesting to hear your take on the subject though Pippin. Thanks for the good read.
I’d disagree on the principal that
If your template file is all php then it’s not really a template file is it? If that’s the case, I’d say there is something very wrong with the way your “template” is built. The point is the the endif style makes the combination of PHP and HTML much cleaner and easier to read.
I personally think they’re useful because user can quickly add html between the php tags without having to know what the php block is. It’s also useful for support, easier I mean, because you can just say “find this line, paste this before that line” without having to ask them to close the php block, add the opening for the other, and only then add the html. Let’s also say that having the user away from the php block minimizes risks for them.
On the main post of the topic, brackets with proper commenting are as useful as long hand notation. And besides, long or short form, I’d always include a comment at the end of a major block so user knows which is the corresponding conditional.
I’d much rather write PHP in my HTML than HTML in my PHP. Why? Because of syntax highlighters.
I agree with this 110%. It drives me nuts and never understood the point of constantly opening and closing PHP chunks.
There is a comment in the cited WordPress coding standards handbook.
I see a lot of devs pushing against this sentiment, but I think the point Pippin is trying to make here is spot-on. The simple underlying lesson here is keep you template files as simple as possible! Pippin, you’re probably going to start a flame-war regarding the use of curly brackets {} versus the alternative syntax for control structures in PHP, but that’s another battle 😉
Template files should be as accessible as possible for non-developers to modify, which is why many apps/frameworks use a purpose made templating engine. For example, the Symfony PHP framework uses a template system called Twig. Their docs have a good discussion on why they use a templating engine. It forces developers to move logic into the controllers (Unlike PHP, Symfony uses an MVC approach which has grown in popularity in recent years) and keeps templates simple. Now of course you need some kind of logic in your templates, but Twig has a limited set of special construct to allow for looping and that kind of thing.
Now I’m not saying WordPress needs a templating system like this. I personally believe straight-up PHP makes a perfectly fine templating system, but with great power comes great responsibility. We as developers often cram too much PHP logic into template files. It’s not always possible, but I try to keep any PHP to a minimum in templates. If at all possible, I try to keep PHP block to a single line.
A very good example of this is how the Automattic theme team made a recent change to the _s theme to moving a great big chunk of logic out of the
image.phptemplate file into a separate function in an include file. Definitely a step in the right direction.Also of note is Alex King’s Carrington Core framework. This attempts to simplify WordPress templating by breaking each template down into smaller “atomic” pieces, and removes the need to have as much PHP logic inside of your template files.
I’ve seen brackets used and the closing bracket had a comment: // end if …
using endif ; is just easier to read at glance with all the indentation you don’t have with function files
I want to write code the ‘right’ way, emphasis on readability. I look to the coding standards documentation on .org to provide the right guidelines. I prefer brackets purely because I think they are more readable for coders and non-coders (so I feel I pick them for the right reasons). But if a particular coding style is better, it should be documented in the coding standards.
Ternary operators are documented in the coding standards, but I’d love more guidelines on those, especially for the javascript implementation (Somethings I’ll see javascript implementations that are like mental gymnastics). For basic conditionals that fit on a line, I find the ternary operator easier to read. And really, if it’s the first time seeing them, it’s a google search away. If you’re not motivated too learn basic operations, the person should probably not be touching php code, since it’s so easy to break things. If it’s something users end up looking for frequently, maybe it should be approachable through a setting or filter…
I’d disagree about brackets being easier to read for non-developers. That’s the whole premise of this post 🙂
Well I’m not sure that non-developers by definition have a much easier time with the if endif style, from your article it appears as an assumption (I have to assume you are getting this from your customer support experiences though). However, a case can be made that brackets is more readable for non-developers. Maybe on the whole, non-developers have an easier time with if endif style, but it’s not clear-cut without supporting data.
Personally, I found non-bracketed conditionals harder to grasp while learning the php side of WP. It’s even more confusing when there are different styles used throughout a code base, which is another reason I stick with brackets everywhere: it’s consistent.
If the if endif style is truly better for non-developers it should be documented in the coding standards as a recommendation for template stuff. In any case, I’m for the same thing: making code easy for users to understand.
I’d argue it’s easier primarily because it’s semantic. The endif, endwhile, etc, literally say what they do: end IF statement, end WHILE statement. Brackets, though still simple, are nothing more than an arbitrary symbol that has meaning attached to it, but there is noting that makes them inherently make sense.
Semantics is a good reason in principle over something non-semantic, I’d agree with that. But in this case is presupposes a non-dev is going to grasp what IF and ENDIF mean. It’s not if it conveys a great deal more verbal clarity compared to IF with brackets. Does endif makes sense to all people? It will to us, but maybe not to all just looking at foreign code. Are brackets that weird? People write with symbols all the time, they use parentheses, colons. Not that big of a leap I think to understand it groups a block of text/code/css. I could be wrong though, it’s tough thinking about the things we take for granted and putting on a true beginner’s hat.
I love the motivation behind this though. How to make things easier for non-devs. But if you want to go the extra mile for these folks (and limit support requests), why not simply argue for more code commenting and documentation examples? I think that makes a bigger impact regardless of whether you use brackets or not.
Ultimately disagreement about what is easier is completely fine. The important thing is that you (speaking generally) as a dev consider very seriously what is and what is not best for the users, both those that have development experience and those that do not.
I have the same hangup as Peter, here. I simply think it’s an assumption that something like ENDIF; makes more sense to non-devs. I kind of laugh at myself when I say that because you’d think that clearly spelling out a meaning would always be more clear. But I just think this situation is slightly different. Parenthesis, square brackets, and curly brackets mean something very specific to me no matter where I see them. And that means is they hold something inside of them.
Even when I was simply adjusting color codes in CSS, it was still obvious the limits I had to stay within because of those brackets. I honestly do not feel that spelling it out makes it easier. I believe it complicates it for non-devs… as they may not even understand what a conditional is.
What? I can use : instead of { }? Why didn’t somebody tell me sooner? I’m your classic case. I can bang the heck out of html and css while everything I know about php has been learned by trial and error. I’ll look forward to trialing :
I’ve got a similar stance as the rest of the guys here – in my experience the brackets have been more intuitive for my students to learn. My personal preference is to use brackets too. because it feels more intuitive to me but that’s exactly what this is all about – a matter of preference.
With that being said I honestly don’t think it matters which you use in terms of readability, at least when you’re considering non-developer end users making edits, because both do still translate into exactly the same pseudo-code, yet neither of them reads as naturally spoken english. So either choice is still so far from the natural speech pattern of the [non-developer] reader that following either of them is still taxing. Neither of them appear to be more intuitive than the other from my perspective.
And for a non-developer to choose to edit their theme files themselves, with no prior knowledge of php, what matters most (and much more so than the theme author’s choice of brackets/not) is nestling. Making sure your code is properly nestled so it visually gives off cues at to what is happening is much more effective.
I would also argue that the most readable of the two variants would actually be the one with the most accurate and concise internal commenting XD
Rather than focusing on the semantics of your code (because I’m neither for nor against the use of either method) why don’t you invest the time you spend worrying about it into actually developing things, or even making the front-end more readable – for instance the 11px font-size on this site is way too small to read on my phone without zooming in. That’s a major readability issue there you could table on the user facing side of your code.
I love your stance on properly nesting your code; that is by far one of the most important aspects of making template files easier for users to read and modify.
Why do I worry about what is best? Because it is my responsibility as a developer to seriously consider what is and is not best for the users of plugins and theme (and anything else) that I write. Personally I’d say my portfolio speaks for itself in terms of “actually developing” things.
Thanks for the note on the 11px font. I will increase it. As a young developer that still (probably not for long) has strong vision, I easily forget these things at times 😛
For the record, it is 13 px 😀
Sorry maybe I came across cheeky when I mentioned about you reinvesting the time you worry about the semantics of back end code into actually developing things. I didn’t mean to and I do see that you build plenty of useful things 🙂
What I meant was that you may be able to provide more value to your customers by focusing more on things that matter more to them than the semantics of your code.
Speculatively you can say that more people will see what the code creates rather than look at the actual lines of code. So the time you invest in worrying about making your code readable by the average person might actually be better placed in what gets output by the code. But it is MIGHT be better – because it could well be that your customer base does indeed look through/edit the code more than the average user. In which case that makes your customers an exception to the norm.
Again, not to be cheeky, but it is 11px for anyone on a screen below 800px. Have a look in your stylesheet or use chrome dev tools/firebug and take a look within the following media query for this code:
@media (max-width: 800px){
#featured,
#main,
#featured_below,
#bottom {
font-size: 11px;
}
}
You’re #main ID actually spans the majority of the page so the 11px is cascading through to everything that’s not explicitly stated afterwards – and it’s also got a class of .sidebar-right attached which, in my opinion, is semantically incorrect lol
Oops, you’re right. Fixed!
Awesome! I’m glad I proved to be helpful eventually and not just disruptive haha
Here’s another one favoring endif; endwhile; in templates, even for developers. One thing I haven’t seen touched in the discussion: using closing statement line comment (regardless of using } or endsomething) to hold information about which loop is ending
while ( have_posts() ) : the_post();
if ( $something ) :
....
if ( $someorother ) :
....
endif: # $someorother
endif; # $something
endwhile; # have_posts()
This is mainly useful in more complex templates whose line counts span outside of a single screenful.
And on a lesser note, here’s something I find newbishly annoying:
while ( $whatever ) :
....
endwhile; // end of the loop
“Way to state the obvious there, buddy!”
I actually did reference the closing comments when I said:
But I agree, the best way to make code human readable is by including human readable comments 😀
Please do not use template files.
This message brought to you by Thesis 2, which only requires data—not files—for templates.
As you were.
Can you show an example of how it works?
Initially, I have to say that I really disagree with the idea of “no template files”.
I was waiting for this.
If there has ever been one thing that really, really impressed me within the WordPress world, it’s how Thesis 2 handles templating. After seeing how it’s data-driven and basically creates templates “on the fly,” I have always felt like template files will forever be the second best way to do things… even while I was building Volatyl.
I have no idea what the pros and cons are of having data-driven templates. I just know that it makes more sense than anything else. My only issue with them in Thesis 2 is that I feel it has far outgrown WordPress and is going against grain that’s not even worth it. But you already know how I feel about that, Chris.
Can’t wait to see that system somewhere else.
File-less templating is also done with the Views plugin, which I like. There are definitely perks here (no php for non-coders to mess with or learn), but there are downsides too. The biggest one- and Sean said it already – is that it goes against the grain of the rest of the WordPress ecosystem. Another drawback is that users have to learn how that works too.
Consider this:
Let’s say you have a post box div that contains some HTML inside it. For now, this post box is in use on your traditional, default blog page (the home template in WordPress for sites that are not using a static home page).
And now let’s say you need to create a custom template that uses this post box, but with slightly different interior output (“interior output” = the stuff inside the div), such as including an email sign up form underneath the post. Under the WordPress template paradigm, you’d need to:
— FTP into your site
— copy the text you need from the appropriate template file(s)
— create a new template file and paste in the code you need, taking care to include everything necessary for solid SEO and complete rendering (as developers, we take this step for granted as no big deal, but an average user has almost no hope of doing this 100% accurately)
With Thesis 2, the process is much simpler because HTML templates exist as data. This means that there’s no need to edit a file, which is not only cryptic, but also prone to mistakes because of the nature of hand-editing anything.
(Incidentally, this is the same reason why large manufacturers use automated processes to produce goods—faster, more consistent production with less variance in quality.)
Anyway, to create a custom template and make the aforementioned adjustments is a breeze with Thesis 2:
— using the interface (not a cryptic file that you had to access via FTP), simply create a new custom template and populate it using the “copy from existing Home template” command
— spot-edit the Post Box on the new custom template (visually, with drag-and-drop) by moving an email signup form into the desired location, and save the template
The process with Thesis 2 is so deceptively simple that you may miss the “big wins” contained therein.
First, there is no need for FTP, which means no need for average users to understand WordPress (or Thesis) folder hierarchy or how to navigate through their server. It’s easy to scoff at a statement like this…until you have 50,000 customers who are unfamiliar with FTP and who balk at the very notion of learning it.
Second, there is no need to understand template context—SEO, markup, completeness, etc.—when using the Thesis Skin Editor in this way. Because the Home template was copied in its entirety, the markup was already optimized for output.
In this case, the only noteworthy edit was adding an email signup form to the Post Box, and that’s precisely the action the user would take in the Thesis 2 interface.
In contrast, under the old WordPress theme paradigm, the user would hand-edit a template file, which is fundamentally different from working with the precise piece of data that you want to change.
Third, now that I’ve mentioned “template file,” I have to mention one of my favorite things about Thesis 2:
Because of the WordPress theme system, you’ve never seen a template in its entirety before.
You’ve seen the results of a template—the output rendered on a particular webpage—but you’ve never seen an entire template at one time while editing.
The reason for this is rooted in the nature of the template file system itself. Most WordPress “templates” are actually runtime collections of at least 3 different files, such as:
— header.php
— index.php (or any other requested “template” file)
— footer.php
Ironically, this method approximates OO modeling—essentially, the header and footer files are “objects” that get used by all the other templates.
However, because of this multi-part construction, you can never see your templates in their entirety while editing them.
Thesis 2 is not limited in this way because its templates are entirely data-driven. Thesis simply compiles the data for a particular template and then presents it to you in the Skin Editor, where you can make modifications, test different outcomes, etc.
And the winning doesn’t stop there. The data-driven environment allows us to do incredible things like:
— build a data manager that can backup/restore/import/export templates, design data, CSS, and more
— offer precise support based on a user’s current data settings, which are far easier to work with than FTP and WP login credentials (for those tough troubleshooting cases)
I could go on forever here, but the bottom line is that data-driven templates require fewer moving parts and open up lots of new possibilities for editing, interacting, analyzing, and testing websites.
Oh, and one more thing—who among us has not had template files hacked at one time or another?
Template files are extremely attractive to hackers and spammers because they are directly responsible for HTML output.
Because Thesis 2 doesn’t have any template files, it cannot be hacked in this same manner.
On a more philosophical note, when you have a problem like template files getting hacked, there are 2 possible approaches to a solution:
1. implement the latest “hardening” techniques, keeping in mind that this is a moving baseline that requires constant upkeep over time (because hackers find new ways to win)
2. Adjust the system so it no longer works the same way and cannot be exploited in the same manner.
WordPress continues to cling to its now-antiquated theme architecture because there is so much riding on it. They wouldn’t dare nuke 3/4 of their themes—even if most of them aren’t worth the bytes they occupy—in the name of introducing a newer, better system.
With Thesis 2, I saw an opportunity to improve upon a broken system, and I did exactly that.
From my perspective, data vs. file-driven templates are basically the same as geometric vs. linear curves in algebra. Quite simply, data-driven templates are more flexible, more adaptable, and require NO hardcoding (every template file is hardcoded).
Haven’t not personally tried Thesis, I can’t whether this is true or not, but my biggest challenge against file-less templates (and non-standard templates) is that they usually break a lot of behavior that WordPress plugins expect.
For example, I have seen file-less templates that completely remove wp_head, wp_footer, and a lot of other standard actions. As a plugin developer, these are the bane of my existence because plugins absolutely rely on the presence of standard WordPress hooks and filters.
If Thesis manages a data-driven template system AND doesn’t break any of standard WordPress behavior for plugins, great.
My other dislike (not specifically of Thesis) of data-driven template files in the realm of WordPress is that they go against what is expected. I’ve run into countless support issues where a user wanted to do something, and I instructed them how to do so in a standard WP theme, only to find out that they were using a theme that built it’s own entire template system. This ending up doing nothing but a disservice to the user because suddenly they couldn’t accomplish what should have been extremely simple.
I’m not saying it’s impossible to move forward, or that the current templating system is best (not at all)., but when we work within an ecosystem, I believe products (plugins and themes alike) have a responsibility to at least attempt to stay within the borders of the expected behavior.
Data driven templates are awesome (see the comment above about the Symfony template engine), but I do not believe they belong inside of WordPress, at least not until WordPress core beings making a transition to them. If Thesis is able to push WordPress core in that direction, then I have nothing but major props for you.
By the way, in response to your comment about not seeing a template file in it’s completeness, I actually believe this is a great perk of the current system as it breaks a complex set of functions and code blocks (HTML and PHP both) into manageable chunks.
As was best said by Jeffrey Way, one of the best things you can do for yourself as a developer and for others looking at your code, is to break your project down into manageable chunks.
Trac ticket: http://core.trac.wordpress.org/ticket/24549
I know that you, me, and others have talked about this on Twitter, and I’ve shared my own thoughts on this, but I will admit that you’ve definitely put an interesting spin on the idea of how code should work within template files.
Namely, I’ve never really considered template files as being user-centric (versus pure PHP files). Part of this, I think, is because of my – and others, really – background: We get so used to being the ones that write the code and thinking of the presentation as being what the user wants to tweak, that we may think about it in terms of CSS, but rarely in terms of things like The Loop, conditionals, etc.
So, to that point, that’d definitely food for thought for me. I don’t know if I’ll change my coding style or not, but I do know that I try to stick with the standards as much as possible and considering that template files in WordPress are traditionally written this way, it’s worth considering.
That said, I do feel a tension when it comes to writing code with colons and
endifandendwhilewhen I think have braces, matching, and terminating comments like} // end whilecan help on both levels (since some IDE’s don’t match:withendif, for example) especially when it comes to nesting code (but that borders on code smells which is off topic :)).Anyway, I’ve written a lot simply to say that you’ve definitely given me some food for thought, but I don’t know if I’ll end up changing or not – so thanks for making me sound like a crotchety-get-off-my-lawn-old-man :).
As I said at the end of the post, I think the most important take away is simply considering what may be best, regardless of which side you land on.
Emphasis should be made that this relates to template files which may have long HMTL parts between the conditions and loops – if you wish to go the non-Thesis 2 route of course. Pure PHP files (e.g. functions.php and any supporting classes) shouldn’t necessarily adhere to this as indenting and commenting with no HTML would make the code readable.
Do you find that most non-devs understand the concept of the WordPress “Loop” and where code should be placed in a template?
No, not generally.
Loop syntax notwithstanding, I prefer – and will stick with – using opening/closing curly braces. I have nothing other than my own opinion/preference regarding their use.
The thing is, that’s all I see for the opposing argument, as well: opinion and preference.
if : / endifis more symantic/intuitive thanif {}? Sounds like a matter of opinion/preference.if : / endifis easier thanif {}for new/non-developers to grok? Sounds like a matter of opinion/preference.And regarding your argument against using a ternary expression: as-written, your alternative generates an
undefined indexnotice. Why sacrifice elegance, efficiency, and clarity simply because a new/non-developer might not previously have been exposed to a normal PHP expression?In the end, I’m not arguing for using curly braces vs. endif; rather, I’m arguing for not arguing at all over matters determined purely by opinion/preference.
Well said, Chip.
I disagree simply because I don’t think it’s actually a matter of personal opinion: I believe it’s a matter of decided what is best for your users, not you as the developer.
As developers, we make choices on aspects of our projects that affect the experience of our users, and sometimes we have to make choices that go against our own personal preference because it end result is better for the user.
You’re right about the undefined index, but this was only meant as an example; it was not taken from any real project.
While my original statements may have come across this way, I don’t believe in arguing over preference either, but I do strongly believe in considering what is best for your users, even if it goes against personal preferences.
To be fair, if someone makes a solid argument for a particular code practice that benefits the end-user, I think it’s more than worth thinking through. There are two big motivations here, making it easy for non-developers and possibly lowering the support burden for developers – not some kind of diabolical ideology about how devs should be coding. I don’t think Pippin’s arguments were based on opinion or preference in the same way programmers often quibble over programming languages and such, you almost make it sound that way though.
Peter, yes, that’s exactly what I meant.
That’s my point: I see it <em.asserted that one method benefits the end user, but I see no evidence that the assertion is true. If there were evidence (not merely anecdote or assertion) that one method benefits end users more than the other, then I would consider that evidence.
But in lieu of evidence, there is more assertion:
I disagree wholeheartedly with that assertion. Brackets have semantic meaning that is obvious to developers and non-developers alike – semantic meaning that facilitates understanding their use convention in a programming language.
And to whatever extent that if/endif could be shown to be marginally more beneficial for end users than curly braces, I still would not advocate for Theme developers to abandon use of curly braces (or ternary statements).
Why?
WordPress Themes are written in PHP. In order to get one’s hands dirty with WordPress Themes, one must learn some degree of PHP. I disagree with reducing Theme development conventions to the lowest common denominator in the same way that I disagree with reducing web hosting knowledge to the lowest common denominator, just because WordPress makes running a CMS so darn easy. Anyone who self-hosts a WordPress install bears the responsibility to learn some basic knowledge around running and securing a web server, just as someone who wants to modify or develop a WordPress Theme bears the responsibility to learn some basic PHP knowledge.
Whoops, misunderstood you!
Fair points that we get to agree to disagree on 🙂
Huh. I hate when people don’t use
{}in their code. Theendif/endwhilemakes the code harder to read.I just read the new Themeforest WP Theme subsmission requirements. Requirement 6 in the PHP section states the following:
Authors should strongly be encouraged to always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.
I was kind of “for” the end* on template files which include HTML and strongly against it in pure PHP files i.e. functions.php. I guess we just have to get used to one standard and maybe it has to be enforced from high above.
I do understand Pippin reasons and I’m ok with them.
What bugs me is the so called ‘standard’. The whole thing about standards is to normalize ‘personal’ tastes in a way that different people can work in harmony without imposing their own preferences. Am I correct? If so, let me repeat what I wrote at WP PHP Coding Standards.
—
I don’t think it’s about taste, but standards. I think both syntaxes should be ok, otherwise if I’m a newbie and I use Twenty Thirteen or _s as objects of learning… I’ll be doing ‘wrong’ without knowing.
I’ve followed up on this directly on the PHP handbook: https://make.wordpress.org/core/handbook/coding-standards/php/#comment-19978
As far as I can tell, the consensus is that the alternative syntax for control structures is completely fine for Core’s coding standards.
Thanks!
Great Read! Good points!