Get it All
Together

So the issue is this: I’m creating a faceted search interface for a client’s application. Rather than clutter a window with textbox after textbox, select after select, most of which they don’t use on a regular basis, my solution is to create dynamic form fields based on the user’s requests. Need to search a SKU? No problem! Need to select from a list of clients? Gotcha covered.

All of this has worked out quite swimmingly overall, but a bug was brought to my attention today that I had to share with the rest of the Internet. Specifically: users were typing their responses into a jQuery Autocomplete field and then clicking “Submit,” only to find that their response was not recorded and not passed on in the query. Annoying!!

With a bit of digging, I discovered the problem. The jQuery autocomplete UI does not allow the value of the field to be updated until one of two events is fired: “change” and “select.” Trouble is: if you go directly from typing a value into the autocomplete field, directly to the submit button, the “change” event does not have time to fire.

The solution to the problem, which I discovered on the always-helpful StackOverflow website, follows below. The gist of it is that you need to first prevent the form from submitting, double-check that autocomplete fields have been properly “change”-d and then submit the form:

I’m sure I’m not alone among developers who are continually frustrated by the lack of imagination shown for implementing the Customizer in WordPress. Sure, I have praised its existence and support its use to replace the labyrinthine system of developer-created admin pages. But then once I got into serious development work, I quickly found that having all the HTML controls handed to you means having the ability to decide how they get rendered taken away from you.

For example, I’d like to give users of my core theme the option to define the number and content of columns on their site. Doing so obviously means creating repeating fields: first, you define the user-specified number of columns, then you produce enough identical fields as necessary to define each column. In my case, that meant providing an ID, column width at various responsive sizes and of course, the content of the column.

Yes. I could certainly decide that no one needs more than four columns and just assign each column it’s own static block of controls. If there’s no Column 4, then those settings are just ignored. But this is a sloppy way to build a UI that is going to naturally lead to some confusion when changing settings never seem to have any effect. Better, then to just have dynamically created settings blocks. One drawback: the Customizer API has no repeating fields and doesn’t even include a vehicle for a button that doesn’t submit, leaving you without the option to create a JS-driven solution.

After months of frustration, I eventually found Kirki. Now, we are talking! I currently include Kirki as a Composer package into the core of my base theme, but it’s also available as a plugin for those who would be more comfortable with that solution. From the Kirki homepage:

Kirki is a Toolkit allowing WordPress developers to use the Customizer and take advantage of its advanced features and flexibility by abstracting the code and making it easier for everyone to create beautiful and meaningful user experiences.

So, it’s not an entirely new API or a replacement. It simply harnesses the power already manifest in the Customizer, but gives it a few gooses that make it a whole heck of a lot easier and more flexible to use.

Using Kirki

Kirki frees you to create forms that properly express what your theme does, rather than having to build all that functionality into your theme or worse than this, simply allow your theme to be driven by the limitations of the current Customizer UI. A full spectrum of HTML5 form elements is introduced, along with a plethora of more exotic controls. Especially useful for me – beside the repeater control – were the multicheck and radio-image controls. But there’s so many more that I’d like to play around with! Maybe for some custom implementations, I suppose.

Replacing the existing Customizer API calls with the Kirki API calls was a snap in fact, about the only confusion was that there was so much less code than before, I had to keep checking that I’d actually gotten all the controls passed over:

 // Icon Fonts:
Kirki::add_field( 'hn_reactive', array(
'type' => 'multicheck',
'settings' => 'icon_fonts',
'label' => esc_attr__( 'WeLoveIconFonts', 'hn_reactive' ),
'section' => 'icon_fonts',
'priority' => 10,
'choices' => ReactiveCustomizer::$icon_fonts,
) );

I use nine fonts from WeLoveIconFonts.com, so as you might imagine, a huge selection of code simply disappeared when this Kirki version replaced it. Who doesn’t love that??

As for building repeatable blocks of controls, this too is a simple matter:

/* 
// Columns:
*/
Kirki::add_field( 'hn_reactive', array(
	'type'        => 'repeater',
	'label'       => esc_attr__( 'Column Definitions', 'hn_reactive' ),
	'section'     => 'hn_layout_defaults',
	'priority'    => 9,
	'settings'    => 'column_contents',
	'default'     => array(
		array(
			'content' 	=> 'post_data',
			'small'		=> '9'
		),
		array(
			'content'	=> 'default',
			'small'		=> '3'
		),
	),
	'row_label'		=> array(
		'type'		=> 'text',
		'value'		=> 'Column'
	),
	'fields' => array(
		'col_id' => array(
			'type'			=> 'text',
			'label'			=> esc_attr__( 'CSS Column ID', 'my_textdomain' ),
			'description'	=> esc_attr__( 'Any XHTML-compatible ID you like', 'my_textdomain' )
		),
		'content' => array(
			'type'			=> 'select',
			'label'			=> esc_attr__( 'Content', 'my_textdomain' ),
			'description'	=> esc_attr__( 'Specify what kind of content will go in this column', 'my_textdomain' ),
			'choices'		=> $this->content_choices(),
		),
		'small' => array(
			'type'			=> 'text',
			'label'			=> esc_attr__( 'Cols at small', 'my_textdomain' ),
			'description'	=> esc_attr__( 'How many grid columns this column takes up at small and up sizes.', 'my_textdomain' ),
		),
		'medium' => array(
			'type'			=> 'text',
			'label'			=> esc_attr__( 'Cols at medium', 'my_textdomain' ),
			'description'	=> esc_attr__( 'How many grid columns this column takes up at medium and up sizes.', 'my_textdomain' ),
		),
		'large' => array(
			'type'			=> 'text',
			'label'			=> esc_attr__( 'Cols at large', 'my_textdomain' ),
			'description'	=> esc_attr__( 'How many grid columns this column takes up at large and up sizes.', 'my_textdomain' ),
		)
	)
) );

I have so far found Kirki to be exactly the tool that I need, until of course WordPress comes up with their own solution.. and who knows when that will be?

It happens from time to time that we need to associate Models which do not share a common key. An example of this is when I needed to associate pages with templates in a complex join where the PageSettings Model has a primary key of pageid and the PageTemplate Model has a primary key of template_id. We cannot use the primaryKey index of the association array to indicate the relationship, so we need to bypass that index altogether and instead use ‘conditions’ to specify the relationship as follows:

var $hasOne = array('PageTemplate'	=> array('foreignKey' => false,
								       'conditions'	=> array('PageSettings.page_template = PageTemplate.template_id')));

Note also that the ‘conditions’ clause is set using explicit conditions, inasmuch as we are stating that the PageSettings.page_template in the current query should be the same as the PageTemplate.template_id value. I’ve personally been confused in the past, thinking that the ‘PageSettings.page_template’ => ‘PageTemplate.template_id’ formula would naturally be the preferred way of forming the condition in CakePHP. Certainly, that would make sense based on convention, but for reasons I’m not familiar with, this is not how they do it.

Another post in my Development Walk-Through Series, following me through the development of my own application to share my thoughts and observations. Please consider subscribing to my feed if you find this information helpful.

Now that you’re working on your Models in Phase Two of your development process, you have a second opportunity to trim up your database. Once you start putting together CakePHP queries, it quickly becomes obvious that CakePHP will arrange your queries according to it’s own sense of MySQL rather than what you might have originally thought. This means that the database development you did in Phase One will have to be altered a bit.

But the way you put together queries is also important. For example, when assembling the [‘conditions’] array within your query, the order in which you specify the conditions is directly reflected in the way the conditions are built into the query.

Why is this important? Well for a start, because if you’re using any multi-column indexes, those indexes rely on the order of columns in the query being in the same order as they appear in the index. Without the correct order, they simply cannot be used. I don’t have any proof to back this up, but it stands to reason that this fact may point the way to another tweaking possibility: that the order of columns probably matters regardless of whether or not you use multi-column indexes.

The take away from this is that when you create queries in the CakePHP manner, it’s important to look at the resultant query and make sure it’s behaving the way you expected it to. If you can tweak the query, do it. If you cannot, it’s probably time to rethink some of your optimization strategy to better reflect the reality of the system in which you are working.

If you’ve been reading through my Development Walk-Through Series, this is Part II. Part I can be found here.

I’ve spent long hours tweaking my database, reading up on relatively arcane MySQL tuning techniques, filling the database with dummy values, querying, checking, requerying. I’m reasonably certain that the database structure I’ve chosen is the best option for my application. At least, that’s the way it appears for now: databases always change over time, so it’s worth keeping a loose hold on your concept of “acceptable.” Now it’s time to start putting together the CakePHP side of the show.

And what’s the first step? Well, once you’ve uploaded your files and established a connection to the database, it’s time to start building the models[1. The process for uploading and setting basic configuration of a CakePHP installation is well-documented and we shan’t go into detail here.]. Models are the CakePHP expression of your database structure and relationships. By properly building and configuring your database model files, you can speed the development of new database queries by allowing CakePHP to do a lot of the lexical heavy lifting. Instead of spending time getting frustrated trying to figure out what’s wrong with this code:

SELECT ratings.rating ratings.category
FROM `ratings_entries`
JOIN `ratings` ON ratings.rating_id = ratings_entries.rating_id
WHERE ratings_entries.cmp_id = %cmp%
	AND ratings_entries.zipcode = %zip%
	AND ratings.cat_id = %cat%"

You can simply create the relationship in rating.php, add the WHERE conditions to an array of variables and let CakePHP build the query for you[2. By the way, the problem with the example MySQL is that there is a missing comma (“,”) between ratings.rating and ratings.category].

But there is an inherent difficulty and almost contradiction to the way CakePHP’s documentation explains building your first app. Namely, the CakePHP docs show you how to build a model, then a controller and finally three separate view files for each individual database table. This is a simple setup aimed at producing a working model, not an optimal example. For a start, you may not necessarily need to use controllers or views for every single database table. Beyond that, it is not at all practical to have to create a model, controller and view for every single table just to find out if the models you’re building are working or not. The contradiction is that, while models, controllers and views should be independent, the example forces them into an uncomfortable marriage.

The solution for your model testing needs is to create one controller and use the $uses variable to its best advantage, including all the models you need into a single location. This may be – and almost certainly will be – entirely too many models for any one practical controller in your application. But this is a short-cut method aimed at bringing in all your data models and working with them. Whereas the example application shows you the following basic configuration:

var $uses = array('Ratings');

You can instead load all your models into this single controller:

var $uses = array('Ratings','RatingEvents','KitchenSink');

Now you can test your basic queries and make sure they respond the way you expect. You can have a quick check for lexical errors in your PHP without having to build three other PHP files before you get started. In short, you can develop just the models and leave the controller and view development where they belong: in the controller and view development steps.

I must stress at the outset that this post is merely my thinking out loud about a subject that has been on my mind with my new CakePHP project for some time. I do not claim any particular prowess with MySQL especially, but have discovered something rather interesting while trying to tune up my database.

I have made the point in posts past that building a new application with CakePHP is all about creating a proper database. Well, over the course of months (since, having a full-time job, I don’t get to work on my project as much as I’d like), I’ve been developing what I’d hoped would be a well-normalized and efficient database. However, the question remains unanswered until you’re able to build a test fixture and start benchmarking your queries. In my case, since the new project is in fact a ratings system, the application relies heavily on performing averages.

Thus one additional question is: does calculating in MySQL perform better or worse than calculating in PHP? It stands to reason that there might be some performance variance between the two, just because they’re two different things and therefore one might assume that they might approach the same relatively simple task in different ways. However, using my test fixture, I’ve found that at least in the relatively simple case of doing averages, there’s really no performance difference between the two.

The test fixture I created selects a random but still predictably-valid set of criteria for a given query and performs the query one hundred times in a row. In the case of the MySQL calculations, it then simply returns the microtime difference between the start and end of the query each time (to create a stopwatch effect). In the case of the PHP calculation routine, it performs the averaging calculation and then returns the same stopwatch value. In each case, the stop watch times are then averaged after the loop is finished to arrive at the final average calculation time. This test is then performed ten times in a row to account for variations between the various random samplings. Pseudocode is below:

for 10 iterations:
    for 100 iterations:
        get microtime1
        query database
        (if php) average values
        get microtime2
        stopwatch[] = microtime2-microtime1
    end iteration
    average stopwatch values
    return stopwatch average
end iteration

It should be noted that the database I’m using is very simple and holds a relatively trivial amount of data. I filled it with over half a million records among 7 tables, but the lion’s share are in the tables that require calculation, which is just two tables. The database after all that data still only holds about 19Mb of data. Its also worth noting that the table on which I’m performing calculations holds only an ID, a category ID and the calculated data. This was by design because of MySQL performance tips provided in this well-viewed video by MySQL guru Jay Pipes.

I may find that other configurations, such as adding or removing indexes, may yield different results. I’ll be posting my findings as I go, since that’s what this blog is all about.

As always, WordPress continues to hustle through, onwards and upwards, towards their latest release. Looks like there will be a lot of concentration on media uploads in this new version, based on the polling data. Even cooler is the newest “trash can” feature for deleting posts:

via WordPress › Blog » 2.9 Features Vote Results.

Lower ranked features aren’t off the radar, but may take lower priority than some other (non-media) features we have in the works. One of my favorite 2.9 features is in trunk now, and changes the way we delete content. Goodbye, annoying popup asking me if I’m sure I want to delete a comment/post/etc. Hello, fast and quiet removal into a trash can, from which the content can be retrieved if it was deleted by accident. Think Gmail style. We’re also hoping to work on improving page management, though that has a number of technical issues that may cause it to be a 3.0 feature instead.

Back on the media thing, it would be nice if they expanded the media API to allow us developers to access the Media Library outside of posts. This might, for example, allow us to build themes with custom header images that users could upload to their Libraries and select on a config page. For myself, I would love to be able to update the DFE News Harvester plugin to include the option to use an image from the user’s Media Library.

The question is: how much of what they choose to do going forward is based on popular vote? Much of the WP community is non-developer, so while their opinion is important, its not the best way to push the platform in new directions.

I’m hoping a list of new features will be released ahead of development, just so we can take a peek.

The WP folks are announcing the latest version of WordPress will be released some time later this month.  Granted, there’s not a lot left in the month and they’re only just beta testing now, but nevertheless they plan on releasing this month.  The new features are exciting to contemplate, but especially helpful to us developers is the new Widget schema:

via Version 2.8 « WordPress Codex.

WP_Widget is a class that abstracts away much of the complexity involved in writing a widget, especially multi-widgets.

They’ve basically created a new class from which all new plugin widgets can be produced.  This is, as noted, especially helpful when you want to have more than one instance of the plugin on the page at any one time.  The process for this has previously been laborious enough that I haven’t bothered to write any such thing into any of my plugins.  Of course, such labor-intensive duplication is silly when you use a language capable of near-OOP programming and apparently the powers that be WordPress now agree.

I just thought I’d write a note about the new Favorite Actions bar in the new version of WordPress. This seems to have been designed as a way to mollify the concerns of the people who used to like the old layout of the administration areas better. But it’s a handy little shortcut to important things and of course, there’s a natural tendency as a plugin developer to want to utilize this space for your own plugin.

In fact, I was looking up how to do this very thing when I happened upon this page. The author cautions, quite rightly, that using this shortcut bar too much will end up clogging the thing and making it useless.

So, it seems to me that the responsible solution for plugin developers who want to make use of this new space would be to make it an option of your plugin which is always disabled by default. Doing so would allow your plugin users to make their own choices about which options to include in the favourites and which to leave as standard options. It is, after all, called a “favorite” actions bar.

In fact, I am hoping that future iterations of the WordPress core will include options to make this bar genuinely customizable according to your own preferences. The combination of a customizable favorites list and optional inclusion of plugin functions would represent the best of all possible worlds for this easily abused space.

OK, so I realize that the official stable version of WPMU is not out just yet.  But still and all, I’m running the latest beta on this site and it’s quite stable so far.  I’ve not seen so much as a single error yet.  Then again, the day is still young, so to speak.

Of course, this marks WPMU’s foray into the new admin layout and while it’s markedly different than the previous two itterations, its slowly revealing itself to be a real improvement to the system.  The last revamping was really just a reimagining of the same basic WP layout and maybe not quite bold enough to be a real usability improvement.  They rearranged some things and changed some font sizes, but ultimately it was the same top nav design.

Now that we’re into the left hand navigation style, I think it’s going to work.  My one complaint is that it would be better if we were able to move stuff around, either within the submenus or moving top-level stuff where we want it in the list.  I can’t tell you, for example, when the last time was that I used the “Links” for anything at all on this or any other site.

There’s a bunch of new features as well, including a quick post area on the Dashboard and the ability to reply to comments on the comment moderation screen.  Both of these things will be welcome additions to the site, especially my political site.  Having to constantly go to the front page, click the article and then reply has been a source of endless irritation in the old version of WP.  Jotting down quick notes to the world is more easily accomplished from the Dashboard while you’re working on other things.  That’s handy.

There is also a more intelligent “Publish” window to the right of the writing window on the Add New Post screen.  Now the buttons in this section more closely reflect the status of the article you’re working on, displaying “schedule,” if you’ve set it up as a post-dated post, or “update” instead of “save draft” if the article is already published.

What I’ve not yet had a chance to do is actually crawl through the changed code and figure out neat new stuff to do.  For example, it appears as though most of the menus are considerably more configurable than they’ve been in the past.  Adding new menu items to the Add Post screen should be much easier going forward. There are more options for site administrators in WPMU 2.7 as well, allowing you to set parameters like new blog defaults and such.

I’ll definitely report back as I discover things.