What's the HARDEST theme stuff to do in WordPress?

[Ryan]

Lol, I'll stay up then!

BTW, what I'm talking about at WordCamp NZ is posted on their site ... http://wordcamp.org.nz/call-for-spea...nt-ideas-wiki/

[alicam]

About to upload it. Sorry for the delay.

[alicam]

Still rendering the video... meanwhile the wordcamp NZ site is down... seems like they're in the middle of an upgrade or something.

[Ryan]

They've been upgrading all day. It's been a complete mess. Not sure what's going on with it.

[Ryan]

I need to go now, it is too late at night for me. I look forward to watching it tomorrow though :)

[alicam]

Ok here's my video reply. I had stupid problems with the video and it took forever. Sorry.

This video explains why I think the Carrington theme by Alex King is so important...

http://bit.ly/jhjHi

Comments welcome here or on my blog.

-Alister

@alicam

[Otto]

Wish I could watch that video, but it just tells me to enable Javascript and Flash. Since I have them both enabled, I'm at a loss.

I agree with Ryan. Carrington doesn't make any sense to me. It's overly complicated and makes things 1000x harder to do. The hardest theme stuff to do in WordPress is try to make any sort of sense out of somebody's extremely overcomplicated theme.

Themes should be simple. Simple is better. Complex and frankly annoying code does not make things simpler.

Edit: Found the video by examining the page source code.

I agree with the extreme amounts of classes and such in the CSS idea, but these are not advantages of Carrington in particular. It's fine to add rich semantic markup and then use CSS to style, but that's just a matter of adding simple code to the body and divs and such. See, WordPress 2.8 has a lot of this stuff built in now. You don't need complex code to do it anymore. post_class(), body_class(), etc. None of that needs to be done in the theme's actual code anymore. If you're rolling your own classes like this, then you lose the advantages of standardized class names and such. Admittedly, I'm sure there's room for improvement in these areas, but putting these in the theme itself seems like a bad idea to me. They'd be better off in a plugin, where all themes on the site could take advantage of them. The theme is going to be modified by the end user, I'd like to avoid complex code in themes because of that.

With regards to your idea of modifying the markup, I see this as an extremely bad idea. The markup should remain standard and similar to all the other markup. Ideally, your markup would be basically identical across all your pages, and it would be simple. Body, DIVs for the content and sidebars, no wrapper divs, etc. All that markup crap that has to be added is because of limitations on styling. In other words, in a perfect world, the markup would be pure and only describe the content itself, and there'd be zero markup there that is only to help out the look of the page. The page's look would be entirely CSS defined.

Another way to look at this: If I take away the CSS entirely, does the page still read okay? Does it look okay? When I design a theme, I focus on getting as much of the "look" into the CSS as possible. Why? Because I look at sites on my cellphone too. And I like them to not have a crappy look when I see them "naked" as it were. Many sites fall into this trap and have all this stuff showing up that looks just plain terrible when rendered in unusual browsers. And not everybody has (or wants) an iPhone.

[Ryan]

I don't have time to watch the video right now. But currently my opinion is roughly the same as Otto's, hopefully you can sway me with your video :)

[alicam]

Guys the video shows up just keep waiting. Sorry it's an issue with how I load JS in the footer instead of the header.

[alicam]

Otto,

I agree with you on everything you've said, but can see that you have not understood my point.

I used the example of Sandbox and CSS to explain what Carrington does to the markup, NOT to suggest that CSS is what Carrington does. As you said, the whole semantic classes thing is "put to bed" now, well and truly, with the inclusion of those in WP 2.8, as I said in the video.

What I WAS trying to do was use that Sandbox story to highlight was Carrington does with markup. I was trying to highlight that what Sandbox allows us to do in CSS, Carrington allows us to do in the markup.

That it's not an either/or scenario (CSS or markup) but now both. Carrington allows you to modify the HTML markup (i.e. output) at a very granular (or as Alex puts it, "atomic") level.

So, for example, if you want to change the HTML slightly for every comment by the post author, can do. Want to change the HTML in all posts that have a custom attribute of "fred", then you can. Want to add something to the HTML of the loop when you're in category "boloney", then you can, etc.

As I said in the video... it's not that you CAN'T do that in ANY theme, for argument's sake, but that in attempting to do so you'd more than likely end up with spaghetti code full of if statements or a switch with a lot of cases. Either way, not a setup that would help your users work out what's going on.

Compare that to what, frankly, I think is a very elegant solution in Carrington. It's well laid out, if follows WordPress conventions, and it's clean. The fact that you're confused MIGHT just mean you don't get the power of it yet, not that it's lousy!

As a specific example...

I have asides on my blog. At present they're "pure CSS", which means I'm turning off a bunch of stuff although it still renders in the markup. It's good, but it's kinda silly to get the PHP to process stuff that's just going to get "display:none" in the CSS.

So, in Carrington all I have to do is add a new file to either the /content or /except folders (depending on whether I display excerpts or full posts on index/archive pages), modify the PHP/HTML there and I'm done!

Carrington will do the rest and I'm not mangling my index.php template file with one of possibly many if statements of switch/cases. Get it?

I accept that for a bog-standard WordPress theme with no smarts Carrington is not going to have opportunity to "show off" but start building a business or magazine site with a blog, gallery, product pages, faq, etc and all of a sudden you're moving a long way from "plain vanilla" and Carrington comes to life.

All this explains why for Vanilla -- a theme I am building for the most robust of applications -- Carrington is a worthy inclusion, IMHO.

I will do a video to explain how Carrington works in more detail ASAP.

-Alister

Wish I could watch that video, but it just tells me to enable Javascript and Flash. Since I have them both enabled, I'm at a loss.

I agree with Ryan. Carrington doesn't make any sense to me. It's overly complicated and makes things 1000x harder to do. The hardest theme stuff to do in WordPress is try to make any sort of sense out of somebody's extremely overcomplicated theme.

Themes should be simple. Simple is better. Complex and frankly annoying code does not make things simpler.

Edit: Found the video by examining the page source code.

I agree with the extreme amounts of classes and such in the CSS idea, but these are not advantages of Carrington in particular. It's fine to add rich semantic markup and then use CSS to style, but that's just a matter of adding simple code to the body and divs and such. See, WordPress 2.8 has a lot of this stuff built in now. You don't need complex code to do it anymore. post_class(), body_class(), etc. None of that needs to be done in the theme's actual code anymore. If you're rolling your own classes like this, then you lose the advantages of standardized class names and such. Admittedly, I'm sure there's room for improvement in these areas, but putting these in the theme itself seems like a bad idea to me. They'd be better off in a plugin, where all themes on the site could take advantage of them. The theme is going to be modified by the end user, I'd like to avoid complex code in themes because of that.

With regards to your idea of modifying the markup, I see this as an extremely bad idea. The markup should remain standard and similar to all the other markup. Ideally, your markup would be basically identical across all your pages, and it would be simple. Body, DIVs for the content and sidebars, no wrapper divs, etc. All that markup crap that has to be added is because of limitations on styling. In other words, in a perfect world, the markup would be pure and only describe the content itself, and there'd be zero markup there that is only to help out the look of the page. The page's look would be entirely CSS defined.

Another way to look at this: If I take away the CSS entirely, does the page still read okay? Does it look okay? When I design a theme, I focus on getting as much of the "look" into the CSS as possible. Why? Because I look at sites on my cellphone too. And I like them to not have a crappy look when I see them "naked" as it were. Many sites fall into this trap and have all this stuff showing up that looks just plain terrible when rendered in unusual browsers. And not everybody has (or wants) an iPhone.