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.
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.
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.
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!?
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.
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.
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.
For 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.
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 (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 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.
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.
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.
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
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.
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.
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.
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:
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.
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.
wp_register_style( 'yourCustomFormCss', plugins_url('css/custom_forms.css', __FILE__) );
And finally we enqueue our script using wp_enqueue_style
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’.