Month: November 2014

Profisearchform 1.74 will come soon!

The next version of my plugin will be out soon. It will contain some bug fixes in the order-by-field but the most interesting changes will be for plugin developers, who want to extend the functionality of Profisearchform and deliver additional plugins:

Server side

As you already know, the plugin always delivers some filter hooks for you, where you can hook in with your own plugin. There will be some additional filter, to enable you to hook even better into the plugin. One of this hooks is for example sf-all-data. This filter is executed after a search is finished and just the moment before it will be delivered. This filter passes all data, which is usually send via JSON. So, you can alter this data using the sf-all-data filter. You will receive an array like this:

array(
	"post" 		=> array(),
	"result" 	=> array(),
	"head"		=> "",
	"nav"		=> array()
	
);

The post array contains the information of the search filter. The result array contains the single list elements, with the results. The head string contains the string “XX posts out of YY posts were found” and the nav array will contain the navigation list elements.

Furthermore, the single result list element will contain an additional attribute data-postID, which contains the ID of the post.

Client Side

But action hooks are always on the server-side. To give you even more abilities to write more complex plugins, which work together with Profisearchform, we have now defined Javascript Events which will enable you to hook into our plugin on the server-side.

One example: The “sfLoadEvent”

If a search is executed and the results are displayed, this event will be triggered in Javascript. You will be able to add an event listener, which will enable you to act every time, the results are displayed. So, for example, lets say, you want to display Profisearchform in masonry style and you are using a Javascript framework in order to do so. With this event, you will be able to apply the masonry framework every time the new results are loaded.

A basic script using this event:

var element = document.getElementsByClassName( 'sf-wrapper' );
element = element[0];
if(element.addEventListener){
	element.addEventListener('sfLoadEvent', function( event ){
		alert( 'Results loaded.' );
		console.log( event.data );
	}, false); 
} else if (element.attachEvent){
	element.attachEvent('sfLoadEvent', function( event ){
		alert( Results loaded.' );
		console.log( event.data );
	});
}

As you can see, this event is attached to div.sf-wrapper. So to listen to this event, you have to add the EventListener to this element. the event itself will deliver you a data object, which contains the array, which is delivered by the plugin via Ajax as well as the field values, which are used.

console.log( event.data ); will result in

	{
		"fields": 	{
					"1":value
					"2":value
					...
					"search-id":(string)
				}
		"data":		{
					//The array mentioned above
				}
	}

With these changes in 1.74 the plugin will enable you to fully customize and extend the plugins functionality to your needs. I hope, you like it.

WP 4.1: Towards improved Queries

Today, I had a look into the latest developments for the next WordPress version 4.1 and there are some heavy changes going on! Boone Georges works on the central classes WP_Meta_Query, WP_Tax_Query and WP_Date_Query. So basically the way, you list your posts in WordPress will be reshaped and you get more possibilities using these classes.

Multirelational and nested

The most important change in my eyes: You will be able to create nested and multi-relational queries. What does this mean? Boone Georges give us an example:

$query = new WP_Query( array(
    'meta_query' => array(
        'relation' => 'OR',
        array(
            'relation' => 'AND',
            array(
                'key' => 'city',
                'value' => 'Miami',
            ),
            array(
                'key' => 'state',
                'value' => 'Ohio',
            ),
 
        ),
        array(
            'relation' => 'AND',
            array(
                'key' => 'city',
                'value' => 'Augusta',
            ),
            array(
                'key' => 'state',
                'value' => 'Maine',
            ),
 
        ),
    ),
) );

This meta query consists out of two different arrays, which are related by “OR”. Each of this arrays now contains again two separate arrays, which in this case are related by “AND”. The first one is displaying all posts which contain in the meta_key “city” the value “Miami” and in the meta_key “state” the value “Ohio”. The second one is displaying all posts, which contain the city “Augusta” and the state “Maine”. And these two arrays now are related by OR. This WP_Meta_Query will output all posts which either contain Miami/Ohio or Augusta/Maine.

This is quite a boost in possibilities because until now, we where just able to create a single relationship between meta values. Now, you will be able to create countless relationships.

Reduced SQL

Sometimes, when you design a huge query, WordPress creates quite a complex SQL code. Sometimes this code is unnecessarily complex. For this issue, there will be some changes to create a more simple – and this means also quicker – SQL code. Take for example

array(
  'tax_query' => array(
    'relation' => 'OR',
    array('taxonomy' => 'tax1', 'field' => 'slug', 'terms' => 'term1'),
    array('taxonomy' => 'tax2', 'field' => 'slug', 'terms' => 'term2'),
  )
)

which results in

SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts  
INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) 
INNER JOIN wp_term_relationships AS tt1 ON (wp_posts.ID = tt1.object_id) 
WHERE 1=1 AND
...
AND (wp_term_relationships.term_taxonomy_id IN (XXX) 
  OR tt1.term_taxonomy_id IN (YYY) ) 
...

while it could be rewritten like

SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts  
INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) 
WHERE 1=1 AND
...
AND (wp_term_relationships.term_taxonomy_id IN (XXX, YYY) ) 
...

Not only the taxonomy SQL will change for performance reasons. Also the meta query will enjoy some improvements, as the issue 24093 will be addressed with the new version:

When multiple clauses are passed to WP_Meta_Query under the scope of an AND relation, a new table JOIN is required for each clause. With very large meta tables, this can lead to poor performance.
Boone Georges

Boone Georges will replace the table joins in this case with sub queries. With WordPress 4.1 a more simple syntax will be written. Thanks for this!

Other Changes

In his blog post, he addresses also other changes, he want to include into WordPress 4.1.

So, for now I will have a look into these changes and see, if my search filter plugin is still running. If so, the next thing is to think, how my plugin can benefit from these new improvements 🙂

photo credit: Huasonic cc