Content Blocks: Shortcodes & Widgets & Nav Menus

[westonruter]

I recall talking a conversation at some point with @mattheu regarding how shortcodes (as enhanced by shortcake) are a great candidate for the much-mused “content blocks”. I believe in this conversation it was also suggested that widgets (and nav menu items to a limited extent) are just another side of the same coin. I've been wanting to tackle a rewrite of widgets for awhile now to make them JS-driven (#33507). This now has a dependency on adding JSON schema information to widgets to allow their PHP-serialized instance data to be reliably represented as JSON (#35574), and this in-turn now seems to have a dependency on the Fields API which can be used to specify the schema and also dynamically build the form control via JS.

All of this to say, and forgive me if this all been hashed out previously, to me it seems that the Shortcake project has a lot of overlap with Widgets and the Fields API. Shortcodes could even be implemented as widgets, where the shortcode name is an alias for the widget type (class or id_base), and the shortcode attributes can be passed in directly to the_widget as instance data.

I wanted to open an issue to start a conversation and dump some ideas I've had for awhile, if at least to direct me to where I can join an existing conversation.

Some related Trac tickets:

• #33507: Allow widget controls to be JS-driven
• #35574: Add REST API JSON schema information to WP_Widget
• #28580: Speed up customizer by lazy-loading controls and settings as needed
• #35669: Store widgets in a custom post type instead of options
• #33473: Shortcodes + Widgets. Unified "component" API (aka Content Blocks)

[danielbachhuber]

@westonruter Maybe we could schedule a hangout in the near future to discuss at depth?

[westonruter]

Actually, I think we are overdue for wpdev-:sushi:

[danielbachhuber]

Good point. @mattheu can you make it to Portland anytime soon?

[mattheu]

Agreed - there are definitely some commonalities between all of these projects. And we've quickly run into the limits of standard shortcodes - I think the concept of using widgets stored as a post type would be a great solution for this.

Also would be great to be able to build the forms with the Fields API using standardized schema.

Would be good to hang out - but Portland is a little far for me ;)

[westonruter]

Well, I'm also fine with a hangout :smile:

Monday, April 4th?

[danielbachhuber]

Monday, April 4th?

Works for me! We should also do :sushi: soon

[westonruter]

@mattheu night owl or early riser? :smile: http://time.is/compare/0800AM_4_April_2016_in_Portland,_Oregon/Nottingham

[westonruter]

It looks like the Trac ticket for this is https://core.trac.wordpress.org/ticket/33473

[mattheu]

Later is usually best for me - any time 16:00-21:00 UTC is good

[mortona42]

Hi, I'm very curious about this conversation. I'm a relatively new WP dev, with lots of Drupal experience - lately I've been very interested in component driven design and providing flexibility for content authors to add these components to their posts.

Shortcake does scratch the itch, and I can see how projects like shortcake bakery can allow us to start creating shared component repositories. I'm curious how the other approaches like Widgets differ and what the WP community is more inclined to use.

[danielbachhuber]

@mortona42 You're more than welcome to join our Hangout. I've sent you a Google Calendar invite. We'll be using the Hangout link on the invite.

[khromov]

@danielbachhuber I would love to get an invite as well! :8ball:

[NateWr]

I'd like to get an invite. I usually have a meeting Monday evening but it's short so hopefully won't clash.

[d3v1an7]

@danielbachhuber Would love to listen in, but timezone difference might be difficult to manage. Will there be a recording?

[danielbachhuber]

Will there be a recording?

Probably not. We'll do our best to take notes / produce a summary for afterwards.

[goldenapples]

I'd like to listen in on the call as well... been thinking about this problem but haven't come up with a good solution, and I'd like to catach up on discussions that have been happening elsewhere. Can you send me an invite?

[danielbachhuber]

Can you send me an invite?

Yep, sent!

[paaljoachim]

Would it be fitting with a make core forum post summery of the hangout discussion? I bet a lot of people would like to read the summery and perhaps partake in a followup discussion.

[westonruter]

@paaljoachim here are the notes from the call: https://docs.google.com/document/d/1dxR5AUpC4RR-UKgWD_e6qTnB9XSEdNCrDdhT47QDikY/edit

[paaljoachim]

Thank you Weston!

[pingram3541]

Just wanted to add, after reading the notes, that I fall into that "faction of devs that hate shortcodes fundamentally" only because the lack of UI and the fact that WP renders raw shortcodes on the front end when it otherwise doesn't know what to do with them thus providing a public view of all the nasty bracket notations. Visual Composer has been mentioned and I'm sure we've all seen a page render when that plugin is disabled and what the result on the front end is, well embarrassing tbh and when there IS a strong enough case to reveal actual brackets in the front end content, another mechanism should be provided to allow for this but let's not simply puke out this garbage otherwise.

Additionally, the fact that shortcodes often reside within the content, filtering mechanisms also contribute to this dislike of shortcodes as I find myself more often inconvenienced by unwanted line breaks, p tags, stripped elements such as empty spans etc. vs the word processor experience as a writer because some other plugin or theme author introduces this filtering and I have no way to control it without writing my shortcodes to completely un-register all shortcodes, render my shortcodes unfiltered, and then re-register the rest back in. Otherwise, there is no safe way to "protect" shortcodes because of the playground in which they exist natively.

The idea of using the widget UI for shortcodes in intriguing especially when considering the customizer and benefit of live editing on the front end but I'm curious about cpt storage specifically in regards to post meta which is sanitized. For storage of shortcode atts not initially a big deal but what about storage of inner content that could break due to the sanitization process...or would that reside in the cpt content which could also fall victim to the filtering mechanisms again?

Or maybe I'm missing the boat on this entire discussion?

[westonruter]

The idea of using the widget UI for shortcodes in intriguing especially when considering the customizer and benefit of live editing on the front end but I'm curious about cpt storage specifically in regards to post meta which is sanitized. For storage of shortcode atts not initially a big deal but what about storage of inner content that could break due to the sanitization process...or would that reside in the cpt content which could also fall victim to the filtering mechanisms again?

@pingram3541 a widget shortcode could just have the widget ID as its sole shortcode attribute, and so there wouldn't be the problems currently faced with data in shortcode attributes being corrupted in the TinyMCE editor.

[westonruter]

FYI: Current state for implementing JS-driven widgets, with with forms being re-usable JS components, can be found at https://github.com/xwp/wp-js-widgets

[westonruter]

I've also created a new repo for a project to be able to add post/page-specific widget areas to content in the Customizer: https://github.com/xwp/wp-customize-content-widgets The readme outlines how I think it can work.

[westonruter]

Re:

Todo: Allow Customizer controls to be used outside the context of the Customizer.

See #29071: Make it easier to include an instance of the Customizer outside of customize.php

[westonruter]

I've fleshed out several examples of embedding Customizer controls in a standalone way, including multi-field controls and making use of the new control notification API in 4.6-alpha to manage the validation state: https://github.com/xwp/standalone-customizer-controls

Screenshots:

[westonruter]

I've just opened an issue on the JS Widgets project (a next-generation of widgets in core) to propose that any JS Widget defined be automatically made available as a Post Element: https://github.com/xwp/wp-js-widgets/issues/11

[westonruter]

I see this as being a key focus area for 2017.

[MickeyKay]

Love it! This would be fantastic.

[westonruter]

I just released JS Widgets v0.2.0 which includes JS-driven adaptations of all the core widgets (aside from Links), as well as a Post Collection bonus widget. Another standalone widget plugin called Next Recent Posts Widget takes the concept of JS widgets a step further and uses client-side JS templating for rendering the widget as well, implementing instant updates to changes. In this widget, selective refresh used to obtain rendered REST API data, while the raw value is used until the rendered data is returned. So this means that when entering -- into the widget's title will result in -- appearing in the rendered widget while waiting for the server to return with — that wptexturize applies. I think it's ready now for development to be done on integrating JS Widgets into Shortcake as their own distinct Post Elements.

[westonruter]

A PR is now open for JS Widgets which makes all widgets (that subclass WP_JS_Widget, which the plugin does for all core widgets) available as Post Elements via Shortcake: https://github.com/xwp/wp-js-widgets/pull/32

The JS widget Form gets embedded into the shortcode UI form and the widget instance data is stored as JSON in an encoded shortcode attribute.

And the shortcode preview then just renders the widget:

This is the first time I've tried extending Shortcake with a custom field type. There are some outstanding todos in js/shortcode-ui-js-widgets.js for some glitches with the integration. Also, the way in which the form is embedded seems somewhat hacky, making use of a hidden input that the JS Widgets Form component syncs its value with.

I'd very much appreciate your feedback and code review.

[westonruter]

There are some outstanding todos in js/shortcode-ui-js-widgets.js for some glitches with the integration. Also, the way in which the form is embedded seems somewhat hacky, making use of a hidden input that the JS Widgets Form component syncs its value with.

FYI: I've figured out the missing piece here in how to define a custom View for a given field: https://github.com/xwp/wp-js-widgets/pull/32/commits/267498c4ff2b6f8229dd6e8f41c96fca593f5589

[westonruter]

Just released JS Widgets 0.4.0 which now features full support for Shortcake and being able to use widgets as post elements: https://github.com/xwp/wp-js-widgets/tree/0.4.0#changelog

[StaggerLeee]

A PR is now open for JS Widgets which makes all widgets (that subclass WP_JS_Widget, which the plugin does for all core widgets) available as Post Elements via Shortcake: xwp/wp-js-widgets#32

Hi @westonruter . Sorry for offtopic. Can you put all these examples in Shortcake Wiki ?