Hi Jonathon,
there is already a (basic) UI for shortcodes on github: https://github.com/sheadawson/silverstripe-shortcodable maybe you’re interested in this module.
Though seeing a rendered shortcode or at least a graphical placeholder in Tiny would be nice ;)
We make a lot with shortcodes like “snippets” or “show a list of events / tagged pages” and my editor loves it much.
Cheers,
Werner
Von: jono...@gmail.com [mailto:silverst...@googlegroups.com] Im Auftrag von Jonathon Menz
Gesendet: Samstag, 04. Oktober 2014 19:36
An: silverst...@googlegroups.com
Betreff: [silverstripe-dev] Re: Block editing modules
I've recently been thinking about something related to this concerning ShortCodes that could be another solution. The idea is Visual Short Code Editing and goal is to provide a simple way to insert and edit structured content in wyswiwyg fields.
I figure ShortCodes are great and powerful but too technical for most CMS users. They're not intuitive as they require memorisation of syntax and attributes to use effectively. Non-technical people want to click a button and fill out a form and have the shortcode generated in the background - like how it works with Embeds and Links.
I was thinking that ShortCodes are basically DataObjects that are stored directly in content instead of the database. So why couldn't we combine the contextual freedom of ShortCodes with the editing convenience inherent in DataObjects?
Perhaps there could be an interface for 'VisualShortCode' that could be applied to any DataObject. Then there could be an Insert drop-down menu in TinyMCE that automatically lists any DataObject types that use this interface. A pop-up form could be generated by the getCMSFields() function. Then for updating objects, it would be great if ShortCodes could be rendered as blocks in the Editor with an 'Edit' button on top of them. (This would be good for images and videos as well).
I may have over-simplified things here but I think developing a simple GUI for ShortCodes would unleash their power to a wider audience, and could provide a solution to the Content Block problem that's based on existing functionality and editing conventions. Oh and since ShortCodes are stored directly in content, they are automatically Versioned when used on a Page.
On Friday, 3 October 2014 08:51:26 UTC-6, Sam Minnée wrote:
Hi everyone,
This follows on from a discussion that was happening at the SilverStripe Europe meet-up. Everyone is talking about SilverStripe block modules!
The good news is there are already a lot of modules in this arena. However, it is one of those spaces where it's not clear which of these modules people should use. In my view, everyone is going to benefit if we join forces on one of those modules, and port the good elements of the other ones into it as pull requests. In particular, I think that we should work to have a standard interface/base-class for defining the blocks themselves, so that other module developers can contribute them. Anything else we might want to do can be construed as improvements to that system, rather than creation of a new one.
I did a bit of a survey of modules in this space and found these modules have a lot of similarities:
http://addons.silverstripe.org/add-ons/sheadawson/silverstripe-blocks (516 installs on packagist, commits from Sept 2013 - August)
http://addons.silverstripe.org/add-ons/nobrainerweb/silverstripe-content-blocks (73 installs on packagist, commits from May 2013 - now)
http://addons.silverstripe.org/add-ons/richardsjoqvist/silverstripe-blocks (39 installs on packagist, commits from April - September)
http://addons.silverstripe.org/add-ons/prij/silverstripe-modularpage (13 installs on packagist, commits from 16-23 April)
http://addons.silverstripe.org/add-ons/bummzack/page-blocks (7 installs on packagist, commits from 17-30 September)
We also have the our original widget module, http://addons.silverstripe.org/add-ons/silverstripe/widgets, and this one is a little different, closer to being able to give design control to the CMS author, as it lets them build their own grid: http://addons.silverstripe.org/add-ons/burnbright/gridstructuredcontent
Finally, @werkzeugH and @Zauberfisch showed us some work that's not in an open-source module.
Looking at this, I have a few thoughts:
1) Integrating with the draft/published cycle is really important. Right now I believe the bummzack modules does this, as does Zauberfisch's code.
2) Right now, most of these modules work by listing content blocks in a GridField. I think this is fine initially, but a more streamlined user experience where you could see the flow of content editing fields down the page would be worth looking into. I think that a UX-refresh could be done as an incremental improvement to one of these modules down the track.
3) The modules that have been around the longest (sheadawson and nobrainerweb) probably have had the most production installs, and so it's worth considering them as the basis. However, neither of these include draft/published functionality.
4) There are two broad use-cases of these modules. I don't really know what their names are, but I call them "widget side-bars" and "composite pages". Widgets tend to have much more re-use, and features like a default list of modules make sense. Composite pages tend to have larger volumes of content, and it's better to be able to see the content in the context of everything else on the page (as opposed to buried in a GridField). However, it seems like we don't need to have two completely separate systems for managing those.
...anyway, this is really just to share some notes and start a discussion. I think a logical next step will be to assess the functionality / status of the existing modules.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.