Category Archives: WordPress

Importing 1100 users into WordPress from a CSV file using WP-CLI

The Problem

A spreadsheet of ~1100 people (name, email address, etc) that needs to be imported into a WordPress site as users.

I tried several user import plugins, but I had trouble with some users not importing (duplicate email addresses and/or usernames), and the plugins I tried didn’t make it easy to see which accounts were failing to import and why.

The import process via the WordPress dashboard was also encountering timeout problems due to the large amount of data being imported.

The Solution

WP-CLI’s user import command available to the rescue!

I used the following command to import the 1100+ user accounts:

wp user import-csv --skip-update user-import.csv

Note: this command skips user accounts that already exist because I included the --skip-update flag.

The output of this command made it very easy to identify the lines/users that were failing to import due to their email addresses already exist.

Bulk Deleting all Subscriber Accounts

I fixed up the duplicate data in the CSV file, and then used the following command to delete the imported user accounts before attempting the import again:

wp user list --role=subscriber --field=ID | xargs wp user delete --yes

Note: this command deletes ALL existing subscriber user accounts.

Once the imported accounts were deleted, I was able to retry the import using the command above.

Using WP-CLI for this ended up working great, and the import process was much quicker than using a plugin because I didn’t have to worry about server timeouts and other problems.

Are you using WP-CLI?

If you’re not already using WP-CLI, be sure to check out my previous presentation.

The WordPress Melbourne User Group: a 1200 day history and a look into the future

The History

In June 2010, Andrew Davis, Anthony Cole and myself met with the idea of reinvigorating the (then defunct) WordPress Melbourne User Group.

The discussions went well, and the following month we hosted the first meeting (which had 8 people in attendance).

1202 days later, I’m immensely proud to say that we have organised 47 WordPress Melbourne User Group meetup events (an average of 1.2 events per month), all of which have helped WordPress users learn and share their knowledge about WordPress and related topics.

The Thank You’s

I’d like to extend a sincere thank you to the following people and companies, who have all played a big part in making WPmelb a success.

The sponsors (past and present):

The venues (past and present):

The organisers (past, present and future):

The regular volunteers (past and present):

The speakers:

  • There have been in excess of 60 volunteer speakers (too many to list unfortunately).

The members and community:

  • Countless people have come along to our events to expand or contribute their knowledge
  • These people have also helped spread the word about the group, and encouraged their friends to join and attend.

As of today, we are lucky enough to have almost 1000 members.

Without all of you the user group would be meaningless.

Thank you.

The Future

With my impending move to Perth, tonight will be the last WPmelb event I attend for a while.

I’ve also stepped down as lead organiser, and I feel confident knowing that a talented and awesome team of volunteer organisers will be ensuring that the group grows and prospers into the future!

It’s been fantastic being a part of the WordPress Melbourne User Group over the last 3 and a half years.

I’ve met so many great people, learnt so many things, and had countless opportunities to share some of my knowledge with others.

If you live in or near Melbourne, and are interested in WordPress, I strongly recommend that you join the friendly group and come along to an event.

Command Line WordPress with WP-CLI

Tonight at the WordPress Melbourne User Group September 2013 Meetup, I gave a presentation titled Command Line WordPress with WP-CLI.

Video:

Slides:

 

Are you already using WP-CLI? If so, please let me know what your favourite WP-CLI command is.

If not, I suggest you go to wp-cli.org and give it a try :)

The Inaugural BeachPress Australia – August 2013 – Phillip Island, Victoria

A weekend where WordPress developers and/or businesses owners get together to write code, share ideas, collaborate on projects, and maybe even relax.

Do you like WordPress?

Do you like sharing ideas, stories and (GPL) code with like minded people?

Do you have an idea for a new plugin, and want to team up with someone to get it finished and published?

Do you have a WordPress project that you’ve been wanting to finish, but haven’t been able to find the time?

If you answered yes to any (or all) of those questions, then this weekend is for you!

When?
Arrive Friday 16 August 2013 after 3pm.
Depart Monday 19 August 2013 by 9am.

Where?
A deluxe 5 star holiday house (including ocean views) in Phillip Island, Victoria:


(Photos courtesy of the holiday house’s owner)

What’s included?

  • 3 nights accommodation in Rhyll, Phillip Island, Victoria.
  • 7 meals (Friday dinner, Saturday breakfast, Saturday lunch, Saturday dinner, Sunday breakfast, Sunday lunch, Sunday dinner).
  • your own bed (including linen).
  • the opportunity to collaborate and have fun with some great Australian WordPress people!

How much?
$250 AUD per person (paid in advance).
Note: we are not going to profit from this event – any extra money will be spent on additional food/drinks/snacks for everyone.

What do I need to bring?

  • your laptop and charger
  • mobile phone (with mobile data) – wifi is not available, so we’ll need to use our phones for internet access
  • any alcoholic drinks
  • any specialist snacks/food
  • your wetsuit (if you’re crazy enough to swim during a Melbourne winter!)

Who is organising this?
James Collins and Aaron Rutley.
(Two WordPress developers from Melbourne, and organisers of the WordPress Melbourne User Group).

Can I come?
We are keeping the numbers small – places are limited to 10-12 people.
If you’re willing to sleep on the floor (instead of in a bed), it is more likely we’ll be able to squeeze you in.
So if you’re interested in coming, please contact me.

This event is now sold out. Please keep an eye on the blog if/when we organise another one of these events.

I can’t make it on those dates. Will there be another one?
No promises, but we’re really excited about this concept, and we’re hoping to make them a (semi) regular event in different locations around Australia.

Full disclosure: this event wasn’t my idea – recently in Portland, Justin Sainton organised an event called BeachPress, and he’s been kind enough to give me some advice and let me run a similar event in Australia.

Releasing a WordPress Plugin – What’s Stopping You?

At OM4 we’re typically  creating a WordPress plugin in order to solve a requirement for one (or more) of our paying clients.

Some of the time, the problem we’re solving is quite specialised and unique, so there would be little benefit in releasing it to the masses.

However in a lot of other cases, the problem we’re solving for our client is a generic problem that applies to a lot of other people out there.

In those more generic cases, we have tried to make an effort to give away those plugins to the public by releasing them into the official WordPress plugins repository.

So far we’ve publicly released 4 plugins into the repository, and today we reached a milestone: our WordPress plugins have now been downloaded more than 100,000 times!

The main reason we released these plugins was because we wanted to try and give back to the WordPress community. After all, we had free access to WordPress and 25,000+ plugins due to the generosity of others, so why not return the favour?!

Speaking of why not, there are a few common arguments against publicly releasing a plugin, which I’ll try and address below.

1. But won’t I get too many support requests if I release my plugin?

Well, it depends.

In our case, we’ve had 100,000+ plugin downloads, but we’ve had a mere 18 support requests, which equates to:

  • 1 support request for every 5555 downloads
  • 1 support request every 11 weeks

Personally I think those numbers are very low, and I attribute that fact to the following 3 reasons:

a) A simple plugin designed to do one thing only

In our case, the plugins  we chose to publish are all very simple plugins, which are designed to done thing only.

The biggest plugin we’ve released is a mere 600 lines of code, however I’ve come across plugins in the repository that have 50,0000+ lines of code.

Now I have no doubt that those large plugins can be useful to people, but I personally wouldn’t want to release a plugin that large without charging for support (because there would be a lot of support requests)!

b) Decisions not options

The plugins we’ve published all have very few user options (which follows WordPress’ philosophy of Decisions not Options).

This helps keep your plugin small, simple, and easy to use.

Speaking of WordPress’ philosophy, in my opinion the main points that are relevant to plugins are:

  • Design for the Majority
  • Decisions not Options
  • Clean, Lean, and Mean
  • Striving for Simplicity
  • Out of the Box

I strongly recommend you read the philsophy and try and apply it to your plugins.

c) Clear & simple documentation

We have also put quite a lot of effort into documenting each plugin (in the plugin’s readme.txt file), so that the users can get up and running without having to ask questions.

Remember that you wrote the plugin, so you understand how to use it. However your users don’t have that knowledge, so they’ll need clear and simple instructions.

2. But isn’t releasing a plugin extra work that I won’t get paid for?

Technically, it is a little more work to publicly release a plugin, but if you’ve gone to the effort of writing the plugin for a client, why not spend another hour packaging it up and releasing it on WordPress.org?

Speaking of extra work: the major benefit to releasing your plugin is that other plugin developers might do some work for you!

I’ve had several developers who have been nice enough to send me bug reports (and pull requests) for our plugins, which has saved us some time and thus benefited our own clients.

If you’d like to encourage this community development, I strongly recommend putting your plugin’s code on GitHub (in addition to the WordPress plugin repository).

3. But I don’t know how!

If you are interested in releasing your plugin, I encourage you to have a look at the WordPress Plugin Developer Centre.

Conclusion

Now that I’ve been working with WordPress for ~6 years,  I can’t even guess how many lines of code I’ve written!

But when I pause for a second and compare that  to the amount of code that I have released publicly, I realise that there is still a lot of room for improvement. Is it too late to be making more new year’s resolutions?!?

I’m interested in hearing from you.

Is there anything in particular holding you back from releasing your WordPress plugin code to the public?

I’d love to hear why, and help encourage you to take the plunge and release it.

Happy 10th Anniversary WordPress!

Today (May 27) is WordPress’ 10th anniversary!

(Technically speaking, today marks 10 years since the first WordPress release).

In that time, there have been 79 WordPress releases (19 of which were major releases that were named in honour of a jazz musician).

To celebrate, there are over 650 WordPress 10th Anniversary parties around the globe. So be sure to get along to one of them and spread the WordPress love.

WordPress' 10th Anniversary Parties

Also, be sure to check out the anniversary posts from WordPress co-founders Mike Little and Matt Mullenweg.

How to Get Involved in the WordPress Project

Recently at WordCamp Melbourne, Ryan McCue said the following to all attendees:

If everyone simply contributed just one thing to the WordPress project, then WordPress would be infinitely better.
Ryan McCue

Please pause, and think about that for a second.

Going back a few years, there seemed to be a heavy focus on core code being the primary way to contribute to the WordPress open source project.

However in recent times, I’ve noticed a lot of effort has been put into helping the community contribute to the project in other ways (such as documentation, events, or support).

The WordPress Foundation has recently posted a great summary on how you can get involved in the WordPress project.

Regardless of whether you’re using WordPress for business or personal reasons, I strongly suggest you have a read of the article, which lists these teams/areas that you can get involved in:

  • Accessibility
  • Community
  • Core (testing, bug reporting, code wrangling)
  • Documentation
  • Events (WordCamps, meetups, etc)
  • Meta (wordpress.org)
  • Mobile ((iOS, Android, Windows Phone, and BlackBerry apps)
  • Polygots (translations)
  • Plugins
  • Support
  • Themes
  • UI (user interface design & development)
  • Updates (news / blog posts)

In my case, so far I have helped out with WordPress core (bug reporting & fixing), documentation, events, plugins, suport and updates.

However I haven’t been contributing as much as I would like to. I’ve only used six of the thirteen ways that I could be contributing, so there’s definitely still room for improvement!

How are you planning on contributing to the WordPress project?

New in WordPress 3.6: the attachment_url_to_postid() Function

If you’re writing a WordPress plugin, you may have a scenario where you have an attachment (file) URL, and you’d like to obtain the associated post (attachment) ID.

Luckily, this is very easy to do in WordPress 3.6 because of the new attachment_url_to_postid() function.

The function’s syntax is simple – you pass it a string (the file URL), and it returns an integer (the associated post id), or zero on failure.

Here’s a simple example:

As mentioned above, this function is available in WordPress 3.6 – it will cause a fatal error if you try to use it in any earlier versions such as WordPress 3.5.x.

Thanks to Zack Tollman for the heads up about this handy new function.

Better Mobile Detection with WordPress’ wp_is_mobile() Function

Although WordPress themes typically use Responsive Web Design to tailor website for mobile devices, there is sometimes a need to use PHP (backend code) to detect whether the visitor’s web browser is running on a mobile device.

For example, there may be scenarios where you may want to output certain HTML markup (such as a mobile navigation menu) on mobile devices.

Alternatively, you may only want to output a slider containing large images on desktop and not mobile devices. Doing this via PHP (instead of CSS) means that the visitor’s mobile browser won’t have to download all of the slider images even though the slider is never displayed.

WordPress’ wp_is_mobile() function to the rescue!

wp_is_mobile() is a litte-known function built into WordPress that detects whether the visitor is using a mobile devices such as iPhone, iPad, Android, Silk, Kindle, BlackBerry, Opera Mini, and Opera Mobi.

The function was introduced in WordPress 3.4, and it can be used in a WordPress plugin or theme.

It's a simple function that accepts no parameters, and returns a simple boolean (true/false) value.

Here's a simple example:

Interestingly, WordPress core currently uses this function in a few different places:

  • To completely disable the Visual Editor for Opera Mini.
  • To enable jQuery UI Touch Punch in the WordPress dashboard for mobile devices.
  • To detect whether the current device can upload files.
  • To disable the "shake" effect on the WordPress login page when an incorrect username or password is entered using a mobile device.

Are you currently using the wp_is_mobile() function in your plugin or theme? If so, I'd love to hear what your use-case is.