When running an online store, it’s important to ensure that the entire user experience is an effortless process. This helps your visitors navigate through the steps easier, but also makes them more inclined to come back later. In this post, we’ll look at a (relatively) simple principle that can help your users checkout faster and easier: Credit card validation.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

The thing with credit cards

Using credit cards to make payments online has been around since the dawn of e-commerce. The thing with credit cards is that they consist of lengthy numbers (16 characters in total) that people could easily enter wrongfully. This leads to errors in the checkout process and frustrations with your customers. Because credit card numbers also need to pass a thing called the Luhn algorithm, you’d be best off using a library to validate said numbers.

To make everyone’s life easier, here are a few options for your checkout field validation to validate credit card numbers in the form of libraries.

Libraries

There are a bunch of libraries that exist in the wild. These can assist you to make credit card number validation that much easier. Some libraries are automatically shipped along with payment providers to ensure a seamless experience.

Stripe

Recently, Stripe deprecated their old jQuery plugin in favor of two new options: Stripe Elements and Stripe Checkout.

Stripe Elements provides you with UI components to more quickly help you collect sensitive card details. Elements is what you’d use if you want to manually implement the processing of information (i.e., have a custom payment/checkout form).

Stripe Checkout is the bigger brother of Elements. It’s a more ‘plug-and-play’ version of Elements, where you can effectively receive payments with a single line of code.

Depending on your preferences and technical skills, you could decide to go with either option.

jQuery

If you’re not using Stripe or just want a simple jQuery library, you should check out jQuery Credit Card Validator. This simple library checks against a variety of credit card brands. Note that this library only validates if that particular credit card number is valid. The library can’t validate the CVC code, so you have to do that manually.

Another option is to use the credit card method of the jQuery Validation plugin. However, this library only validates the length of the inserted credit card number but does not check if the number passes the Luhn’s algorithm. Probably not as useful as the previous library.

Security considerations

Although we added validation on the front-end, this does not mean that we’re done. You will always need to ensure that there is a form of server-side validation when it comes to dealing with sensitive data, such as credit card numbers. Luckily, most payment providers already do this out of the box, so you don’t have to think about it.

The solutions provided here are not 100% secure. You should treat these as an enhancement to the user experience and nothing more than that.

Conclusion

By adding some validation on the front-end, you’ll ensure that users (almost) immediately get feedback about the information they provided when filling out credit card information. This is better for the overall user experience and also helps avoid annoyances with your customers if they make a mistake when filling out the form, as it gets caught early on.

Read more: ‘eCommerce usability: the ultimate guide’ »

Our checkout page caught our attention, because it simply looked shit. There was no clarity, no images, not anything to make it look anything close to appealing. It was basically just a bunch of text. So that’s the first thing we wanted to change. We wanted to make it actually look like a cart and checkout. But where to begin? Conversion freak as I am, I wanted to make sure we’d make the changes that would improve the user experience. And my expectation was this would actually increase conversion as well. So this is the list I came up with:

  1. Add images of the product to the cart;
  2. Add inline validation in the form’s fields;
  3. Add a progress bar;
  4. Remove the dropdown list and add a bullet list;
  5. Add credit card and PayPal logos;
  6. Add a “Continue Shopping” link;
  7. Change button shape, color and placement;
  8. Add reassurance no additional costs will occur;
  9. Increase the cache time of products in the cart to 24 hours;
  10. Output decent errors.

Quite a long list right? That’s why I said in one of my earlier posts you shouldn’t be afraid to make big changes. Let me now go through this list and explain why I wanted these things changed.

Product images

Images are a known conversion booster. Having decent images on your category and product pages can have a pretty big impact on your conversion rate. Now, our products don’t really allow for pictures, because they’re just software. However, adding the pictures and color of the plugin in question should add more clarity. In our opinion, it does. You don’t have to look for the description now, you can just see the same Yoast avatar as on the product page. So it adds clarity, makes it easier for people and actually helps our branding as well. That’s a win-win.

Before

Old cart After

Cart

Inline validation

Inline validation means you provide instant feedback on what people fill in in your form. So if a person fills in an email address with a format something like xx@xx.xxx, that field’s edges will go green and a checkmark will appear. This will give people immediate positive feedback, making them more likely to complete the form, and actually liking the process more as well. As you can imagine; the more feedback you’ll give, the better. So add inline validation to as many fields as possible.

After

validation1

Progress bar

The progress bar works along the same lines as the inline validation, as it’s a sort of feedback as well. However, it also makes it visible for visitors how far along they are in the process. This actually results in gamification, which makes it even more likely they’ll finish the whole thing. And to take the positive feedback one step further, we’ve made it so you always enter in step 2 out of 4. Because really the visitor has already taken the biggest step: click the buy button. That deserves some validation! Lastly, adding a progress bar made sure we didn’t need to have a text explaining the process anymore. This is made much more clear by this progress bar.

Before

Old progress

After

Progress bar

Remove dropdown

We’ve removed the dropdown list for selecting the payment options and added a bullet list. We’ve done this, because now it’s immediately visible for visitors what options there are. Along with the next step this facilitates a lot more transparency.

Old list

Add logos

Adding logos of our payment options makes it more clear for visitors what kind of payments we accept. Of course, we already had the ‘Accepted Payments’ widget, but our widgets are turned off on the checkout page, to avoid clutter. So we’ve added them in the bullet list of payment options.

Before

Old list

After

Logos

Continue shopping

Sometimes when you’re looking at your own website, you think: “Why haven’t I seen this before?!” This was one of those moments. We realised we’ve never had a continue shopping option from the checkout. Which is weird really, because we certainly don’t want to discourage people from buying more of our products. We’ve added this directly under the product in the cart, because it’s part of the process of filling your cart.

After

Continue shopping

The button

We’ve changed the shape, color and placement of our button on the checkout page. The main reason we did this, was because it would stand out more this way. It’s shaped like an arrow, which just like the Continue Shopping textlink, gives you a sense of direction. In this case your attention is directed towards the arrow that gives you the feeling of moving forward.

Before

Old button

After

Button2

Reassurance

We’ve added the reassurance “there will be no additional costs” next to the total shopping amount. We’ve done this, because unexpected costs are the #1 reason for people to abandon their shopping cart. We want to assure people this won’t happen with us, and they won’t discontinue their purchase out of fear that it might.

Before

Old Total

After

Reassurance2

Increase cache time

Quite a few people add the products they’d like to have to their cart, but actually don’t buy them right away. So we’ve made it so that when people add something to their cart, this will be remembered for 24 hours, instead of the initial 1 hour. This means people can return to their cart during the next 24 hours and still be able to check out.

Decent errors

This might actually be the most important change we’ve made. We’ve made our errors much more visible. At first, they were errors in plain text, right below the text of our checkout page. This meant you just didn’t see it. Now we’ve added an error message right next to the field that’s not filled in right, along with a red cross in the field and borders that turn red. This makes it very clear that something is wrong.

After

Error

Results

Possibly partly due to the switch to Stripe, we’ve seen an increase of 30% in successful transactions!

We also compared the conversion rates of June to the conversion rates of October. These are the first two full months in which we’ve made no changes. Results: the conversion rate has lifted from 48.14% to 53.60%, which is an 11.30% increase.
Note, however, that these results aren’t very reliable, apart from the fact the new checkout page is probably better. The checkout page conversion rates differ quite a bit over months.

What do you think of these changes? Maybe you have some good ideas for us, or have recently ‘upgraded’ your own checkout page? Let me know!

This post first appeared on Yoast. Whoopity Doo!

At first, the topic of how to learn SEO online seems like something that’s been fairly well-covered on the web.

I mean, there are sites like Moz.com, Search Engine Journal and so on. But as it turns out, they are more about the in-the-trenches practices and advice for people who are already deep into SEO.

But what if you’re just starting out? There surely has to be something for the beginner on a site like Moz, right? Well, not really.

Here’s why. Granted, Moz has their beginner’s guide to SEO (link), but that thing is 10 friggin’ chapters. Again, 10 chapters. In total, that’s probably in the 30,000+ word range. And 30,000 words is a mid-sized book.

What’s wrong with it? Let me quote the classic:

Ain’t nobody got time fo’ dat!


How to Learn SEO Online

So…Moz isn’t really a good place for a beginner to learn SEO online. In fact, there are very few places where a beginner can actually get some useful advice; advice that they can implement right away without having to go through a whole book worth of content.

And I know I speak the truth because I still consider myself somewhat a beginner. I too have difficulties picking the right tactics and staying confident that what I’m doing will actually work, especially with things changing so fast.

So, long story short, I’ve been doing a lot of researching on this, and by the looks of things, I can only recommend three ways of obtaining good SEO advice for a beginner (that is if you’re a person who wants to grow your business’ online visibility by ranking it high on Google).

1. Relevant and updated gathering posts

Every once in a while, a blogger goes the extra mile, contacts a number of top players in the SEO market and asks them about their most current advice that could help a true beginner succeed.

This time, it’s Ayodeji of Effective Inbound Marketing who’s done this. He took the time to interview 19 SEO experts and published the results in one large gathering post.

Posts like that are great places to go for relevant information. The experts featured are people practicing SEO every day. So whenever they get asked about what they’d do if they were just starting out, they always share the most current and updated advice.

Furthermore, I actually encourage you to look for similar “how to learn SEO online” posts in the future. If not Ayodeji then someone else will surely repeat this group interview thing in a couple of months or so.

2. Link building strategies at Point Blank SEO

Point Blank SEO is one of the coolest SEO blogs in the last few years. The advice is clear, understandable, and actionable.

For instance, link building is known to be the core of SEO. In plain English, if you want to do SEO actively, you’re going to be link building a lot.

So a while ago, Jon – the founder of Point Blank SEO, published this link building strategies page.

What’s great about it is that it features quite a lot of tactics, but each one comes with a short description, so depending on how much time and dedication you have for this, you can pick something that suits you in one way or the other.

3. Fizzle and their website traffic course

Fizzle is a training site created by Corbett Barr. It provides quality, real-talk business training with no BS. It’s a paid program ($35 a month), but there’s also a $1 trial.

One of the courses available (and the library is quite big) is about website traffic. Ultimately, the reason why we’re doing SEO is to get traffic. Good search engine rankings on their own are pointless if they don’t bring traffic, right? And it just so happens that Corbett knows a thing or two about traffic. After all, he’s the guy behind Think Traffic.

The website traffic course at Fizzle is video-based and consists of 16 lessons. Everything is laid out nicely and easy to follow, just what a beginner needs.

Feel free to take advantage of the $1 one-month trial and check it out.

Action and learning

I guess that’s it for the places to go, but I’d like to take one more moment to encourage you to do some sniffing around of your own. Good SEO advice is only as strong as it is up-to-date. So, unfortunately, you need to be on a constant lookout if you want to build and retain good search engine visibility.

Oh yes, one more thing. For some additional info on how to learn SEO online and apply it to your online business, make sure to also check out these two posts: the SEO glossary – to get to know the terminology, and my guest post on ProBlogger talking about the essential SEO settings for sites running on WordPress.

If you like the stuff, just enter your name and email below to sign up to my newsletter,
where you’ll get more resources just like this one.




How to Learn SEO Online If You’re a Beginner (and an Online Business Owner)? | newInternetOrder.com

ntestIf you’ve had the chance to read The The 4-Hour Chef by Tim Ferriss then you know that he’s kind of hooked on the idea of one-pagers.

In essence, a one-pager is a very condensed resource about a given topic. It’s meant to list only the essential, and only the bits that will give you the most results while at the same time requiring the least of your input/effort.

I’ve liked the idea of one-pagers right away the minute I saw them. That’s probably because I like structured information. I like structure in general. Okay, I’m a Structure Nazi (like a Grammar Nazi only less mainstream).

Seeing that one-pagers are a great tool to convey somewhat complex ideas in a relatively easy to grasp manner, I’ve decided to use them on this blog.

My first target, as you can see in the headline – split testing and statistical significance.


Split testing and statistical significance 1-pager

Preliminary

Check statistical significance

Checking statistical significance will let you know if the results you’re getting from your split test are by any chance accidental.

For that, you can use my statistical significance calculator >>.

If your results are significant, you can name the winner and the loser of your test.

loser winner

Next step: scrap the loser, create another version of your test subject and run it against your winner in a new test. In other words, start over.

Don’t over-interpret

 

The main thing to keep in mind when split testing is not to over-interpret your results. Just because there is a winner and there is a loser, doesn’t meant that you will be able to tell exactly why the test has turned out the way it did. The reasons can be many.

It’s a lot safer to just take the results as they are, and not build theories trying to explain them. Most of the time they turn out to be false anyway. Your time is much better spent creating a new version and running the test again.

Your downloadable copy.

What’s your relationship with split testing? Do you even lift split test?


[Printable] Split Testing and Statistical Significance 1-Pager | newInternetOrder.com

WordPress 3.7.1 is now available! This maintenance release addresses 11 bugs in WordPress 3.7, including:

  • Images with captions no longer appear broken in the visual editor.
  • Allow some sites running on old or poorly configured servers to continue to check for updates from WordPress.org.
  • Avoid fatal errors with certain plugins that were incorrectly calling some WordPress functions too early.
  • Fix hierarchical sorting in get_pages(), exclusions in wp_list_categories(), and in_category() when called with empty values.
  • Fix a warning that may occur in certain setups while performing a search, and a few other notices.

For a full list of changes, consult the list of tickets and the changelog.

If you are one of the nearly two million already running WordPress 3.7, we will start rolling out the all-new automatic background updates for WordPress 3.7.1 in the next few hours. For sites that support them, of course.

Download WordPress 3.7.1 or venture over to Dashboard → Updates and simply click “Update Now.”

Just a few fixes
Your new update attitude:
Zero clicks given

Version 3.7 of WordPress, named “Basie” in honor of Count Basie, is available for download or update in your WordPress dashboard. This release features some of the most important architectural updates we’ve made to date. Here are the big ones:

  • Updates while you sleep: With WordPress 3.7, you don’t have to lift a finger to apply maintenance and security updates. Most sites are now able to automatically apply these updates in the background. The update process also has been made even more reliable and secure, with dozens of new checks and safeguards.
  • Stronger password recommendations: Your password is your site’s first line of defense. It’s best to create passwords that are complex, long, and unique. To that end, our password meter has been updated in WordPress 3.7 to recognize common mistakes that can weaken your password: dates, names, keyboard patterns (123456789), and even pop culture references.
  • Better global support: Localized versions of WordPress will receive faster and more complete translations. WordPress 3.7 adds support for automatically installing the right language files and keeping them up to date, a boon for the many millions who use WordPress in a language other than English.

For developers there are lots of options around how to control the new updates feature, including allowing it to handle major upgrades as well as minor ones, more sophisticated date query support, and multisite improvements. As always, if you’re hungry for more dive into the Codex or browse the over 400 closed tickets on Trac.

A New Wave

This release was led by Andrew Nacin, backed up by Dion Hulse and Jon Cave. This is our first release using the new plugin-first development process, with a much shorter timeframe than in the past. (3.6 was released in August.) The 3.8 release, due in December, will continue this plugin-led development cycle that gives much more autonomy to plugin leads and allows us to decouple feature development from a release. You can follow this grand experiment, and what we’re learning from it, on the make/core blog. There are 211 contributors with props in this release:

Aaron BrazellAaron D. CampbellAaron HolbrookAaron JorbinadamsilversteinAlexander HoerethAlex Mills (Viper007Bond)Amy Hendrix (sabreuse)andg, Andrew NacinAndrew NorcrossAndrew OzzAndrew SpittleaskapacheatimmerBarryBeau Lebensben.moodyBen MillerBernhard RiedlBFTrick, Billy (bananastalktome)bmbBrandon KraftbrianhoggBrian RichardsBryan PettyCarl DanleyCharlesClarksonChip BennettChoubyChris Olbekson, Chris RudzkicoderaaronCoen JacobsColin RobinsoncyoniteDaan KortenbachDaniel BachhuberDaniel ConvissordartissDaryl Koopersmith, Dave RossDavid LaiettaDion HulsedllhDominik Schilling (ocean90)dpashDrew JaynesDrProtocolsDustin FilippinidzverEdward Caissieenej, Eric Andrew LewisEric MannEvan SolomonfaishalFaisonFoofyFrankie JarrettFrank KleinGary CaoGary PendergastGaya Kessler, George StephanisGizburdtgoldenapplesgradyetcGregory CorneliusGustavo BordonihakreHelen Hou-SandiIan DunnIpstenu (Mika Epstein)itinerant, J.D. Grimesjakub.tyrchaJames CollinsJen MyloJeremy BullerJeremy FeltJesper Johansen (jayjdk)Joe HoyleJoey KudishJohn Beales, John Blackbourn (johnbillion)John FishJohn James JacobyJohn P. BlochJonas Bolinder (jond3r)Jonathan ChristopherJonathan DesrosiersJon Cave, Jon LynchJoost de ValkJoseph ScottJosh BetzJustin de VesineJustin SaintonK.Adam WhiteKailey (trepmal)KetwarookevinBKim Parsellkitchin, Konstantin KovsheninKonstantin ObenlandkoopersmithKurt PayneLance WillettLee Willis (leewillis77)lessbloatLew AyotteLuke Gedeon, Marcin PietrzakMarco CimminoMarco GalassoMark JaquithMark McWilliamsMarko HeijnenMel ChoyceMichael BeckwithMike Hansen, Mike SchinkelMike SchroderMilan Dinicmitcho (Michael Yoshitaka Erlewine)Mr PapaNaoko TakanoNaomiNashwan DoaqanNateJacobsnathanrice, Niall KennedyNick DaughertyNick HalseyNick MomrikNikhil Vimal (NikV)Nikolay BachiyskinoahsilversteinnofearincnukaganullvariableOleg Butuzov, Paolo BelcastroParhamPaul BironPaul de WouterspavelevappeterjaapPeter WestwoodPhilip Arthur MoorePippin WilliamsonplochaPollett, Ptah DunbarRami YushuvaevRasheed BydousiRayBernardrborenReuben Gundayrfair404Richard TapeRick RadkoRobert ChapinRobert Dall, Rodrigo PrimoRon RennickrpattilloRyan BorenRyan McCueSam HotchkissScott ReillyscottswebScott Taylorscribuscruffian, Seisuke Kuraishi (tenpura)Sergey BiryukovShinichiNSimon ProsserSimon WheatleySiobhanSiobhan Bamber (siobhyb)sirzoorosolarissmoke, Stephanie LearyStephen Edgar (@netweb)Stephen Harrisstrangerstudiossweetie089swissspidyTakayuki MiyauchiTakuma MorikawaTaylor Lovett, tivnetTobiasBgTom AugertoschoTravis SmithUlrich SossouvericgarVinod DalviWeston RuterwikicmsWill NorrisWojtek Szkutnikwycks, Yoav Farhi, and Yuri Victor.

Enjoy what may be one of your last few manual updates. See you soon for version 3.8!

Olanguagesne of the new features alongside the auto-update feature in WordPress 3.7 is support for “language packs”. More info about these will be coming out eventually, along with new tools for plugin and theme authors to use to manage this system (or to not have to micro-manage it, rather). A lot of this feature is yet to be implemented on WordPress.org, but the core support for it is in WordPress 3.7.

In order to use it most effectively, there’s a few ground rules that you, as a plugin or theme author, need to follow. Fortunately, they’re pretty simple.

Text-domains = the plugin/theme slug

Firstly, for language packs to work, your text-domain must be identical to the plugin or theme’s slug.

What’s a “slug”? Good question. If you examine the URL of your plugin or theme on WordPress.org, you’ll find that it looks like this:

http://wordpress.org/plugins/some-text-here

or

http://wordpress.org/themes/some-text-here

That “some-text-here” part is the slug. It cannot be changed by the plugin or theme author once the entry is created for it in the WordPress.org directory. It is a unique item to plugins/themes, and that’s how WordPress.org will be managing and naming the language files.

Therefore, your “text-domain” must be the same as that slug. In all your translation function calls, the text-domain must be there, it must be a plain string, and it must be identical to the slug of your plugin or theme on WordPress.org.

Headers

For translation to be most effective for your plugin/theme, you need to include a header in it that you may not be including:

Text Domain: put-the-slug-here

This “Text Domain” header is read and used to load your language pack files even when your plugin is not activated. This allows the headers of the plugin (like the description and such) to be translated properly when the plugin is displayed on the Plugins/Themes screen. So your international users will be able to read that text too, before ever using the code.

If you want to include your own translation files instead of using the language pack system, then this still works. The core code will look for the relevant *.mo translation files in the plugin’s directory. If you use a subdirectory, like “/languages”, then you can use a header like the following:

Domain Path: /languages

Note that the Domain Path for plugins defaults to the plugin’s own root directory, but the Domain Path for themes defaults to “/languages” to begin with. If the default works for you, then you do not need to have this header at all.

Also note that if a language file is not found for a particular configuration, then WordPress 3.7 will fall back to using the language pack system to attempt to find it. So if you only include, say, 3 languages, and there are language packs for 4 more, then those 4 more will still work.

Speaking of configuration,

Function calls: load_plugin_textdomain or load_theme_textdomain

Here is how to properly call them, with the Headers you’ll need included for good measure:

If you want to allow for translation MO files in the plugin’s own directory:

Text Domain: plugin-slug
load_plugin_textdomain( 'plugin-slug', false, dirname( plugin_basename( __FILE__ ) ) );

If you want to allow for translation MO files in the plugin’s languages subdirectory:

Text Domain: plugin-slug
Domain Path: /languages
load_plugin_textdomain( 'plugin-slug', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );

If you want to use language packs exclusively (note: WP will still check the base /wp-content/plugins directory for language files, just in case):

Text Domain: plugin-slug
load_plugin_textdomain( 'plugin-slug' );

If you want to allow for translation MO files in the theme’s languages subdirectory:

Text Domain: theme-slug
load_theme_textdomain( 'theme-slug', get_template_directory() . '/languages' );

If you want to allow for translation MO files in the theme’s “lang” directory:

Text Domain: theme-slug
Domain Path: /lang
load_theme_textdomain( 'theme-slug', get_template_directory() . '/lang' );

If you want to use language packs exclusively (note: WP will still check the theme’s own directory for language files, just in case):

Text Domain: theme-slug
load_theme_textdomain( 'theme-slug' );

Important:

  • Any calls to load_plugin_textdomain should be in a function attached to the “plugins_loaded” action hook.
  • Any calls to load_theme_textdomain should be in a function attached to the “after_setup_theme” action hook.

How it will work

Eventually, WordPress.org will have a way to allow plugin/theme authors to upload translation files. Or, it will have a way to allow users to submit their translations to them via translate.wordpress.org… Regardless, the relevant MO files will be made on some basis, and the files will be made available to WordPress users through the normal plugin/theme update process. The auto-update system will automatically download these MO files into the /wp-content/languages directory. There will be plugins and themes subdirectories under that to hold these files.

The files will be named “slug-locale.mo”, where slug is the plugin or theme’s slug, and the locale is the relevant locale information about the language (like “en_US” for example). When load_plugin/theme_textdomain is called, WordPress will look in the specified place for the relevant MO file, and if it does not find it, then it falls back to looking in the /wp-content/languages folder for it, on that named basis. If it finds it, it loads it up and uses it.

This gives the plugin or theme authors the ability to continue to manage their translations themselves, as they’ve always done, or use the new language pack system and let WordPress.org manage it for you. The language pack system has a number of advantages:

  • Users only download the languages they actually need, instead of all of them. Your plugin is smaller, the download is faster.
  • New translations can be approved and pushed as updates independently of the plugin or theme. No more need to bump the version just to get new translations to users.
  • Translations can be handled much easier, or ignored by the author entirely. Communities can (eventually) do their own translations through translate.wordpress.org.

Things like that. These all rely on plugins and themes doing translations a certain and specific way, along with properly internationalizing their code for translation.

Obviously, any code not doing this sort of thing won’t get these benefits. Well, we can’t fix everything at once. But hopefully, the most common and popular ones will do this (or already are), and they can be integrated into the system quickly and easily.

Some tools to help

If you’re a plugin or theme author, do yourself a favor and use your SVN client to get a copy of this repository:

http://develop.svn.wordpress.org/trunk/

This is the core develop repository for WordPress. It comes with the WordPress trunk code (in /src) but it also has some important tools you’ll need in the /tools/i18n directory. Note that to use these tools, you need the *entire* checkout, not just the tools. The tools make calls back into the WordPress core code to do some of the work, so the whole /trunk directory needs to be available there.

Also, those tools are managed by the core team. So keep them to date by doing an svn update every once in a while too.

Here’s one of those tools: makepot.php

And here’s how you run it:

> php makepot.php wp-plugin /path/to/my/plugin-dir plugin-slug.pot

This will scan your plugin’s directory and create a POT file for you to give to translators or include with your plugin. Theme authors, same deal, just replace “wp-plugin” with “wp-theme”.

Here’s another tool: add-textdomain.php

It will read in a file and add a proper text-domain to all translation function calls it finds. To use it, you can do this:

> php add-textdomain.php plugin-slug /path/to/a/file.php > newfile.php

The newfile.php will be identical, but all the translation calls will be fixed up and have the plugin-slug in there as intended.

The tool outputs the new file on standard output, which I redirected into “newfile.php” as you can see above. This is so that it is non-destructive by default. If you’re confident, and have backups of the files just in case, you can use it in-place like so:

> php add-textdomain -i plugin-slug /path/to/a/file.php

The original file will be replaced with the modified version. Use this at your own risk. I’m paranoid, I prefer to make a new file for manual comparison. ;)

This tool will go through and add the text-domain to any calls where you might have left it off. I have done this many times. Force of habit, or I just forget to do it, etc.

More Info

And if you’re having a hard time with making your text translatable in the code, I have a couple other posts on that topic as well. See them too.

So go forth, plugin and theme authors. Start fixing up that code. Many of you may have nothing to fix. Some of you may just need a header change. But it’s worth giving it a once over anyway. It certainly would be very nice if, as the new features begin to be added to WordPress.org, then your code was all ready and set to take immediate advantage of it, wouldn’t it? :)

Several updates to this post below!

Today at Pubcon Matt Cutts of Google once again promoted the use of autocomplete-type, a new property for web forms that works in Chrome (and possibly other browsers, I haven’t checked). Google first introduced it back in January 2012 in this post. I wanted to do this quick post to tell you to turn off autocomplete in your browser.

This test URL will show you why quicker than I can explain it in words. Please try it and come back. If you’re using autocomplete to, for instance, sign up for an email newsletter, you might have just provided that website with your full address and/or (even worse) your credit card details too. It’s as simple as adding the fields to the form and hiding them from the user…

So: turn off autocomplete until your browser has better controls on what gets autofilled.

How to turn off autocomplete in Chrome

In Chrome, go to your Settings, click Advanced, then make sure the top box here (that is checked in the screenshot) is NOT checked:

disable-autocomplete

Post Updates

  • It turns out Matt was talking specifically about requestAutocomplete, which is altogether different. This blogpost explains it best, go read it, as it’s rather cool. It effectively deals with the problem shown above by showing you what will be autocompleted! However, as you can see in the test above, you’re still vulnerable right now if you use “normal” autocomplete.
  • Safari is just as vulnerable to what I showed above as Chrome is. In fact, autocomplete is on by default in it:
    safari autofill
  • Filling credit card info requires you to focus on a credit card specific field that is not the credit card name field. This makes this feature inherently more safe, but it still means you could retrieve your personal address and much more when all you thought you were giving out is your email address or name.

This post first appeared on Yoast. Whoopity Doo!

The second release candidate of WordPress 3.7 is now available for testing!

Those of you already testing WordPress 3.7 will be updated automatically to RC2. (Nice.) If you’d like to start testing, there’s no time like the present! Try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”) or download the release candidate here (zip). Please post to the Alpha/Beta area in the support forums if you think you’ve found a bug, and if any known issues are raised, you’ll be able to find them here.

Developers, please test your plugins and themes against WordPress 3.7. If there is a compatibility issue, let us know as soon as possible so we can deal with it before the final release.

For more on WordPress 3.7, check out the announcement post for Release Candidate 1.

WordCamps are casual, locally-organized conferences that celebrate everything related to WordPress, and are a great opportunity to meet other WordPress users and professionals in your community. This has been a great year for WordCamps — there have been 56 so far in more than 20 countries, and there another 15 on the calendar before the year’s over. If there’s one near you, check it out! In addition to getting to know your local WordPress community, most WordCamps attract some traveling visitors a well, giving you the chance to meet contributors to the WordPress open source project and get involved yourself.

Here are the WordCamps on the schedule for the rest of this year.

October 25-27: WordCamp Boston, Boston, MA, USA
October 25-26: WordCamp Malaga, Spain
October 26: WordCamp Nepal, Kathmandu, Nepal
October 26: WordCamp Sofia, Bulgaria
November 7: WordCamp Cape Town, South Africa
November 9: WordCamp Porto, Portugal
November 9-10: WordCamp Kenya, Nairobi, Kenya
November 15: WordCamp Edmonton, AB, Canada
November 16-17: WordCamp Orlando, FL, USA
November 16: WordCamp Denver, CO, USA
November 23-24: WordCamp London, UK
November 23-24: WordCamp Raleigh, NC, USA
November 23: WordCamp São Paulo, Brazil
December 14: WordCamp Las Vegas, NV, USA
December 14-15: WordCamp Sevilla, Spain

No WordCamps on this list in your area? Not to worry! There are thriving WordPress meetups all over the world where you can meet like-minded people, and we maintain a library of WordCamp videos at WordPress.tv.

Get Involved

  • If you’re interested in organizing a WordCamp in your area, check out our WordCamp planning site.
  • If you’re interested in starting a WordPress meetup in your area, let us know and we can set up a group on meetup.com for you.
  • And speaking of WordCamp videos, we’ve recently enabled volunteer-generated subtitles/closed captioning of the videos on WordPress.tv to make them more accessible. Interested in helping? Check out the WordPress.tv subtitling instructions.