My first New York City WordPress meetup

Tonight, my last night in New York City, I attended the New York City WordPress meetup. Via Twitter, I got invited to the meetup by host Steve Bruner, who did a great job at organizing this meetup. With two great speakers and over 50 people attending, it was a great meetup. If I ever will be in New York again at the time of another edition of this meetup, I’ll make sure to attend it again!

First speaker was Jeffrey Way of Envato. He showed how easy it is to set up a Custom Post Type and add Custom Taxonomies and Custom Meta Boxes to it. During his talk, he came across the little bugs that often occur during development. With the help of the public, all bugs got fixed. Jeffrey did a great job pointing out lots of possibilities with Custom Post Types and his talk proved to be very interesting.

Next up was some sort of surprise speaker, Andrew Nacin. I asked him about two weeks ago if he would be in New York during my holiday. He wasn’t sure by that time, but in the end he contacted Steve to give a quick talk on the upcoming WordPress 3.3 version. It was great to meet Andrew again, the last time we met was at WordCamp Netherlands in november last year. I even got the chance to make fun of him on stage, when someone asked for his own WordPress blog. Yes, it hasn’t been updated since April 16. ;)

All in all, it was a very good WordPress meetup and I’d love to attend more in the future.

My take on code standards for snippets

Some time ago, Remkus de Vries wrote a post on standards for code snippets. I’m a true fan of the WordPress Coding Standards, so hit me if any of my code snippets are not in line with those standards. I’m not going to argue Remkus’ opinion that code snippets should be written according the WordPress Coding Standards.

He also did a great job pointing out that there is a lack of comments in (WordPress related) code snippets around the web. I tend to provide the snippets that I published with some comments, but I do not follow any standards while doing that.

The thing that triggered me to write my take on code standards, is Otto’s comment:

No. Never.

Snippets I post are not meant to be working code. They are not tested, not run, and not meant to be used as copy-pasta. Usually I type them on the fly, off the top of my head. They’re a demonstration only, to show somebody how to do something.

Also, Github is the tool of the devil.

So no, not going to happen. Not now, not ever. No.

I’m not going to reply on this statement about Github – and later on Git too. Yes, I’m a Git fan too, will get back on that later. But the main topic in his comment is very interesting.

Are code snippets ready to use?

Even with proper documentation, are all code snippets ready to use? Most of the time I can’t tell, based on just the code. The documentation adds some more value to the snippet and I’m more likely to use it.

But still, the question is: Does the snippet work? There is no way to see that the code has been tested, not to mention at what version of WordPress it has been tested. Yes, the author of the post can mention it. But we all know that code is shared in various ways, so the original post might not always be available.

A new documentation standard might come in hand here!

Introducing the @tested documentation tag

What if everyone who wants to publish ready to use snippets, adds an extra tag to their docblock to indicate that it has been tested to a certain version of WordPress?

Let me add this new tag to the function Remkus used in his post:

<?php

add_filter( 'body_class' , 'ft_add_guest_body_class' );
 /**
 * Adds a body class for guests.
 *
 * @author Remkus de Vries
 * @link http://remkusdevries.com/when-sharing-wordpress-related-code-snippets-i-can-haz-standards-please/
 * @tested WordPress 3.2.1
 * @param array $classes Existing body classes
 * @return array Amended body classes
 */
 function ft_add_guest_body_class( $classes ) {

// add 'not-loggedin' to the $classes array

if ( ! is_user_logged_in() )
 $classes[] = 'not-logged-in';

// return the $classes array
 return $classes;

}

With this new documentation tag in place, we can clearly see up to what version of WordPress the code has been tested on. If the code hasn’t been tested, then just leave out the docblock and post the snippet like you’re used to (so Otto can just continue posting his awesome snippets on the web, without having to test them ;) ).

My first code in WordPress core

It took me quite a while, mostly because I have been way to busy to keep up with everything that was changing in WordPress core. Yersterday was the big day, my first patch (#17895) got comitted to WordPress core with Changeset 18767.

The first moment I started working on patches, I knew this was a cool thing to do. I actually improved the code of my favorite CMS, which I worked with much every single day. But you are hooked once your first bit of code is accepted in the WordPress core, I can tell now! This really got me started, I am very much willing to contribute more code to the core.

And this patch also shows how the WordPress community is working as a team. My first patch turned out to be pretty good, with the advice of Andrew Nacin. That changed when Jon Cave showed at my little party and he was able – by effectively using the return calls in other functions – to strip the code until it was at the size it is now.

That shows how this thing rolls. Everyone improves the code that’s in WordPress core and the same goes for new code that is planned to go in the core.

File upload size tweaks for Gravity Forms

One thing about Gravity Forms that really bugged me and a couple of my clients, is the lack of proper file upload error handling. If a file upload fails, for whatever reason, the form just continues it’s routine, leaving the file upload behind. This is not what you want if you rely on your upload for post thumbnails for example.

It would be even better if Gravity Forms added the option to limit the file size as a setting. Reading through the support forums learned me that they are working on it, so hopefully this is just a temporary solution.

This pretty straight forward code extends the validation of a form with upload fields in it.

function custom_validation( $validation_result )
 {
 // Get the form out of the validation results
 $form = $validation_result[ 'form' ];
 // Loop trough all the uploaded files
 foreach( $_FILES as $key => $file )
 {
 if( $file[ 'error' ] == 1 )
 { // Error code 1 is a failed upload
 // Set validation to false, making the form show the warning
 $validation_result[ 'is_valid' ] = false;
 // Get the id of the upload field that failed
 $exploded = explode( '_', $key );
 $input_id = $exploded[ 1 ];
 // Set the appropriate vars inside our form
 $form[ 'fields' ][ $input_id ][ 'failed_validation' ] = true;
 $form[ 'fields' ][ $input_id ][ 'validation_message' ] = 'Upload failed. File size?';
 }
 }
 // Put the form back in the validation result and return it
 $validation_result[ 'form' ] = $form;
 return $validation_result;
 }
 add_action( 'gform_validation', 'custom_validation' );

Warning: This code is not completely tested and should therefor be considered experimental. Do not use it in a live environment, without proper testing.

How does it check for file upload size?

It comes down to a very simple check, using the $_FILES upload array for errors. Error code 1 is a failed upload, code 0 is a successful upload. I don’t really know what error code 3 is, but it seems that upon no file upload, error code 4 is set. Gravity Forms does it’s job well in handling required fields, so we’re only checking error code 1 in this code.

The way I get the id of the upload field is pretty dirty, but there is no other way I could think of right now. The $_FILES array only carries the name of the upload field, perhaps some other hack could add the id to that?

Any known downsides to this code?

If a field upload field fails, the file name is still stored inside the upload field. The user has to press a ‘delete’ link right next to it to clear it and be able to upload a new file. This is not really a problem, but it would be wonderful to have a way to clear that upload field too, next to showing the error message.

Evangelism: Hosting my first WordPress meetup

The 22nd of June, Luc De Brouwer, Johan Slob and myself are hosting a WordPress meetup in Eindhoven. Since Luc and I got to talk more and more about WordPress evangelism, this is the ideal first step in hosting WordPress related events.

Since this is the first meetup in the southern region of the Netherlands, we didn’t know what to expect. The amount of people signing up well exceeded everything we ever hoped for. Right now, we’re around 70 attendees and that number is increasing every single day.

I got to say, the program looks pretty promising.

The meetup program

18.45: Registration with coffee and tea
19.15: Introduction by Johan Slob, Coen Jacobs and Luc De Brouwer
19.25: Joost de Valk on WordPress SEO
19.55: Coen Jacobs on Custom Post Types
20.10: 3 x 5 minutes of WordPress Q&A
20.25: Break with coffee and tea
20.40: Tom Hermans on Post Formats
20.55: Luc De Brouwer on WordPress evangelism
21.10: 3 x 5 minutes of WordPress Q&A
21.25: 3 x 5 minutes of WordPress pride/cases (show-off)
21.50: Final thoughts by Johan Slob, Coen Jacobs and Luc De Brouwer
22.00: Afterparty

Location and signing up

There is still room for more attendees, so sign up at the WordCampNL website now! The event will take place in Seats2Meet Strijp-S in Eindhoven.

It’s going to be an exciting evening with lots of great talks, networking and helping each other out, that’s for sure. In case you can’t attend the meetup, you can always follow our official hashtag #wpm040 on Twitter.

WordPress evangelism

I have to say that it’s quite exciting to host such a meetup. The responses have been overwhelming and I’m really looking forward to the event.

Evangelism is a powerful thing and it is so much fun to do. It’s a way to give something back to the WordPress community, that gave me so much in the past years. I love the WordPress community, this is what I give in return.

Stick the WordPress Admin Bar to the bottom of your page!

Annoyed by the new Admin Bar that WordPress 3.1 introduced? It is overlapping the top 28 pixels of your website, but you don’t want it to be completely gone? My Stick Admin Bar To Bottom plugin snaps the Admin Bar right to the bottom of your screen.

Besides snapping the Admin Bar to the bottom of your page (wether it is displayed at the frontend or backend), it also makes the sub menus pop up, instead of down.

What needs to be done is making it look good when used with other plugins who appear at the bottom of pages, like the Debug Bar plugin. That’s planned for the next release.

Smart WYSIWYG Blocks of Content is now 3.1 compatible

Today was a big day for the WordPress community. WordPress 3.1 was released, introducing a bunch of exciting new features. Like most people, I updated some of my WordPress installations right away. One of my clients installations was running my Smart WYSIWYG Smart Blocks of Content plugin and when I updated that installation to 3.1, I instantly noticed that there was something wrong.

All of the Smart Blocks where no longer available and WordPress trimmed the post_type of the Custom Post Type to a lowercase version without spaces. Once I started the plugin, I choose to use ‘Smart Block’ as a post_type, which seemed to be a great idea back then. But with the change to a lowercase version in the WordPress queries, all of the Smart Blocks where no longer query-able, so pretty useless.

Hero of the day is Andrew Nacin, who pointed me to some code in his Log Deprecated Notices plugin, which I could use to fix this problem. Few minutes ago, I fixed the plugin, all new Smart Blocks will be using ‘smartblock’ as post_type and all the old Smart Blocks will be converted to new onces, the minute you update the plugin to version 0.4.1.

UPDATE: Thanks to Brian’s comment, I managed to fix another bug in this plugin. It is fixed in version 0.4.2 which is now the latest version available.

Don’t we all love Comic Sans?

It was Andrew Nacin’s tweet that got me thinking. Why isn’t there a plugin that gives us all the Comic Sans awesomeness that we can find, right in our beloved WordPress administration panel? That’s where my Comic Sans FTW plugin kicks in. Enjoy!

Don’t we all love this soft edged and curly font? It really adds value to all the work the Core UI team put into the looks of the WordPress administration panel. Thanks for all the feedback and exciting new features that you all mentioned in the past hours! ;)

My take on the Post Formats criticism

Aside

WordPress 3.1 will give us Post Formats. There is a lot of arguing on if themes and plugins should be able to add their own Post Formats. It is quite clear that the Post Formats serve a totally different need than everyone is thinking. In case you need to create your own Post Format, you should use a Custom Taxonomy instead of a Post Format. All of you still complaining about standardized Post Formats, should read Andrew Nacin’s excellent post On standardized Post Formats.

More information on the difference between Post Formats, Custom Taxonomies and Custom Post Types is to be found on Otto Wood’s blog: Post types and formats and taxonomies, oh my! and on Mark Jaquith’s blog: Post Formats vs. Custom Post Types.

I love the WordPress community

It’s been a while since my last post on this blog. The last two months have been filled with work, work and even more work. But that’s a good thing! My days are almost completely filled with WordPress development and I’m pretty confident that even the last few hours of the week that aren’t filled with WordPress yet, will be too soon.

Since WordCamp Netherlands (where I spoke about plugin development), I’ve noticed that the WordPress community is a community which I love to be part of. In the past years I’ve been working in many open source communities. But once I got into WordPress, the other communities look like just another computer club.

Being part of the WordPress community is different. I notice that I’m really looking forward to a new release – breathtaking moments every time the active tickets counter in Trac hits 0, feel proud of our community once the new release is there. It almost feels like a family, scattered all over the globe.

The more effort, time and dedication I invest in my WordPress work, the more I get back from the community. People are genuinely interested in what everyone is working on. And it all comes down to improving our favorite open source project.