We’ve stated time and time again that the Ignite UI controls based on jQuery and jQuery UI are pure client-side scripts that are completely server agnostic (meaning they do not depend on the back end). So we keep saying you can use them everywhere, yet time limits the number of platforms we can cover with guides and such. There has been one article on Using jQuery Grid with PHP pretty much. We figured it might be a good time for some more. PHP itself is so tightly integrated with web content (petty much described as HTML-embedded) that every html snippet and sample you find is yours for the taking. Considering that along with JavaScript, they are the two most widely spread scripting languages, I would also assume if you do Web with PHP you probably have a decent experience with both. You can tell

It’s all good and merry when integrating with your own site’s internals, but what if you are developing for something like WordPress? It’s extremely popular and powers a decent chunk of the top websites. The thing about WordPress is that perhaps part of its popularity is due to the fact that it provides a very powerful, but at the same time very user-friendly platform to build sites on – and by that I mean a very easy interface for non-programmers, extensive admin panel, widgetized themes and a plethora of extensions. That also means that if you are in the role of the programmer you have a lot of demand and a platform to develop for

General

I think everyone are/will be quite pleased with the ways you can add functionality to WP – they all have their strengths in certain areas, but more on that later.

Let’s start with the general concept of running an Ignite UI widget in a page – you need jQuery, relevant jQuery UI and Ignite UI scripts (an awesome place to get a list of requirements for each control is to visit the Ignite UI API Reference where each control’s home page gives a detailed ordered list of dependencies or sink yer teeth in the Documentation). As you probably already know the reason I mentioned PHP is because WordPress is built with it – that means you could probably just go and output whatever and wherever you like. However, the beauty of it is that you don’t have to – WordPress kindly offers to handle a lot of that for you:

• Don’t just output script tags! Use the wp_enqueue_script() function instead – it has jQuery and jQuery UI scripts already registered, so you can simply use something like:
  

  wp_enqueue_script('jquery');

  
  There are a ton of plugins or widgets that use jQuery  already and the great deal about this is that the function will not add the library again if it’s already been included - trust me you do not want to double it, I've seen that cause errors, plus you don’t really want to try and check for yourself either, so please use this instead. Also provided are a number of additional settings to provide source location for the script and even define dependencies. Preferably save the Ignite UI control initialization scripts with whatever options you need in a script file and also queue it in the same way.
  On a side note, there’s also wp enqueue style().
• Be mindful where you include - Note that usually, scripts are added to the head of the document, depending where you do the call, however WordPress will allow mid-page calls to the function that will output the scripts in the footer instead. There’s also option to include in the footer. Use the available action and filter hooks to properly initialize those. Also make use of is_admin()to skip unnecessary script loads in admin panel, unless that is your goal.  

• No conflict – in the queue function reference there’s a chapter on the jQuery noConflict more – please be aware of that if you are using the default library. Also, in case you are wondering – Ignite UI widgets are indeed properly wrapped in a self-executing function to guarantee safe usage of ‘$’ in private scope. So basically you should only worry about your own code.

What are your options?

So how can leverage the extensibility WordPress provides? Do think of the following as concepts, I might end up doing some, but for now everything below is strictly an idea.

Shortcodes

I think those are by far the easiest to get going ( plug they are decently user-friendly) and WordPress gives you a Shortcode API. As you can see there a short code will be kind of good for adding Ignite UI widgets where you don’t require a lot of settings from the user (you provide most of the defaults) or the control itself is fairly easy to set. That is because, while the API does provide a method to have attributes, asking someone to enter 20-ish or more of them is just wrong. An example for the igRating can look like this:

[ig-rating value="1"]

And through the add_shortcode() you assign a function to this tittle that WordPress will call to replace the tag.

On the flip side, short codes can be added anywhere (pages, posts) so you don’t have to worry about proper hooks for those. The also tricky part is that the attributes don’t do camel casing, therefore you won’t be able to match the Ignite UI widget settings exactly and directly pass the encoded the attributes as options for it.

There are a lot of References at the bottom of every WordPress documantation page (which totally rocks!) so check those out, and here’s a bonus from me with an awesome video guide - WordPress Shortcode API Crash Course.

Widgets

These are also pretty popular, as their main goal is to add content and functionality to sidebars of "widgetized" themes, however since that just means sidebars are registered, so there are ways to add a ‘sidebar’ to your posts and pages (by making a new template, and then using it for new ones). Widgets are not quite as simple to implement, but again there’s Widgets API to the rescue. You have a base class to extend and a few functions to override. The end goal of course is to have something like this in the admin panel:

WordPress will be extremely kind to handle all the database work for you – serializing back and forth, and calling your functions with the ready-to-use arrays. While that totally rocks, just how many settings fields do you think would be acceptable to stick in there? I’d say not too many or you are going to have a really poor user experience. So again much like the short code – good for not-so complicated controls or when used with plenty of defaults you provide instead.

Plugins

And we reach to the most capable option to develop with – as stated the plugins “can extend WordPress to do almost anything you can imagine”. Plugins Docs can be your starting point, but there’s one that is even more interesting – the option register your own settings page with plugin options via the Settings API and have it appear in the admin panel like this:

And as you’d expect WordPress will abstract away the database plumbing – much like the Widgets options you can output a settings form and the names of inputs will become attributes of the options object you can later on request. The nicest part is that you get a whole page for your control settings ad you can really go wild here – tabs and what not and as many settings as it makes sense.

You will have to worry about hooks and what not, but I’m guessing it can be worth it.

What do you think?

So what do you think would be the most appropriate way to go with this? Do you thing that different solutions fit different controls better? Looking at the Ignite UI toolset, imagine a control being available in WordPress as whether a short code, widget or plugin – as an user, which one are you more likely to use and how? What would you do as a developer?

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev. If you have already developed anything with Ignite UI and WordPress we’d love to see your work and if you haven’t but you are interested, go for the WordPress documentation and grab yourself some UI fuel from:

Also stay tuned to see where this ends up!

And as always, you can follow us on Twitter @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!