That is for developers who have led a virtuous life.

In the real world, redevelopment usually means that the names and locations of URLs change significantly. In this world, you are mapping 500 pages of .aspx pages, numbered like “content/30593″ (if you are lucky) to your new WP/Drupal environment.

Still in this ever-so-real world, you are also redirecting 3 other sites that your client wants to collapse into a single site. The goals is this process are:

• to make the user experience as seamless as possible so that they are directed from old, cached Google links, links on existing sites or browser bookmarks to an appropriate page, without hitting 404 pages, which are frankly a buzz-kill.
• to let search engines know where to find the new pages you’ve created, and avoid losing link juice built up over the months/years.

This process is very similar for WordPress and Drupal. Today, I’m going to talk about my experience doing this for a WordPress client.

The assumptions are:

• You have an installed WordPress instance with cPanel access.
• That your site is developed and ready to go live.
• That you are changing hosts. If not, you can ignore step 1 below.

The steps I took are:

1. Update the nameservers for your old domains to point to your new host
2. Add the new domains as parked domains in cPanel
3. This may automatically add some rewrite rules to your .htaccess. In my case, it added it to the wrong place. The rules were put at the end of my .htaccess, when they should be near the beginning. Rewrite rules are executed in order – if a line above it is executed first, the line you’ve written may not even been triggered. That’s why I changed the order.This is what my modified .htaccess looks like:

   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   Options +FollowSymLinks
   RewriteEngine On
   RewriteBase /
   
   # Promoted parked domain redirects to top -
   # they were added to bottom of redirect rules
   # by default, so they weren't being triggered
   RewriteCond %{HTTP_HOST} ^oldsite.com$ [OR]
   RewriteCond %{HTTP_HOST} ^www.oldsite.com$
   RewriteRule (.*) http://newsite.com/$1 [R=301,L]
   RewriteCond %{HTTP_HOST} ^oldsite2.com$ [OR]
   RewriteCond %{HTTP_HOST} ^www.oldsite2.com$
   RewriteRule (.*) http://newsite.com/$1 [R=301,L]
   
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   </IfModule>
   # END WordPress

4. Go to your homepage and make sure your site actually still works. If it is not loading or is returning errors, you probably have an error in your .htaccess.
5. Install the “Redirection” plugin, which allows you to manage the redirections from the WP interface. The regular expression support will be very helpful for URL patterns. Very cool plugin.
6. Add all your redirections in the Redirection interface.
7. Go to bed (nameserver propagation can take 24-72 hours). Wake up and test your redirects. If they work, yee-haw. If not, panic and start throwing things (or, failing that, read the steps above again and retest).

That should be it. You can also monitor your site using Google Webmaster Tools to check the 404 errors that users are getting. There’s probably a plugin for that too (404 notifier?), but you should be checking Webmaster Tools anyway to check for any number of site performance issues.

BTW, I am definitely a bit out of my comfort zone writing WP tutorials, as I am a full-time Drupal developer and WP is just something I’m learning for my own interest and to keep up to date. This is less a tutorial and more a description of an approach that worked for me.

Please don’t hesitate to correct me or suggest any improvements on the above.

Final caveat is that rewrite rules can seriously mess up your site if not done properly. Please test any .htaccess changes on a non-production site before going live with them. And make a backup of your current .htaccess file before making changes.

Drupal’s documentation on translation makes it sound like this is someting best left to experts with specialized equipment. When in reality, with the changes in CCK, it is actually fairly straightfoward.

Keep in mind that I am not an expert in translation and have only found a method that works for me. I can’t say whether this is the best method, and I’m sure it could be improved on, but the documentation on Drupal translation for non-experts was sorely lacking and hopefully this will at least help fill that gap.

1. Install the most recent version of CCK – check to be sure it includes the new Internationalization support.
2. Download and enable the Multilanguage module, including CCK translation and string translation submodule (you will also have to enable Localization and Content translation)
3. Add the language you want to include on the admin/settings/language page.
4. Go to Translate Interface at admin/build/translate.
5. From here you can search and replace individual strings. This is tedious. Instead, click on Export.
6. Under export translation, choose the language and select either Built in interface or CCK (there’s a good chance you will need to translate both)
7. Click export.

This exports a file with the extension .po. Open the .po file in a text editor. You will find a long sequence of strings that look like this:

#: field:field_a_allotted_time:option_Stop
msgid “Stop”
msgstr “”

The msgid is the original text, and the msgstr is the text you want to translate to. Go ahead and add the translations wherever you see words that need translating. So, the string above would become:

#: field:field_a_allotted_time:option_Stop
msgid “Stop”
msgstr “Arrete”

Replace all the “msgstr”s you can find, then save the file.

Go back to Drupal, and now click on “Import.” Choose the saved .po file and import it back into the site, using the setting “Existing strings are kept, only new strings are added.”

If you go back and look at your site, you may see nothing has changed. If so, go back to the Translate Interface settings and choose “Refresh.” Select the text group, then choose “Update translations” rather than “Refresh strings.” This should update the site with the new translated strings.

Have a look at your site again. Are you happy?

But, not really. Because there is no magic to it. Plus, I’ve made too many mistakes in hiring developers to get all cocky about it or anything.

Still, I have a good eye for talent and I know what a good developer looks like.

So, what am I looking for?

In short: ability, passion, awareness and restraint.

Ability

A developer needs to have a certain level of skill. Having worked on high-profile or indisputably complex projects, such as creating a 3d rendering software, that requires excellent programming ability in a setting that encourages real-world outcomes, is a major plus.

For me as a Drupal developer, they need to have the following: PHP, jQuery, CSS. Obviously, most developers will meet that minimum bar. So, ask them if you can have a look at some of their code. Get them to show you a module or a custom application they developed. Have a look at it, or if you’re not a programmer yourself, get someone in your organization who is look over the code. Is it elegant, well-commented? Do you think as you are reading: what a nice solution? Or, wow, I’ve never thought of doing it that way? Is it shorter than you expected for the functionality? These are good signs. Good code is like a Hemingway short story; not a single character more than what is needed to move the narrative.

Passion

Good coders love what they do. Questions that pop into my head when I’m looking at developers are:

• what sites/blogs do you read/contribute to?
• what technologies do you think have a future? which ones don’t?

People who aren’t passionate just read and learn what they need to fill the minimum requirement for the job. Drupal requires PHP, so they have read enough about PHP to do the job in front of them. The coder you want, though, is personally offended by bad code, gets excited when talking about developments in technology.

A good litmus test of a Drupal developer is: what do you think about Drupal 7′s usability improvements? If they look at you with a blank stare, get nervous. If they look at you, pining for permission to allow their forehead to get all veiny with passion about drag-and-drop form construction, this is a good sign. You want a geek. Geeks are good.

Awareness

Dear god, how many developers have all of the skills we need, but don’t know how to talk to other non-coding humans. People have a natural, healthy aversion to jargon, because using jargon to non-specialists sends a flamboyant semaphore: I don’t know how to explain what I’m doing, and I lack awareness about basic social conventions. When we talk to different audiences, we continually recalibrate our language, our tone. We pay attention to cues and attempt to adjust our message to accommodate them.

Someone who can’t do that is lacking in the package you are looking for.

Also, people who don’t listen are deadly, and they suck to work with. Don’t hire them. Bad things: bluster, bragging, interruption, needless repetition. You know the type. They’re in the wrong profession. Developers should be patient listeners.

Restraint

Good developers are self-managers, and able to monitor the mood of clients. They know when to push and when to pull back. They pay attention to the room.

Websites are emotional enterprises as much as technical ones. They carry the weight of an organization’s conception of itself, they represent things people care deeply about. Developers who understand that this is a vulnerable and definitional process for an organization are rare and wonderful beings. Hire them when you can.

Yes, sometimes, it probably is. Assuming the process goes well, $50,000 (and up) buys peace of mind. It’s assumed that the quality of programming and design will generally be high. Meetings will be on task and well-organized. People will create semi-realistic timelines.

However, just because someone is paid a lot doesn’t mean they have some magic formula for quality or excellence. I’ve found that higher-end consultants can be all over the place: sometimes, overcharging you because they are seemingly too insecure about looking “professional” to admit they don’t know how to do something, or upselling services I don’t need.

What consultants often don’t give you is a site that reflects the vibe of your institution of business. Their sites may look slick, but do they really get you?

Consultants also don’t make smart decisions about outsourcing work. I’m always thinking about whether to send work to our $20/hour student, or to hire a $50/hour consultant, or just to do it myself. A consultant is still charging you $80-100/hour, whether they are writing code or copying and pasting JavaScript. I prefer to spend several different rates for work that requires different levels of expertise.

Also, the larger a project gets, the less “real” your spending seems. It’s like when you buy a house. You might be looking at a house that’s $500,000, but then see one that’s even more perfect for $530,000. You weigh the pros and cons, but you don’t necessarily consider what a large sum $30,000 really is.

You’ll agonize over buying a $2000 couch, but make decisions that involve spending an extra $30,000 without breaking a sweat.

Once figures for a service or product start getting around the $30,000 mark, realistic cost-counting becomes more and more difficult. Is it really a big deal to spend another $1,000 for a customized newsletter, when you’re already spending $45,000 on the whole site? Sums that would normally give you (rational) pause, begin to seem relatively trivial – they can be rationalized as belonging the larger sum.

For this reason, I prefer to do much of the work in-house. When resources are scant, people treasure them, and make the most of them. Spending a lot doesn’t necessarily lead to a good, efficient outcome; a lot of times, it leads to cost indulgence.

I got up on a ladder and within two minutes, had successfully electrocuted myself and shorted out the power in the apartment. I also knocked myself off the ladder. It fills me with some trepidation to think of how much current must have been flowing through my flesh to overload a circuit. Perhaps I will experience odd telekinetic powers or alarming mental lapses many years from now.

Anyway, once I had been knocked off the ladder, my ex called down to the manager and had him come up and do the job properly. He was a crusty old Scotsman, whose natural temperament was simmering irritation. I’ll never forget the way he looked, slowly, with infinite and silent scorn, first at me, and then at the tangle of wires spouting crazily from the ceiling.

It was totally emasculating.

I think about that day whenever I’m working with a user who is, to put it plainly, not very good with computers. It sucks to feel helpless and clumsy around someone who’s an expert. At some level, we’re going to feel threatened or inadequate, and we’re far more likely to be obedient and accept whatever they tell us we need.

As experts, we should be aware of this power dynamic and resist the urge to participate in it.

That’s why I try to be humble. Because everyone sucks at something. Remember the things that don’t come naturally to you when you approach a user, and your approach will likely be the right one.

What’s often missing from that picture is the utility player. The utility player is the type who does the little things right. They repair CSS code. Crop a banner image. Tweak a few lines of PHP. Basically, the many fine tasks that need to happen, but often don’t because of deadline pressure, forgetfulness or priority. They act as a bridge between coders and designers, content editors and managers.

Doing the little things doesn’t get you a lot of visible credit. The utility player doesn’t get applause at the project meeting, but without them, projects frankly just don’t move as quickly or efficiently. Designers and developers can be immersed in a “big” task, and won’t have time or energy to attend to little things. Yet, on a complex web application, little things make a big difference. By the end of the project, if you don’t fix them, there will be dozens or hundreds of these “minor” issues. A utility player can attend to these details, or add small pieces of useful functionality that otherwise would get dropped.

The second reason utility players are so valuable is that they do the work that you sometimes feel reluctant to ask from designers or developers, either because paying $60-120/hour for an experienced developer to be repairing faulty CSS is painful, or because you don’t want to insult them with work they may consider boring or undemanding. It’s just natural to feel shy asking high-priced consultants to do relatively-humble tasks. Yet, a web project arguably consists of more repetitive, menial work than flashy Ajax functionality.

If you don’t have a utility player right now, they are easy to find via craigslist.

An intern or co-op student in an all-around discipline like Media Studies, or a graduate from a web design diploma program, can make an excellent utility player. As recent graduates, they’re usually pretty well-versed in modern web technologies, including Flash and video. Many of them have basic to intermediate PHP/JavaScript abilities. And they’re eager for the work. You’re not afraid to give them any kind of task, because it’s all good experience for them. Both sides win.

Of course, they’re far cheaper than a first-rank developer or designer.

And I all for working on the cheap whenever possible. Having a good all-arounder can save you a bundle over the course of a project.

Most developers are self-starters – we learn complicated subjects without formal training. But, where to start?

I can learn a new technology through online tutorials and forums, but I’m more apt to actually see the forest and the trees with a good book. For example, before I found “Flash 5 Game Development,” I could use Flash. After reading it, I understood Flash. Yet finding computer books in Vancouver has been a hit-and-miss affair since Half-Price Computer Books’ physical storefront closed several years ago.

The choices came down to two major venues: Chapter’s, which is strong in some areas (CSS, PHP/MySQL), but weak in others (Drupal!). Or the Vancouver library, where typically, the most current, useful books are checked out and have months-long waiting lists. There’s a bit of a disjunct between this sleek, towering monument to learning and the antique offerings on the shelf – Learn Corel Paint 5!

That’s why the eBooks section of the library website is a godsend, particularly the Books 24×7 site. The coverage is incredible! A search for WordPress brings up 150 hits, including recent titles on theming and development. The keyword ‘Drupal’ brings up 74 titles, including books I could never find through Chapter’s.

This makes it easier to decide whether to develop a site in a technology I’m less familiar with, knowing there is a deep resource of reference material available.

That’s how I justify it professionally. On a personal level, it’s just geek heaven.

As a bonus, it also automatically tells Dreamweaver to handle file extensions like .info, .module etc. Handy!

I had a CCK field that is quite long (4 pages of text in some nodes). I wanted to include a “Read more” button at a point of my choosing.

Ideally, any text after this “breakpoint” would be hidden (via jQuery or plain old JavaScript). When the user clicks on it, the hidden content would be revealed.

I also wanted something that can be used in a TinyMCE environment and can be added easily by non-technical users. That’s really the main thing – I can do this myself easily, but it has to be easily addable by users.

That’s why it’s very important for web professionals to present themselves well when applying for jobs. In my own limited experience, they often do not. I am not an HR person and do not hire very regularly. But I have recently been involved in several hiring decisions, and it is honestly a bit shocking for me how poor the average job application is.

This is intended as a public service to those who are looking for work. If you do any of these things, I think you probably won’t get the job:

Worst Mistakes on a Job Application

1. Failure to tailor your email/cover letter to the job itself. By far the worst of all sins. It is immediately obvious when you have sent a generic email blast out to 100 employers. DON’T DO IT! I just throw these away without thinking about them. If you can’t be bothered to a) research the company or even b) read the job ad, then I can’t be bothered to contact you. This is a basic litmus test: if the job ad mentions PHP and MySQL, and you do not mention either in your response, you go  to the bottom of the pile.
2. Spelling mistakes. Not everyone is a native English speaker, and I am quite open to working with people who do not speak English perfectly. But an email cover letter is a short document. If you can’t be bothered to check spelling in a two-hundred word document, I’m pretty sure you won’t be a fit for us.
3. No portfolio or broken links in a portfolio. Many people write to say their portfolio website is “coming soon.” How hard is it to put up a one-pager with some screenshots? If you aren’t ready to show a portfolio, perhaps you should have waited before jumping into the job market.
4. Excessive formality or informality. I like and appreciate a bright, conversational tone in a job application email – that communicates confidence and social facility. But something like:
   “hi there,
   saw your ad.”
   is far too informal and goes straight to delete. Excessive formality isn’t quite as bad, but it does signal a stuffiness or social awkwardness. Recent Asian arrivals often have this issue, as they have trouble adjusting to a more informal style of business communication in North America. If that’s the case, spend a few hundred dollars and get a career coach who can help you, at the very least, put together a solid cover letter.We may say we accept cultural differences, but the truth is, we prefer people we feel comfortable with. Especially if we have to make small talk with you in the lunchroom every day for the next 2-5 years. Social awkwardness is not something we are generally looking for in a new workmate.
5. Generic greetings when I have stated my name in the ad. Dear sir, to whom it may concern. Um, I said my name in the ad. That should be an opening for you. The fact that you didn’t take it smacks of either sloppiness or social awkwardness.
6. Not applying for things because you don’t have one or two of the requirements. This one I can only speculate about, but I’ve observed that many applicants feel they’re immediately disqualified if, say, the position asks for experience in Flash development, and they don’t have much Flash. In truth, a strong, engaging and targeted application package (and stated willingness to learn) will take you a long way toward getting the interview, especially if all the other applications are lackluster. Use your judgment, but if you think you have most of the requirements and can quickly learn the rest, go for it.

Things that work:

1. Tailor your job ad to the employer. Do your research. Find out the name of the person you’ll be applying to if possible. At bare minimum, read the job ad carefully and craft an email that meets those requirements.
2. Write in concise, well-formed, lively paragraphs. It is well worth it to hire a writing coach if you are not good at this and can afford it. There are great continuing education and low-cost community-center courses that can help you for a reasonable fee. This is a major investment in your future – good writers have a leg up in any profession.
3. Provide prominent links to sample portfolio pieces.
4. Talk about your soft skills as well as your technical skills. Communication, time-management, teamwork – those are the things that are hardest to teach, and matter the most. You can pick up Java or PHP in a month or two. Soft skills are the qualities that stay with you and that good managers value most.