Sometimes I would find myself updating WordPress options on 54 different blogs trough the admin interface. Completely tired of it I created a little tool to automate these kind of things trough the command line interface (like every self respecting developer would do). The wp-cli project was born. 

Why did I started a new project instead of modifying one of the available tools?

My code is inspired on some of them but they all missed one essential concept: pluggability. You can add commands to wp-cli from anywhere in WordPress on the fly, which allows anyone to take full advantage of the command line interface.

Shortly after my first batch of commits @scribu picked up the project and added some great functionality and insights. Today multiple people are contributing to the project and I hope plugin developers will pick it up in the near future.

Interested? Fork the repository on Github.

In the last few years we had to hire freelancers for different types of work and amongst them there was a stunning difference in style. So how can you be the perfect freelancer? It is a combination of style, communication and great work.

Of course the most important thing is doing the actual work you are hired for as good and fast as possible. If you deliver great quality on time you are already a good freelancer. But there is more, and if you do those extra things right you can be almost sure that client will hire you again.

Most important to me are your communication skills, I prefer to be in contact with our freelancers through email because they can be easily recaptured later on. Answering emails correctly and replying on all the topics is a start. Just answering as fast as possible is not a good idea, think about what you write and make sure you cover all aspects. This is extremely important, especially when you are dealing with someone who knows your job as well.

When you have to be in touch with your client’s client directly try to copy your employer’s writing style. This is great for the end-client experience and if the end-client is happy your client will be happy as well. (Please don’t do this if your client’s communication style really sucks)

Your biggest job is to infiltrate the company you are working for as good as possible. Know who you have to contact for which question, know who is responsible for what, find out which processes are interesting for you. If you know exactly how the company works you will not only save time but the person responsible for you will be happy you don’t always need to pass by him, be aware however, that some clients like to control every task you do, in that case you need to discuss everything with them. Try to use the tools they use, try to act exactly like they do.

Show availability when they need you in off-hours. Sometimes there are matters that require urgency, a project that dropped on their laps at the last minute, site that went down, content that needs producing, a bug that was discovered shortly after launch. It is in these dire times that they will need help the most, and if you show availability, they will greatly appreciate it and will definitely consider working with you in the future.

If you are payed by the hour, always make an estimate of time you are going to spend on a job. Your employer will be doing the same. If you exceed that time more than once you will have to start questioning yourself. Not only because it annoys you but because your employer sees his margin going down and will probably replace you with someone else if possible. So if you want to stay working for him: only invoice what you initially planned, and tell him you did so, together you might think of a solution for the issue or realize the estimates are too positive. If you want to lose your job, just invoice the lump sum.

When you work with monthly invoices, send your invoices on time. We send our freelancers a reminder the last day of the month to ask them to send their invoices. If you don’t send them in time you will not be payed on time. Never back-date an invoice, date the invoice with the day you are actually making it.

Send your client a follow-up email a month after you finished the project. Just to check if everything is still working and if he is still happy with your work. This will not only be good for your rating by the employer, but he might be working on a new project and because you are sending that email you remind him of the great job you did last time and might reply with something like “Oh, we have a new project coming up, interesting in working on that as well?”

To summarize:

• Do your job the best you can, and finish on time
• Communicate with style
• Infiltrate the company
• Show availability
• Send invoices on time
• Follow up on your project

Other things we changed since the initial launch of the tester:

• Support for https requests and the %{HTTPS} variable.
• Support for server port and the %{SERVER_PORT} variable, default server port is 80.
• Fixed a bug with parsing path which sometimes resulted in an empty result.
• Fixed a bug that added the port number behind the url when using the %{SERVER_PORT} variable.

If you have ideas for implementing other variables in the tester, please let us know. We hope you love the tester as much as we do and we would like to thank everyone for the kind words and shoutouts.

To our surprise there was no simple app to test rewrite rules, so we decided to dedicate our wednesday afternoon to build one, here is the result: htaccess.madewithlove.be.

It’s very easy to use, just fill in your htaccess and the url (starting with http://) you want to test and hit the “Check now” button.

By doing that your url will be rewritten according to your rewrite rules, the output view gives the new url and some debugging information you can use to improve your rules.

There are a couple of things which are not supported yet (like ${HTTP_REFERER} and %{REQUEST_FILENAME}) but we hope to add them in the future. Adding the ${HTTP_REFERER} will be quite easy but we need to find a good way to implement things like %{REQUEST_FILENAME}, please comment if you have suggestions on how we should do it.

That’s it! I hope you like it. Feel free to get in touch with us if any problems arise or if you have ideas on how we can improve it.

Update: We updated the checker to also support the HTTP_REFERER, HTTPS and SERVER_PORT variables, read more about the update in this blog post.

The solution turns out to be really easy if we use the WordPress function media_handle_upload. It works with the normal $_FILES array, resizes your image, and gives back the attachment id.

Some example code:

<?php

if(!empty($_POST)) {
	// Create the new post
	$post_id = wp_insert_post($_POST);

	// Attach the image to the post
	$upload = media_handle_upload($_FILES['image'], $post_id);
}

?>
<form action="" enctype="multipart/form-data" method="post">
	<p>
		<label for="post_title">Title</label>
		<input type="text" name="post_title" value="" id="post_title" />
	</p>
	<p>
		<label for="post_content">Content</label>
		<textarea name="post_content" id="post_content"></textarea>
	</p>
	<p>
		<label for="image">Image</label>
		<input type="file" name="image" value="" id="image" />
	</p>
	<p><input type="submit" value="Submit"></p>
</form>

About 6 years ago I remember writing a script to dynamically generate email aliases from a mysql database, on a shared server. All the members of our boys scout group could fill out out their email address in their profile and they would automatically get an alias on our domain by doing so.
About a year later I wrote a control panel for my clients on my reseller package. By using the DirectAdmin API I allowed my clients to manage their email accounts and view their usage statistics. Those where my end-clients, small business owners that would get lost in DirectAdmin itself.

Since then a lot has changed on the field of server management itself but the market of hosting control panels hasn’t changed much. We think it’s time for a change. Instead of hacking all this stuff wouldn’t it be great to, for example, be able to install a plugin on WordPress to manage your mail accounts?

This could easily be done if we had a standard API to talk with a web hosting company’s infrastructure. We’re really curious about why such a thing doesn’t exists yet.

The way we see it, such an API would bring these two main advantages:

• Implementation in apps
  Our employees can create staging servers on the fly on our intranet, in another app we would like to create a separate database for each new client that signs up for the service. But we want to do a lot more and I am sure we are not alone. If every web hosting company would implement a RESTfull service over XML every developer would be able to create apps on top of it, no matter what programming language he uses.
• 3th party control panels
  Great designers and developers could work together to create awesome and usable hosting control panels that work on any web hosting environment. I am sure that when such an API is widely spread open source projects will see the light and that there will be wrappers available for any programming language. Even the hosters themselves could use a skinned 3th party control pane for their own business and working together with the developers to implement specific features.

With all those APIs available for cloud management I think the web hosting companies should really start cooperating on this field and we hope to see an Open Hosting API somewhere in the future.

The first one is a very nice image manipulation library built that uses GD2. A few years ago I wrote my own library to do something similar, but recently I had to use transparency masking on profile pictures uploaded by users. This was something my library couldn’t do. Instead of refactoring my code, a small search turned up the WideImage library and now in a few lines of code I can combine any image with a mask. It provides exactly what I need and I waved goodbye to my old library.

The second library, Simple Paypal Payments, addresses one of the most cumbersome and expensive problems in web development: communicating with the PayPal API. I say expensive because the amount of time you lose with trying to get a useful result out of the bloated, almost incomprehensible, API is staggering and quite unique in these modern days of nice, RESTful API’s. The Simple Paypal Payments library offers some relief if all you’re interested in is the Express Checkout API, which I think is the one used by most small PayPal victims web shops. It offers a very basic interface to handle payments, allowing you to simply add products and call a method to start the process. The only thing I missed was an option to change the currency, but that was only a small hack away.

I hope I helped someone by pointing out these interesting libraries. If you know a better library, feel free to tell us in the comments.

Like they suggest in their comment the wpmu_delete_user function is not ready yet. When deleting a user, WordPress does not allow you to reassign the user’s content to another user. My rewrite below is a merge with the wp_delete_user that lets you do so.

function wpmu_delete_user($id, $reassign) {
    global $wpdb;

    $id = (int) $id;

    do_action( 'wpmu_delete_user', $id );

    $blogs = get_blogs_of_user( $id );

    if ( ! empty( $blogs ) ) {
        foreach ( $blogs as $blog ) {
            switch_to_blog( $blog->userblog_id );
            remove_user_from_blog( $id, $blog->userblog_id );

            if ( 'novalue' === $reassign || null === $reassign ) {
                $post_ids = $wpdb->get_col( $wpdb->prepare("SELECT ID FROM $wpdb->posts WHERE post_author = %d", $id) );

                if ( $post_ids ) {
                    foreach ( $post_ids as $post_id )
                        wp_delete_post($post_id);
                }

                // Clean links
                $link_ids = $wpdb->get_col( $wpdb->prepare("SELECT link_id FROM $wpdb->links WHERE link_owner = %d", $id) );

                if ( $link_ids ) {
                    foreach ( $link_ids as $link_id )
                        wp_delete_link($link_id);
                }
            } else {
                $reassign = (int) $reassign;
                $wpdb->update( $wpdb->posts, array('post_author' => $reassign), array('post_author' => $id) );
                $wpdb->update( $wpdb->links, array('link_owner' => $reassign), array('link_owner' => $id) );
            }

            restore_current_blog();
        }
    }

    // FINALLY, delete user
    $wpdb->query( $wpdb->prepare("DELETE FROM $wpdb->usermeta WHERE user_id = %d", $id) );
    $wpdb->query( $wpdb->prepare("DELETE FROM $wpdb->users WHERE ID = %d", $id) );

    clean_user_cache( $id );

    // allow for commit transaction
    do_action( 'deleted_user', $id );

    return true;
}

I think it would be even better to use the wp_delete_user function in this function instead of just copying the code, by doing that the hooks would be triggered for each blog which would allow each’s plugins to do their thing.

This is Marco’s personal view, as a company we do create html5 websites and we try to adopt it as good as possible.

The short answer: No.
The slightly longer answer: It depends.
The excruciatingly long answer: Read on…

If you’re a web developer like me, regardless of which sites you visit, including this one now, you’ll soon stumble upon the latest buzzword which is HTML5. A lot of articles going around the web tend to use the term HTMl5 very loosely whereas in fact, most of them are about something completely different (CSS3) or a very specific part of HTML5 which is a specification in it’s own right: Canvas.

Why does this happen? Why is CSS sometimes trampled by the term HTML5, and why is Canvas, which is more of a “new technology” rather than an intricate part of HTML5, simply branded as HTML5.

Well, I’m afraid it’s because of marketing, and we as a community have been doing very little, if anything, about it. These articles wouldn’t continue to be published with these misleading titles if we ignored them. No, visiting the article, and pointing out the mistake in the comments won’t help. the light controversy will only help build interest, and people will revisit the site just to discuss the matter.

This all started when Apple decided that HTML would be the ideal engine to build applications for the iPhone, before they announced their SDK. With this in mind, people started looking at HTML’s capabilities, and most importantly, some very specific parts of HTML5 that allowed them to do things that they normally wouldn’t be able to do, like offline storage and such.

Although there is a current HTMl5 draft, and some parts of the specification are pretty much “done” and can be applied to real projects, it really depends on context. On the iPhone it made sense to make use of some of the new features because you could be sure that everyone would be able to use it.

However, HTMl5 is far from finished. How far? Well, it’s only meant to be finished in 2022, at least that was the plan some time ago. Surely I jest, you must be thinking, but no, I’m not. With the increasing growth of popularity of the iPhone people essentially stumbled onto the W3C’s work with it’s pants down. Sure, the bare-bones of the specification are there, and we already have a solid feel for what we we’ll be able to do with it, but it’s far from finished.

Right now the only parts of HTML5 that are “finished”, or very close to that, are the parts that either add semantical value, or help make things prettier. They are both things that can be done, to some extent, with HTML4/XHTML1 and progressive enhancement.

A few years back, some people wrote books on how progressive enhancement was the ideal way for us to take the industry forward. I purchased some of those books, and I still believe that it is a great idea to follow. But somehow, most of those same writers and admired people in our community are now stating that we should shoehorn features that old browsers don’t support, and simply ignore them. What?!

I know that Microsoft has a track record of being slow to adopt new features on it’s browsers, but to even render an html5 site correctly on any stable Internet Explorer you have to run a small Javascript library. When did forcing these features in a browser suddenly become a good thing?

I’m all for preparing oneself for the future, and practicing it while we get there. But this isn’t practicing, this is putting a check mark on a feature set. This hardly adds any value to the site. The tools we have to right now, to build and validate this new code, are still unfinished, or not even created. We are putting the wagon in front of the horse.

Let’s look at the past; when did shoe-horning new features into an old browser ever work well?

Did it work when we started using Microsoft’s proprietary filters?
Did it, or does it work when we use PNG fixes? Sure, those “work”, but I pity the lives of every person visiting a site where I’m forced to implement it.

You all know how those fixes are. You should be ashamed if you don’t think they are detrimental to the User Experience we all like to brag about. Not even JavaScript libraries, which we use in most of our projects, are flawless and can leave some parts of our sites completely unusable.

If your target audience is tech savvy, or is using a certain platform that supports a certain amount of HTML5 features, like the iPhone or Android, by all means, do jump on board, it only helps bring the industry forward.

But if you’re building Bob’s plumbing company site, I highly doubt that his users are running Safari, or will appreciate the extra effort put into that CSS recreation of his logo (which is stupid and completely useless), or be able to use the new form tags like the date picker.

HTML5 isn’t finished, and if you look at which companies are shaping it: Google, Apple, Microsoft and Adobe; you probably realize that they all have their own different interests at stake which contradict crucial parts of HTMl5.

Do you think Adobe is a fan of Canvas which might steal a large part of Flash, or even kill it?
Do you think Microsoft is happy about Google’s efforts to bring 3D to the browser, and it’s push to enable browser applications to become more like standalone ones?

If the HTML group was a real company, and not an organization, none of those companies would be a part of the board, because the conflicts of interest are painfully obvious. And unfortunately we will have to cope with whatever compromises they make so that HTML5 hurts or improves their businesses in the least possible manner.

We can all dance and cheer about how wonderfully semantic and easy it is to use HTML5, but we must remember that right now more than half of the people using the internet have no access to it’s features, due to their browser of choice. This is a choice we must respect as professionals, and adjust accordingly.

Sure, some people might say it’s perfectly fine to start using HTML5 right now, and that there’s no reason not to, but most of those people are also trying to sell you books on how to use this new technology, or some service related to it, like a blog with web development tips and such.

I’m not saying you shouldn’t pick up those books, or read those blogs/sites and learn more about it. I do it, and so should any web developer with any interest. But you shouldn’t let them dictate how you will build sites right now. Remember that the users, and not those book writers or bloggers, are the reason why you have your job.

It’s in your best interest to make the choice that is best for your users, and not the choice that is most convenient/popular, because they almost never mean the same thing.

Sometimes I debate with myself whether they’re using a grid system because they are aware of the advantages a system like that brings, or because it’s a trend. But either way, since some of them don’t understand how a grid system works, I thought I’d write a tutorial on simple guidelines they can follow, to make their front-end developer’s life easier.

Columns and Gutters

Every grid system consists of two concepts: columns and gutters.

The columns are represented above by the pink areas, and gutters are the spaces between them.

In Photoshop, if you design something that only occupies one pink area, it will be the size of the pink area alone. If you choose to occupy two columns, then it will be the width of two columns + the width of 1 gutter. If it occupies 3 columns, it will be the width of 3 columns and 2 gutters, and so on.

Unlike what some people believe, the gutters are not just a fixed value on one of the sides of each column, but instead, they consist of 2 values, on both sites. Let’s take a closer look.

This image consists of two columns and, as you can see, it clearly shows how the gutters are configured in the grid system. The width of the gutter, by default (on the system with 12 columns) is 20 pixels. That means, on the left and right side of each column, there is a margin of 10 pixels.

If you want to occupy any of those 10 pixels, belonging to the gutter, we have to make a rule that resizes the element and removes the margin from either side. Unless this element is used a lot, we just wasted a lot of code, and it’s untested, might break other elements in the grid system and (usually) it’s not used in anything else.

Everything, and anything you design, by default, should always be inside of the pink areas above, and any gutters in between them.

It saddens me, and probably a few other front-end developers elsewhere, when we receive a design from someone obviously trying to improve their work, by using the grid system, but fail to size their elements correctly, forcing us to code the site as if it had no grid system at all, thus eliminating all the benefits of having it.

If your design elements constantly move into the area where the gutters lie, that renders the grid system useless for us. Any code re-usability is wasted, and we have to write something custom from scratch. This means that when we implement the design, the chances are higher there will be more bugs and problems to fix, because the default 960 grid system, is already cross-browser tested.

Why do designers do this? How can we avoid it?

Well, I think it’s quite simple to solve. Most designers simply stick to the default grid system layout, which has 12 columns. Although those sizes are fine for a common website, sometimes they limit the creativity if they want to add something different. When you download the PSD package from the 960.gs website, it includes a 24 column layout, which is much more versatile.

If that doesn’t work, just make a new one! There is a Photoshop script you can download here that allows to create custom 960 Grid Systems on the fly. You can change the number of columns, their width, and various other things.

The better you follow a grid system, the more concise it will be, the less bugs/problems it will have when it’s implemented. I’m not saying that every site should follow a grid, you shouldn’t limit your creativity. You should understand the advantages of using a grid system before jumping on to it.

All designers should remember that the better they understand their medium, the better their designs will be.