1) I’ll try to make note of the pattern when it happens. I’m on the later WP repo version. Do you suggest we start pulling from GH to be more current?
2) Actually, I 98% certain you can do it now with PV (plain vanilla) WP
Each shortcode’s properties would be post meta (or perhaps all the ASE components could be an array to be stored as a single post meta? whatever. But these is a way to store it).
While this probably isn’t the ideal UI / UX just hear me out, please…
Imagine a post meta box below the WYSIWYG – think Yoast’s SEO but different – that’s a list of the ASE component for that post. Every time you do an ASE Insert Component, the shortcode continues to go into the_content as it does now. But instead with this new and improved approach the only variable / property in the shortcode is a unique id. The rest of the meta data (if you will), gets added to the list in the meta box.
Note: I’m not saying the shortcode properties in the post meta_box could be edited there. They’d probably just be display only – and perhaps just the main properties would be displayed. That said, the Edit link would do what it does now, the ASE modal will layer over, the properties will fill in, and the user would edit. The difference is, the properties aren’t coming from the shortcode.
When the_content is output the [shortcode ase_id=”some-unique-id”] gets replaced with <div id=”some-unique-id”></div>. That’s it server side.
The rest of the ASE “meta data” gets passed down as either JSON or maybe even via localized (or similar). The point being, the client side js reads the JSON, builds the component, finds the id selector and appends it. There’s nothing really groundbreaking about that. In fact, that’s kinda where WP is headed, eh? 🙂
As mentioned previously, now that ASE is JSON driven, a lot of the future (?) headaches with shortcodes go away. In fact, instead of inserting a shortcode you could just insert the <div id=”some-unique-id”></div> and skip the short code. The point is, the client side js just needs a marker (aka selector) for each component. The js can do all the necessary magic if it has the selector and the JSON for that component.
Finally, I think this also allows for a couple other advantages:
1) There can be a library of “default” components for a given install that can be search – via AJAX? – within the metabox mentioned above. So instead of having to build from scratch, there can be a library of pre-configed building blocks, so to speak. Maybe along with Edit and Delete buttons next to each component in the ASE meta box list, there’s a Save To Library option?
2) If I want to *temporarily* remove a component, I can. The properties would remain safe & stored in the metabox list (until I delete them). When I want to put it back, all I would need is an input with the shortcode that I can copy from to re-paste into the WYSIWYG. So if I’m trying to decide between two or three different layouts / designs I can manually “A / B” test for my boss, or whoever. It’s not really the current all or nothing. Actually, there could also be a checkbox next to the Save to Library for Display / Don’t Display. This way I can turn components off (or no) without deleting, etc.
3) I would think backwards comparability is easier as well. “The marker” (with the unique id) is 100% independent of its properties. The properties are also all on their own (as good data / model should be). It’s then up to the js to make it work. And that’s where the logic should be any way.
Yup. I think it’s VERY possible in the current world of WP. In fact, I think this approach is #BadAss 😉