Don’t Let Support Get Lost in Translation

I was lurking in the #wordpress support channel on IRC last night and noticed somebody getting the shrug off for a support issue because he wasn’t a native English speaker.

Now, the advice I initially gave him was ridiculed by others in the channel as stupid, but without really knowing the guy’s issue I was doing the best I could with what I could decipher from his broken English. And its not like anybody else was giving it a go, so I invited him into a private chat to get a better feeling for his problem.

We went round and round, him explaining in broken English and me trying to be as clear and concise as possible. Finally, I offered to use Google Translate so he could explain in Portuguese. He was floored that I would do this, but we tried it anyway. Turns out, it made all the difference in the world.

We went back and forth like that, me doing hyperspeed copy pasta with Translate, him doling out the Portuguese and after a few minutes we managed to get his issue resolved.

The problem as I see it is this: WordPress is all about contribution, whether it’s code, knowledge or time. Turning new WordPress users off by turning them away doesn’t really garner much support for the community, especially with the non-English-speaking crowd (who by the way make up about 2/3 of the worldwide community!).

Many users who seek support in IRC support are novice-level and they’re just trying to figure things out. It really doesn’t take all that much extra effort to meet them half way.

Fun?! with Subversion and WordPress

OK, so I’m a bit of a Cowboy Coder and after a session with Mark Jaquith the other week at WordCamp San Francisco, I’ve been mildly shamed into learning what I need to start using version control.

At home I have a pretty high-powered gaming PC and when I’m on the go I’m using a MacBook Pro. So the first thing I did using a (somewhat old but relevant) guide by Westi to setup TortoiseSVN on my PC and started hooking up my WordPress Trunk build repo using SVN. Prior to now, I’ve always sort of done it the hard way, e.g. a whole lot of downloading and ftp-ing a couple of times a week.

First impression: SVN is kind of complicated at first, but once you sort of get the hang of it, it’s a heckuva lot less work overall. After I got the hang of doing checkouts, updates and commits with my local repo, I got a little more ambitious and set out to get SVN setup on my VPS.

After an install, uninstall and re-install, I finally got all of the ra_* (See: Repository Access) modules in place that would allow me to checkout code from http & https URLs. Thanks to a very helpful guide by Otto, I managed to setup svn:externals and perform a couple of checkouts and updates directly from the WordPress trunk and my VPS. Pretty neat.

NoteToSelf: Next time: Read about it, read about it, try, fail, try, fail, fail, WIN.

WordPress On the Brain after WordCamp San Francisco

Wow, OK, so this is a random collection of thoughts after #WCSF last weekend.

Never before have I dreamt, thought about or immersed myself in so much WordPress in such a short amount of time.

#WCSF proved to be ample opportunity for networking, learning, eating and traveling. I met a lot of really passionate people out there from bloggers to developers, designers, entrepreneurs, web hosts and many of the people behind the mammoth that WordPress has become. It really was a fun time.

So here’s a shoutout to Adria Richards, Theme.fm, bluehost, Dream Host, the guys over at Media Temple, Matt Mullenweg, Brad Williams, Jeff Kropp, Lou Anne McKeefery, Pete Mall, Brian Tickler, Dan Ross, the guys over at StudioPress, Adam Chew, Linda Sherman and many others.

Probably the best-spent 3 days I’ve had in the 3 years I’ve been developing and designing for WordPress. Until next time!

WordPress 3.3 Could Improve Child Theme Integration

According to a recent WordPress trac ticket, theme authors could soon be rewarded with a little nugget of functionality that would make using child themes much more extensible.

The ticket suggests introducing a function that works similarly to locate_template(), but rather than returning the path of the file (in the parent theme only), it would return a URI to the file, thus allowing a child theme to override the parent’s .js, .css and even image files. The proposed function is called locate_theme_file().

According to the suggested patch posted by johnbillion, this is the current method for loading template files in parent themes only:


wp_enqueue_style( 'dark', get_template_directory_uri() . '/colors/dark.css', array(), null ); 

If locate_theme_file() is introduced, we could instead see functions like these:


wp_enqueue_style( 'dark', locate_theme_file( 'colors/dark.css' ), array(), null ); 

wp_enqueue_style( 'bar', locate_theme_file( 'bar.css' ) );

<img src="<?php echo locate_theme_file( 'icon.png' ); ?>" />

locate_theme_file() would automatically load any of these files via the child theme, BEFORE the parent. Pretty neat huh?

Up to this point, child themes could only override a parent theme’s template files. If theme authors are rewarded with the ability to enqueue many more types of files at the child theme level with this much ease, I anticipate seeing some really exciting new uses for child themes emerging.

Why Joining the WooThemes Theme Club Was the Smartest Decision I Ever Made

Photo by Flickr/Titanas. Used with permission under Creative Commons License.

I first dipped my toe into the WordPress ocean a few years ago.

My first experiences in the late ’90s with LAMP-based systems with popular bulletin board system phpBB gave me a pretty solid foundation for my introduction to WordPress.

At first, – like many other probably – I didn’t have any idea what I was doing, but I had this idea that if I learned the WP core and how themes worked to expand and enhance functionality of a WordPress installation, that the sky would be the limit. It was.

And so I started off like many others have, with a skeleton theme and a lot of curiosity. I soon found though that at its vanilla state, WordPress is pretty darn complicated. This realization led me to look for a good solid framework. That’s where WooThemes comes in.

Disclaimer: I’m a WooThemes Theme Club member (and evangelist) though I’m not affiliated with them in any way and you’ll never see any affiliate links on my blog.

The thing about WooThemes is that they’ve been at it a few years and they’ve got their ducks in a row. And their framework is consistent.

What I’m talking about with “framework”, is how they handle in-theme functionality and element display across the board. Their code is organized, well-commented and documented. And the format is pretty much the same throughout their entire theme library.

So I do some WordPress design here and there (shameless plug) and for most of my projects I turned to WooThemes for inspiration. I think it’s just that I’ve grown accustomed to the ease-of-use and functionality that comes with a WooThemes design, so when I branch out to other companies and discover the same level of quality doesn’t exist in most other frameworks / themes, I’m disappointed.

So for more than a year now, I’ve been a member of their theme club. It’s definitely an investment at the outset. The pricing starts at $125 up front to join the club, with a $15 monthly maintenance fee after that. I decided having PSD’s was worth it from a development point of view though, so I sprang for the Developer subscription. With a $200 up-front fee and $20 monthly maintenance, it is the best investment I’ve made since I started working with WordPress.

WooThemes’ support is unparalleled and you’ll always be in good hands with co-founders Magnus Jepson, Mark Forrester and Adii Pienaar. They’ve also got a host of “WooNinjas” helping in the forums to make sure everybody is taken care of.

And because I design themes that stay largely in the vein of WooThemes’ bread and butter (magazine, business, personal and portfolio themes), I’ve come to rely on their monthly new releases. It’s always a pleasure to see what they come up with next.