WordPress images uploaded by client too large? try Imsanity

Tuesday, November 22nd, 2011

We have a few clients with teams of hundreds of writers and contributors. It's a real task to make sure nobody uploads 8 MB 4200 x 3700 images to their website.

imsanity plugin

When they do, a couple of things happen: the site slows down. Occasionally somebody manages to put the original in the post and their bandwidth goes through the roof.

While it's possible to put a hard upload limit in which defeats the heavy uploads, the errors create a lot of unnecessary administrative overhead.

Imagine that someone created a plugin which would resize huge images to the maximum size used on your site.

Well someone just did.

Try verysimple's Imsanity.

Weird but very cool branding.

By Alec

WordPress | No comments

WordPress SEO plugins review: All in One SEO, Platinum, Yoast compared

Monday, October 24th, 2011

There are a lot of SEO plugins for WordPress. "SEO for WordPress" has become a major catch phrase. Many companies now offer paid plugins which provide a lot of different options and possibilities how to further customize your site SEO to the tiniest details.

How much of it is really necessary or even helpful? Are the basic page title and meta description fields not enough? Should you pay up to $47/site/month for a plugin only to be able to set "noindex" for some of your categories? Will it help you to spend a week of sleepless nights learning what "noindex" is and when it might be helpful or are there other things you might do during that week which might do more to improve your rankings than "noindex".

Here's some alternative suggestions:

• write the four or five great articles that you've been meaning to do for months
• go out and comment up a storm on the most interesting weblogs in your sector with a link back to your site. You won't get much Google juice at point but you'll bring new visitors.
• answer some questions on related forums to the point people trust you and visit your website for additional information

We believe that every site owner and almost every author on a site should be able to do the basic SEO optimization of his or her own site. This means the SEO plugin should be easy to use and have good default options, which won't put the site at risk. Some plugins risk seriously compromising your indexation in Google just by activating the plugin. In Foliovision's opinion, this is totally unacceptable. We believe in safe intelligent defaults. There's no reason the site owner should have to worry about his or her SEO plugin.

Plugins compared in this article:

• All in One SEO Pack
• Platinum SEO Pack
• WordPress SEO by Yoast
• wpSEO
• Built in SEO functions of Thesis template
• Built in SEO functions of WooThemes - Premium WordPress Templates (we used Daily Edition)
• FV Simpler SEO

Some explanation for the terms we use in the comparison tables:

• Post - any post type, that means post, page or any custom type
• Taxonomy - any kind of taxonomy - category, tag and all the custom ones
• Section - section of a website - front page, category archive page, monthly archive page and so on

General information about tested plugins

Let's start by overview of the basic plugin attributes:

Conclusion

Interface - The vertical space on websites is precious and it also applies to the WordPress post editing screens. Why some of these plugins use so huge interface boxes, that they took over nearly all of my 1680x1050 screen (Thesis is the worst, others just like to waste a lot of space on large padding)?

Compatibility - SEO functions should not be part of any template. What happens when you need to change your site design? You waste extra time on trying to move your existing SEO data from Thesis into some reasonable plugin.

Branding - Most of the plugins put in their branding in your site HTML code. I don't understand why all the SEO plugins have to be like this, I've never seen that anywhere else! Imagine that you have a site with 20 plugins and now each of them suddenly decides that it's going to put some HTML code in the header to let everybody know what you use this or that great plugin by Mr. XY.

Basic functionality

The basic purpose of a SEO plugin is to allow easy editing of all the extra information which gets indexed by search engines:

• Title tag
  • this might be different than the post title in WordPress
  • so it's a nice way how to put in some extra keywords
• Meta Description
  • it's typically displayed bellow each link when you list search results
  • hand written descriptions are the best
  • Google shows meta description based on what keywords are using in the search query, so don't panic if you don't see your descriptions all the time
• Keywords
  • don't have so much power as they used to

The comparison table of basic SEO functions

Conclusion

Title - most plugins require title rewrite enabled to start using the field for SEO title. Title rewrite is by default "on" in most of the plugins, so what happens when you don't want to use it and you are happy with you titles as they are without the plugin? You get no custom SEO titles, or you have to tweak the rewrite to not change the structure of your titles.

Desciptions - the only thing what really matters here is the hand-written description. You don't need to auto-generate that, as search engines will do so by themselves.

Keywords - are not considered by search engines so much anymore.

SEO editing fields for custom post types are missing in Thesis and WooThemes Dail Edition.

Advanced SEO functions

Most of the plugins contain some additional options which might be and might be not helpful for your site. 

• Noindex
  • tells search engines not to put the webpage into its index
• Nofollow
  • tells search engines that the link should not influence search engine rankings of the target
• Noarchive
  • prevents content from being stored in search engine cache
• Canonical link
  • sets the URL under which the webpage should be indexed in search engines
  • WordPress takes care of this on its own for posts and pages
• Directory tags
  
  • allows you to block use of DMOZ open directory data instead of your descriptions

Conclusion

Thesis offers some crazy anti-SEO options, like making sure your front page won't get indexed. That's really a dangerous function, imagine somebody turns it on by mistake and you find out about it few months later. Your search engine rankings would probably be way lower than they used to be. If somebody is doing really a special site which needs to have noindex on front page, surely he can do it without Thesis.

WordPress SEO by Yoast offers a nice SERP preview feature, but it doesn't respect the character limits on title and description. It also has many different features, perhaps more than a SEO plugin should handle. I imagine it's hard to switch to another plugin later is you already like the provided breadcrumbs or XML sitemaps.

Miscellaneous

Here's little extra from our experience. Reasonable Default Options are one of the reasons why we started our own SEO plugin. We were not happy to tweak the settings (or plugin files) on each site over and over again.

Conclusion

Default options - When you install a SEO plugin, make sure you check how the default options change your titles. With FV Simpler SEO, you don't have to be afraid, as there is no change unless you rewrite the title yourself.

Watch out for WordPress SEO, it relies on the template to use the most correct function to display the meta title tag, which is not the case of the standard WordPress template (it uses some extra echo statements in the HTML of title tag). However - the plugin should be able to handle that without destroying the titles in the first place.

WooThemes Daily Edition put's nofollow into header of your posts by deafault. This can be turned into follow in options or changed for individual posts (not working on our test site with clean fresh WP 3.1.1.) We recently had a client install a WooTheme and deindex his site. Needless to say we helped him out of the bind but he was unnecessarily freaked out. Bad choice Woo. But then based on hard experience we don't like Woo Themes or most other commercial WordPress themes at all.

Which one is the best?

Depends. If you like to play around with WordPress and you are interested in the most finest SEO tweaks, then check out WordPress SEO by Yoast. If you are a writer, or you don't want to worry about your SEO plugin deindexing you by accident, then our FV Simpler SEO is the safest and easiest to use by far.

If you think otherwise or want to recommend another plugin, we'd love to hear what you like about the other plugin and why. If you have any suggestions on how to improve FV Simpler SEO, let us know.

By Martin

SEO, WordPress | 6 comments

Ten steps to build a great mobile version of your website

Monday, June 13th, 2011

Building mobile versions of websites was an arcane art for a couple of years. And not all that necessary as only a minority of people had smart phones and even fewer of them were using them to actively browse the web. Over the last year as the devices get better and better, more and more visitors are using their smart phones to visit websites.

If you don't already have a mobile version of your site, it's time to put one in right now. Here's how you do it, from A to Z. If the beginning seems a bit complicated, just push ahead. There's an easy point form summary at the bottom of the article.

If you have even a reasonably busy WordPress site, you need to have a caching solution in place. Without caching, you'll get your site kicked off shared hosting lickety-split or you'll cripple performance on your VPS. Visitors like fast sites and cached sites are two to five times faster than uncached sites. For WordPress, there are three major choices in caching solutions: WP Super Cache, W3 Total Cache and Hyper Cache.

For a mobile site, you need to have a caching solution which will pass through mobile clients quickly and reliably to your mobile version.

Of the three above, by far the most reliable is WP Super Cache. Donncha O Caoimh has been providing reliable code (and an almost unspellable name) for five years now. (Donate here. We did.)

WP Super Cache mostly works.
A real work horse, Super
Cachejust keeps on ticking

Sometimes high performance,
always high maintenance, deploying
W3 Total Cache is like taking the
space shuttle to the grocery store

Hyper Cache seems to work
the new kid on the block,
showing promise. We've
had issues with Hyper Cache
on some of our bare bones
Debian server.

Start by making sure your caching plugin is properly set up. These settings are not the default but are where you want to be. Donncha includes the most compatible and much slower defaults in his plugin (good idea, as new WP users can get some benefits with little risk). Here are Donncha's main instructions to get WP Super Cache to really fly and to reduce your load times for Google (good for SEO):

• Mod_Rewrite. The fastest method is by using Apache mod_rewrite (or whatever similar module your web server supports) to serve "supercached" static html files. This completely bypasses PHP and is extremely quick. If your server is hit by a deluge of traffic it is more likely to cope as the requests are "lighter".
• If you are not using legacy mode caching consider deleting the contents of the "Rejected User Agents" text box and allow search engines to create supercache static files.
• Likewise, preload as many posts as you can and enable "Preload Mode". Garbage collection will still occur but it won't affect the preloaded files. If you don't care about sidebar widgets updating often set the preload interval to 2880 minutes (2 days) so all your posts aren't recached very often.

Now it's time to get ready to set up the mobile version. First you need to make a choice on building your own mobile solution or starting with a mobile plugin. We recommend using a plugin as starting from scratch is a lot of busy work. There's really not all that much room 320 x 240 pixels for creativity (the exception proves the rule guys) so you may as well set up something attractive and standard and business-like. There are a couple of good plugins out there to give you a running start.

Free and slightly unreliable: WP Mobile Pack.

WP Mobile Pack works or broken

Paid and very good but with some issues outside of Apple's i-universe: WP Touch Pro. Here's a WP Touch Pro feature chart (there is/was a free version as well).

You'll want a full list of user agents for which you will serve the mobile version. Next, make sure the list of user agents match in both your mobile plugin and in your cache plugin.

Here's a list to match WP Super Cache's list of mobile user agents which you can copy and paste into the user agent theme preferences in WP Touch Pro.

Mobi
Mobile
MMP
240x320
400X240
AvantGo
BlackBerry
Blazer
Cellphone
Danger
DoCoMo
Elaine/3.0
EudoraWeb
Googlebot-Mobile
hiptop
IEMobile
KYOCERA/WX310K
LG/U990
MIDP-2.
MMEF20
MOT-V
NetFront
Newt
Nintendo Wii
Nitro
Nokia
Opera Mini
Palm
PlayStation Portable
portalmmm
Proxinet
ProxiNet
SHARP-TQ-GX10
SHG-i900
Small
SonyEricsson
Symbian OS
SymbianOS
TS21i-10
UP.Browser
UP.Link
webOS
Windows CE
WinWAP
YahooSeeker/M1A1-R2D2
iPhone
iPod
Android
BlackBerry9530
LG-TU915 Obigo
LGE VX
webOS
Nokia5800
iPhone
iPod
incognito
webmate
Android
dream
CUPCAKE
froyo
BlackBerry9500
BlackBerry9520
BlackBerry9530
BlackBerry9550
BlackBerry 9800
BlackBerry 9780
webOS
s8000
bada
IEMobile/7.0
Googlebot-Mobile

This list doesn't include the WP Super Cache substrings as they are too short and dangerous to use in WP Touch Pro as WP Touch Pro matches substrings throughout the user agent, while WP Super Cache matches substrings against just the beginning of the user agent. Pasting the full list of substrings into WP Touch Pro makes full Safari and Opera display mobile versions (they match on "tosh"). We'll keep working on a better version of mobile agents for WP Touch Pro and post it here.

If there's a problem, all that will happen is that mobile user will get the standard site uncached.

Here's the WP Touch Pro theme preferences where you should paste the user agents above:

WP Touch Pro user agents

There's some discussion about whether to give a full site or the mobile site to an underpowered device which can't really handle the full WP Touch experience.

In principle these weak web browsers like Opera Mini 4 have special mobile modes to deal with standard sites, doing the reformatting themselves. But the reformatting will be easier if they are starting from WP Touch's advanced mobile version.

The difference won't be that great.

Here are some screenshots of WP Touch Pro iPhone version and Opera Mini minified version.

Opera Mini WP Touch Pro version
Not bad for a start if a bit too wide

Opera Mini WP Touch Pro filtered mobile
that's more like it and includes site colours

The minified version of the normal website through Opera's built-in mobile proxy is not much worse but the navigation (not shown) is much more difficult. And you have to rely on the end user to turn on minified versions. Relying on the end user is a fool's game.

Opera Mini full site Opera mobile proxy filter

WP Super Cache handles mobile settings a bit differently than W3 Total Cache and Hyper Cache. WP Super Cache doesn't let you hand in a list of mobile devices but generates it itself and puts it in .htaccess along with the basic rewrite rules. Here's what the list looks like:

RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC] RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800|iPhone|iPod|incognito|webmate|Android|dream|CUPCAKE|froyo|BlackBerry9500|BlackBerry9520|BlackBerry9530|BlackBerry9550|BlackBerry\ 9800|BlackBerry\ 9780|webOS|s8000|bada|IEMobile/7.0|Googlebot-Mobile).* [NC] RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC]

The advantage of this system is that it makes bypassing normal processing ultrafast (the movement happens at an OS level, rather than on invoking PHP).

It also means you as the end user don't get to fiddle endlessly with what devices to include. You'll have to count on Donna to choose the right ones.

Which it seems he does.

As you can see, it's very complete, including iPhones, Androids, Palm, Blackberrys, Palms, Nokias, Symbian.

On the other end though, if you are using WP Touch Pro, you'll have to give it a list of devices. Look out for versions under 2.2. The Skeleton template 1.0.8.1 does not handle blackberrys very well. Skeleton Template 1.2 definitely does, so if you're having trouble, make sure to upgrade WP Touch Pro to the latest version and then update your template.

Both Hyper Cache and WP Super Cache have built in compatibility with WordPress Mobile Pack. If you haven't already jumped on the WP Touch Pro bandwagon, WP Mobile Pack might be worth a try as it's already fully integrated to two of the top cache plugins and free. Unfortunately, WPMP appears to have some compatibility issues and is not kept up to date. You'll have to do some digging of your own to get it to work properly.

Once you are up and running, you'll want to test your settings. Here are the easy tests. Opera has a desktop emulator for their advanced mobile browser and an online java version for Opera Mini.

http://www.opera.com/mobile/demo/
http://dev.opera.com/articles/view/opera-mobile-emulator/

Test for iPhone with Safari by enabling the developer menu and then reassigning user agent. On a Mac, I recommend Keyboard Maestro to set up a hot key on the menu command (usually application menu items can also be done in keyboard section but it's a bit trickier). I've assigned command-U and it really speeds up testing for different user agents. You can also then use Safari to test for Blackberry user agents and other exotica.

Ideally you'd have at least a few real mobile devices with which to doublecheck your site. An iPod Touch is a great inexpensive stand-in for an iPhone/iOS. Opera Mini will install into most devices in parallel with the main browser. Make sure to navigate around to be sure everything is working.

When you know that your mobile versions are making it through you'll want to sit down and have a think about what someone visiting your site on a mobile browser would want to see (insurance calculator, mortgage calculator, listings search, catalogue or weblog posts) and put those front and center. You might even want to remove large sections of your site which won't display well on a mobile device from mobile navigation.

With multiple mobile device formats (think iPad), WP Touch Pro has alternately display models which it handles internally.

So to recap here are the steps.

How to Quickly Build a Great Mobile Version of Your Site

1. Put together a list of user agents which you would like to show a mobile version (the longer the merrier, there's no sense in being parsimonious here).
2. Set up your cache plugin not to pass through mobile devices (not to show cached full pages). Recommendation: WP Super Cache which comes with baked in list.
3. Set up your mobile plugin to serve a mobile version to those same user agents (if you miss a few, no worries). WP Touch Pro recommended.
4. Check appearance with Safari in iPhone mode and with Opera Mini online emulator.
5. Tweak appearance to match site colours.
6. Tweak menu items to show what is important for mobile and hide what is irrelevant for mobile or will not display well.
7. Remove mobile plugin branding (branding on commercial plugins/themes is obnoxious: are you listening Brave New Code?).
8. Add a large 512 pixel icon for people who bookmark, create automatic apps in Safari. (WP Touch Pro feature).
9. Test that mobile versions are being served up to the principal user agents and browsers with Safari.
10. Test on whatever real devices you do have.
11. Send your client to visit the site on his or her mobile device (remember what I said about adding Blackberry user agents: this is the moment of truth, an astonishing number of clients will have Blackberrys).
12. Prepare to do this for all the rest of your clients.

Every site should have a mobile version now. WP Super Cache and WP Touch Pro make it very easy for developers to provide high quality mobile versions at an affordable price. There's no excuse not to offer clients an affordable mobile version of their site.

By Alec

SEO, WordPress | No comments

WP e-Commerce 3.8 Review: Why WP eComm code is still broken

Tuesday, June 7th, 2011

wordpress 312 wp ecommerce 383

This week I had an interesting conversation with Dan Milward, the marketing guy and co-founder of the WP e-Commerce WordPress shopping cart plugin.

Let's start with the facts. WP eComm is now on version 3.8.4. Currently, the reports in from front line users are: 4 say it works, 12 say it's broken.

Why People Hate WP eCommerce so much

Dan told me that sources inside Automattic had revealed to him that in the past as soon as Instinct Entertainment publish a new version there are five reports of the plugin being broken on current WordPress. His sources then erased that feedback.

This is a very bad sign: when you need insider help to erase negative feedback. Not the first time I've seen this happen at Automattic: Mark Jacquith has had to warn plugin database maintainers off deleting plugins which compete with their friends plugins. Second bad sign: people who hate your plugins enough to wait for a new version to mark it as broken.

Dan manages it. There are three strategies he uses which bring Instinct Entertainment to such grief.

Keep reading WP e-Commerce 3.8 Review: Why WP eComm code is still broken

By Alec

Internet Marketing, WordPress | 16 comments

Drupal vs Joomla vs WordPress: Developer’s Perspective

Saturday, April 2nd, 2011

In a CMS discussion group I belong to, someone recently asked:

Is there someone with experience with Drupal, Joomla/Mambo and WordPress who can tell what the differences are? What are the strong and weak points?

For better or worse, I am that person. So here's my summary of the advantages and disadvantages of each of the above CMS platforms.

Drupal

Advantages

• Very clean core code.
• Good project leadership from Acquia.
• Some very good developers available for hire.
• Fewer clowns available for hire (you can either code Drupal or you can't, it's harder to fake it).
• Can be made very server efficient in the right hands (scaleable).

Disadvantages

• Less ready made drop-in plugins. You're going to  have to get your hands dirty almost every time.
• More imposing default user interface.
• Fewer developers.
• More expensive developers.

Joomla/Mambo

Advantages

• Good menu system.
• Strong static page structure (cf. weblog).
• Built-in membership/community features.
• Long time on the market.
• I'm searching here.

Disadvantages

• Built-in performance pretty sluggish/clunky.
• Horrid built-in URLs.
• Weak weblog section.
• Hard to theme. A Mambo/Joomla site looks like Mambo/Joomla, like it or not.
• Crappy built-in SEO. Leading SEO plugin belongs to a very peculiar developer and is encrypted (have fun repairing the SEO plugin, we reverse engineered and decrypted it for our site to make our changes even after paying for it).
• Nasty, nasty core code. Very difficult to fix broken items.
• Fractured community (never healed after Joomla/Mambo split back in 2006).
• Most good plugins are pay.
• Rather mediocre developers. Anyone who likes to code in Joomla/Mambo in 2011 ought to see a psychiatrist.
• Developer pricing is all over the map as there are many old-school Mambo/Joomla developers still ought there churning out convoluted future-resistant code quite affordably.

WordPress

Advantages

• Huge community.
• Easy to optimise for performance thanks to Donncha O Caoimh and Frederick Townes. Great work guys.
• Easy to theme in a unique way. A WordPress site does not have to look like a WordPress site.
• Great plugin architecture.
• Plugins for everything.
• Lots of great professional developers.
• Fast development cycle. Improvements every year.
• Active leadership from Automattic and founding team. Particular thanks to Mark Jaquith for keeping the community running with less nepotism and more fairness than most collective human endeavour.

Disadvantages

• Fairly weak core code (in comparison to Drupal, but not Joomla!) but core getting better every year.
• Lots of really crap faker developers in the pool who couldn't build a working website to save their mother's life.
• Lots of popular but seriously broken plugins which will cripple your website performance forever and make it nearly impossible for you to cleanly upgrade (NextGen Gallery, I'm looking at you but not just you).
• Really crappy commercial themes which are heavily marketed but compromise your ability to either upgrade or switch themes and compromise performance for the life of your site.
• Weak static page management without adding plugins. Easily fixed with said plugins.
• Too fast an upgrade cycle. You have to keep upgrading your site, whether you like it or not, for security reasons. There are no security releases only new versions. Feel the pain for a commercial site with running a full complement of plugins. Corollary: choose your plugins and plugin developers very, very carefully for cleanliness of code and frequency of update.

Conclusion

For a very large commercial project, I can see a justification for choosing Drupal. On a big project, most of your expense will be custom development anyway - everything has to be optimised and integrated - so you don't much care one way or another about a myriad of plugins which you will probably not use. I still wouldn't make that trade-off: slightly better core code for a vast pool of community contributed code. But it's a defensible position.

Joomla/Mambo should die a violent death. We did our first CMS project in Mambo and last year redeveloped a couple of existing sites in Joomla. Our best developers - very platform agnostic - threatened to quit if I accepted anymore Joomla work. Such crappy, convoluted spaghetti code they'd never seen. And these developers have had ample chance to see the worst side of WordPress.

The only justification for a site in Joomla/Mambo is that it's legacy (i.e. you already did a lot of custom development on it six years ago and don't have the budget to migrate) or that you are part of an international network standardised on Joomla/Mambo and the mothership discourages anyone from leaving the central platform (our client's situation). For everyone else, just migrate out and count your blessing that you got your site out alive. Enjoy the fresh air and clean code of WordPress (or Drupal).

WordPress is the platform of choice in my opinion for the small, medium or large business. Whatever holes you can find in WordPress (editorial management process, page management, ecommerce, membership site) are easily solved with high quality plugins.

The cool part about WordPress is that the core is kept clean so that you aren't forced to load code you don't need if you want a simple weblog. Thus WordPress can be a weblog, a corporate information site, a membership site, a store or an international news network.

We regularly develop advanced real estate sites in WordPress, maintain a very sophisticated insurance site, have developed elaborate furniture rental systems and develop the most delicious cooking sites as well as gorgeous online literary reviews. Not to mention political, news and law sites. All in WordPress.

The danger with WordPress include the overhyped commercial themes which don't solve your problems but pretend to (I'm looking at you DIYthemes.com and Thesis, WooThemes and ElegantThemes). A related danger are the weak developers and hangers on who have infested the huge WordPress community and enthusiastically give bad advice, whether about SEO or gallery plugins. These clowns will happily break your website for pay or into a defective by design commercial theme. Forewarned is forearmed.

Just like any other serious professional endeavour you need steady hands on deck when you want to take your site to the next level if you want to maintain performance, appearance and compatibility. Once you have substantial traffic or need ecommerce, WordPress is no longer a DIY venture for the non-programmer.

We personally recommend people start a new site on WordPress.com unless they are developing for an established business. Once you have an audience or a functioning business, self-hosted WordPress is the way to go. Even the sky is not a limit. There are few sites we could not develop better and faster in WordPress.

By Alec

Business, WordPress | 194 comments

What’s wrong with commercial WordPress Themes: WooThemes vs ElegantThemes

Monday, March 28th, 2011

As a web development company, we build a lot of sites. Many of the sites are true custom development jobs, starting from TwentyTen or Cutline for the base template files. That's the right way to build a site, as you'll quickly see.

But often our clients can't afford custom development. So we bought developer licenses to WooThemes.com and ElegantThemes.com and thought we were set. While Woo are as a group not very refined and seem to be getting less so every month, ElegantThemes offers many really well-designed themes.

All these paid templates with extensive configuration dialogs (WooThemes, Elegant Themes etc.) usually look nice and are a great alternative if you have little money to spend, little or no template programming skills and you want to be able to tweak how your site looks like.

Not so fast.

Not only do the handy internal configuration tools for "quick customization" give clients every opportunity to break their own sites, they carry a lot of overhead. Your CSS files will be bloated as you are always offering the code for two column, three column and six or seven different colours.

But there's a limit all this configuration options have and you can't get beyond that limit without changing the core files of the template, so if you want to do some serious customization, and not just change the colors, there's nothing good about the configuration screens.

There's a lot of talk about how professional paid themes are in comparison to free themes. It's not what we've found. Cutline, Twenty Ten and Oulipo are all much better coded than any theme we've found at WooThemes or EleganThemes.com. You can't just choose any free theme but a good one looks to be better than a paid theme. There's a couple of reasons. First, a good free theme is not trying to be everything to everyone so most don't suffer featuritis. Second, a free theme is often coded at leisure and only released when it's ready. Paid themes are a commercial product and the more themes a developer can cram out quickly, the more he earns.

Featuritis often means that extra functionality is jammed into the functions file which should be taken care of via plugins. If you add extra functionality via plugins, it's easy to switch themes. If all your custom functionality is in the theme, your website is a prisoner in a pretty gilded cage. We can help you move out, but it's a task.

Here are some concrete case studies of our latest misadventures with paid themes. Read and weep for all the unfortunate site owners who are enduring slow site loads and crashing shared hosting the world over with commercial themes.

Daily Edition by WooThemes - Premium WordPress Templates

When building a site or a plugin, we always check the number of database queries made when displaying the index page, archive page, single post and so on. That helps us discover any bad (by "bad' I mean not necessary) database queries and bad code inside the plugins or templates before a database server goes down because it's overloaded - nothing special on shared hosting environments, it even happens for well optimized and cached sites which have a bad luck of being too popular.

To do this kind of audits use WPDB Profiling plugin for WordPress. It shows you all sorts of information in the site footer and you can turn it on and off as you like.

We built a website with Daily Edition template and when it was all ready to go live, we discovered that it has 85 queries on every page load! It took us a while to figure out where the problem is and it still sounds a bit weird: the number of queries dropped to around 65 after we turned on the "Hide SEO custom fields" option:

Weird Daily Edition Options

How can displaying the SEO custom fields on post edit screens take extra database queries?  We use FV All in One SEO Pack plugin for SEO, so we don't have these problems. But who would guess that turning off unused features can speed up your website so much?

The updated version, which was released shortly after we found these issues has around 60 queries, so this problem appears to be fixed. However, there are more issues. Let's go deeper into PHP here:

The Tabbed widget of Daily Edition is taking too much queries. For example, here's the original popular posts code:

$popularposts = "SELECT ID,post_title FROM {$wpdb->prefix}posts
  WHERE post_status = 'publish' AND post_type = 'post'
  ORDER BY comment_count DESC LIMIT 0,".$pop_posts;
$posts = $wpdb->get_results($popularposts);
if($posts){
  foreach($posts as $post){
    $post_title = stripslashes($post->post_title);
    $guid = get_permalink($post->ID);
    ...
    (display code here)
    ...
    woo_get_image('tiny',35,35,'thumbnail',90,$post->ID,'src',1,0,'','',true,false,false);
    ...
  }
}

That code takes 2 addition database queries for each related post!

Here's how we rewrite the function to avoid that:

1. use the WordPress function to get the posts - don't use direct SQL commands on wpdb object if possible
2. use global $post

global $post;
$tmp_post = $post;
$myposts = get_posts('showposts='.$pop_posts.'&orderby=comment_count&order=desc');
foreach($myposts as $post) {
  ...
  (display code here)
  ...
  woo_get_image('image',35,35,'thumbnail',90,$post->ID,'src',1,0,'','',true,false,false);
  ...
}
$post = $tmp_post;

This code takes only 1 query for 1 post and if some of the posts already appear on the page, they are not queried again, thanks to some internal WP caching mechanism. Notice that we store the original $post object in a variable and then put it back.

Going through various templates, you will be probably able to find more glitches like this one.

Delicate News (version 2.0) by Elegant Themes

The template looks great. We do some modifications based on client's requests and everything is fine. It runs on development site with a real set of data copied from the live site, so we should have a good idea about it's performance. The number of database queries is perfectly normal this time.

Delicate News demo template

The problem appears as soon as we take the new site live. There is some inefficient code, as the site runs out of PHP memory. So we quickly troubleshoot the issue, until we found that it's in the template:

Delicate News template tries to use a better count of comments posted to an article than WordPress does and it's running that algorithm each time a post is displayed. On the index page, we display around 10 posts plus this site has a lot of comments - put these two things together and your site goes down like a rock.

Normally WordPress counts number of comments for a post only when a new comment is posted - check out wp_update_comment_count_now in wp-includes/comment.php. Then it stores that in database (wp_posts table, comment_count field). It even provides a plugin hook called wp_update_comment_count.

Here's where the dangerous function is hooking to the standard WordPress template functions:

Line 32 in DelicateNews/includes/functions/comments.php:

if( phpversion() >= '4.4' ) add_filter('get_comments_number', 'comment_count', 0);

Comment out that line and your site will run again:

//if( phpversion() >= '4.4' ) add_filter('get_comments_number', 'comment_count', 0);

So even if you check the number of queries, you are not completely safe. An option to disable a function like this one would be a nice addition to the template configuration screen, or better - a complete rewrite of that function. This is an example of a extra template functionality which does not work as well, at least not in all cases.

We are not saying, that these templates are bad and you should not use them, but if you do, you better check if they are alright, before you use them on some project, as you can't be really 100% sure they work flawlessly in all situations - specially after some tweaks.

Checklist for template checks & optimization

Here are some general steps we follow

• Use WPDB Profiling plugin for WordPress,
• Check out the output of WPDB Profiling and look what takes extra queries - you should be able to see plugin functions
• Make sure you test the template as both logged and non-logged in (with no cache, make sure you enable WPDB Profiling for non-admin users when doing this)

Check following items

1. Index page
2. Archive page
3. Single post
4. Single post with a lot of comments
5. Page

To isolate the problematic parts you can

• Disable plugins
• Disable sidebar widgets
• Disable whole sidebar
• Disable any unusual part of template (front page posts slider, advanced navigation, ...)

Excerpt from WPDB profiling analysis. Going through this list can save you a lot of trouble.

Here's a sample pingdom.com site load time report on two minimalist sites, one using a non-repaired paid theme, one using a custom theme built on cutline. One takes 20 seconds to load, the other 4 seconds to load, both on clean fast servers. Guess which one is which.

wordpress cutline custom theme load times

wordpress paid themes load time

Recommendation

Where possible avoid paid themes at this point. They are all top-heavy. You are much safer starting with Twenty Ten or Cutline. If you must use one, hire a good developer to clean out the theme before going live.

By Martin

WordPress | 48 comments

How to install WordPress on H-Sphere – Cartika hosting

Thursday, July 16th, 2009

Installing WordPress to Cartika hosting is no different than installing it on any other web host. The focus of this article is in showing the specific sequence of steps which needs to be done in order to quickly and properly install WordPress in Cartika's Control panel.

Keep reading How to install WordPress on H-Sphere - Cartika hosting

By Martin

WordPress | 5 comments

WordPress SEO and Dedicated IP’s

Tuesday, July 14th, 2009

One of our Typepad to WordPress clients would really like to rank higher with her nice new WordPress weblog. She is hosted at Bluehost.com. Her IP number is 66.147.242.185. I ran a quick check to find out what other websites are on that IP.

Here is just a partial list of her neighbours:

Keep reading WordPress SEO and Dedicated IP's

By Alec

SEO, WordPress | 2 comments

Typepad Export Options: Congenial Lies from SixApart’s Anil Dash

Tuesday, May 12th, 2009

Last Friday, Anil Dash and I had a delightful conversation. I mean that delightful. Anil and I share many of the same passions: the web, media, user interface, weblogs.

Anil Dash of SixApart / Typepad by Joi Ito

Anil is a very congenial sort and was a prominent early weblog writer. He is now both a Vice President at SixApart and head evangelist for Typepad.

I have a deep and intimate acquaintance with SixApart's Typepad service, as a founding user in 2003 and now as the founder of the premier Typepad to WordPress rescue service.

The starting point of our call was clear. Anil is annoyed about my regular unfavourable postings about Typepad. I don't know if SixApart is annoyed about our rescue service itself - we've moved some pretty high profile sites in the last few months, some of which I am not even at liberty to disclose their names.

Keep reading Typepad Export Options: Congenial Lies from SixApart's Anil Dash

By Alec

Business, WordPress | 9 comments

The ideal WordPress comment code

Wednesday, April 30th, 2008

When an article is written, various comments from other people may hold great deal of information regarding the topic. That's why it's very important to open discussion on web pages. In our company we mainly use WordPress, so I'll explain how to properly set up comments on WordPress. Our publishing platform Foliopress is based on WordPress version 2.2.3, so screenshots and settings will apply mainly to these versions, but other versions are surely, not so different.

First order of business is allowing discussion in wordpress. Settings for this are in Administration back-end in Options->Discussion. For our company these settings are preferred:

Wordpress discussion options

Information on these settings (from WordPress developers) are here.

Keep reading The ideal WordPress comment code

By Peter

WordPress | No comments

SBI (Site Build It) versus WordPress: How to Structure a Website

Monday, April 28th, 2008

For years, I've been on the Site Build It list. SBI is the creation of the rather annoyingly gushy Ken Evoy who never stops his carnival barker cries about his one-stop-site-creation tool. 

Ken Evoy Pumping Site Sell

Evoy's been at it since the bad old days when the internet was a mess and Site Built It! did have the advantage of actually getting a website up in some form - easier than coding html from scratch for the neophyte.

Throughout SBI's history, Evoy has shrieked about his process and his proprietary tools. On the surface, a clear process and proprietary tools are a good idea. Probably worth the price of admission (or so I thought at the time). The issue with the proprietary tools (which otherwise might be a good deal) is that you can only use them a little bit. Come and play for one hour per week, see you next week. Not exactly inviting brainstorming or creativity.

In contrast, the indepdendent expensive (many of which are free) tools Evoy condemns let you use them as much as you like once you find them.

Keep reading SBI (Site Build It) versus WordPress: How to Structure a Website

By Alec

Internet Marketing, WordPress | 18 comments

SEO Images: Optimising for Google Images

Wednesday, March 26th, 2008

We've been properly labelling and tagging our images for years. Some of our websites get most of their visitors from Google Images.

Google Images is the greatest SEO reserve left in the world. Chris Silver Smith of Netconcepts let the cat out of the bag in 2006 and told the whole world about optimising for Google images. But it's hard work optimising images for Google Images and most webmasters still can't be bothered. There's still gold - or at least visitors - in those hills.

As Chris didn't cover the technical details in-depth, here's a step by step guide for optimising your images for Google images.

Most websites publish their images like this:

<img src="/images/192a/986943.jpg" alt="image">

Where's the problem? Missing height and width, meaningless directory name, meaningless file name, generic alt tag.

Here's what a properly formatted image should look like:

Keep reading SEO Images: Optimising for Google Images

By Alec

SEO | 33 comments

Why WordPress? – the Tumblr Question

Saturday, January 5th, 2008

I just read the strangest apologia for a new service: Uh, why’s the official Tumblr blog on WordPress? (broken link - http://blog.davidville.com/2007/02/23/why-wordpress/#comments)

Simply - all the CMSy stuff it comes with. Blogs are an awesome platform. WordPress lets our entire staff contribute to the same blog, maintain tags and slugs, save and give feedback on drafts, upload and store media, back and forward publish posts, group our archive by month, lets our audience comment, lists trackbacks, et cetera, et cetera. It’s awesome! Blogs rock! But we knew this. WordPress is the perfect way for a business like ours to communicate with our audience.

Sounds good to me. David Karp goes on to write about the advantages of Tumblr: "posting with zero obligations, little or no comment". Great for wisecracking, difficult for communicating.

Keep reading Why WordPress? - the Tumblr Question

By Alec

WordPress | 4 comments

How to Comment Code in WordPress Templates

Sunday, December 9th, 2007

I've spent a lot of the weekend working on a Vancouver real estate website which we converted to WordPress last year.

(Don't feel too sorry for me, the rest of the weekend I spent with my girlfriend.)

There were a bunch of issues in the PHP code which I couldn't solve myself so I had to leave my efforts there for the designer.

I was unable to comment it out with html comments (what I usually do). PHP comments wouldn't work either, so I put some serious research into how to comment PHP properly.

It turns out there is a simple but very effective trick:

<?php /*
comment
*/ ?>

I recommend reading the full article on How to Comment Code in WordPress templates if commenting WordPress templates is something you need it do occasionally. It will save you a lot of time.

I am sure much of this applies to our friends over in Mambo/Joomla and Drupal land.

A tip of the hat to My Digital Life for his article - Comments and Comment Blocks in PHP.

By Alec

WordPress | No comments

Lost WordPress Admin Password and Email? How to get back into your weblog…

Friday, October 19th, 2007

What should you do if you've forgotten or lost your WordPress Admin password?

Step one of course would be to fill in your username and your email into the lost password form.

But what if you don't know one of either your username or your email?

Are you out of luck?

Not if you have admin access to your server.

First things first.

1. login to your server admin account (cPanel, Hsphere, Plesk, etc...)
2. open up PHP MyAdmin (see your host's help file)
3. open up your WordPress weblog database
4. don't panic when you see the complicated screen
5. click on wp_users in the left hand column
6. choose browse from the top menu
7. you will see all your users with usernames and passwords
8. go back to the login screen
9. request a new password
10. if necessary modify the email to one which will come to you

If you want to make your life miserable you can replace the hash key instead and login directly. But why bother when you can just go back to using the standard interface.

I'm sure I've saved at least one person a call to his or her server admin with this info.

Enjoy posting in your newly recovered WordPress weblog!

By Alec

WordPress | 51 comments