Question: does versioning only save 2 stages? about silverstripe-blocks HOT 6 OPEN

This issue is a result of the history tab currently being coupled with the site tree part of the cms. I think I read somewhere that there are plans to make history tab work with versioned dataobjects in ss core. A quick google found this module, which seems like it could be a good start in the interim. https://github.com/bluehousegroup/silverstripe-data-object-version-viewer

Also this module might be a more suitable basis than blocks module - https://github.com/dnadesign/silverstripe-elemental/

from silverstripe-blocks.

Thanks for the clarification and those 2 references. You're right that elemental might fit better to my use case. However it doesn't support multiple block areas, so if I'd want to support that, I'd better stick with this one.

from silverstripe-blocks.

I often swap out $Content with blocks interface as well in the CMS (using
this blocks module). You could even save blocks' content into the page
Content area (along with in-text anchors per block) to make your pages
searchable & deep-linkable.

The current versioning interface (buttons, really) gets added by the
BetterButtons module if I'm not mistaken. The Versioned extension on itself
adds full extra tables for historical versions to the DB, identical to
pages. So the version-viewer module should work perfectly for that (nice
find, Shea!)
​

On Mon, Apr 18, 2016 at 11:32 AM, Anselm Christophersen <
[email protected]> wrote:

Thanks for the clarification and those 2 references. You're right that
elemental might fit better to my use case. However it doesn't support
multiple block areas, so if I'd want to support that, I'd better stick with
this one.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#82 (comment)

from silverstripe-blocks.

Another problem, which one of my clients just ran into, is that there is no way to differentiate between Saved and Published. Basically, if the client makes a change to a block and clicks "Save" then both buttons are green and the client doesn't know that the "Saved" version isn't actually published. It's not till they click "Published" that the version that they are seeing in the CMS goes live. So...I would imagine the add-on needs to be updated so that the "Published" button is updated so that it reflects the actual published state of the current "version" that is being seen, right?

from silverstripe-blocks.

Hi Jeff,

You could take a lack at my block enhancements module for that kind of
functionality.

Op 4 aug. 2016 4:44 a.m. schreef "Jeff Whitfield" <[email protected]

:

Another problem, which one of my clients just ran into, is that there is
no way to differentiate between Saved and Published. Basically, if the
client makes a change to a block and clicks "Save" then both buttons are
green and the client doesn't know that the "Saved" version isn't actually
published. It's not till they click "Published" that the version that they
are seeing in the CMS goes live. So...I would imagine the add-on needs to
be updated so that the "Published" button is updated so that it reflects
the actual published state of the current "version" that is being seen,
right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#82 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA9ZokL_Lp0l5gmcR_wYrpJvnA4ZtlXsks5qcVITgaJpZM4IIB8t
.

from silverstripe-blocks.

Thanks Michael! I'll definitely look into that! :)

from silverstripe-blocks.