Wordcamp 2013 Lancaster – my thoughts

Having just returned from Wordcamp Lancaster 2013, I thought what better time to write a quick round up of how I felt the weekend went than now. Having previously been to Wordcamp Portsmouth 2011 I was keen to make up for missing 2012’s Edinburgh event. I hope by providing some feedback and some relevant information to those who didn’t attend this years event in Lancaster it might help them make decisions about going in the future.

I’ve decided to break the review down into the following areas; Location, Venue, Hotel, Range/Quality of talks, Workshops and Social.

Location

Lancaster was chosen for the location of the premier UK WordPress developer event of 2013 (although it is rumoured they are also having a London based event in the winter hush, hush), affectionately (as always) dubbed Wordcamp 2013. Lancaster itself is a pretty quaint northern city with a huge University presence but when uni’s out for the summer it’s pretty quiet. Lancaster was a difficult venue to travel to for a Londoner like me, though it does have reasonable travel links via Virgin trains from London Euston. On a friday night a direct train to Glasgow stops at Lancaster without needing a change (bonus!). This is a slightly different story on a Sunday evening however, a 4 hour train ride with a change at Manchester Picadilly is what your looking to get you back to London Euston.

Venue

Lancaster university was the event venue, I couldn’t fault this. Perfect location and a nice university campus with alot of new buildings. The lecture theatres were perfectly fit for purpose. Though it was a little difficult to find the relevant area of the campus that the event was taking part in. There was some hot and cold food provided at lunch time which was a nice touch, seems as you had very little choice for alternatives.

Hotel

We stayed in the Lancaster House Hotel. This was awesome! Nicest hotel in Lancaster (apparently) certainly seemed pretty good. Great breakfast, good rooms, even better showers and a nice array of other facilities such as swimming pool, sauna and gym.

Range & Quality of talks

I like to measure the quality of an event by the amount of tangible things I walk away with, against what it costs me to be there. This years Wordcamp 2013 for me didn’t quite live up to my expectations. Despite it’s extraordinarily cheap event ticket prices (just £25 if you grab an early bird ticket) being in Lancaster I had to chuck another £300 just for travel, accommodation and food costs. I use WordPress professionally week in week out and I go to be involved in the community and learn a few things myself while i’m at it. This year I struggled to identify one tangible thing that I could look back on and say that i’ve added x to my armoury this year.

Range of talks

The good: There was a reasonable range of talks (at least in title), most of the talks were high level talks which applied to a wide range of event goers. Most of the content covered in the talks was easy going (with a few exceptions) and there was plenty of room for event goers to ask questions at the end of talks with little objection. I felt that all those giving talks did so with good delivery, well spoken and capable of answering questions to a good level at the close of the talks.

The bad: Most talks lacked relevancy to WordPress or relevancy to real life application when using WordPress, which in my mind makes it difficult for event goers to put talks into context or convert to something tangible. There was a big lack of advanced subject matter / Workshops for heavy WordPress developers to truly geek it up at the entire event. Some talks were even outright boring mainly due to their lack of relevancy or loop back to reality from theory.

Quality of talks

The quality of talks for me this year was lacking in content more so than it was speakers. I thought each of the speakers were more than capable of presenting. I just thought the talks lost focus on the audience being able to have an “aha” moment! To me alot of the talks lacked a little bit of finesse and very few added real value back to the advanced WordPress event goer. I guess I normally also expect the talkers to be those pushing WordPress to the limits or having particular expertise in certain areas of WordPress. Indeed that is at least where i’m personally likely to learn the most. This year felt like alot of speakers first talks and some of the talks came across asif the speaker hadn’t truly mastered his/her subject matter in real life situations, before giving it.

It may sound a bit harsh, and it probably is, besides, it’s always easier to sit in the audience goading the speaker, than it is to be the speaker, right!?

Workshops

There wasn’t really any. Nothing hands on anyway. Bit disappointing personally for me, though I do understand they add an extra layer of complexity to proceedings.

Social

Events and conferences alike are always good places to go and meet people working in similar fields to you. Usually you’ll find lots of friendly people and this year was no exception. There was even a social drink up in Lancaster town in the evening on Saturday night.

Will I be going again?

Probably. I guess I wouldn’t be writing this post if I didn’t want someone to read it and make it better next year.

Install WordPress From Mac Os X terminal bash/shell/terminal profile function

Sometimes staying on top of the latest version of WordPress can be quite annoying when your testing things locally or rolling out regular wordpress sites. I normally install with .svn but this is a neat little bash script function I threw together to grab the latest version of WordPress and unzip into the current directory through Mac OS X Terminal command.

Open up your

vim ~/.bash_profile

and paste the following code into it.

wp-install(){
	wget http://wordpress.org/latest.tar.gz;
 	tar xfz latest.tar.gz;
	mv wordpress/* ./;
	rmdir ./wordpress/;
	rm -f latest.tar.gz;
}

Now quit and re-open terminal or type ./profile for the changes to take effect.

CD into the desired directory and type wp-install and let magic behold you, you’ll shortly have the latest version of WordPress downloaded and installed.

Linode – My early impressions

linode logo gray Linode   My early impressionsFor quite sometime now i’ve been looking for a place to house my personal projects, which gives me the flexibility of a cloud style host but with full root access so that I may toy around with installing whatever I need.

Linode offers the ability to deploy Linux virtual servers in the Linode cloud. With it’s simple Stackscripts for quick deployment of LAMP or LEMP server stacks. You can also deploy Stackscripts with popular open source CMS WordPress, CMS Drupal and even a Minecraft multiplayer server in a few clicks.

Check out some of the awesome Stackscripts on Linode – http://www.linode.com/stackscripts/

Linode might not be the cheapest cloud based VPS you’ll find, but with it’s basic package starting at just $19.99 a mere £12 p/month it’s still pretty in-expensive.

I deployed the WordPress and Ubuntu Stackscript from Linode in a few minutes then successfully setup vhosting and my WordPress sites in not a great deal longer. So far my Linode has 16 days of uptime. Running this very blog icon smile Linode   My early impressions (amongst others)

This blog is running on an Ubuntu LAMP stack, with WordPress (Version 3.4.2 at the time of writing), fine tuned with WP Super Cache and CDN Sync Tool for fast static content delivery. It’s also fully responsive icon wink Linode   My early impressions buzzzwwooorrdddds.

One thing I have noticed since deploying my Linode is the fantastic community behind it. Unlike other alternatives, i’ve noticed Linode has an extremely knowledgeable and loyal following of fellow mostly friendly and happy to help Linux server enthusiasts. Linode has some excellent tutorials and help guides coupled with an excellent IRC channel which is almost always buzzing.

I’m so far very impressed with Linode and in comparison to AWS it provides a combination of cloud, community, help and control at a good price. AWS micro instances are cheap at about £10 p/m but do not offer guaranteed resources, where as Linode does. I also kept getting MySQL crashes on my AWS instance.

Linode even offers a generous 7 day money back guarantee.

Entering the world of mainstream WordPress Plugin development

Having written quite a few private WordPress plugins, I am now about to take on the task of creating a WordPress plugin for the general public (GPL License…obviously). It’s quite a different task from creating plugins for self or a limited use, but nonetheless one i’m looking forward to having in my own portfolio and my place of works.

I’m currently weighing up some options in terms of what to create, but at my place of work (Bytewire) we use WordPress alot for our clients and indeed many of our own projects. We have in this time come across some annoying problems which potentially a great plugin could very much help to overcome. Deciding on a feasible plugin to create is often one of the hardest things for a developer, especially so if it’s your first. I’m not venturing into making a plugin for any other reason than to help others and ticking off a personal milestone.

When developing a plugin for general public use you do have to remember a heck load more stuff, here’s some of the stuff i’m preparing my plugin to be ready for, and to handle.

Developing general release WordPress Plugins

When your developing for the general public you have to remember that your own integrity will be judged by the very integrity of your own plugin. If your plugin breaks a prospective users site, or, simply doesn’t do as it says, the user is likely to be very unhappy and potentially blacklist you as a plugin developer choice for future needs. How can you overcome these problems? Well, the simple answer is – be thorough, very thorough.

  • Make sure you check your plugin can function in a WordPress MU setup, by providing different or extra funtionality if is_multisite()
  • Comment your code well – WordPress is based on a GPL license, and actively encourages, code sharing and the ability to delve into one anothers code and make changes where seen fit. This helps with learning and extendability.
  • Debug your code – Using the WordPress functionality, make sure you debug your code so that you are not using deprecated functions or code
  • Build your plugin for the current WordPress version, do not attempt to support older versions of WordPress. As wrong as this may seem, Worpdress actively encourages this and warns all users not on the most up to date versions of WordPress they are not guaranteed a secure service unless they are. This can often be enough alone to persuade many clients and blog owners to upgrade. Generally WordPress wants to encourage upgrades as much as possible and with the possibility now to perform the upgrade in a matter of a handful of clicks, any user could do it. Suggesting to me if a user needs to use your plugin and he can’t without upgrading, WordPress effectively gets what it wants from your support as well.
  • Ensure you provide the properly formatted readme.txt file when submitting it to the plugin repository on WordPress
  • Make sure you are familiar with Subversion, you are required to use this to make changes to your plugin going forward.
  • You are most likely to find that your WordPress plugin is naturally fairly backward compatible, depending on the functions it makes use of, but as a general rule of thumb you could make sure it’s compatible with at least the last two major releases. Given that they are done on a 3-4 month basis, this would give you all users in the last 8 months by default and any that have upgraded in that time. Which is fine.

These are just a few things that are notable about diving into the world of WordPress public plugin development, there but many more. Perhaps as time goes by I will look to add to this post and grow it with my experiences. In the mean time if your a reader and you’ve got any great ideas for a killer WordPress plugin then i’d love to here from you.

How to query wordpress posts by custom meta

WordPress custom meta for posts and pages (including custom post types…obviously) can open the door to extending WordPress in many great ways.

One such way is enabling custom input areas on the backpanel for specific post types and using them to store more specific information for each project you undertake.

For example say you’ve got a wordpress project which your client needs to be able to add and edit farm animals onto their site. Great! Custom post type time I here you say.

But wait…! You can use the title for the name of the animal and the main body to explain a bit about it, but what about storing the animals weight or how many you have of that animal on your farm. Simple answer, you can’t, well least not in a nice way.

Enter custom meta.

I’m not going to get into how to add custom meta to a custom post type, or indeed any type of post on WordPress, but I will show you how to use it in a WP_Query so you can query what you’ve created on the front end.

Now lets consider querying the top 5 weight heavy animals on the farm where farm animal type = nondairy.

    $loop = new WP_Query(
    array(
        'meta_query' => array(
	    array(
		'_myfarm_animal_type' => 'nondairy',
	    )
	),
	'post_type' => 'services',
	'posts_per_page' => 5,
	'caller_get_posts' => 1,
	'orderby' => 'meta_value',
	'meta_key' => '_myfarm_animal_weight',
    )
    );

Wallah!

Great huh? Not quite farmville, but you get the gist.

I may extend this post further in the future so check back if it interest’s you.

Setting Default WordPress FTP, SSH & SFTP Details

Sometimes hosts are really un-helpful and don’t set up your WordPress ftp details for you, or maybe you set your WordPress install up yourself and WordPress is asking you for FTP details.

Either way, what you’ll quite quickly find, or have already found (hence your now here reading this post) is that downloading plugins is slick when WordPress just WORKS. When it asks you for FTP credentials everytime, well…that’s just annoying.

So how can we stop this? Well it’s pretty easy actually.

What you’ll need

  • Access to editing your wp-config.php file
  • Your host’s FTP or SFTP details

Get cracking

Open up your wp-config.php file, found in the root of your WordPress install.

Add the following if you just want standard FTP connection.

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/home/site-name/www/');
define('FTP_CONTENT_DIR', 'wp-content');
define('FTP_PLUGIN_DIR ', 'wp-content/plugins/');
define('FTP_USER', 'yourFTPUsername');
define('FTP_PASS', 'yourFTPpassword');
define('FTP_HOST', 'yourFTPhost');
define('FTP_SSL', false);

To connect with SFTP then all you’ll need to do is add to the above, the following definitions and add your credentials paths.

define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');

wordpressFTP1 Setting Default Wordpress FTP, SSH & SFTP Details

Trust me when I say this, when Wordpres just WORKS. It is a great experience!

Enqueue WordPress script on certain theme template pages only

Enqueuing scripts the proper way in WordPress can help avoid annoying javascript problems and allows us to specify dependancies of our scripts I.E. jQuery, so that WordPress may load the specified scripts before our script, thus eliminating problems.

I quite often find myself wanting to enqueue scripts into one particular page template rather than loosely across my entire site, in a vein attempt to try and keep the site as efficient as I possibly can.

So I thought I’d share with you how to achieve that.

Firstly open up your functions.php file.

if(!function_exists('register_my_scripts')):
    function register_my_scripts(){
    }
endif;

Add the above function. This function will control enqueueing scripts for your theme.
Now we must tell WordPress through registering an action that we want it to check this function when it enqueues scripts in the wp_head(); function called in the header.php file.

We can do this by adding this line of code to our functions.php file.

add_action('wp_enqueue_scripts', 'register_my_scripts');

And wollah, now WordPress will call our function when it attempts to register scripts. Now hopefully you may already be familiar with the WordPress functions wp_register_script and wp_enqueue_script

If not heres a rundown.

wp_register_script
A safe way of registring javascripts in WordPress for later use with wp_enqueue_script().

<?php wp_register_script( $handle, $src, $deps, $ver, $in_footer ); ?>

Use the wp_enqueue_scripts action to call this function, or admin_enqueue_scripts to call it on the admin side. Calling it outside of an action can lead to problems.

For further details see the wordpress wp_register_script page »

wp_enqueue_script
A safe way of adding javascripts to a WordPress generated page. Basically, include the script if it hasn’t already been included, and load the one that WordPress ships.

usage:

wp_enqueue_script(
     $handle
    ,$src
    ,$deps
    ,$ver
    ,$in_footer
);

Use the wp_enqueue_scripts action to call this function, or admin_enqueue_scripts to call it on the admin side. Calling it outside of an action can lead to problems.

For further details see the wordpress wp_enqueue_script page »

Given that you now have a reasonable grasp of whats going on lets move this forward, first we want to register our script name with WordPress and then we want to enqueue it.

This can be quite easily done with the following.

//Register our script
wp_register_script('my-script',
get_template_directory_uri() . '/assets/js/my-script.js',
array('jquery'),
'1.0' );
//Enqueue the script
wp_enqueue_script('my-script');

Put this inside our earlier defined function of register_my_scripts. First of all I register my-script and then I enqueue it in the load schedule with wp_enqueue_script.

How to do this only on a particular page?

The answer is very easily. Inside the function we can simply wrap the register and enqueue script actions with the following.

if(is_page_template('about.php')):
// code
endif;

Sweet as a nut. See below for the full finished code example.

The full thing

if(!function_exists('register_my_scripts')):
    function register_my_scripts(){
        if(is_page_template('about.php')):
            //Register our script
            wp_register_script('my-script',
            get_template_directory_uri() . '/assets/js/my-script.js',
            array('jquery'),
            '1.0' );
            //Enqueue the script
            wp_enqueue_script('my-script');
	endif;
    }
endif;

Some points

You will notice that in my wp_register_script I have used jquery as a dependancy this means that it will now be loaded by WordPress after jquery, neat huh?

You’ll also notice that I have put a version of 1.0 into the register, this is handy for upgrading the scripts to prevent caching problems, as the version is appended to the end of the file name like so:

http://localhost:8888/my-site/wp-content/themes/my-theme/assets/js/my-script.js?ver=1.0

If you make some changes and want to avoid any caching issues, simply upgrade the version to 1.1 in your code.

How to create WordPress pages with just pure PHP

I’ve seen alot of people ask how to create pages within WordPress with some simple PHP code so I thought i’d give answering it a go.

You’ll be pleased to know that the solution is pretty straight forward and nothing to strenuous.

We’ll start off by defining a function to handle creating pages in WordPress, you could use this function in your themes function file or indeed in any custom WordPress Plugin.

if(!function_exists('daves_create_page')):
    function daves_create_page( $slug, $option, $page_title = '', $page_content = '', $post_parent = 0){
        global $wpdb;
        $option_value = get_option($option);
        if ($option_value>0) :
            if (get_post( $option_value )) :
	        // Page exists
	        return;
	    endif;
	endif;
	$page_found = $wpdb->get_var("SELECT ID FROM " . $wpdb->posts . " WHERE post_name = '$slug' LIMIT 1;");
	if ($page_found) :
	    // Page exists
	    return;
	endif;
	$page_data = array(
            'post_status' => 'publish',
            'post_type' => 'page',
            'post_author' => 1,
            'post_name' => $slug,
            'post_title' => $page_title,
            'post_content' => $page_content,
            'post_parent' => $post_parent,
            'comment_status' => 'closed'
        );
        $page_id = wp_insert_post($page_data);
        update_option($option, $page_id);
    }
endif;

After defining this function we can call it into play very simply with the following.

daves_create_page(
    esc_sql( _x('example_page', 'page_slug', 'davespage') ),
    'daves_page_id',
    __('Example Page', 'davespage'),
    'Some example content.'
);

Hope this helps some people out, as you can see, pretty straight forward and unobtrusive.

Correct way to add CSS to WordPress Plugin Backend

Many of us have dabbled with making our own WordPress plugins, but what alot of people forget is we need to make sure we’re as compatible with WordPress going forward as can be.

Over the last 3-5 months I’ve really started to discover the hidden power of WordPress and today i’m blogging about another find.

It’s quite a simple topic really. Many of you will want to include your own custom stylesheets with your plugins, but what’s important is keeping the integrity of your WordPress plugin intact.

So whats the correct way to Enqueue your css stylesheet?

There is a couple of ways in which you could achieve it, but being prudent is best.
Include the stylesheet only in the admin pages that you absolutely need to, in the case of the backend, only on the submenu pages you need to.

I am of course assuming here that your pretty familiar with the plugin backend and that you know how to create sub menu pages for your WordPress plugin.

$page = add_submenu_page(
    'edit.php',
    __( 'My Plugin', 'myPlugin' ),
    __( 'My Plugin', 'myPlugin' ),
    'administrator',
    __FILE__,
    'my_plugin_manage_menu' );
    /* Using registered $page handle to hook stylesheet loading */
   add_action( 'admin_print_styles-' . $page, 'your_plugin_styles' );

This would of course normally be wrapped in a function or class, whichever your coding style prefers.

We are telling WordPress in the above example to add an action to call our custom function ‘your_plugin_styles’ on printing styles for the page WordPress object reference now contained within $page.

// Hook somethings up in our plugins init function
add_action( 'admin_init', 'your_plugin_admin_init' );

Next, I have added an action to be fired on ‘admin_init’ to call ‘your_plugin_admin_init’.

And what i’ll do inside this is call a custom_forms.css file that I need to use for some styling on the backend of this plugin. I’ve also housed it in a css/ folder within my plugin directory for convenience.

function your_plugin_admin_init(){
    wp_register_style( 'yourCustomFormCss', plugins_url('css/custom_forms.css', __FILE__) );
}

And finally we enqueue our script using wp_enqueue_style

function your_plugin_styles(){
    wp_enqueue_style( 'yourCustomFormCss');
}

And this is our working procedure.

Bringing it altogether.

We first fire our plugins init function called ‘your_plugin_admin_init’ inside this we register our css style with WordPress. Ready to be called later. Then whilst registering our menus, we tell WordPress on this admin page ONLY, to fire our custom css calling function ‘your_plugin_styles’ and from within that we enqueue our previously registered script ‘yourCustomFormCss’ using ‘wp_enqueue_style’.

Some useful links