Category Archives: WordPress

A Twenty Eleven trick that doesn’t work on WordPress.com blogs

Posted on
1

One of the things that bugged me since the first time I saw Twenty Eleven, is it’s lack of a sidebar on single post pages. To work around that, I tried to add the footer sidebar to the side of the single column layout. That wasn’t too hard, with a few easy CSS overrides (that even work on WordPress.com blogs, with the Custom CSS Upgrade):

.one-column #page {
max-width:971px;
}

#primary {
max-width:690px;
}

#supplementary {
max-width:230px;
border-top:0;
position:absolute;
top:220px;
left:830px;
}

#supplementary.two .widget-area,#supplementary.one .widget-area {
float:none;
width:100%;
}

Problem with this idea is that this will break the responsive design. This code should only be applied on the full size version of the theme. On any smaller screens, the footer sidebar should be shown below the content. Because my CSS uses absolute positioning, there is no way this will scale well. We need a media query here.

It would work if we would wrap the CSS code in a media query like this one:

@media (max-width > 800px ) { /* CSS GOES HERE */ }

Unfortunately, WordPress.com strips out specific CSS3 properties and characters.

Until WordPress.com supports media queries (and with that, other CSS3 goodies) we can’t fix this in a way that scales well. In case you want to attempt this, give the WordPress.com Custom CSS plugin a try. It is very close to the code they use at WordPress.com.

Twenty Twelve is now part of WordPress 3.4

Posted on
2

The first version of the all new Twenty Twelve theme has been added last night to WordPress 3.4 Alpha in Changeset 19842:

Initial import of the Twenty Twelve theme, by Drew Strojny. This time around we’re trying something different than the previous twenty-something themes, a much more minimalist approach that affords easy use as a CMS in addition to being blog-forward. More information will be on wpdevel soon. Props drewstrojny and lancewillett.

You can see a live demo, setup by James Collins: Twenty Twelve demo.

Please keep in mind that this is a very early version of the new default theme.

Many new features, changes and tweaks will be added in the next few weeks, while WordPress 3.4 is shaping up for its first beta.

Added a single character of BuddyPress code

Posted on
1

Months after my first WordPress contribution, my first BuddyPress contribution is there.

Changeset 5637 adds a single character, using a new function instead of the old deprecated one. After making this patch, I learned from Paul Gibbs that this was already added in trunk and I was simply looking at the 1.5 branch…

So, I have to work on something bigger to earn full props here. Good thing I have ticket #3929, where there is a slightly bigger patch in the works. :)

UPDATE: Paul just pushed Changeset 5646 which commits my other patch. Yay!

My first post on WPCandy

Posted on
Reply

My first post on WPCandy is now live:

Make theme standards your New Year’s Resolution
Most theme authors have their own habits. Most habits will have a positive effect on themes, or least on the time it takes to develop themes. Developers sometimes forget, though, that there are Theme Development Standards everyone should use while coding themes. Some are more obvious than others, but none of them are that hard to stick to.

My first New York City WordPress meetup

Posted on
2

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

Posted on
Reply

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

Posted on
20

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

Posted on
6

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

Posted on
1

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!

Posted on
14

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.