Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content Blocks: Shortcodes & Widgets & Nav Menus #585

Open
westonruter opened this issue Mar 14, 2016 · 34 comments
Open

Content Blocks: Shortcodes & Widgets & Nav Menus #585

westonruter opened this issue Mar 14, 2016 · 34 comments

Comments

@westonruter
Copy link
Contributor

@westonruter westonruter commented Mar 14, 2016

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

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 15, 2016

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

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Mar 15, 2016

Actually, I think we are overdue for wpdev-🍣

@danielbachhuber

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 15, 2016

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

@mattheu

This comment has been minimized.

Copy link
Contributor

@mattheu mattheu commented Mar 16, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Mar 17, 2016

Well, I'm also fine with a hangout 😄

Monday, April 4th?

@danielbachhuber

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 17, 2016

Monday, April 4th?

Works for me! We should also do 🍣 soon

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Mar 17, 2016

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Mar 17, 2016

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

@mattheu

This comment has been minimized.

Copy link
Contributor

@mattheu mattheu commented Mar 17, 2016

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

@mortona42

This comment has been minimized.

Copy link

@mortona42 mortona42 commented Mar 19, 2016

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

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 21, 2016

@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

This comment has been minimized.

Copy link
Contributor

@khromov khromov commented Mar 21, 2016

@danielbachhuber I would love to get an invite as well! 🎱

@NateWr

This comment has been minimized.

Copy link

@NateWr NateWr commented Mar 21, 2016

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

@d3v1an7

This comment has been minimized.

Copy link

@d3v1an7 d3v1an7 commented Mar 22, 2016

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

@danielbachhuber

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 23, 2016

Will there be a recording?

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

@goldenapples

This comment has been minimized.

Copy link
Contributor

@goldenapples goldenapples commented Mar 23, 2016

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

This comment has been minimized.

Copy link
Contributor

@danielbachhuber danielbachhuber commented Mar 23, 2016

Can you send me an invite?

Yep, sent!

@paaljoachim

This comment has been minimized.

Copy link

@paaljoachim paaljoachim commented Apr 17, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Apr 18, 2016

@paaljoachim

This comment has been minimized.

Copy link

@paaljoachim paaljoachim commented Apr 19, 2016

Thank you Weston!

@pingram3541

This comment has been minimized.

Copy link

@pingram3541 pingram3541 commented May 10, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented May 12, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented May 12, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented May 12, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Jun 26, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Jun 29, 2016

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:

multi-field-control

media-control

color-control

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Aug 22, 2016

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: xwp/wp-js-widgets#11

@westonruter westonruter changed the title Content Blocks: Shortcodes & Widgets Content Blocks: Shortcodes & Widgets & Nav Menus Dec 11, 2016
@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Dec 11, 2016

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

@MickeyKay

This comment has been minimized.

Copy link

@MickeyKay MickeyKay commented Dec 11, 2016

Love it! This would be fantastic.

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Jan 4, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Jan 13, 2017

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

Widget Post Elements

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.

Widget Form

And the shortcode preview then just renders the widget:

Widget preview

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

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Feb 14, 2017

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: xwp/wp-js-widgets@267498c

@westonruter

This comment has been minimized.

Copy link
Contributor Author

@westonruter westonruter commented Feb 17, 2017

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

This comment has been minimized.

Copy link

@StaggerLeee StaggerLeee commented Mar 4, 2017

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.