Block editing modules

1,069 views
Skip to first unread message

Sam Minnée

unread,
Oct 3, 2014, 10:51:26 AM10/3/14
to silverst...@googlegroups.com
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.

Roman

unread,
Oct 3, 2014, 11:25:40 AM10/3/14
to silverst...@googlegroups.com
Hi Sam.
Great that this is becoming a topic.

Before I started developing my own, I briefly looked at some of the existing modules. I haven't had the time to test them all in detail (I mainly looked at code and documentation) and didn't even discover all of the ones you listed here.

My main issue with the existing implementations were:
- No versioning
- Too much effort to create custom blocks
- Some of them already went too much into a specific direction which made them less usable to be really versatile
- Lackluster documentation (both in code and readme files)

So I decided to create a new module (https://github.com/bummzack/page-blocks) that consist of the essentials that I used for several other projects already.

All your points that you're bringing up are correct, but I also have a hard time imagining a module that works for all the different possible use-cases. Or we would end up with a core-module and lots of different modules around it that add the required functionality (similar how GridField works)?

I think a basic "content-blocks" module could work for "composite pages" AND widgets/sidebars. The basic-block types and their abilities can be interchangeable (eg. both approaches could make use of a "Gallery-Block"), but the User Interface most likely has to be different in both cases.

Inline-editing would be a great improvement over the administration via GridField and is definitely worth looking into. Not an easy task though ;)

I think before we create the "super-blocks-module" we could/should take a step back and try to figure out what the core functionality should be? I'd also be interested to hear opinions of people who used one of the listed modules in production (preferrably people who didn't develop the module themselves).

Cheers - Roman
--
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.

Shaun de Greeff

unread,
Oct 4, 2014, 3:41:06 AM10/4/14
to silverst...@googlegroups.com

Brilliant idea...i think the community would really benefit from something like this.

 

I've been thinking that besides different block types (eg video, gallery, text etc) it would also be useful to have something that makes it easier for the end user to create columns and rows.

If you are using bootstrap of foundation that makes use of some sort of grid system it would be cool if the end user would be able to create content that allows them to make use of the grid

system without having to know css and html. I have been toying with a couple of ideas specifically for Bootstrap.

 

Would this be something that would be useful as part of the block editing modules?

--

Roman

unread,
Oct 4, 2014, 3:54:10 AM10/4/14
to silverst...@googlegroups.com
That would certainly be useful, but that's already too much into a specific implementation for my taste. Not everybody uses bootstrap and not everybody wants a row/column layout etc.

For me, this definitely falls into the "addon" category, which would be a module that extends the functionality of a core blocks module.

Sam Minnée

unread,
Oct 4, 2014, 7:24:42 AM10/4/14
to silverst...@googlegroups.com
This is closer to what the burnbright/gridstructuredcontent module does, and I think is quite a different use-case from the blocks module, as it drifts into putting design control into the author, which isn't really the goal of a blocks system.

wolfv

unread,
Oct 4, 2014, 11:17:10 AM10/4/14
to silverst...@googlegroups.com
Great! This is a topic I am researching since way too long!

I think that back in the days, the page-elements module was a great first step: http://www.page-elements.com/ I've been searching something like this ever since :)

Right now, the best editing interface for something like this would be something along the lines of this editor http://innovastudio.com/builderdemo/example4.html
Unfortunately it's not free or open source software so it can't be integrated into silverstripe without paying for a license. But maybe something similar could be created for silverstripe, either as replacement for tinymce or for a specialized editing interface.

Cheers,

Wolf

Zenmonkey

unread,
Oct 4, 2014, 11:43:28 AM10/4/14
to silverst...@googlegroups.com
This is great, it's a concenpt I've been trying to come up with a solution to for a while. I'm leary of a systen then would tie it's data-model to the presentation layer too much. In terms of concept this article on A LIst Apart is great way of thinking about content blocks http://alistapart.com/blog/post/longform-content-with-craft-matrix Though training end user not to think about desktop layout is a bit tricky.

I think the big issue from an end user perspective is how saving and versioning is handled. The big problem with current gridfield implementations is that content blocks are relations and there is no way to easily control versioning not only on the the individual blocks but the collection on the page. Users tend to think of the page a whole unit and not a bunch of seperate DataObjects. Though I worry about the chaos of crating some sort of versioned relation table on $has_many relations.

colymba

unread,
Oct 4, 2014, 12:34:22 PM10/4/14
to silverst...@googlegroups.com
Hi,

I think this is great to open a discussion on this.
Personally this is something I have been doing for a long time now (what Sam called "composite pages") and I have always used a gridfiled with great success, whether the blocks are organised vertically on the page or in a grid.
Sometimes I don't even use the CMS, all done through a ModelAdmin....

This is fairly easy to implement with what is already out there (GridField Bulk Editing Tools, GridField Extensions, Versioned,...) and to me the gridfield is perfect for it.
I usually have a main "block" class and a collection of different sub-classes that can be added to the GF. This way I can create any type of content I want and have a template for each one. I even put together a quick preview for the user in the cms via the setFieldFormatting() of the  GridFieldDataColumns component.

I would personally not be interested in a GF component that comes bundled with block types and/or linked to a specific layout etc, since every site I make has it's one grid, and block type.
To me this component should be mainly a GF "skin", replacing/enhancing the current GF template to display those blocks nicely with some nifty options:
- let's you choose what custom fields to use as "block info" (type, layout, etc...)
- add block before/after buttons
- a nice preview of the block (let's you choose template and css to include for each block class)
- drag and drop obviously
- versioning or simple draft/live function

Then every developer is free to build on top of this "framework" without "bloatware" and create their own block type and layout.

Jonathon Menz

unread,
Oct 4, 2014, 1:36:19 PM10/4/14
to silverst...@googlegroups.com
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.

Conrad Dobbs

unread,
Oct 5, 2014, 2:47:40 AM10/5/14
to silverst...@googlegroups.com
I may as well throw my hat in the ring as well. https://github.com/webtorque7/inpage-modules/

Developed this for a client about a year ago. Used it a few times. Recently updated the UI a bit and have also added a "template" system which allows you to configure page types which will pre-populate the modules for you. Set the template on the parent and it inherits down like the security settings.

Borrows heavily from pages for versioning etc. Has it's own section where you can navigate around all the modules and see the version history etc.

Can create different modular sections by creating different many many relationships with different base classes. Had 3 for one project, main content area, a sidebar and footer.

Modules are reusable by "saving to library".

Modules are managed in their own tab on the page with a custom form field using accordion with drag and drop sorting. Modules update via their own ajax, not the page form submission. There is a custom relationship editor for modules which opens the data objects in a popup. There's been a few hacks to get things like the uploader and treedropdown working.

It's left to the developer to configure the relationships and add the editor to the form.

Currently renders in the template by looping over the modules and calling $Me to render the template. The modules are essentially mini pages.

I quote liked the look of http://neokoenig.github.io/jQuery-gridmanager/ which jedateach posted. More involved in getting an interface like this going.

I think the key to a good modular system is giving the user the extra flexibility and control to build pages, while still making sure the html and code is in the control of the developer.

mst...@silverstripe.com

unread,
Oct 5, 2014, 5:11:26 PM10/5/14
to silverst...@googlegroups.com
This was posted on IRC last week by Ryan-Toast which looked quite good: http://www.gfycat.com/SomberGeneralChinesecrocodilelizard - Not sure if there's an open-source module though.

Loz Calver

unread,
Oct 5, 2014, 6:44:48 PM10/5/14
to silverst...@googlegroups.com
Just touching on the subject of a GUI for shortcodes: https://github.com/sheadawson/silverstripe-shortcodable handles this quite well :)

Jonathon Menz

unread,
Oct 5, 2014, 7:41:14 PM10/5/14
to silverst...@googlegroups.com
Sweet, thanks for that link Loz! That already does most of what I want - being able to edit existing shortcodes in the content would be the next step.

Sam Minnée

unread,
Oct 5, 2014, 9:17:25 PM10/5/14
to silverst...@googlegroups.com


On Saturday, 4 October 2014 08:43:28 UTC-7, Zenmonkey wrote:
This is great, it's a concenpt I've been trying to come up with a solution to for a while. I'm leary of a systen then would tie it's data-model to the presentation layer too much. In terms of concept this article on A LIst Apart is great way of thinking about content blocks http://alistapart.com/blog/post/longform-content-with-craft-matrix Though training end user not to think about desktop layout is a bit tricky.

Thanks for that link—I've seen that before, but had forgotten what the link is. I think that general layout of the editing interface makes perfect sense.
 
I think the big issue from an end user perspective is how saving and versioning is handled. The big problem with current gridfield implementations is that content blocks are relations and there is no way to easily control versioning not only on the the individual blocks but the collection on the page. Users tend to think of the page a whole unit and not a bunch of seperate DataObjects. Though I worry about the chaos of crating some sort of versioned relation table on $has_many relations.

Yeah, this is something that might need some core improvements to handle versioning & publication workflow for a-page-and-its-dependent-components. I don't think that VersionedGridField is quite right here, for the reasons you point out, although it's better than nothing.


Hamish Friedlander

unread,
Oct 5, 2014, 10:36:39 PM10/5/14
to silverst...@googlegroups.com
Somehow you've brought "Content Blocks" around to the hardest problem we've recently discussed Sam, graph versioning :).

Since it's come up, I'll put some brief thoughts down. Sorry for length, it's a bit complex. TLDR; graph versioning is hard to get right, and a global solution would affect all parts of a CMS, so we shouldn't just hack our way through it based on the requirements for Content Blocks

There's lots of solutions to graph versioning (versioning of several connected objects). The two I've put any significant thought into are:

* Triggered versioning

This is where a parent object "owns" a set of other objects. Publishing that parent object also publishes the other objects.

The problem with triggered versioning is that it only works nicely if there's a clear 1-n owner/owned relationship - in other words a child can be traced back to one-and-only-one parent. When you have n-m relationships - you've got multiple parents - you end up with difficulties. Either you have to track the published version for each parent - which is hard to store efficiently, and hard for content editors to keep track of which parents still need to be updated - or publishing a parent ends up publishing that child on all the other parents too, which is often undesirable and surprising to the user.

The situation people are probably most familiar with that causes these issues is the assets. Images can be used by multiple Pages at once. You don't necessarily want publishing a new Image to affect all Pages straight away, and you definitely don't want the publication of a Page to update the live Image for all other Pages, but you also don't want to have to search for all the Pages that happen to use an Image to make sure they're using the most appropriately up-to-date version.

Tree re-organisation is another example where triggered versioning fails. In this case a graph of all Pages linked by the ParentID and Sort fields where there's no clear owner, so it's not clear which object should be the trigger parent.

* Set versioning

This is where you never actually publish the changes on a specific object, but instead can view all the changes across the entire Data Object graph that haven't yet gone live, put a selection of those changes into a "set" of changes, then publish all changes in the set at once.

Developers are probably used to this mode of operation, since it's basically like a (limited to one branch) version of git. You can see all your un-committed changes, then you can pick some of them and commit them all as one operation, leaving the remained of your changes uncommitted.

Set versioning solves all of the technical cases where triggered versioning falls over, but has a couple of non-technical issues. The first is that it's conceptually a little more complex for content editors. Especially for simple sites where a basic "single Page publishing" is enough, it's introducing complexity for no benefit. The second is that it'll need a lot of UX rethinking, as you need a separate view to see all the prepared-but-unpublished changes.


In general, because I think the UX challenges can be solved but the technical ones can't I currently prefer Set versioning over Triggered versioning.


But how does this relate to Content Blocks?

I'm assuming a data structure something like

Page <--{1-n}--> Layout Blocks <--{n-m}--> Content

where "Layout Blocks" are pre-configured models that have one or more slots to load Content into, and a template for preparing that Content for display in the Page (i.e. Widget-likes).

When you add Layout Blocks to the Page, these Blocks should be treated as part of the Page - their changes publish when the Page is published, and can't be published separately.

However the Content is probably published independently of the Page. Normally, once associated with a Page, when you publish a piece of Content you want that to update on all the Pages that Content is associated with, without having to publish those Pages too.

So actually this model could be solved with Triggered versioning. We've got one 1-n relationship that Triggered versioning deals with nicely, and although we've one n-m relationship that Triggered versioning normally wouldn't deal with, because we've explicitly said "we'll publish the Content separately" we're probably OK.

However if we break that one requirement, Triggered versioning is going to fall over.

For instance I'm not sure how this model would handle: workflow on a Page, when a Content object that's used by a Page is removed from the published site, or when a client _doesn't_ want publishing Content to affect all Pages at once.


So we're left with:

- Use Triggered versioning, and put up with the limitations

- Use Set versioning

- Try and do Content Blocks separately from versioning concerns, using a temporary / hacky solution until we can set Set versioning working


My personal suspicion is that trying to use Triggered versioning is going to lead to pain, and we don't want to wait until we can get Set versioning working to standardise Content Blocks, so we're likely to have to go for the third option.

Hamish Friedlander
SilverStripe
http://www.silverstripe.com/


Thomas B. Nielsen (Nobrainer Web)

unread,
Oct 6, 2014, 7:15:38 AM10/6/14
to silverst...@googlegroups.com
To me it looks as if some wants a system that can create full pages/designs, and some wants to add more structure / options for content.
My module https://github.com/NobrainerWeb/Silverstripe-Content-Blocks is a module for content.
A user should be able to do better content, than with the default single Content field, but he should not try to do design. Columns should be available for the content editor, but with some limitations defined by the designer.


I have the following functions now - need to update the git repo, made a mess of it though :-(
- Build content in blocks
- Each content block can have its own DataModel by extending the base DataObject Block
- Each content block can have any number of templates - display the data differently, but still controlled by the designer. Visual selection for the user (thumbnail preview)
- Drag and drop reordering
- Attach a block to multiple pages (related with many_many) - show a notice that a block is in use on more pages (editing the block changes all pages)
- Hardcode a single block into a template by its ID $OneBlock(ID)
- Nested colums. An extension to block, that allows the creation of blocks under a block. Templates using Zurb Foundation allows for use of the same templates in nested blocks.

I think the "complete" module needs the following extras
- No need for duplicate templates to do simple text and image placements. Rather have an intelligent template, where the user clicks, image left/right, small/medium/large/fullwidth image, should text float/wrap around the image? (Display logic module?)
- Versioning (Draft/Live)
- Permissions
- Search
- Option to have multiple "placeholders" on a page. Ex: Option to add blocks to a sidebar, content area, footer
- Admin preview. For me the "Split mode" preview in admin is perfect for this - but it needs to be shown when editing a DataObject also, and not just for sitetree objects. Zauberfish mentioned he had a go at this.
- Form handling (routing to BlockController) works, but needs more testing /development
- Use the manifest for finding templates

And Zauberfish - get that nice module on Git!

PS: I can see that there is lot of technical stuff around versioning and i do agree with Hamish in that it should be handled as page - we are just not there yet.

Sam Minnée

unread,
Oct 6, 2014, 5:17:14 PM10/6/14
to silverst...@googlegroups.com
Hey Hamish,

Yep, I'm good like that. I guess the reason I bring it up is that it cuts to the heart of why we've got divergence in these modules.

1. I've got mixed feelings about "layout blocks" as I feel that they drift into turning the CMS into a design tool; this is especially true with responsive design. I think that, in general, it would be better to have 1 or more sequential feeds of blocks placed into the template by the designer makes more sense, and then letting users drop in one or more pre-defined layouts (e.g. image + paragraph).  That said, I don't think layout blocks shouldn't be denied the right to existence, just that it might be a different module. ideally, you could install the "layout blocks" or "custom grid" module, and it would let you drop in the same content blocks as the regular blocks module.

2. Setting aside reusable blocks—blocks pulled in a "block library" rather than created specifically for a page—I think that triggered versioning will work intuitively, so it's good that it's easier. I think having a mechanism for triggered versioning in the framework will be of value and I'll start to look at it.

3. For a library block (i.e. a blocks from the block library) I see a few things:
    a. If you're editing a library block directly, and then publish it, all uses of it should update. Providing the user of where it is used will help—"this is used on 5 pages, all of these will be updated when you publish <a>see details</a>"
    b. If you're creating a page that uses a library block, and it has unpublished changes, then there should be an option to publish the library blocks at the same time, but you should also be able not to do it. If you had set versioning, then it would make sense to create a set and include the library block change in that; in the meantime something more usecase-specific could be baked into the blocks module.

-----

On a completely separate note, I'd like to ask everyone—what about the "Widget" class? We have a number of modules out there that provide widgets, and while I could raise a lot of valid issues about the editing UI, it seems like the Widget base class might still be a logical choice for the base class of the components, perhaps with some minor amendment? It feels a bit like reinventing the wheel to throw it away and start again...

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Marcus Nyeholt

unread,
Oct 6, 2014, 7:49:33 PM10/6/14
to silverst...@googlegroups.com
I've got a frontend-dashboard module that makes use of a Widget subclass to represent the dashlet - the one nice thing about making use of them is that the individual dashlet is URL addressable, meaning in a JS environment, partial page updates are very straightforward. Conceptually, it might be good to define how a "block" is represented separate from the container framework - that might make it simpler to choose a presentation mechanism separate from the block functionality itself. The Java Portlet Container / Portlet spec could be a basis for some of this (though that does get a bit messy and convoluted, so pick the good from bad :). 

Not to get too OT, but on the topic of set-based versioning, I've had a "changesets" module (https://github.com/nyeholt/silverstripe-changesets) floating around for a while that I've never used for anything in particular, but that I experiment with from time to time for these kinds of scenarios (ie lots of objects being edited that need to be published at once). The current "experiment" being to push sets of content out to other SS instances in a serialised manner (via https://github.com/nyeholt/silverstripe-syncrotron). 
A few of the hurdles involved

* the application of 'versioned' is a bit cludgy around non-SiteTree data object types - SiteTree implements some additional helper methods for interacting with the 'verisoned' state of things. Other modules go some way of helping out, but all have their fiddly bits. Would be nicer to have better generalised Versioned support in core
* many_many relationships and versioning those relationships. In some cases I find it easier to use a multivaluefield on the 'parent' object so that the relationship is versioned along with the object's data. It's not as queryable, but in some cases you don't need that ability. Other times, having a separate versioned DO to represent the that many_many join can work, but it's a PITA and can introduce complexity that's undesirable
* the implementation I've put together 'locks' an item into a specific user's changeset, meaning that other users can't edit that item until the user has published or cancelled the changeset. This is a bit kludgy, though the alternative of having multiple per-user 'layers' (somewhat like Alfresco's AVM content store) is probably out of scope of what SS can handle without re-writing some bits of Hierarchy and DataList to handle it (at least, my quick 2 hour beer-code poke around indicated that much)

So the set based approach can work, but in some cases the 'triggered publish cascade' may be optimal. 



g4b0

unread,
Oct 7, 2014, 5:45:10 AM10/7/14
to silverst...@googlegroups.com


Il giorno venerdì 3 ottobre 2014 16:51:26 UTC+2, Sam Minnée ha scritto:

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


Don't forget, speaking about widgets, my extension to the original class: http://addons.silverstripe.org/add-ons/zirak/widget-pages-extension
It provides a more flexible widget management than the original module, and it can also be eventually versioned. I'm using it in a copule of installations and it works fine.

g4b0

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Oct 7, 2014, 5:01:00 PM10/7/14
to silverstripe-dev
Just half a cent here in terms of versioning.   

So far, the SS core offers page versioning but nothing else out of the box.  In my experience this works really well, although I sometimes wish that Data Objects were versioned as well. 

The thing is with page versioning that the versioning does not take relationships into account at all. For example, if we save a page, the version of the parent does not change even though visually, the parent may change (as it may list the children). What is more, pages can have all sorts of other relations with each other without affecting any of the versioning. For example, a product group page type may have a many-many relationship with a product page type. Thirdly, a page may show a bunch of dataobjects and when the Dataobjects change, the page version stays the same.

My question is: if Page versioning works so well without any relationship managements (triggers, etc...) then why would we worry about versioned relationship management for data objects (or page widgets for that matter)?

As illustrated in some of the posts here, it is not easy to manage these versions in terms of relationships. I know that from my own work with e-commerce (e.g. if a t-shirt product (Page) gets a new colour variation (e.g. red option) with a new price (DataObject) then is this a new version of the Product Page?) 

What if we had the following basic strategy?

  • * dev can choose for any dataobject to be version-able.  Pages are versioned by default.
  • * all objects are individually versioned - i.e. they do not trigger the saving of a new version of any related objects. 
  • * we create a new piece of code that allows any has_one, has_many and many_many to include a version number. For example, we could save the ID like this: 123.456 where 123 is the ID number of the related object and 456 the version number of the related object. Then, if you retrieve a relationship object(s), it checks if the ID numbers contain a dot and if so, it will retrieve the relevant versions. Obviously, we could also create two fields (e.g. MemberID and MemberIDVersion) rather than using the dot notation. 
Is that far too simplistic? 

I guess the main question is how we communicate to the CMS editor what versions apply for what relationships and how they can be updated to a newer version.

Nicolaas

John Milmine

unread,
Oct 7, 2014, 6:58:19 PM10/7/14
to silverst...@googlegroups.com
At DNA we've used page components (or elements) in our designs for a while and in systems other than SilverStripe.

We rolled out wellingtonnz.com using this methodology. We do it so that content can be richer and more tightly controlled than a wsiwyg editor. For example we often disable images in the wisiwyg and add an image component so that we can control dimensions across breakpoints.

Some learnings we've had.

1) Does need to be versioned
2) Editing interfaces aren't ideal currently.
3) Ordering is essential, layout not so much, users get the idea of that pretty quickly (as long as they use the CMS semi-regularly). Layout becomes a guide anyway due to responsive.
4) Workflow + versioned dataobjects creates issues.

The last point has caused some pretty major issues for us. You can reasonably easily version dataobjects and getting an save/publish/unpublish/delete interface isn't too hard with existing modules.

You can also reasonably easily get workflows applied to dataobjects. We've done some modifications to the workflow system so you can define a workflow based on object type not hierarchy, as some of the objects we wanted workflowed didn't have a hierachy.

However you end of with a ton of workflows if you have a workflow for each relationship level. i.e Page has many item boxes lists which have many item boxes = 3 distinct workflows. So we've ended up creating a nested publish so that the user describes the changes they've made to the page and any of it's sub objects and then when the page is published it runs through the sub objects and publishes them too. This means we've also disabled the publish button at the lower level objects so that it always has to go through the parent workflow process, otherwise small (but potentially important) changes can be made and published without running through a workflow process.

We're still having some teething issues with it currently (launched last week), it seems some users can delete the object without unpublishing it. So now we have a un-editable published item... Still tracking that one down.

Also note that if you add versioning to a pre-existing object then you need to run through all the objects and publish them otherwise you'll have a rather empty public site.

Roman

unread,
Oct 8, 2014, 2:06:41 AM10/8/14
to silverst...@googlegroups.com
Hi John

My first implementation of content-blocks also used the same approach you're using: Publishing the page automatically publishes the relations.
I steered away from that in my page-blocks module to give the editors more control over what content parts they want to publish (explaining the admin-interface has become more complicated with this change though).

I had the same issue regarding deletion of content.
If you're using BulkManager, then this action handler might come in handy: https://github.com/bummzack/page-blocks/blob/master/code/bulkmanager/GridFieldBulkActionVersionedDeleteHandler.php

Otherwise you could also create a custom delete action for the GridField (eg. something like GridFieldDeleteAction).

Thinking about it, I wonder why this isn't in the framework core? A check if an item is versioned can easily be done and then the already existing delete action could also delete the published version. Maybe I should create a pull request for that.

John Milmine

unread,
Oct 9, 2014, 12:54:36 AM10/9/14
to silverst...@googlegroups.com
Hi Roman,

Did your allow for workflow?

Sent from my iPhone
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/3kC1-iG1nYw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.

Roman

unread,
Oct 9, 2014, 2:12:34 AM10/9/14
to silverst...@googlegroups.com
Hi John

No, I didn't.

Simon J Welsh

unread,
Oct 13, 2014, 4:46:36 PM10/13/14
to silverst...@googlegroups.com
http://xkcd.com/927/ seems relevant here.
> --
> 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.

---
Simon Welsh
Admin of http://simon.geek.nz/

Michael van Schaik

unread,
Nov 12, 2014, 6:15:49 PM11/12/14
to silverst...@googlegroups.com
Hi all,

This "block editing modules" discussion has so far been really interesting. I'm trying to choose between using any of the existing modules or going with a very simple solution using SortableGridfield combined with various 'Block' dataobjects. I've come to a selection of existing modules to test (nobrainer, richardjoqvist, bummzack, sheadawson & dnadesign's), but figured I'd ask here first; have there since been any attempts to combine all this functionality into one module yet?

Thanks,
Michael

lu...@lerni.ch

unread,
Nov 13, 2014, 5:06:53 PM11/13/14
to silverst...@googlegroups.com
Hi all

I started a Google Spreadsheet to have a quick overview of the different modules, since this takes way to much time to evaluate. I wanted to complete it a bit more before I post it here but time is the limiting factor. I release early and hope it helps others and others help to complete it a bit more - it's open to edit for everybody and I hope you do :)

https://docs.google.com/a/kraftausdruck.ch/spreadsheets/d/1JvodD2L9K4b4hIrq1lTKb1Mpky5pgoOY0fElgKrrgq8/edit#gid=0

lukas


Am 13.11.14 00:15, schrieb Michael van Schaik:

Ingo Schommer

unread,
Nov 13, 2014, 5:41:40 PM11/13/14
to silverst...@googlegroups.com
I've written up some research as well a few weeks ago. Highly subjective, not a reflection of the core team, just needed a place to organise my thoughts that might be useful to others.

Conrad Dobbs

unread,
Nov 13, 2014, 6:40:05 PM11/13/14
to silverst...@googlegroups.com
For webtorque7/inpage-modules, originally you could have as many modules open as you like, but this created usability issues. The main one being there was confusion over the save buttons, sometimes they would be off the screen for the module. The user would then click the save button for the page and lose their changes to the module. We changed it to one module at a time so we could have clear controls which are obviously separate from the page controls.

The titles make it easier when reusing modules to find the one you want.

Michael van Schaik

unread,
Nov 14, 2014, 11:49:20 AM11/14/14
to silverst...@googlegroups.com
Hi Lukas, Ingo,

Thanks for both the documents, I've made some additions to both today.

After testing some of the modules, I've found a few patterns in common which I'll try to give an (opinionated) description of.

Editing interface
The module by webtorque is the only one (WerkzeugH?) with a custom editing interface. All others use a flavour of Gridfield. Using gridfield often means editing the different parts of a page requires some going back and forth through the CMS (going into the dataobject, losing context of the page). On the other hand, editors (and developers) are already familiar with this interface paradigm and it is probably compatible with existing modules like translatable/fluent. The interface by webtorque allows for inline editing and sorting, which is very nice. I think this is requiring quite some custom code & logic though, which might be harder to make compatible with other modules.

Relation management
I think the page-blocks should be many-many, so blocks will be reusable (most modules do this or have this on their todo). From the editor perspective you're just building a page and so it should be possible to re-use content you've already created elsewhere, doesn't make sense to have to recreate that for every page.

Some modules also add a ModelAdmin for the different Blocks to be managed (a.k.a. library). I think this is nice since it's of practical use (overview, centralised editing), but also because it reenforces a Block to be perceived as an object on it own (instead of purely as part of a page).

Page areas
Some modules allow for blocks to be added to multiple different areas of the page (e.g. before content, in sidebar, footer, etc). This may be achieve by multiple Gridfields, but I think the base dataobject class will then have to be subclassed for each area, since otherwise the ORM won't know which relation an object belongs to(?). Another solution to this would be to base the objects around the widget classes, like the module by Dnadesign does (doesn't currently seem to support multiple areas, but could probable be easily added). 

Also dragging from one area/relation to another would be nice, but I think this currently isn't supported by Gridfields. A different approach that works around this, is how the module by Sheadawson works. All blocks are in one Gridfield on the page and you can just select the area for the block to appear in via a dropdown on the block itself. 

Versioning
As discussed in this thread, this seems quite a complex area, especially with n-n relations. From the editor perspective, he/she will be building a page out of stackable blocks of content. Pages are verioned as one item already (you cannot just publish the title field and leave content in draft so I guess versioning the related objects this same way (trigger) seems OK from a user perspective. A block item is then just perceived as a piece of content which is displayed on multiple pages. If I update it on one page, it will also be updated on other pages which use it. If I don't want that to happen, or if I want to edit the block only for the current page, I should duplicate the block instead of re-use it.

Departing from that, it does make sense to make it possible to publish an individual block without publishing the others on a page, since the blocks are not just one field on a page but actual objects (most modules allow this, Bummzack, Dnadesign & Webtorques also version them). The module from Dnadesign contains an extension solving triggered publishing nicely (as an option), allowing for all blocks to be published together with publishing the page.

Controllers
In order for forms to work in blocks, they need some kind of controller logic including allowed actions on the page they're used on. The module by Dnadesign seems to achieve this by instantiating the controller from within the model (eg Userforms). Webtorque's module adds a /m/ module action to any page via the controller extension.

Search
Some modules replace the regular Content area of a page with a text-only representation of the page's blocks, in order for it to appear in the standard search results. This does seem like a bit of a hack and I think it it does make sense to leave the standard Content area untouched and make the blocks appear around it, like widgets do. Not sure how search should be fixed instead, any suggestions?

Conclusion
I haven't been able to pick the best option yet, all the parts I need already exist, just not in one universal, extendible module yet.
Hope this summary helps getting there though.

Cheers,
Michael


--

Roman

unread,
Nov 14, 2014, 1:23:49 PM11/14/14
to silverst...@googlegroups.com
Michael, thanks for that thorough summary.

We also talked about the block modules at the latest SilverStripe Meetup and there were two important points that stuck with me:

Too many use-cases to create a module/UI that works for all
There are a lot of different use-cases for such content-blocks. Ranging from vertically stacked content-sections to grid-layouts or even widgets. A UI that caters to all these use-cases is very hard to do and will potentially also scare off developers who wish to create new block-types, as building the UI for them will probably be a rather complex task.
That's why I actually like a very abstract (yet familiar) interface to edit these entries - such as a Gridfield - that also leverages the CMS components that are already available.

In an ideal implementation, the "core" content-blocks module would only contain model classes and maybe some simple helpers to edit them via Gridfield. Then there could be different layout modes and UI improvements that are being added on top of this module (say, a module that adds WYSIWYG editing inside the CMS).

Versioning
You have already touched on this, and yes, I think this is a problem, and not only in regards to content-blocks. In a scenario where all Page-content is built using content-blocks, the versioning of the page becomes less important than versioning of the content-blocks themselves.
Versioning in it current state is lacking in some areas though:
  • The User-Interface of SilverStripe is built around page-versioning. Having prominent "Save & Publish" buttons on a page AND adding the same features to smaller content blocks within that page is going to cause confusion.
  • Many_many relations aren't versioned, which is problematic in some cases: Imagine an image-gallery. If a user adds/removes an image or performs a sort, these changes will be applied immediately (live), which is a totally different behavior than with any other content-part.
  • As outlined by Hamish in another email, there's also a problem with data-objects that are linked in several relations, where publishing the block would result in the block being published everywhere else.

I personally like the has_many approach for content-blocks (Page 1 -> * ContentBlock). It solves some problems that are related to versioning and I don't think re-using of the same content-block is that important. The re-using could be solved by some of the mechanisms that are being used for SiteTree as well, such as "Duplicate" (duplicate the block and link it to another page) and/or "Virtual Page" (a dataobject that only serves as a pointer to the original object).

It also looks like this might become an upcoming feature in SilverStripe (http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6478313-column-or-block-content-editing), so maybe there will be a single module to rule them all :)

Cheers - Roman

John Milmine

unread,
Nov 15, 2014, 12:16:24 AM11/15/14
to silverst...@googlegroups.com
Hi guys,

I'd like to second a few points from Roman.

Too many use-cases to create a module/UI that works for all:
As I noted earlier, once responsive is in the picture order, not layout is more correct. Layout changes with the screen size, order does not. It's still possible to denote columns within the model, or denote some layout using enums or options (i.e 'Size' => 'Enum("Small,Medium,Large")'). Coupling your datamodel to your CSS requires quite a bit of project context and should therefore be considered a enhancement or sub class of these blocks to define this.

Editing interface:
This module should be considered basic, so using things like gridfield encouraged. It's very easy to add an 'Edit this' link on the frontend which takes users directly to the edit screen within the gridfield, if the user requires a more full on frontend interface this would be an enhancement.

Relation management
The use of has_many is better for a couple of reasons:
1) Versioning
2) Reusing a content block is easily achieved with a Virtual Block
3) Less confusing UI, than a Library (model admin)

Has_many and many_many are different but both useful
On wellingtonnz.com we use both options, we have a ContentPage which has many content blocks and creates pages like: wellingtonnz.com/discover/things-to-do/eat-and-drink/the-craft-beer-capital/classic-wellington-craft-beers/. We also have reusable blocks for landing pages: wellingtonnz.com/discover/. In doing so we have use a gridfield in both options, but in the many_many case we disabled editing, creating, deleting in the gridfield and actually include a link to the Block Library model admin. This makes it clearer to the CMS users that they're outside of a page and therefore changes may apply to a bunch of pages. We also show them a list of the pages that this object is included on, to make sure they have all the information.

Please note that the content page implementation uses a WidgetArea and all components extend Widget, whereas for the many_many approach we just use a Block extends DataObject.

At this stage the fact that many_many doesn't have versioning is kind of a feature. It means that a CMS can edit a block and when publishing that block the change goes out to all the pages at once. We just apply a separate workflow to those objects, so that some users can edit content pages, some users (more admins) can edit the 'Block Library'. As ownership is not implied by the many_many relationship versioning (and workflow) of the block should be entirely separate from the page. The only problem here is making that obvious to the CMS user.

In some instances moving from a many_many to a more complicated has_many is easy to do and means that versioning is introduced. For example related pages is a typical many_many, but can be easily expressed as SubclassedPage has many RelatedPages, RelatedPages extends DataObject has_one ParentPage => SubclassedPage, has_one RelatedPage => Page. As above versioning may or may not be a feature for many_many relationships, it's certainly not wanted on our landing pages in wellingtonnz.com

Page areas
Adding multiple areas is also very easy when you go with the widget approach:

private static $has_one = array(
'WidgetArea1' => 'WidgetArea'
'WidgetArea2' => 'WidgetArea'
);

or in elemental's case:

private static $has_one = array(
'Content' => 'ElementArea'
'Sidebar' => 'ElementArea'
'Footer' => 'ElementArea'
);

You could also subclass WidgetArea to restrict certain blocks to certain areas, or just derive this from the page type you're editing.

Controllers:
Widgets have already solved this which means having a form within a block is easily achieved.

Search:
It's also worth noting that search should be from the users perspective not the data model perspective so rendering them out as the frontend HTML means that the searchable content is closer to what the user expects and sees. The data model should not considerable more correct in this instance. Whether or not this should be $Content is up for grabs.

Translations:
Yes both our landing page many_many blocks and our content page has_many blocks have been translated in wellingtonnz.com. It did require a bit of work, which was mainly about showing the language of the block library. I don't believe this is currently in Elemental as this work was focused around the many_many relationship not the has_many relationship which Elemental uses.


BTW loving that this conversation is happening and the engagement from around the community.

John




--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/3kC1-iG1nYw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.

Shea Dawson

unread,
Jan 16, 2015, 11:29:35 PM1/16/15
to silverst...@googlegroups.com
If anyone's interested I've just done a bunch of work on sheadawson/silverstripe-blocks module, including the addition of block versioning. I think it's getting pretty close to a solution to the requirements discussed here. See readme for full list of changes - https://github.com/sheadawson/silverstripe-blocks

Ryan Wachtl

unread,
Jan 16, 2015, 11:36:04 PM1/16/15
to silverst...@googlegroups.com
Excellent, I’m working on a site that makes heavy use of the blocks. Thanks for all the effort, I’m very pleased with the new features in 1.0. I’ll `composer update` and check it out.

- Ryan

Ryan Wachtl
Principal Consultant, Beyond Usability
@ryanwachtl
www.linkedin.com/in/ryanwachtl


Shea Dawson

unread,
Jan 17, 2015, 12:16:20 AM1/17/15
to silverst...@googlegroups.com
Awesome. Let me know how you go... I haven't tried upgrading an existing project to use 1.0 yet but I know there are a few changes that will mean you'll have to manually update some of the block/relationship data. Will probably end up creating a dev task to help with this. 

--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/3kC1-iG1nYw/unsubscribe.
To unsubscribe from this group and all its topics, 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.



--
Shea Dawson
Web Developer
LiveSource

mobile +61 451125303
skype squatchnz
email sh...@livesource.co.nz
web www.livesource.co.nz

Cam Findlay

unread,
Jan 19, 2015, 8:28:26 PM1/19/15
to silverst...@googlegroups.com
That's the nice work there Shea ;)

Shea Dawson

unread,
Jan 20, 2015, 1:49:30 AM1/20/15
to silverst...@googlegroups.com
Cheers Cam. Much credit is also due to Michael van Schaik. Thanks for your help with both the direction and implementation Michael... and of course the initial motivation :)

Michael van Schaik

unread,
Jan 20, 2015, 4:07:06 AM1/20/15
to silverst...@googlegroups.com
Shea, thanks! :)

Vriendelijke groet,
Michael van Schaik

(Niet aanwezig op donderdagen)


​​m...@restruct.nl
+31 10 800 94 18
Middelstegracht 89C
2312 TT Leiden
Schiekade 189 unit 204
3013 BR Rotterdam


--

wolfv

unread,
Mar 16, 2015, 12:03:31 PM3/16/15
to silverst...@googlegroups.com
This discussion is old, but I recently found out about a great WYSIWYG editor, based on a "block" like approach which works a lot better for responsive websites etc.

It's called LivingDocs and the engine is available under GPLv3: https://github.com/upfrontIO/livingdocs-engine (clone the repo and try it out, you'll be amazed).

A specific interface for SilverStripe would need to be developed (e.g. integrating the image selection popup).

I believe this editor would give SilverStripe an important advantage over most other CMS. It would be more like a replacement for TinyMCE, so not totally in the direction of the blocks modules that are already existing for SS.
The editor is little known but of very high quality.

I would be happy to collaborate on a SilverStripe integration for livingdocs (I am using it in my python SilverStripe competitor, SilverFlask ;)

Cheers,

Wolf

Jonathon Menz

unread,
Mar 16, 2015, 2:46:30 PM3/16/15
to silverst...@googlegroups.com
This looks really awesome Wolf. I downloaded the repo but had to edit the bundled demo a bit to get it working and got the feeling it was still partly broken. Any chance you could share a link or zip file to a functioning demo so others can see how it works easily? I think you're right that this could be a great advantage for SilverStripe.

I don't think this necessarily has to be used instead of existing blocks modules - in some cases they might compliment each other quite well. The living docs approach could replace editing for the traditional Content area, providing unique versioned content on a page-by-page basis, while a blocks module could be used for adding content around that space which may not be unique to that page and may not be versioned.

Cheers,
Jono

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 16, 2015, 9:09:56 PM3/16/15
to silverstripe-dev
Hi Everyone

Just my two cents worth ... the way I see this works is as follows:

1. core team makes sure the core form functionality in framework is super fast and flexible, as well as maintaining documentation on how to include AJAX calls from form fields in the CMS, adding buttons, etc... 

2. all amazing devs out there create a ton of form fields with all sorts of functionalities - added to packagist as modules. 

3. addons.silverstripe.org provides a list of modules that simply provide a form field allowing the rest of us to mix and match form fields as required. 

Then you can mix and match relevant form fields for use in the CMS and beyond.

This Living Docs idea sounds great, but it does not have to replace the HTMLEditorField at all.  

Nicolaas


--
Nicolaas Thiemen Francken
  www.sunnysideup.co.nz
  phone: +64221697577

wolfv

unread,
Mar 17, 2015, 5:53:42 AM3/17/15
to silverst...@googlegroups.com
Hi Jono,

yep, getting the demo to work is a bit tricky. I'm hosting the demo here, now: http://w-hy.ch/livingdocs-engine/public/
You can drag and drop content from the panel on the document. At the moment, no default fill text is added, so some of them appear white... clicking inside should allow to enter text. It's only a very, very basic demo.

The livingdocs team also has a website where you can request a trial account: https://livingdocs.io/

True, it can easily be a plugin. I completely agree with all what was said. 

But I think it would be the right move to get something more modern on board than TinyMCE, and livingdocs provides a great editor framework that can be tightly integrated into the CMS.

Cheers,

Wolf

Hamish Friedlander

unread,
Mar 17, 2015, 11:08:53 PM3/17/15
to silverst...@googlegroups.com
Unfortunately we can't integrate any editor (or any other code) that's only licensed under the GPLv3 into SilverStripe core - SilverStripe uses a BSD style license, and if we included GPLv3 code we would have to change to using that license.

One solution is that you could make a module, and then only the module would need to be GPL licensed - along with any other code that depended on that module.

https://github.com/upfrontIO/editable.js (which living docs uses as it's core contenteditable interface) does look like a cool basic WYSIWYG editor for people wanting to experiment with front end or block editing though, and is liberally licensed so could be used in core.

Hamish Friedlander | CTO
SilverStripe
http://www.silverstripe.com/


wolfv

unread,
Mar 18, 2015, 8:13:27 AM3/18/15
to silverst...@googlegroups.com
Hi Hamish,

actually, I was wrong, and it is distributed under a LGPLv3 license. Does that make a difference?

Cheers,

Wolf

Jonathon Menz

unread,
Mar 18, 2015, 11:47:32 AM3/18/15
to silverst...@googlegroups.com
Thanks for hosting that demo Wolf. I signed up for beta access to living docs too and highly recommend it - it's a really nice editing system and you can get a lot better feel for it from the beta than the source demo. It reminds me a bit of Canvas from Campaign Monitor. Encourage anyone interested to sign up and have a play. Would love to see a module powered by this at some point.

Martine bloem

unread,
Mar 18, 2015, 12:01:43 PM3/18/15
to silverst...@googlegroups.com
Really interesting, this :)

Unfortunately it doesn't seem to play well with safari on iOS, which is something I was kinda looking for. How is that for other tablets, does anyone know?

Martine

wolfv

unread,
Mar 19, 2015, 11:55:14 AM3/19/15
to silverst...@googlegroups.com
Martine,

I just tried the touch support on my Nexus 5 Android smartphone. It works! 

The thing about the editor is, that the only part that is FOSS is the "core". The specific (and CMS-specific) functionality needs to be build on top of that, which requires some investment of time. So touch support is also a question of how that module would look like.

I would gladly offer to work on that if someone would team up, however, my time is unfortunately limited as I still need to study :)

Wolf 

Jonathon Menz

unread,
Mar 19, 2015, 12:51:25 PM3/19/15
to silverst...@googlegroups.com
Hi Wolf,

If you spearheaded the development of a module for this, which parts would you want to do yourself and what would you want help with? If you like I could help out with the visual side such as UI mockups/designs and CSS.

Jono

wolfv

unread,
Mar 20, 2015, 9:04:12 AM3/20/15
to silverst...@googlegroups.com
Hi Jono, and everyone,

I indeed couldn't resist from starting to work on this. Here is a first impression: https://vimeo.com/122740856 I hope this helps convincing others to share the burden! It really is just super basic demo, using the default bootstrap theme of livingdocs.

I uploaded this first draft of the module here: https://github.com/wolfv/silverstripe-livingdocsfield

Please, if anyone is interested in collaborating, just let me know and I'll give you instant push access to the repo.

Mockups would be greatly appreciated. 

I think this is a vital effort to develop the CMS further. Editing experience should be No1! People today want responsive websites, and TinyMCE is just not suited for that sort of editing.

Cheers,

Wolf

wolfv

unread,
Mar 22, 2015, 2:57:12 PM3/22/15
to silverst...@googlegroups.com
To all interested,

I have developed the LivingDocs module further during the weekend. It's now possible to save content to the DB and load it, drag and drop new fields, delete fields and change properties. Image and link inserting is also working.

As pictures tell more than words and moving pictures are even better, here is another screencast: https://www.youtube.com/watch?v=kx6eEOIj-dA

The module is on github, too. I hope to find some help in developing it to make it ready for prime time :) It would also be cool to have a custom LivingDocs design that fits the Simple theme.

Cheers,

Wolf

Jose Antonio Molina Busquiel

unread,
Mar 23, 2015, 7:01:34 AM3/23/15
to silverst...@googlegroups.com
Hi,

All the efforts should be oriented to implement this module.
The main CMS 's all have this ability.
It is somewhat fundamental in Silverstripe.
It's like shortcodes. Long ago should be allowed nested shortcodes.
Thank you very much for all your efforts Wolf.

Best regards,
Jose A.
Reply all
Reply to author
Forward
0 new messages