Chronicles of a build – qTranslate Headway Theme block 03

In my previous post I’ve detailed the creation of an Headway block that will display qTranslate language selector on the page. I will try to modify the existing block plugin to add some JavaScript to its options panel.

The objective

qTranslate can display the language selector as a drop-down or as a list of languages. I’ve added an option to decide whether the list should display horizontally or vertically and that option only makes sense for the list format; all this means that the layout mode (horizontal or vertical) should show, using JavaScript, only if the selected display mode is the list one.

Hooking in the right place

Headway might be an heavy customisation of WordPress admin area but still sticks to its basic principles and the source code is full of actions and filters developers can hook to.
The one I’m looking for is the one that’s run when a user right-clicks a block and gets the following contextual menu

Block contextual menu
Block contextual menu

When the user clicks the Open Block Options voice then the block options panel will be created using an AJAX callback and an hook, in the form of an action specific to that block type, will be triggered. That action for qTranslate block is


where for other blocks it will be

headway_block_options_<block type> 

which is nothing new but the block id set in the main Block class

<?php namespace qtblock; class Block extends \HeadwayBlockAPI { public $id = 'qtblock'; ... 

A first application

Once I’ve found the action I will hook to it to print some testing script to the page

<?php namespace qtblock; class Block extends \HeadwayBlockAPI { public $id = 'qtblock'; public $name = 'qTranslate language chooser'; public $options_class = '\qtblock\BlockOptions'; public $description = 'An [Headway]( block to display qTranslate plugin language chooser on the page.'; 

in the init method I hook to the action

 public function init() { add_action('headway_block_options_qtblock', array($this,'printVisualEditorScripts')); } 

while here my code will actually print something to the page

 public function printVisualEditorScripts() { $out = '<script>'; $out .= 'alert("Go!");'; $out .= '</script>'; echo $out; } ... 

And that’s the result

As simple a script as it can get
As simple a script as it can get

While that may not seem astonishing it took me several XDebug runs to catch the right action and solve the issue in the next paragraph.

That’s not the proper way to include scripts

Not at all. The proper way to print scripts to the page in WordPress is to use the wp_enqueue_script action hook and have WordPress deal with caching and dependencies while also allowing other plugins to do something with the scripts.
Sadly that can’t be done here because wp_enqueue_scripts has been fired already when the AJAX-built and loaded options panel for a block is shown.
This possibility gone I will elaborate on that and further develop the technique in the next post.

Code on GitHub

The resulting code can be found on GitHub under the ajax_options branch.

I appreciate your input