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’.
Earlier today I was talking about how I haven’t blogged in a little while, I feel ashamed at the truth of it. So as I was problem solving with a colleague tonight I spotted the opportunity for a nice helpful quick and dirty little WordPress post.
Some times the case may arise when you have set a static page as your blog page and wish to add a small blurb above your post loop, or even some custom meta to control a few images in your layout theme? Now it’s a piece of cake just to add them into your theme. But, point is, the client’s not going to dive into that file, nor do we want them too. So what we want to be able to do is, spew out some content, and then spew out the loop of blogs.
For those of you seeking the answer, or an answer I should say. You will most likely have been frustrated for a little while that $posts->ID refers to the post loop and by default wordpress has it’s wp_query instance set to your post loop settings.
It’s easy enough to manually enter the id and grab the page however, we want to do it dynamically. so after a little digging, I came up with this solution.