Wrangling with post thumbnail live editing.
Webpack I love you
The Kirki library packs a lot of punch and working with it is a breeze.
In its “punch” is included the flexibility to leave developers the possibility and joy, should they be so inclined or required, to do things their way.
One of such occurrences is the one where the “Front to Back” needs to live edit the page featured image (aka “post thumbnail”) and needs to do so using some custom JavaScript.
As soon as JavaScript came up I’ve run to webpack and set it up for the project.
Probably overkill for the time being but still useful if the project is to scale.
Setting up Kirki
The plugin decoupled the template generation from the Kirki panel, section and field registration phase and I will not go into details; relevant to the post is the fact that a call like this one will be made to the library when accessing the Theme Customizer:
Kirki::add_field( $ftb_config , array(
'settings' => 'ftb-page-some_page-featured_image',
'label' => 'Featured Image',
'section' => 'ftb-page-some_page-section-content',
'type' => 'image'
'transport' => 'postMessage',
'js_vars' => array(
'element' => '.thumbnail-id'
'js_callback' => 'ftb.replace_src',
),
));
The interesting part comes after the type line where the specified transport for the setting becomes the postMessage one and the plugins specifies a target element and a JavaScript callback.
The plugin, at template compilation phase, will translate this markup
<ftb-featured-image attr="class=thumbnail-id"></ftb-featured-image>
into this PHP markup
<?php ftb_the_post_thumbnail( '', array( 'class' => 'thumbnail-id' ) ); ?>
The ftb_the_post_thumbnail function is a wrapper around the the_post_thumbnail function to make sure either the real post thumbnail markup or a placeholder markup outputs on the page.
If the post thumbnail is defined then it will be something like this
<img
width="1100"
height="619"
src="http://wp.dev/wp-content/uploads/2016/03/150324154025-14-internet-cats-restricted-super-169.jpeg"
class="thumbnail-id wp-post-image"
alt="150324154025-14-internet-cats-restricted-super-169"
srcset="http://wp.dev/wp-content/uploads/2016/03/150324154025-14-internet-cats-restricted-super-169.jpeg 1100w, http://wp.dev/wp-content/uploads/2016/03/150324154025-14-internet-cats-restricted-super-169-300x169.jpeg 300w, http://wp.dev/wp-content/uploads/2016/03/150324154025-14-internet-cats-restricted-super-169-768x432.jpeg 768w, http://wp.dev/wp-content/uploads/2016/03/150324154025-14-internet-cats-restricted-super-169-1024x576.jpeg 1024w"
sizes="(max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 1362px) 62vw, 840px"
>
or something like this if the post thumbnail is not set
<img class="thumbnail-id" src="">
The plan
In short: everything.
To allow for a complete and realistic preview of the changes each one of the full markup attributes has to be either updated or added.
The callback function will be passed, when the image is updated, two arguments:
- the element entry (e.g. “.thumbnail-id”)
- the new image absolute URL
This is not nearly enough to update all of the attributes and a call to the back-end, to have all of the needed attributes, will be required.
But since I’m calling the back-end there I could as well leave it the task to give back some fully formed HTML markup that the front-end will be able to simply replace.
Was I dealing with a fully controlled markup I’d go intercooler.js all the way but that’s not the case so I will have to do some more work.
REST API infrastructure
I’ve already worked with the REST API infrastructure while developing the idlikethis plugin (source code here) and found it so convenient I think I will walk the same path again.
Next
I will register the needed endpoint leveraging the REST API infrastructure and implement the JavaScript code needed to have the featured image replaced live.