As a developer, the problem and solution are usually quite clean-cut (such is the nature of code, prodominantly). The solution, however clean-cut it may be, isn’t always visible when approaching a coding task. At times like those, I employ a theory:

Whatever you do to figure out the solution, whatever pencil-tapping or repeated contact between your head and desk occurs, the end result will work and be exactly as per the task set out to you.

Knowing this, the task of achieving the goal becomes seemingly less stressful and a bit clearer to tackle. In addition, I find it important to clear one’s head, move away from the problem for a few minutes and give it some thought from a different angle.

That’s my theory, anyways.

Stop. Think. Re-evaluate.

Over the last few weeks, WordPress plugin development has become one of my favourite things to do. I find it exciting to be able to create functionality, incorporate it seemlessly into the WordPress system and see it work smoothly with the other modules. While plugin development for WordPress is incredibly powerful, it also carries with it a few areas where people commonly stumble over and potentially lose interest in their code… which could be the next big thing. Here are a few guidelines I’ve picked up in order to step over the stumbling blocks.

1. Understand actions, filters and hooks, where to use which action and their limitations.

Actions, filters and hooks are what allow developers to insert their code into virtually any part of the WordPress system. While there are only almost 400 hooks documented, there are in fact around 800 hooks in the WordPress system. The WordPress codex has a great reference for actions, filters, hooks and how to use them.

2. register_activation_hook() does not function the same way as add_action().

While looking through the WordPress forums, the register_activation_hook() function (runs the function you pass to it when the plugin is activated) has come up as a regular topic of conversation. Users are attempting to display text on activation, using it as if it were the add_action() function. register_activation_hook() does not function the same way. The function, the way I understand it, works in an almost overall scope, not having access to variables within your plugin for display purposes. In short, don’t try to echo or print variables with this function. It won’t work. The function is best used for doing common setup such as installing database tables, setting default options, etc.

3. Use dbDelta instead of mysql_query or $wpdb->query() when installing database tables.

The dbDelta function (which you pass your database query to) is used when installing tables into your WordPress database. It is also used as an upgrade script in the same area. Don’t forget to include the WordPress upgrade script before running dbDelta(). The include looks like this:

require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

4. Understand the scope of your plugin and work within it.

As mentioned above, WordPress plugins can be used to hook into essentially any area of the WordPress system. This includes standalone menus, as well as running actions when a post or page is saved, for example. Understanding the objective/s and scope of one’s WordPress plugin is essential to choosing the correct approach for the plugin. If it’s a short plugin with specific objective, there’s no need, in my opinion, for more than one or two files. Keep it simple. On the other hand, if the plugin is a large, standalone module, I don’t believe there’s any reason to have cluttered files of hundreds of lines of code, where an Object Oriented approach would ultimately serve as a much cleaner and more extendable solution.

5. Plan, plan, plan.

Planning on paper, drafting a code map on screen, talking it through with other developers. Planning a plugin can never be done too much. It helps with all of the above steps as well as helping to see where you need to be at the end of the development and planning a solid roadmap for the journey to get there. Also, other users may have ideas that could streamline your plugin even further.

These are just a few things I’ve picked up on my WordPress plugin development journey. I’ll post more if and when they come up. I hope these tips are useful and help in overcoming the potential stumbling blocks when getting started with WordPress plugin development.

If you’ve ever coded for a system that is build in a convention you’re not used to (for example, coding using a MVC framework, if you’re not used to it), this concept will begin to make sense. It refers to the almost complete paradigm shift required when approaching an unfamiliar coding framework or system. Here are a few things that I’ve found ease the process of coding with the other side of your brain.

1. Find people who code using the other side of their brain, more often.

Knowing one or two people who are used to the particular environment in which you are coding can be invaluable. It’s most useful, I believe, with those smaller tweaks and refinements that you may need to make… or the small and unexpected bugs in your code.

2. If the system has a user guide, keep it open.

User guides can often be bloated and unusable. If the documentation has a function reference and a brief explanation of the concepts behind the system, you’ve got it.

3. Pay attention to coding conventions.

If the original designers of the system are coding in a particular convention, stick to it. There’s usually a reason for the convention and sticking to it will save you time and potential future re-coding anyways.

4. Try to lay as much groundwork as possible before integrating the system with your code.

Pay attention to the finer details of the system and try to view the system on a more abstract level. This will enable you to see the bigger picture and to code or style any areas you may need to back-track and do at a later stage.

I hope these short tips are useful. If you have any to add, please add them in the comments.

Does this make for a good CMS?

Yes and no, in my opinion. On the one hand, it affords a wider audience the opportunity to create a customised CMS that allows for more streamlined updating of content. On the other hand, however, would this cause an effective “end” to programming on the web?

I believe a good CMS is one that achieves balance. The ability for users to be able to create custom content types with ease (possibly point-and-click) as well as all the essential core elements (content hierarchy, user management and authentication, etc) being taken care of. In addition to this, the ability to allow developers to hook in their own custom-written code, without having to code the core elements every time they need a new CMS for a project.

I believe the above approach is a step towards truly enabling developers. By “enabling”, I mean allowing developers to focus on the bits of code that make their projects awesome, to learn and excel at what they do.

That’s my thought for the day. What do you guys think?

http://websiteurl.com/parentpageslug/subpageslug (Note: note a real URL)

What if you require a value to be set depending on the highest level parent page? The process looks like this:

1. Get the permalink for the current page (using the global $post object).
2. Remove the website URL from the string, leaving only the full slug.
3. Split the slug into an array, using the ‘/’ as a separator.
4. The route slug should be at one of the indexes in your array (most likely index 1).

To get the information for the root page, we are going to use a native WordPress function called “get_page_by_path”. To run this function, we will declare it like this:

$root_page = get_page_by_path($root_slug);

This line returns an object (into $root_page) containing the information for the root page of the page we are currently viewing.

I’ve left points 1 to 4 up to you to work out. Everyone has their own way of coding things. If you know of a smoother or quicker way to achieve the same result, please let me know.

Thanks guys. I hope you found this quick snippet to be useful.

Perch is lightweight and easy to install and integrate into any website– new or existing. It allows the administrator to create custom content types (eg: one for pages and another for a single block on the website’s homepage) as well as providing a clean, customisable and easy to use system for the client user to work with. 

Perch retails at 35 Pounds per license. This looks like a potentially strong contender in the CMS market, despite it’s youth. I’d be keen to see a working demo version on their website. The video is quite explanatory, although there’s nothing quite like browsing through a CMS yourself on a demo version.

I hope you guys find this as useful as I have today.

View the HTML characters reference.

Just when you thought browser compatibilty testing was a laborious task, another web browser pops onto the scene. Internet Explorer conditional comments will hopefully adapt to reflect the addition of IE8, allowing users to customise their CSS and XHTML code for the specific browser… as well as possibly notify users of their browser of choice.

I’d love to read your opinions on this release. I look forward to testing IE8 and seeing how it renders my web code.

Is there one CMS to cater to the needs of any and all projects?

CMS stands for Content Management System. This is an application, usually run on the web, that allows end-users to update the content of their website with ease. It can also allow content to be added en mass and worked with by the system (for example, an events guide that only displays upcoming events). For large websites with reams of content, a CMS is invaluable in the organisation, management and authoring of content. In the web industry of today, content management is becoming more and more important, as users with to have as much control over their websites as possible, while minimizing the time spent on the phone or emailing a web developer to update their website for them.

Various options present themselves when faced with the task of selecting a content management option. A variety of pre-made systems exist (WordPress, Expression Engine, Drupal, Joomla, Textpattern, etc) that have been tried, tested and extended by users worldwide. While many of these systems have limitations to their functionality and control from a development perspective, they have been tried, tested and are maintained by users worldwide, which is a huge advantage when developing a system that will grow and flow with the constant change that is the web.

Another option is building your own CMS. While this option is an incredible approach, allowing full control over functionality, integration of a design and extension of the core, it is difficult to keep up a custom CMS with a minimal developer count on the team constructing the system and potential security risks that may have been overlooked. While a these concerns are true, a custom CMS can also be as lightweight as desired, carry only the functionality necessary and be tailored to suit the needs of each website it is used for.

There are pro’s and con’s to each decision. What are your thoughts?