A solution for designers who don't know Wordpress
bckmn.com
bckmn.com
The default theme was, and still is, too bloated for learners to wrap their heads around. It has too many features, too many branches, and too many sub-templates extending the main template, due to the fact that it also needs to serve as a showcase for all of WordPress's features. I resorted to downloading the most minimalistic third-party theme that I could find, cleaned it up some more, and used it as a base for all the themes I've written since then.
I'm glad that someone finally made an open-source theme specifically for the purpose of being a rock-solid base for other themes. This is something that should have been done by the core developers 10 years ago. I don't know how much longer we'll have to suffer the sprawling spaghetti monster that WordPress is, but since a lot of us are stuck with it anyway, why not make our lives easier for the time being!
P.S. Please add a link to the GitHub repository, too. Some of us prefer git clones to tarballs.
[1]: http://underscores.me/ [2]: http://wordpress.org/extend/themes/toolbox [3]: http://themble.com/bones/ [4]: http://www.rootstheme.com/
Also, I'm getting nitpicky here, but you also don't exactly call a function to start a loop. You call a function to fetch the posts in an object. You then use a pretty bog-standard while loop to loop through that object. You do call a method of said post object to determine whether or not the loop should continue - is that considered bad practise generally?
I understand why a lot of people think the WP loop is badly constructed. The start of a typical loop in WP is this:
if (have_posts()) : while (have_posts()) : the_post();
which is essentially shorthand for this: if (have_posts()) {
while (have_posts()) {
the_post();
}
}
I think the cause for some misgivings is that people might not realised that have_posts() is actually doing this: return $wp_query->have_posts();
So you're actually just running a method on the global post object. You'll make similar post objects for custom queries, and interact with them in an identical fashion.And yes, I'm referring to the weird `if (have_posts()): while (have_posts()): the_post();` boilerplate. Back then, for a PHP newbie like me, it looked like a magical one-liner ... until I realized that the loop actually terminates hundreds of lines later with an endwhile/endif statement. It's so easy for newbies to miss the significance of the two colons, especially if they're not familiar with the "alternate syntax for control structures".
Although I now understand how the loop works, it still pisses me off that I have to call a function to populate a bunch of hidden variables/objects that are later fetched by other functions. Too much going on behind the scenes == difficult to grok. A simple foreach() loop would have been much more intuitive. Perhaps this will happen sometime soon using the Iterator interface, now that WordPress has finally left PHP 4 behind.
I definitely agree that a best-practise step-by-step theme construction guide in the Codex would be very useful. I still see many themes using things like query_posts() instead of creating a new WP_Query or a hooking into the pre_get_posts filter. As I mentioned below, Wordpress would ideally have its built-in functions trimmed dramatically, though this would really murder backwards compatibility.
I don't really think it's Wordpress's fault that the Loop uses the alternative PHP control structure, but I agree that the Loop's Codex page is abominable. You may or may not be aware that the Codex is a wiki, and thus poor quality information can and will be added.
I would like to see a loop using the Iterator class. However, there are quite a few complexities to that, as mentioned in this feature request [1]. They also point out that you can foreach and count on $wp_query->posts, so you can get to your information in a more obvious PHP-friendly way for now.
<?php while (have_posts()) : the_post() ?>
<h2><?php the_title() ?></h2>
<?php the_content() ?>
<?php endwhile ?>
There are four unique functions there. All of them depend on non-obvious global state and three of them are used specifically to produce side effects. the_post() invisibly overwrites a global and changes an iterator. It not only mutates global state, but it does something different if you accidentally call it twice. And WP's the_whatever() functions echo something and return nothing?! Want to do some filtering on the title before you print it? Better use get_the_whatever() instead. WTF?! Heres how it should work: <?php foreach ($post in $wpdb->get_posts() : ?>
<h2><?= $post->title ?></h2>
<?= $post->content ?>
<?php endforeach ?>Additionally, Wordpress has tons and tons of bad functions. If so many themes weren't dependent on them, I'd advocate for entirely stripping out a good chunk of them. Someone needs to write Wordpress: The Good Parts, or at least a really canonical good practise guide. I guess it could be a good weekend project.
For the functions you mention, you're actually not too far off what they really do. the_title() [1] is just slightly formatting get_the_title [2], which is mostly just returning $post->post_title.
Unfortunately, skipping the built-in functions means also skipping the slightly obtuse but powerful filter system. However, if you're not interested in the built in WP stuff, then there's no harm in outputting the titles directly.
Btw, yes, I realise this is mostly academic in the context we're talking about.
[1]: http://core.trac.wordpress.org/browser/tags/3.5.1/wp-include... [2]: http://core.trac.wordpress.org/browser/tags/3.5.1/wp-include...
<?php if (have_posts()) : while (have_posts()) : the_post() ?>
<!-- do loop stuff -->
<?php endwhile; else : ?>
<!-- no posts found, show a default or error of some sort -->
<?php endif ?>EDIT: I often have to teach other developers the basics of Wordpress - just pointing someone to the Codex sometimes isn't good enough, especially on a tight deadline. This theme can really help out.
And seriously, enough with the negative comments about Wordpress. Love it or hate it, it's there to stay, and it's in our best interests to educate developers how to theme it correctly.
Of course, that could just be the bias of my own skillset talking.
No need to hate on new, useful teaching aids. Everyone needs to start somewhere!
None of these things are particularly difficult, and they all have good documentation and tutorials, but I would think someone who was resistant to looking up a function signature would probably get bogged down and give up somewhere higher up on the list.
Now, this could still be useful for learners, I just don't know that the target is designers who can't be bothered to learn.
The themes included with wordpress, twenty-eleven and twenty-twelve can be too complex, and have a lot of cruft we don't need. So we usually start with a skeleton theme, like this one - although this one is a particularly well documented skeleton theme.
Sometimes it takes an example theme like this to make things 'click' for a new developer. For that reason alone, it can be very useful.
Of course being a designer and not a developer, you're going to struggle learning syntax and convention (that goes for any language or application like Wordpress). Stick with it, the Codex is great.
It's true the Twenty Ten and Twenty Eleven default Wordpress themes were bloated and if you were trying to use them as a base or learn, you'd probably be overwhelmed by the kitchen sink approach the core team took when creating those themes. Having said that, if you want a clean starting base for a theme, try using the bundled Twenty Twelve: http://wordpress.org/extend/themes/twentytwelve — which is arguably the best default theme ever to grace Wordpress. Most naked themes you encounter for Wordpress aren't naked at all (Bones especially abstracting an already abstracted CMS even more).
Having said that, this naked theme looks good. It's actually naked and well commented but not naked to the point it's really any less simple than Twenty Twelve (just less files). The benefit of considering a default theme as a starting base is that you get to see how the experts develop a Wordpress theme and the added bonus of how to use the custom background functionality and the Theme Customization API as well.
This kind of reminds me of my Actual Barebones HTML5 Github: https://github.com/Vheissu/Actually-Barebones-HTML5-Template — It's literally a HTML file that gives you a HTML5 structure without assuming you want jQuery or anything of the sorts. The term naked and barebones seems to have lost a lot of meaning in the web world.
However, I think it heavily falls down in it's ambition of being a good general-purpose starter theme by making some strongly opinionated decisions out of the box. There's far too much grid code in the CSS. It also bizarrely bundles fittext and fitvid, two excellent libraries which have nothing to do with Wordpress.
I would also argue that anyone building a Wordpress theme should be looking things up on the Codex. You don't have to "learn" the Codex any more than you have to "learn" the dictionary. It's there as a reliable and canonical reference, and telling people not to use it will result in bad code and confused developers.
A quick Google search usually brings up the most relevant Codex page and while their code examples aren't always the best, the web usually provides enough user-written tutorials to get my the solution I need.
For those interested, this would add a significant amount of reading material so they could have a better understanding.
I mostly use Starkers as a totally bare bones template starting point. If anyone is interested: http://viewportindustries.com/products/starkers/
Now let's see how quickly this gets downvoted into oblivion because WP.
I'm a developer, not a babysitter, and while I can stand guaranteeing a product I build, I cannot and will not try to guarantee a product that stands a very good chance of being hosed by some retarded exploit (relative to a custom product). Since I'm not in the babysitting business, "better" for my clients is a product that won't be the Turkish graffiti or BlackHole distribution engine in six months' time.
It also needs to be said that for some reason lately, clients have consulted developers who have put it into their heads that using WP automagically brings your price and development time down by half, regardless of the circumstances. That's absurd, but it's usually the first real question I field about the technology we use to build products and services. If a client really wants to know the specific reasons why we don't use WP, you can bet that I don't have a problem explaining this exactly as I've explained it to you, albeit perhaps with different terminology. Simply put, I don't use WP because it is too risky versus the custom product we build, and that whole mess is something I don't want to clean (for free, which is what they'll demand when it happens). Even if I "maximize" some profit margin using it, I still feel that I'd be doing a disservice to my client. I'm totally honest with my clients, and if they insist I use WP, I insist they go somewhere else. And at the end of the day, if you aren't honest with your clients, you're a bad developer and a bad person.
That's my opinion, and I realize other people feel very differently, and that's fine.
That certain clients have unrealistic expectations because WP should be cutting dev time in half etc, that's an interesting point. I think client education factors in here.
You can be running another CMS or something custom and run into security exploits all the same though, if not more so. Something custom doesn't get the same amount of eyeballs from developers to ensure everything is secure. And even static sites can be hacked and abused if a hacker gains access to the server.
On security, the custom code we have written and deploy for our customers is stuff that I trust, because it's something we built ourselves and are extremely familiar with. Our products also come with a built-in automated "security service" that helps tremendously in keeping us from being the lowest-hanging fruit. Importantly, not even using WordPress immediately shuts down the near-constant traffic on the internet devoted to finding insecure WP deployments. While I completely agree that a WordPress deployment in the right hands can be as secure as anything out there, I don't trust the codebase in general, and certainly not as much as I trust my own code, despite there being a large number of coders sifting through WP. And all bets are always off if an attacker gains entry into the hosting provider.
As a specific example, WordPress doesn't use PDO at all, instead using the mysql_ functions (not even mysqli_). This is a pretty glaring problem from my point of view. The excuse WP core developers have used is that it's basically too tightly-coupled to use anything but MySQL (and specifically the mysql_ functions). That's a pretty big red flag to me, when a developer says that their product is too tightly-coupled to stop using functions that have been officially deprecated in the language for quite a long time. In fact, the feature request for PDO in WP is a kind of in-joke to outsiders (http://core.trac.wordpress.org/ticket/21663).
Also (and importantly), I don't sell myself as a WordPress developer, but as a custom web and mobile applications developer. I have done this intentionally so that I won't succumb to the temptation to start rolling out quick and dirty WP deployments, but instead focusing on providing a custom-built, quality product that I can honestly say they can trust to function well and function securely for a long time to come.
I just realised the theme is under GNU General Public License, does this means I have to share my modifications to the theme?, what if i want to build on it and sell it?
thanks