Hopefully there is a one minute formula to avoid this: a one line SQL statement that will update all guids of attachments in one go, directly in the WordPress database.

The procedure

Access your new WordPress database via phpMyAdmin.

Click the ‘SQL’ tab – framed in red in the picture below.

SQL tab in phpMyAdmin

In the ‘Run SQL query/queries on database nameofdatabase‘ field, enter the following query:

UPDATE `pre_posts` SET `guid` =  REPLACE( `guid` , 'http://old-url-to-wordpress' , 'http://new-url-to-wordpress' ) WHERE `post_type` = 'attachment'

pre_ is your table prefix (the default being ‘wp_’)

http://old-url-to-wordpress is the previous url to the WordPress directory (not to mix up with the home url!)

Similarly, http://new-url-to-wordpress is the new url to the WordPress directory.

And this should do the trick!

Simplifying the WordPress admin to improve its usability can make your customers very happy (and therefore more likely to recommend your services) and can greatly reduce the need for unanticipated customer support following projects!

Here are 5 things to consider to make the WordPress dashboard simpler.

1. Remove those dashboard widgets

You know, all these boxes of ‘stuff’ that try to assail your attention when you land in the admin…Just get rid of them for you client. That way, the first time they log in, their attention is channelled towards the only useful thing on that page: the menu.

It’s a matter of seconds: click on the ‘Screen Options’ tab at the top of the screen and uncheck all the boxes.

2. Hide unnecessary menu items

Create a ‘webmaster’ or ‘tech ‘ account providing access to a full admin menu, and an account with a simplified menu for the customer. As a rule of thumb, you can get rid of the ‘Links’ and ‘Tools’ sections. Remove ‘Posts’ if he/she doesn’t intend to blog. In some cases, the essentials boil down to just ‘Posts’, ‘Pages’, ‘Comments’ and ‘Media’, most of all if all the rest can be found in a webmaster account.

Here is how you can remove admin menu items. Place the following code in you theme’s functions.php file or in one of your plugin files.

add_action( 'admin_init' , 'simplify_menu' , 999 );

function simplify_menu(){ 
 remove_menu_page('link-manager.php');
 remove_menu_page('tools.php');
} 

This particular example removes the ‘Links’ and ‘Tools’ sections for all users. Build an appropriate conditional statement to remove sections for particular users only, e.g. to remove these links for the user with id number 5 only:

add_action( 'admin_init', 'simplify_menu' , 999 );

function simplify_menu() {
  $current_user = wp_get_current_user();
  if( $current_user->ID == 5 ){
      remove_menu_page('link-manager.php');

      remove_menu_page('tools.php');
  }
}

3. Turn off unnecessary custom post types

When would you want to do this? In the situation where the customer wants you to work with a theme they purchased, and said theme generates a series of custom post types, e.g. ‘portfolio items’, that you know are not relevant to the project.

You create a child theme to bring changes to the purchased theme. To remove the unnecessary post types, place this code in the functions.php file of the child theme:

add_action( 'after_setup_theme','remove_project_custom_init', 100 );

function remove_project_custom_init() { 

 remove_action('init', 'custom_post_type_1');

 remove_action('init', 'custom_post_type_2');

}

in which custom_post_type_x is the name of the function in which the custom post type is registered in the original theme.

4. Use and abuse of the Advanced Custom Fields plugin

The advanced custom fields plugin - http://www.advancedcustomfields.com/ - allows you to add content fields to posts. You can add these fields to all posts or select a particular subset of posts, pages etc. I strongly recommend to try it and most of all to purchase the repeater field addon.

To give you an example, I often use ACF for testimonial pages. Instead of expecting the website user to format the quotes and signatures themselves in TinyMCE, a testimonials meta box is provided. Adding a testimonial then consists in pressing a button and filling a ‘quote’, ‘client name’,  ’client website’, and ‘client website url’ form. Like so:

The formatting of the testimonials is automated in the theme. The alternative would be to create a custom post type for testimonials, but it just seems more intuitive to look for a particular page’s content in a corresponding page in the dashboard.

5. Use scripts already included with WordPress

If you are creating your own theme or plugin option pages, think of re-using features already used somewhere else in the admin. I am thinking of the Farbtastic colour picker or the ThickBox media uploader for example. Admin users already know how to use them and it looks more consistent and professional.

You can find a list of the scripts already available in the WordPress Codex wp_enqueue_script function reference page.

Let’s deal with this problem as cool-headed Zen masters. Moaning about it on forums is not going to improve the situation. Educating clients en masse is simply unfeasible. So here are a few tips that I use to avoid the pressure and still keep clients and design partners happy.

1. Phone and emails OFF for most of the day

With the exception of days of website launches, or prior arrangements with clients, I check my emails and voice mail twice a day: once in the morning, and once at the end of the day. The rest of my day is made of solid, distraction-free programming time. No-one so far has complained.

2. Assign more time than you need for all tasks

We all know web projects generally take more time than anticipated. On top of that, as freelancers, we never can work full time on anything: there are quotes to write, emails to send, admin to do… So simply assign more time than needed for your web projects and inform clients and partners of that deadline. You will sometimes (yet less often than you’d think!) end up delivering ‘in advance’, thereby making everyone happy.

How much extra time to add really depends on the type of project and how confident you are with the task at hand (is it routine or something new for you?) For example, WordPress themes usually take me 2-3 days to code, but I always give a 5 working day deadline to clients.

3. Spell out your requirements to finish the job on time

A common scenario in web project is this. The design is kind of finished but maybe there’s one last thing for which the designer is still waiting for feedback e.g. one or two illustrations, and the client is still working on the copy. But the client is keen to have his/her website and asks if you can get started with what you have.

Well… it depends. Usually I don’t mind (mostly because I require a substantial upfront that has the virtue of increasing my patience when things are hanging in the air mid-project). But, I make it clear that I cannot completely finish the website by the agreed deadline if I don’t receive all the material X days prior to that deadline. I remain flexible, yet sensible and clients appreciate that.

4. Cut down on waffling and manipulative channels

Meetings and conference calls are good for two things: seeing how you get on with the client and reaching several people in one go. Full stop!

Phone/Skype calls are good for one thing: clarifying instructions and briefs. Full stop!

For any other reason, email is the appropriate medium. It keeps a trace of every transaction, you can refer to it as many times as you like and, last but not least, it forces the sender to spell things out in a structured way… which phone doesn’t do. What am I getting at? Beware of that client that systematically tries to get you on the phone. Usually, they are wafflers; at worst, they count on emotional factors to pressure you – because it’s not easy saying ’no’.

Also beware of voice mails telling you to call back asap because ‘it is urgent’. In 90% of the cases, ‘urgent’ can be replaced by ‘I sat on it until last minute and now I am panicking’. Don’t let the panic get to you and set the pace back where it belongs by replying via email.

There is no need to get angry or resentful of the client. They usually are not aware of what they are doing or of their emotional state, but don’t let it get to you.

5. If you happen to be delayed

Sometimes you just got your timing wrong or you are delayed by other things. You know the client is going to call to see what’s going on. Fair enough! The trick here is to get in touch with him/her before they do. As soon as you feel the need to push back the deadline – and that is BEFORE the deadline – get in touch with the client, explain the situation, and suggest an alternative schedule. It is the honest and considerate thing to do as it allows clients and partners to re-adjust as well.

Hope that helps. Any other tip to share, please leave them in the comments

To save YOU those agonizingly slow and frustrating moments, here are a few things that I wish had been made clearer about jQuery in WordPress.

1. It’s already in!!

There is no need to add a copy of jQuery to your WordPress theme or plugin. It’s already there in the core package. You still need to call it though, just in case it wasn’t loaded yet.

Insert it using the wp_enqueue_script function; the handle for jQuery is simply… ‘jquery’.

2. Calling ‘$’ doesn’t work!

Nope you cannot write
$(document).ready(function(){});

as the ‘$’ is not recognized in Worpdress. You need to use ‘jQuery’ instead, like so
jQuery(document).ready(function(){});

If you absolutely want to use the ‘$’ call, you simply need to pass it as a variable from function to function.
jQuery(document).ready(function($){
anotherfunction($);
});

3. Passing variables to jQuery

At times, you will want to provide server-side variables to jQuery, a good example would be the path to your theme or plugin. But if you insert your script properly using the wp_enqueue_script function, how do you pass those variables to the jQuery environment?

Using the wp_localize_script function, which assigns an object containing the various variables you wish to transmit to your script.

See this page for details on its use: http://codex.wordpress.org/Function_Reference/wp_localize_script

More in future posts! Any questions, please ask in the comments

It all started 8 months ago, at a time when I started feeling all too comfortable with WordPress. So I thought I’d see what else was out there. Maybe Drupal would be more appropriate for developing biggish applications. After all, I had heard a lot of good things about it.

You know how love stories go at first. The modularity, the custom data types, the views module… I was under Drupal’s spell. Soon, all I wanted was to get hands on. Yet, Drupal was playing hard to get: its documentation was wrapped in an aura of mystery. Am I the only one to find it confusing that, despite significant differences between successive versions, pages relevant to Drupal versions 5, 6 and 7 are jumbled up together?

I thought I’d persevere, so I did what I usually do when the online material is not great: I bought a textbook, Pro Drupal 7 development by Tomlinson and VanDyk. The book was OK – though I bought it before realizing how wide the differences between Drupal versions were so I had to return my originally purchased “Pro Drupal 6 development” in favor of the one cited above -_-

Theming was OK too… as long as I didn’t want to override native functions. Somehow, even when staying as close as possible from code found in the book or online, none of my overriding functions would work. That’s OK… (see, I have the patience of an angel) I quickly found out that when I wanted to create my own functions, the vast majority of the time, a module already existed for that.

That’s how I ended up spending all my time in the admin area, which, to say it plainly, I just hate. Forgetting hierarchy in favour of modularity is fine for a computer… not so great for a humain brain. There were too many ways of getting to the same page while none of these ways seemed obvious and clear. The default editor, guys… come on! I know it’s fun to install and setup modules (erm…) but is it not just minimum standard to have a somewhat rich editor? And that’s when the question first popped into my mind? WHO USES THIS? WHO IS THIS FOR?

I wanted to code but was pushed back to the graphical interface by the unclear documentation. Yet the interface is not really intuitive and the editor is SO plain you’re tempted to shove HTML directly in there. But I can’t ask my client to do that when they update their site!

So again I thought maybe it’s for big teams of developer/webmasters but considering the clunkiness of Drupal and the training required to use the interface, you might as well train your team to code using a proper, flexible framework such as cakePHP or Zend.

The question came back to life when I installed a Drupal website on my shared server. It was unbearably slow! I did a bit of research online to notice that it was a common pitfall of Drupal 7. To make it work at a decent speed, you need to be able to optimise your server for it… as if me or any of my clients would have that kind of access to their server!

Oh, well… I realized my mistake and am back in the arms of WordPress now and if it doesn’t satisfies a projects needs, I’ll use one of the many PHP frameworks!