A few weeks ago Dustin Curtis (designer/blogger/self-described Villain) wrote about his experimental new blog network called Svbtle. Svbtle is the codename of both the network and the content management system running he created to run it. Curtis said that he decided to create his own blogging solution after being “irritated by the complexity and uninspiring nature of most blogging platforms.” Along with a minimalistic design and approach to blogging, Curtis is also (currently) only allowing those bloggers onto the network who he has invited on board.
There are 23 members of Svbtle right now. A number of them have run their blog on WordPress before. A handful of the Svbtle members were using WordPress to power their blogs immediately before switching to Svbtle. It’s easy to write that off as little more than excitement over something new and exclusive, but perhaps there’s more to it.
At WordCamp Phoenix a couple of weeks ago I presented a talk on WordPress and journalism. Specifically, I talked about how WordPress can empower those in the field of journalism. I’ll have the slides up soon, but the specifics of the presentation aren’t necessary at the moment.
My presentation was a part of the “My WP” track, a track that featured presentations on WordPress in various verticals. One talk focused on how creative people use WordPress, another focused on real estate, and another on non-profits and government. I don’t mean to say that Phoenix is the only camp to organize presentations on these kinds of topics, but walking away from the event, particularly after speaking within that track, I find myself excited about the possibilities that WordPress verticals bring.
a group of similar businesses and customers that engage in trade based on specific and specialized needs (source)
As someone studying and writing a good deal about this particular industry, it is difficult to find inspiration sometimes. I think it happens, at least to me, when I spend a little too much time reading and absorbing the talk within the community itself. WordPress professionals talking to other WordPress professionals is a lot of fun, but it’s also a bit of insider talk. It’s not representative of the full influence that WordPress has on the world.
Magazine themes are quite alluring. Sliders, pictures, columns, unique blocks of different content on demos. But beyond the perfectly crafted demo marketed to entice you to purchase what you’ve convinced yourself you must have, you probably don’t need it at all.
I’m willing to bet almost no content driven website actually needs a “magazine” layout. In fact, for those that utilize them, it may hurt what’s most important to their bottom line — me, the reader. My page views and my time on their site.
A subject finally getting some attention in the WordPress community is i18n, or internationalization.
Internationalization is the process of making an application ready for translation. Often this gets confused with localization, which is the process by which the text on the page and other settings are translated and adapted to another language and culture.
Both internationalization and localization are equally important within WordPress, but there cannot be any localization if the theme or plugin has not been internationalized first. Therefore it is of utmost importance for WordPress theme and plugin developers to internationalize their software, regardless of whether it ever actually receives a translation into another language.
In the past couple of months we have seen more and more articles being published on the subject of internationalization. Some are even dripping with frustration!
I must admit that I have left frustrated comments on sites like WPCandy, WPBeginner, WPMU and the like, whenever something is promoted that is not properly internationalized. It seems I finally got someone’s attention as Ryan is the one who asked me to write this editorial after I left yet another frustrated comment on one of the articles published here.
For those whose native language is not English and who want to develop websites in more than one language, it is very frustrating to read any news about Fantastic Hypothetical Theme A or Cool Plugin B that were just released, only to realize after downloading that it is actually completely useless since it hasn’t be internationalized!
And do you know what is even worse? When said theme or plugin costs money (often called premium). Not only is that frustrating, it’s just wrong. Despite the number of features your theme or plugin has, if it has not been internationalized it shouldn’t be sold in the first place.
This is just not open for discussion. Internationalization should be common practice, not a feature!
Most theme authors have their own habits. Most habits will have a positive effect on themes, or least on the time it takes to develop themes. Developers sometimes forget, though, that there are Theme Development Standards everyone should use while coding themes. Some are more obvious than others, but none of them are that hard to stick to.
In the last few months I’ve heard of theme developers making silly mistakes. To name a few:
including a sidebar directly into header.php instead of using sidebar.php (via Ryan Duff),
and hard coding menus in header.php instead of using WordPress menus.
For these mistakes and others popping up, consider this a reminder: there is a Theme Testing Process you can use to test your theme. Yet many themes out there aren’t even close to checking all the boxes on that list. Even on massively popular marketplaces like ThemeForest, there are themes that fail in the first few steps.
The WordPress.org and ThemeForest theme review team are already using the Unit Test to limit the number of poor quality themes out there. The next step is for theme developers follow these coding standards by default. With WordPress improving every single day, it’s time to improve the quality of all the great looking (but poorly coded) themes out there.
So with the new year closing in pretty quick, what are other New Year’s resolutions for theme developers? Just how high are we going to set the bar for WordPress themes in 2012?
WordPress 3.3 “Sonny” is out now and (hopefully you’ve noticed) we’ve gone through all the noteworthy features in a big blog post. But noteworthy is a relative term. The real question is: which feature is the noteoworthiest to you? Or, a better question using real words would be: which feature in WordPress 3.3 is your favorite?
Vote in the poll below, and stop by in the comments to let everyone know why you voted the way you did. You can pick up to two features when you vote.
For extra bonus points this post, check back on the results of our similar poll when 3.2 was released. Do the most popular features in that poll still effect your use of WordPress?
Without a doubt one of the most interesting additions to WordPress in recent memory is the custom post type. Developers have built out all sorts of plugins and features using custom post types since they were made available to the community. In fact, I’m willing to bet a number of you folks are using them, and likely in large number.
When you vote in the poll, it would be great if you also jumped into the comments and told us about the post types you’re using (or not using) on your websites.
If you are having trouble with your WordPress website, or if you ever have a problem with it in the future, you should first check the number of plugins you are running. If it’s a big number then you’ve likely found your problem. You should trim down your number of active plugins immediately.
The best thing you can do in the future is keep that active plugin count as small as possible.
Except it’s not.
None of what I just said is true, and I wouldn’t recommend anyone follow that advice. This sort of advice is both misleading to users and contrary to the spirit of WordPress, yet a growing number of voices within the community are encouraging users to limit the number of plugins they run. It’s a bit sad, because plugins are arguably the best part of WordPress. To convey that they are dangerous in large numbers is to do a disservice to the community itself.
In reality the number of active WordPress plugins you run isn’t important, and the only thing that number can tell anyone is just how much you love plugins.
EDIT: The premise of this post is to specifically call attention to the nefarious practice of using base64_ and other php methods to hide links to 3rd party sites in a theme file. The average user has no idea what is going on: a base64_ function in a footer.php or sidebar.php file is a very very strong indicator that their theme designer is up to no good. It is only an indicator though. When in doubt contact your host or the theme designer and ask them to explain what’s going on. – strebel
We see a lot of themes at Page.ly. We see good themes and we see bad themes.
From our vantage point, hosting thousands of WordPress sites, we literally see everything.
MoPappy will host anything under the sun and could care less what app is running or what it is doing. At Page.ly we only manage WordPress, and we have a keen interest in the performance aspect of WordPress at scale.
Stop the base64_ shit. You are a douchebag if you don’t.
A two hundred character string of HTML in order to encode and hide two backlinks is 75k. That is a relatively big file, and also adds overhead to the PHP process when it is decoded every time the page loads.
I would like to take a moment to tell all theme designers, everywhere: stop the base64_encode shit. You are a douchebag if you do this.
There are more WordPress themes now than ever before, including commercial themes. More and more developers are spending their time and their talents to develop WordPress themes to sell to customers. These are great things.
But a trend that picked up steam, and doesn’t seem to be letting up, is the custom theme options screen. Instead of using the standard WordPress user interface for a given options screen, a number of developers have gone their own direction, creating custom screens with their own design and their own techniques.