SilverStripe 3.0

[Sam Minnee]

Hi everyone,

We've made some mention of SilverStripe 3.0, and I thought it would be
worth talking a bit more about what we have in mind.

Felipe Skroki, SilverStripe's Creative Director, has gone back to the
drawing board with the SilverStripe UI. One major outcome is that
we'd like to radically simplify the SilverStripe CMS user interface.
In particular, we'd like to use front-end editing much more heavily,
rather than having an entirely separate user interface.

At one level, providing front-end editing is very simple, but one of
the powerful aspects of SilverStripe is the ability to create any kind
of template and content model that you like. If front-end editing is
going to be a successful replacement for the CMS, then we need to be
able to deal with the edge cases that this raises.

Furthermore, the ability to upgrade older sites to SilverStripe 3.0
without too much fuss is a major concern. We can't radically alter
the template language or the way that you define your data objects and
page types.

So, we're experimenting. Over the next few weeks, Ingo Schommer and
Hamish Friedlander are going to be making a prototype to see what's
possible. The outcome of that is going to give us a more concrete
idea of what's possible.

That, of course, only one of the areas that we are looking at for
SilverStripe 3.0. Some of the other things on our radar are:

* Improved mobile support

* Improved interaction with social networks

* Separation of Sapphire & CMS

* Completion of the ORM rewrite

* Improvements to the handling of download, images, and other media

* Better tools for module and configuration management.

* Updating the template engine so that uses a more robust parser

One of the reasons that we're announcing this at the same time as the
GitHub migration is that we expect that GitHub will make it easier for
the community to be involved with the development of SilverStripe
3.0. This is a major release, and an opportunity for us to all make
improvements to SilverStripe that we've been wanting for a long time.

SilverStripe 3.0 will be the next release to come out of the current
trunk.

In addition, once we have migrated to GitHub, we plan to create a 2.5
branch based on the current 2.4 branch. This will be a place to make
more minor feature enhancements. We will do this because we want to
the 2.4 branch to be limited to bugfixes only. The 2.4 -> 2.5 upgrade
path will be substantially easier than 2.3 -> 2.4; we don't plan on
making significant API changes in 2.5.

We don't have any details about timeframes at this stage, but we're
starting to ramp up our efforts on SilverStripe 3.0 now.

Thanks,
Sam

[Hamish Campbell]

Two immediate thoughts:

1. IMHO, your "other things" list is vastly more important to the
project than a CMS UI change.

2. The first reason most people give me why the switched to
SilverStripe in the first place is the CMS. What is the rationale
behind such a significant paradigm shift?

A classic case was a presentation at our last Auckland PHP Users Group
Meetup. Keri & Craig from PixelFusion.co.nz talked about how they
switched from SilverStripe to Symfony because they were frustrated
with ORM & templating limitations, performance issues, the difficulty
of upgrading between even minor releases and a lack of community. They
talked about how they still wanted the CMS features and they
proeceeded to present a very slick CMS they're building in ExtJS that
has a similar look and feel to SS. Cue an impressed crowd.

I'm not against what is being proposed and I'll be very interested to
see what Ingo and Hamish come up with, but it doesn't feel like the
best use of resources. Surely once the underlying issues are resolved,
building a Font End CMS would simply be a case of creating a new
module that can work in tandem with the CMS that has made SilverStripe
so popular.

My 2c.

Hamish

[Dan Rye]

In the middle of a lot but wanted to quickly chime in about the CMS.  I'd love the option for a front-end CMS, however I'd like it to be just that, an option.  The way I see it the back-end is going to be needed for back office type things (security, reports, etc) and the current "pages" tab would be a nice back office extension.  A front-end CMS *module* would be the way I'd like to see a front-end CMS implemented. giving the options, and possibility even supporting both with different security classes.

Sorry this is abrupt, I'll engage more later.
-Dan

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Martijn Van Nieuwenhoven]

I agree with Hamish..

I really fell in love with the CMS UI (although I head to learn here some things so she does what I want), icm the Sapphire Framework.
Adding it as a optional layer on top of (for example) BlackCandy so devs can choose to use it or not...

Really, I almost never have to explain something to my clients, because its so logical..

my 4c with tip...

Martijn

[Mat Weir]

I'd love to see what Hamish and Ingo have come up with too.

We already use front-end page editing in a number of sites, but it's limited to page editing and doesn't include page creation or reordering. It's great how easy is to use CMS fields on the front end though, including tabs, HTML editor, Mr Cheese's dataobject manager, etc!

Mat Weir

[Tim Klein]

Yeah agree.

the interface is pretty good as it is. Have had lots of good feedback
from my clients.
I personally don't like 'front-end' editing too much.

Anyways I think a good thing to achieve would be to separate the cms
ui from the rest, and then splitting it up
so there can be a 'frontend cms' or 'iphone-cms' module...

--
Tim Klein

address: Level 1, 1 Searle Lane, Queenstown
skype: kelptim
email: t...@kelpdesign.com
website: http://www.kelpdesign.com
phone: +64 3 409 2031
mobile: +64 21 234 35 78

---

Check out http://www.page-elements.com/

[Sam Minnée]

> 1. IMHO, your "other things" list is vastly more important to the
> project than a CMS UI change.
>
> 2. The first reason most people give me why the switched to
> SilverStripe in the first place is the CMS. What is the rationale
> behind such a significant paradigm shift?

...

> I really fell in love with the CMS UI (although I head to learn here some things so she does what I want), icm the Sapphire Framework.
> Adding it as a optional layer on top of (for example) BlackCandy so devs can choose to use it or not...
>
> Really, I almost never have to explain something to my clients, because its so logical..

Because we're still in the experimentation phase with this it's difficult to talk in too much detail about this stuff, but I'll make a few general comments:

* The system is, in many ways, good enough. But there are content editing systems out there that are more straightforward than SilverStripe for people making content changes. This can manifest itself as requests like "oh SilverStripe's a good CMS but it's a bit much for my blog. Can you install Wordpress because that's better for blogging". I believe that we *can* improve, and we'd like to try. Maybe I want to have my cake and eat it too, but that's how good software gets made.

* One issue that we run into is when you have a heavily tailored content model, it can be confusing to work out which field in the back-end corresponds to which piece of text on the front-end. Providing an editing interface within the context of the real template can help with this.

* We still want to keep the most successful elements of the CMS. For example, the site tree is a great way of seeing an overview of your site. In fact, the biggest issue with the site tree is that it's not given enough real estate.

* We don't want to let this work distract us from necessary improvements to the core framework. One of the reasons for separating Sapphire and the CMS is to make it easier to have separate groups of people work on each, so that we're not stealing attention from each other.

* Right now, the trunk CMS is still a bit of a work in progress, because the JavaScript refactoring work wasn't 100% finished. So, regardless of which way we go, we have work to do before we have a production-ready CMS.

[dospuntocero]

Hi Sam, im really happy to hear about all the new things in
silverstripe 3.0, but there is 1 point that im not that sure is that
important... im talking about the upgrade of older sites, maybe that
will slow things down and im not that sure that many sites will want
to change its current system for other, thinking in the cost for the
change, the new time clients will need to learn new tricks, etc...

we already use a totally different UI for the CMS, but all the work is
based in block lots of css and js and rewrite with our own. its kind
of sad approach... i think it will be interesting to have a unified
front end editing instead of having a completely different system for
the backend that probably will simplify the way we create interfaces
for editing instead of extending leftandmain, one of the complex
things to extend in silverstripe (for me at least)

best
francisco

[Will Rossiter]

1. IMHO, your "other things" list is vastly more important to the
project than a CMS UI change.

Well depends on your point of view as to whats important. This is after all a dev mailing list so its going to come out quite one sided towards the core framework but like Sam said, the CMS UI refactoring won't drastically affect Sapphire development as they can be worked on in tandem.

The thinking behind the need of a UI refresh is that sites being built with SilverStripe have grown from simple, small ~50 page sites to dealing with ~1,000s of pages and providing a backbone for a wide range of complex content models; All more than what the CMS was originally designed to support (over at least 5/6 years ago). 

So there is a huge scope for improving the UI to allow greater flexibility and generally making the CMS product better - not just for developers (easier customization) but for the clients. 

im talking about the upgrade of older sites, maybe that
will slow things down and im not that sure that many sites will want
to change its current system for other, thinking in the cost for the
change, the new time clients will need to learn new tricks, etc...

From the sounds of it so far SS3.0 with its new lighter sapphire, redesigned ORM, improved module management support etc etc would have very little scope for supporting upgrades from 2.4 easily. 

I personally think it would be better looking forward rather than backwards for 3.0.

--
Will Rossiter | Developer
SilverStripe
http://www.silverstripe.com

Mobile: +64 27 389 3454
Office: +64 4 978 7330 ext 58
Skype: will.rossi

Level 5, 97-99 Courtenay Place
Wellington, New Zealand

[howardgrigg]

Excited to hear the ideas of 3.0 but unsure how a SS based site that
is anything more than just pages with content fields would work with
front end editing.

While front-end editing of db contents is easy to handle so much is
done by editing dataobjects and associating them with pages - those
relationships make sense as a tickbox table in the CMS but are
displayed totally differently on the front end. I really look forward
to seeing what Ingo and Hamish come up with to resolve these types of
issues.

Personally I would see frontend editing as an option (or module) which
could live alongside a strong CMS but doubt how much simpler it would
be to bundle all the functions of the CMS into the front end.

[Hamish Campbell]

On Nov 4, 3:35 pm, Will Rossiter <w...@silverstripe.com> wrote:

> I personally think it would be better looking forward rather than backwards for 3.0.

Can I suggest that the core team hold off making comments for a day or
two to let the community have a say.

For better or worse, you've asked for feedback, so let it be heard
before rushing to the defence of the master plan.

Hamish

[Sam Minnée]

> From the sounds of it so far SS3.0 with its new lighter sapphire, redesigned ORM, improved module management support etc etc would have very little scope for supporting upgrades from 2.4 easily.

This is not the case! Although the 2.x -> 3.x change does give us more of an opportunity to be more aggressive when changes APIs, it is critical that we ensure that there is a clear upgrade patch from 2.4 (or 2.5) to 3.0. Certainly, it will be a bit of a challenge to provide this, but we can't left 2.x users out in the cold. Being perfectly selfish, there are few organisations that would be more harmed by the lack of an upgrade path than SilverStripe itself.

Where it's not an automatic process, we will aim to provide documentation outlining what needs to change in your core code as part of the upgrade.

Thanks,
Sam

[Martijn Van Nieuwenhoven]

Hm... no! Share pro's and cons:)

[spronk]

>  * The system is, in many ways, good enough.  But there are content editing systems out there that are more straightforward than SilverStripe for people making content changes.  This can manifest itself as requests like "oh SilverStripe's a good CMS but it's a bit much for my blog.  Can you install Wordpress because that's better for blogging".  I believe that we *can* improve, and we'd like to try.  Maybe I want to have my cake and eat it too, but that's how good software gets made.

I agree. However I'm not convinced front end editing is the complete
solution to this - have you guys seen Concrete 5? It's an extremely
promising looking concept, but for stuff like blogs, or pages with
reasonably complex data, it still becomes quite cumbersome to use.

Personally I think SilverStripe's strength is in the integration of
the CMS and Framework from a site developer's perspective. SS allows
the creation of dependable 'systems' where other CMSs end up being a
nasty collection of modules and "custom fields". By all means, work on
decoupling the CMS and Framework, but don't break the ease of
scaffolding a system in doing so (though I suspect you guys already
have this sussed).

My biggest frustrations with SS are a) the template language (which is
more philosophical designer vs developer stuff than anything else and
I won't go into it here), and b) the usability of the CMS.

The CMS to me feels sluggish and clunky - very modal, and doesn't give
me confidence to work quickly. For example, a common workflow of mine
is to Save & Publish an existing page, then create a new page or
subpage. There's an asynchronous system backing this up, so I can
usually go ahead and click on the page I want to create a subpage of
in the SiteTree while my previous page is saving, however it certainly
feels like I may break something whilst doing so.

What happens in between is a horrible series of ajax loading icons and
slow iframe refreshes. It would be nice if the SiteTree was less HTTPy
- especially with creating new pages.

Second, I think possibly one direction to consider is increasing the
ease of which developers can customise the SiteTree itself, and what
is currently the right hand panel in the CMS. It would be nice if my
Blog didn't use the SiteTree at all - or simply provided a 'snippet'
of the latest entries in the SiteTree with a 'more' button to load a
designated area for this.

>  * One issue that we run into is when you have a heavily tailored content model, it can be confusing to work out which field in the back-end corresponds to which piece of text on the front-end.  Providing an editing interface within the context of the real template can help with this.

One of the big reasons why the company I work for went with
SilverStripe over Concrete 5 (the other finalist, if you will) was the
OO model and the ease of scaffolding tailored content models. However,
I still wish some of the Concrete 5 features would make their way into
SS. Maybe you could take some inspiration from Apple's dashboard
widgets, how they flip around to reveal the configuration or back end
behind them, and use something like Aloha editor for some of the the
simple in-place editing.

I get the feeling that it's a pretty big leap though, and I think if
it comes down to a choice between tightening and polishing what exists
already, and leaping into a new paradigm, I would probably choose the
former.

[Michael Gall]

> My biggest frustrations with SS are a) the template language (which is
> more philosophical designer vs developer stuff than anything else and
> I won't go into it here), and b) the usability of the CMS.

I've long been against the idea of this custom CMS without anything
even close to a true compiler, but I realise that there's a massive
amount of baggage tied up in it as well. Leaving very little choice
but to continue to support it. However I think there is a solution.
Firstly decoupling the template engine (which I think Sam mentioned in
an earlier post) from the object model and controllers. Ideally this
would let the developer use a regular php file. This probably won't
have the same decoupled syntax as it is now, but would provide an
option.

I've done something similar to what I'm suggesting in another project
by including an arbitrary template file into the context of an object
function. It then lets you access the $this variable in your
templates.

Once that's done I think it paves the way to true improvements to the
templating. Implementing something like XHP would then be possible
(and awesome) http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919

Cheers,

Michael

[Sam Minnée]

> Firstly decoupling the template engine (which I think Sam mentioned in
> an earlier post) from the object model and controllers. Ideally this
> would let the developer use a regular php file. This probably won't
> have the same decoupled syntax as it is now, but would provide an
> option.

Although I still like our template language, I'm very much in favour of both decoupling and rewriting it to use a proper parser.

-------
Sam Minnée | Chief Technology Officer
SilverStripe
http://silverstripe.com

Phone: +64 4 978 7334
Skype: sam.minnee

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Everyone

Exciting times! I have just added 0.5 cents worth below.

---------------------- MODEL ADMIN AS STARTING POINT ----------------------

Firstly, I would take modeladmin and improve it in such a way that:

a. it can be used to edit Pages

b. it has a "front-end" extension, which allows you to make stuff editable in the front-end where this makes the life of the editor a bit easier.  

I am recommending it because ModelAdmin is actually much more in need of  polishing than the rest of the CMS. In that way we solve two problems in one.  Of cours, Ingo is a author of ModelAdmin, so that could work well. 

---------------------- FRONT END EDITING CALL ----------------------

We already have the ability to add something like this to any part of our templates:

if dataobect / page canEdit?

  add button here which says ... "edit this list"

end if

Perhaps this could just be made a bit easier by allowing this to be done in a single call $AddFrontEndEditor("MyDataObjectClass"), which uses a ligth-box effect to allow super fast editing of the MyDataObjectClass while browsing a site. 

---------------------- WHAT MODULES TO INCLUDE ----------------------

I also recommend that the include (parts of) dataobject_manager within the CMS / Sapphire framework as well as a few other modules. 

---------------------- SORTABLE ----------------------

Another recommendation would be to include a standard setup for DataObjects to be sorted.  There should be a static variable called $sortable, which instantly makes any dataobject sortable, including a nifty interface to do so. 

---------------------- DATAOBJECTS DESCRIBING CLASS ----------------------

Also, it might be worthwhile to create a dataobject "HelpForEditableClasses" that holds additional information on each dataobject type (including SiteTree extensions) - e.g. it holds one row for HomePage, one for for Page, one row for DataObjectOfMyListOfStuff).  In "EditableClasses" we can store things like a bunch of "HELP" images to show how to edit stuff on a page, etc... etc.... It has advantages to store it in the DB over storing it directly in the "php class", because in that way a non-technical person can add instructions, reminders, etc....  

I imagine, that when you open ModelAdmin for a specific DataObject, this additional inforamtion is instantly available under a help button.  IN the same way, if you open a page in the CMS, there is an optional HELP button which shows you a few screenshots on how to work with the specific page type.

---------------------- FORKS VS SIBLINGS ----------------------

Often browsing / editing needs to take place in a fork like way..... I recommend that in 3.0 we place more emphasis on the ability to go through pages / records in sibling way. 

Fork: 

 - search

 - open first item and read / edit

 - go back to search results

 - open second item and read / edit

Sibling: 

 - search

 - open first item and read / edit

 - click next / previous and read / edit

Just some thoughts ;-)

Nicolaas

[Jason Stratford]

Adding another opinion to the Front End editing issue.

Having a choice of CMS interfaces as modules that are separate from
the core framework would be a massive win win. As we all know a 'one
interface fits all' never works, promotion of choice for the site developer
would be a signifiant plus for Silverstripe.

For us being able to sell front end editing, traditional back end editing
or even mobile editing to a customer as merely a choice of module
installation would be brilliant.

Jason

[Sam Minnée]

Another way of framing this suggestion is that we should push more of the CMS logic into the model layer and out of the specific controllers that manipulate it, which I wholeheartedly support.

Even if it doesn't necessarily mean that there will be multiple CMS interfaces initially, it will make it a hell of a lot easier to add more should we need to.

On 4/11/2010, at 9:13 PM, Jason Stratford wrote:

> Adding another opinion to the Front End editing issue.
>
> Having a choice of CMS interfaces as modules that are separate from
> the core framework would be a massive win win. As we all know a 'one
> interface fits all' never works, promotion of choice for the site developer
> would be a signifiant plus for Silverstripe.
>
> For us being able to sell front end editing, traditional back end editing
> or even mobile editing to a customer as merely a choice of module
> installation would be brilliant.
>
> Jason

-------

[Hamish Campbell]

On Nov 4, 3:35 pm, Will Rossiter <w...@silverstripe.com> wrote:

> > 1. IMHO, your "other things" list is vastly more important to the
> > project than a CMS UI change.
>
> Well depends on your point of view as to whats important. This is after all a dev mailing list so its going to come out quite one sided towards the core framework but like Sam said, the CMS UI refactoring won't drastically affect Sapphire development as they can be worked on in tandem.

Well, of course, it's is a development framework, right?

But my concern is that this sounds like more that a refactoring. A
refactor implies a refinement on the existing (award winning) CMS. As
I read Sam's post, you're talking about a significant shift away from
SilverStripe's major points of difference: a powerful, customizable
and extensible CMS out of the box.

It sounds like you're setting yourselves the incredibly lofty goal of
being all things to all people, which is admirable and I look forward
to seeing the prototype. That said, I simply can't see how a front end
CMS can provide anything but a subset of the existing CMS
functionality (which is probably why I and others are asking why this
wouldn't be 'extra' functionality as a module, rather than the new way
of doing things).

I accept, however, that I might be wrong, and that the purpose of the
prototype is to explore the options.

> The thinking behind the need of a UI refresh is that sites being built with SilverStripe have grown from simple, small ~50 page sites to dealing with ~1,000s of pages and providing a backbone for a wide range of complex content models; All more than what the CMS was originally designed to support (over at least 5/6 years ago).

This doesn't really explain the change in thinking from a "Back End"
system to a "Front End" system.

> From the sounds of it so far SS3.0 with its new lighter sapphire, redesigned ORM, improved module management support etc etc would have very little scope for supporting upgrades from 2.4 easily.

To be honest, API changes between major releases are ok by me. The
core team has made huge improvements in the last year in supporting
previous release branches (eg, 2.3.x and 2.4.x) and in easing the
upgrade path between minor versions. Major releases are the right time
to make API changes, so I don't think that needs to be discussed in
too much detail.

Again, however, I come back to the idea that what is proposed for the
CMS is much more than that.

> I personally think it would be better looking forward rather than backwards for 3.0.

I maybe took that the wrong way when I first read it. Yes, looking
forward is better... but then, acknowledging and building your
successes (all those awards on the SilverStripe.org awards page are
for the CMS, no?) is a good idea too. I wouldn't call that looking
backward.

Anway, enough naysaying from me - I'd just ask you don't ignore the
community feedback. When you organise a PHP meetup for 40-50 people
and one of your presenters spends 10 minutes explaining why they moved
away from SilverStripe despite the great CMS, it leaves an impression.

Regards

Hamish

[Marcus Nyeholt]

> 40-50 people and one of your presenters spends 10 minutes explaining why they moved away from SilverStripe despite the great CMS

Backstory? (probably be better linked than polluting this conversation thread) 

[Sam Minnée]

> Anway, enough naysaying from me - I'd just ask you don't ignore the
> community feedback.

Yeah we're certainly going to factor this feedback into the development of the prototype, as well as use it to judge the prototype once it's ready. Some of these concerns have also been raised internally, and the goal here is to take a high-risk stab at doing something more dramatic.

I think where we're going to end up is having a more fluid relationship between the CMS and the front-end, rather than moving entirely away from a separate system.

It's also very clear that we can't neglect framework improvements. The reason that the initial email focused on the front-end editing component was mainly that this was the only feature that hadn't been discussed previously on ss-dev; most of the potential framework improvements have been discussed on and off for a very long time. ;-)

Cheers,
Sam

[Michael Gall]

I'd like to talk about the DataMapper that's been discussed. The most
major thing that has happened with the Rails 3.0 release is what they
call Arel. It's basically the DataMapper style thing you are talking
about. It's pretty cool, but really complex (it handles alot of the
trouble of joins as well). It's definitely possible to do something
similar in PHP.

You take the jQuery approach of always returning a chainable object.

class Collection extends DataMapper {
function where();
function select();
function innerjoin();
function order();
function limit();
}

each method returns a new Collection object, so at any moment in time
you have a query and lazy loads, when it's iterated.

You can also then create what's known in Rails as scopes, again, this
should always return a DataMapper object, allowing you to chain calls.
$customers->profitable()->female();

class CustomerCollection extends Collection {
function profitable() {
return $this->where("Profitable = 1");
}

function female() {
return $this->where("Gender = 'female'");
}
}

Finally, and I think this is something that would really help the
crazy sql munging that happens in Decorators, I think it's important
to be able to name, selected fields, joins, or conditions.

class CustomerCollection extends Collection {
function profitable() {
return $this->where(array("Profitable" => "Profitable = '1'"));
//This won't be executed.
}
}

This lets you overwrite them easily at a later date before the SQL is
generated/executed.

class CustomerDecorator {
function beforeExecution() {
$this->where(array("Profitable" => "Sum(Profit) > 1000")); //This will be.
}
}

Cheers,

Michael.

[Sam Minnée]

Are you familiar with the work that's been done so far? It's been dormant for a while, but it's in keeping with your idea.

It's here - https://github.com/sminnee/sapphire/tree/new-orm - but once we switch the main repo I'll get it off my personal github account and onto the main one.

The class DataList replaces DataObjectSet (actually it inherits DOS for backward compatibility) and provides the kinds of methods that you're describing. It is functional to some extent but is far from complete.

One main new thing that you're recommending is the creation of custom DataList subclasses for particular objects. That seems like a good idea.

One thing that I don't like, however, is the use of WHERE snippets as the argument to where. We probably want to support it for legacy reasons but deprecate it.

Django had a good idea using an map syntax. Well, they used named arguments but we're in PHP land so we'll use a map:

This would return Sarah and Samantha but not Samuel or Barbara.

return $this->where(array(
'Gender' => 'Female',
'Name:StartsWith' => 'S'
));

A major benefit is obviously to protect against SQL injection. But it also provides us with a good place to move the SearchContext functionality to. This would give us a list of everyone called Ted from accounting:

return $this->where(array(
'FirstName' => 'Ted',
'Group.Title' => 'Accounting'
));

Which is why I suggested 'Name:StartsWith' rather than 'Name.StartsWith' - . is for relations and : is for filter types.

I'm offline for a few days (flying to Zürich) but I'll catch up on the discussion when I'm back. Or maybe you'll catch me bored in an airport somewhere. ;-)

Cheers,
Sam

[Fred Condo]

On Wed, Nov 3, 2010 at 4:41 PM, Sam Minnee <sam.m...@gmail.com> wrote:
> Felipe Skroki, SilverStripe's Creative Director, has gone back to the
> drawing board with the SilverStripe UI.  One major outcome is that
> we'd like to radically simplify the SilverStripe CMS user interface.
> In particular, we'd like to use front-end editing much more heavily,
> rather than having an entirely separate user interface.

My initial reaction to front-end editing is -1, based on my experience
with Plone. Front-end editing sounds like a great idea, but the UI/UX
issues are insidious. Two of the major issues: 1) how to unobtrusively
indicate that fields are editable without defeating the WYSIWYG; 2)
when the Ajax front-end editing was enabled, editors & admins could no
longer simply select text or click on links in editable fields (the
field would go into edit mode on click).

As well, it was extremely difficult to design templates deviating from
the stock Plone layout that would work with front-end editing. The
flexibility of SS templates is a major strength.

The above notwithstanding, SilverStripe is not Plone (thank
goodness!), and I'm interested in seeing the prototype and being
proved wrong.

[dalesaurus]

Wow, what a fun week of SS threads!

I would like to voice my support for Hamish's initial response as well
as Jason and Nicolaas. Front end editing is a nice OPTION but not a
good STANDARD. There are many (many) other CMS' out there that do
that, and few do it really well. The separation of the two allow for
more precise optimization and security controls. When your frontend
is tied to your data management it makes core changes turn in to a
long deathmarch of coding. Just check the recent release timelines
for Drupal or TYPO3 (the latter of which performed a similarly
ambitious change to their administration philosophy).

At the bare minimum, the ORM + ModelAdmin (and required CMS backend)
and forms system keep me coming back to SS project after project. I
don't want to judge before I see a prototype, but I am skeptical about
the move to front end editing.

For compatibility I recently have fallen in favor of the total cut
off. Python and Django are notorious for this between versions, but
in the end it is a good thing for developers and maintainers. Check
out any of the older Wordpress modules to see what kind of chaos
developers must deal with to see that it works with 1.2 up to 3.0.
I've seen compatibility files that are larger than the module itself
which is pretty crappy. As long as the documentation follows suit, I
would not mind at all if 2.x was not compatible with 3.0.

But I heart the rest of the list of 3.0 goals! Also, I like the
template system but that is likely because I'm a developer.
Decoupling is good, but allowing other parses would make a real mess
of the community templates.

On Nov 4, 5:42 am, Fred Condo <fco...@quinn.com> wrote:

[Felipe]

Hi Guys,

First of all thanks for all the insights, suggestions and opinions.
Positive or negative, all are really constructive and useful for us.
I'm part of the team behind the SS 3.0 UI redesign.

Before drawing a square on the white board
we interviewed and observed CMS users, from basic site owners
new to SilverStripe to full on web admins managing 1000's of pages
and spending 40h+ a week in front of the CMS.

Before giving you more details about this
I'd like to clarify some info about the front end editing below:

1) The back end editing will still be possible - First and most
important - we're not planning
to get rid of back end editing completely we acknowledge the front end
editing may not
be the best case for every situation. And given your feedback is worth
considering to be
something that can be enabled or disabled by the dev. So current
templates can be compatible
and upgrades can be cost effective.

2) Front end editing it's only for content - We'll keep using a back
end interface to manage
security, pagetree, comments, files, etc etc

3) We won't do it if we can't have a good prototype - As you know Ingo
and Hamish will be working
on a prototype on the next few weeks to address the challenges we
have. If we can't get to an elegant
solution (or at least know that we can't) we'll leave it and move on.
The last thing we want is a feature
for the sake of a feature.

4) Why we think front end editing is good? - Basically is less
abstraction, you don't have to guess what
will happen if you click the save button. Is similar to the thinking
behind the wiimote (easier to play tennis
using the control as a racket than pressing buttons) .

Please keep coming with the amazing feedback and question, its been a
pleasure participate on this
process.

Felipe

[Martijn Van Nieuwenhoven]

I think frontend editing is a very nice feature in addition to the CMS as it is now.

But I think it then should not be limited to pages only.
Items like news or products, should be a DataObject in my opion to prevent having a large SiteTree, but still each DataObject must be appear as a page if we want to.

Some ideas:

I think its great when you can add the option as an Extension like Translatable.

Object::add_extension('MyDO', 'FrontendEditable');

or just enable it with static $front_end_editable_fields in the DataObject itself.

Also with a permission you can assign to a MemberGroup and maybe also with a canEditFrontend() method, so we can lock certain DataObjects (or even some Fields of a DataObject) when needed.

I don't know if it will work, but maybe its possible to let SSViewer adding a surrounding tag to the editable content and disables the Partial Caching when logged in when a Member has FrontendEdit permissions. When the editable area is clicked a lightbox popup will show the Frontend EditForm with all the front_end_editable_fields of the DataObject.

In that way we won't have to polute templates with html to make templates editable aware and old templates will still work as normal.

That said, maybe its is nice to add the option to allow inline editing for example menu items or lists for quick changes in the same way we add Partial Caching to our templates:

<% inline_editable %>$MenuTitle<% end_inline_editable %>

This might be a performance hit, but these are my thoughts of FrontendEditing..

Cheers,
Martijn

[Nicolaas Thiemen Francken - Sunny Side Up]

Nice ideas Martijn

[Uncle Cheese]

+1 for the effort to rebuild the backend UI. The SilverStripe CMS UI
seems to have been dying a slow death over the last few years. It's
not competitive with other open source CMS solutions, suffers from
numerous shortcomings in usability and organization, and, in general,
it's just dated. It's really just begging for some love from a
talented interface designer.

On the other hand, the Sapphire framework is brilliant, and
unparalleled, IMO, in any other CMS solution, and that's what makes SS
a no-brainer for me. I'm able to deliver solutions to my clients in
hours that used to take me days. Any improvements therein would be a
boon.

But it's hard for me to look past the attention that is needed on the
UX side of things. Frontend editing has been marginally successful in
the Blog module. Clients seem to enjoy using that interface over the
CMS backend if for nothing else than that it gets them out of SiteTree
mania.

UncleCheese





On Nov 5, 10:18 am, Nicolaas Thiemen Francken - Sunny Side Up
<nfranc...@gmail.com> wrote:
> Nice ideas Martijn

[Mark Guinn]

Have you thought/discussed about adding a better or more complete events/observer/pubsub system to sapphire? That was one of the cool things about working with the Kohana framework. Magento has it too if you can get past the complexity. It makes extending core functionality a ton easier though, if the number of events available are sufficient. Check out how Kohana does it for a good model that's not too tightly coupled.

I also agree that the backend could use a facelift, but I don't think it needs to be drastic. The simplicity of the interface is part of what I like about silverstripe vs. something like Joomla or Drupal where you've got all kinds of craziness (separate menus, articles, modules, etc). Just my 2 cents.

Mark

[Marcus Nyeholt]

I was umming and ahhing about whether to post this, as it may add to the confusion, but I figure that with appropriate disclaimers figure that it could prompt further discussion that can help Hamish and Ingo with their research. 

This has NOTHING to do with the core dev research that is being put in by Hamish and Ingo, other than they have been made aware of it, so don't take this to be any kind of official stance by SilverStripe at all, or indicative of any of the actual direction frontend editing might take. 

This is an experimental module that I've been playing around with off and on over the past 12 months to clarify some frontend editing ideas of my own. It's been sitting around on my github account for quite a while so some of you may have played with it already, and I've got a demo site up at http://playground.mikenovember.com/frontend-editing/  (admin:silverstripe, the db will reset itself occasionally). 

My take on things - the reality is that as the CMS is being used in more and more markets, the categories of users using the CMS are getting broader too, and even for a single installation there can be very different user needs that need addressing. Some people need only to edit some text on a page and submit it to a web editor for approval; some need to work with sets of data in a model admin style interface, some need to do complex configuration of pages in trees. I think SilverStripe definitely needs a frontend editing option for a certain class of user - the CMS is friendly, but less idiot proof than it could be for simple tasks (sorry to all those idiots I just offended :)), but at the same time also needs a solid CMS backend for more advanced users. 

[Matt Bower]

Hey all,

Now that I've finally caught up with the dauntingly long thread, I'll throw in my first 2 cents.

On Frontend Editing:

I've been working with the ExpressionEngine CMS for the last 6 months at a job I took on. EE is a backend-style CMS from days long past. However, the company that is responsible for it, EllisLab, released a second CMS product (both are commercial) called MojoMotor that works in frontend editing instead of backend editing. My boss hasn't gotten us a site to use MM on, but from what I hear from the EE community, MM is very much a lighter CMS better suited for smaller sites and that EE is still the big brother of the 2 CMS's. My point is maybe to consider releasing the frontend idea as a separate style CMS. I see frontend editing to be very limiting in flexibility since you have to find ways to manage Users, Files, etc within the context of the frontend. Not impossible, but maybe the job for a different CMS system. And that's where one of the many beauties of SS comes in is that you could create both styles of CMS's as different modules and just drop in the one you prefer. I could see using the lighter frontend editor CMS for smaller site projects.

As for the concern of relating which fields in the backend affect which content on the front, I have a few suggestions based on solutions I've done:

- When I create a new installation of SS, one of the early things I do is alter the labels in the backend for the Title, MetaTitle, and MenuTitle fields since, to the user, it could be hard to keep track of which one affects which area. They all could be the same if the maintainer just enters in the Title and tabs into the Content field. I add a note in parens after each one:
* Page Name (This is the page title in the content area)
* Navigation Label (This is the name of the page as it appears in the navigation)
* Title (This is the title as it appears in the top of the web browser and is used for SEO)
The rest of the fields, I think are pretty self-explanatory.

- Another option is to make a sort of map in one of the CMS tabs for the page entry. I did this for a client who had 7 modules to manage on the frontend of their homepage and so I created a tab with an HTML table in it that mapped out where each module was. One could do this with a prototype layout of a browser window and match each field to each section.

On CMS/Backend Efficiency:

The backend editing does feel a bit sluggish once I launch it on a production server. I think some time should be put into improving the efficiency of this functionality, similar to Apple's improvements to Snow Leopard where there was very little new features for users, but so much was improved under the hood. Also, some UI improvements would be good there. Some ideas, small and large:

- I don't fully understand the load order of the system for each request, but, if this doesn't exist, there should be a "light load" process. Things like the ImageField's iframe rendering don't need the whole system to boot up each time and the Restful Server only needs enough system startup to retrieve the data being requested. Maybe something like a read-only startup process that is more efficient since it won't be making any changes to the data in the system.

- In the SiteTree, create an entry at the bottom of each "branch" that is just "Add A Page" and it somehow brings up a list of possible page types to create. That will give the page creation process a little more context rather than "Select the parent page to create a page under, choose the page type at the top, then click 'Go.'"

- I agree that for things like Blogs and even stores, the site tree model is really inefficient and becomes unmanageable on a blog that's been alive for a few years and receiving frequent posts. I've been mulling over an idea to branch the SiteTree a step below and create 2 branches: a Page which is a static piece of timeless or infrequently changing content, and an Entry which is a piece of content that will have a possibly infinite number of sibling entries. That differentiation may be a little vague as Im still trying to better clarify it, but the major difference comes in the functionality. A Page (as we're familiar with) lives in the site tree in the Left panel of the backend. An Entry will not live in the site tree panel. My idea so far has been to make a repurposed ComplexTableField to edit them in so that they are stacked in short reference and then either a modal window pops up to edit the entry, or the row on the CTF opens down to reveal the Entry's CMS Fields. An entry will also have much fewer fields to edit in the CMS. Many of them will be automatically set in the DO code. There would also be an associated EntryListingPage that you associate the Entry subclass with and it will automatically show the altered CTF on a new tab.

That's all I've got for now. Plus, my writing of this response is cutting into my work hours and I need to hop on that before my boss kills me. More later

Matt

[Alexis Hope]

Wow very interesting read.

All I can say is (and I'm sure everyone here knows) the SS back end CMS has been welcomed by all the end users I've dealt with. 60+ computer illiterates have been loving been 'loving it'.

At the moment I can't conceive a frontend system, but have a lot of confidence in the core team.

Kind regards,
Lex

[mateusz]

From my perspective there are some things in the core that desperately
need to be addressed. That stuff has probably been discussed since
2005, but I haven't been around for that long, so just firing away :)

- versioned filesystem and versioned relations. This is to big to be
done as a patch. Quite a lot of problems I had in the past was because
of this inability of the world of "Pages" to cooperate with the world
of "Files".

- flexibility of the CMS - for example have you ever tried expanding
the list of options in the linking sidebar? You need to extend big
pieces of the CMS, and rewrite the tiny_mce_improvements.js which ends
up being unsupportable.

- rewrite of TableListField into something cleaner and easier to use
from the user's perspective and coder's perspective. Needs to sort,
search, page, allow to easily plug-in per-row actions and per-table
actions, actions on multiple rows, addition of rows and detail editing
that would handle the relations well. And can't be a set of tangled
and deeply extended classes. I'm dreaming, right? :) Actually a set of
cleaner form fields for handling relations and long lists of elements
would be very welcome.

Regards,
Mat

[dospuntocero]

+2 for simply the way we are allowed to customize the cms and
formfields

+3 for adding interfaces like UncleCheese's dataobject_manager to the
CMS core. complextablefields looks ugly and the code is old
(javascript mess there), dataobject_manager works better, has
sortable, search, etc...

+1 for a nice dashboard in the cms. i can provide ideas for this part,
since im working in something for the past weeks, only in wireframes
for now, because i haven't had the time to fight with LeftAndMain.php

regards
francisco

[Sam Minnée]

> +3 for adding interfaces like UncleCheese's dataobject_manager to the
> CMS core. complextablefields looks ugly and the code is old
> (javascript mess there), dataobject_manager works better, has
> sortable, search, etc...

I definitely think that we need an improved alternative to ComplexTableField. However, the problem with dataobject_manager is that it's built on top of subclasses of ComplexTableField. For SilverStripe 3 I'd like to see something rewritten from scratch. One SS3 feature in particular that we can exploit is the new ORM - it's going to make it easier to customise the data that's displayed in a table field without needing to pass dozens of configuration arguments.

Potentially it could be based on the dataobjectmanager - its UI and featureset is certainly very nice - although I would expect a major refactoring to replace its foundations. Also, I don't believe that there are any unit tests for dataobjectmanager yet; unit tests would be necessary before adding such a feature into core. I would suggest waiting until the new ORM is in trunk, or at least working from the new-orm branch after we move to github.

> +1 for a nice dashboard in the cms. i can provide ideas for this part,
> since im working in something for the past weeks, only in wireframes
> for now, because i haven't had the time to fight with LeftAndMain.php

I would say that we look at this in more detail after we establish the overall framework for the SS3 CMS - front-end editing, etc. It would be great to see this kind of feature in the CMS, it's just a question of how it gets implemented. There's a pretty high risk that anything that's created now wouldn't be suitable for SS3 so I would give it.

[Uncle Cheese]

I've had a working version of DOM that is decoupled from CTF for a
while, but I just can't seem to find the time to evolve it into
something mature.

Totally agree that it's a severe shortcoming of DOM. Kind of ironic
that it purports to be so much better than CTF, but yet it's so
reliant on it. :-)

[Martijn Van Nieuwenhoven]

There is a Dashboard module already:

http://www.silverstripe.org/all-other-modules/show/9084

And personally I rather install it because I need it, then disable it because its core....

Same as DOM, I really like it, but I would go for a rather simple, lean and solid TableList codeset thats easy to extend, then a bloated core codebase which is harder to maintain. (You can't take away DOM from Uncle Cheese do you? ;) )

I think it was a good step to dump a lot of FormFields in 2.4.x (If I remember well) and I think its better to have a few FormFields that are really needed for the core codebase, but which we can also decorate instead of only subclassing (dunno if thats possible..) and let developers create custom FormFields which are unique for their projects.

In my small ideal world, the SS3 series will be a solid, less bloated Sapphire and CMS codebase to start with (js refactoring, cms and sapphire splitting) and new features that might make the core codebase possible harder to maintain and make release cycles longer, should be optional.

Cheers,
Martijn

[Hamish Campbell]

On Nov 9, 5:15 am, Martijn Van Nieuwenhoven <marva...@gmail.com>
wrote:

> In my small ideal world, the SS3 series will be a solid, less bloated
> Sapphire and CMS codebase to start with (js refactoring, cms and sapphire
> splitting) and new features that might make the core codebase possible
> harder to maintain and make release cycles longer, should be optional.

I think that nicely summarizes what most developers would like to see
out of 3.0.

[Nicolaas Thiemen Francken - Sunny Side Up]

+1 for Martijn's comments. 

The way I see SS evolve is one tiny super core and 1000s of modules.  If SS Inc can build the former then the community can build the latter. 

[Matt Bower]

Rather than the backend Dashboard being part of the core, I would like to see the Pages CMS panel be removed from being the hard-coded default CMS panel when logging in to allow for sites to define their own default CMS panel, say, a dashboard.

[spronk]

Just a quick comment:

On Nov 5, 5:39 pm, Felipe <felipeskro...@gmail.com> wrote:
> 4) Why we think front end editing is good? - Basically is less
> abstraction, you don't have to guess what
> will happen if you click the save button. Is similar to the thinking
> behind the wiimote (easier to play tennis
> using the control as a racket than pressing buttons) .

Make sure you don't forget that it's a double edged sword. Because of
stuff like versioning and draft vs. published, front-end editing may
in fact introduce *more* guesswork than using the back-end UI. I.e.
are you saving a partial version, are your edits just local until you
save your 'page' as a whole, are you going to spam the version control
history, is it going to affect the live site immediately etc.

[Marcus Nyeholt]

You raise a good point - making people explicitly aware of whether they're viewing a Live / Draft version of content is very important. A couple of ideas

• A prominent visual indicator that what is being viewed is NOT the live site
• Highlight in some way the changed content. This may not be a permanent highlight, but an action like "Show modified content" 
• On modified sites, let users easily see what the content is on the Live site. This would be something like how hovering text on pages run through google translate pops up a box showing what the original text was. 

Marcus

[Nicolaas Thiemen Francken - Sunny Side Up]

just to add another one cent now - I reckon, and I would be interested to hear your experiences, that editing goes as follows:

a. identify page that needs updating

b. open in CMS

c. edit text

d. save and publish -> review results

e. edit some more

f. save and publish -> review results

g. repeat a few more times until perfect

DONE

Moral of the story, the whole concept about saving a draft and then publishing is beyond most users. The concept is excellent, it all works, but for Joe Average it is too abstract and tricky. I know this might sound strange as it is not such a difficult concept to grasp, but when you are focussing on getting the content right you forget about things like saving -> revieiwing -> publishing.

Thus, what I reckon might be better is to provide two options (set as a _config to A or B). 

(a) SMALL WEBSITES WITH FEW VISITORS: all saves are automatically published unless the user specifically sets to "save as draft" only. 

... We can achieve this simply by changing size and text of buttons in CMS (save and publish = bigger button, save button should read "save draft only" and be smaller). 

(b) CORPORATE SITES WITH MANY VISITORS: all saves are saved as draft only and the user has to view the actual page which shows a button "publish now" which goes ahead and does exactly that (forcing the user to review changes before publishing them).

... We can achieve this by removing the "save and publish" button from CMS and adding it to any page being viewed by CMS user where there is unpublished content. 

This is just an idea which might make the CMS simpler. 

Nicolaas

[Sam Minnée]

Yea, having a config option that disables the draft functionality might not be a bad idea. Although personally I'd never use it - even wordpress has draft behaviour.

Sam Minnée

SilverStripe

Skype: sam.minnee

--

[Michael Gall]

The draft behaviour in Wordpress can be turned off by a wp_config.php define.

Cheers,

Michael

--
Checkout my new website: http://myachinghead.net
http://wakeless.net

[Nicolaas Thiemen Francken - Sunny Side Up]

One thing you could do is to separate out a CMS role and a Publish role. So you can get person A to change lots of stuff on the site without the ability to publish and person B, without ever seeing the CMS - being able to publish pages. 

[Sam Minnée]

No, i think the decision to include draft is a site decision, rather than a user decision. Also, permission codes should be kept as rights and not used to encode preferences.

 

On 11/11/2010, at 8:13 AM, Nicolaas Thiemen Francken - Sunny Side Up <ma...@sunnysideup.co.nz> wrote:

One thing you could do is to separate out a CMS role and a Publish role. So you can get person A to change lots of stuff on the site without the ability to publish and person B, without ever seeing the CMS - being able to publish pages. 

[Roman]

Personally I also like and use the draft-mode. But Nicolaas brought in
some interesting ideas.
I guess what's also confusing people is, that sometimes there's no live
or draft mode available. Eg. when using DataObjects. These are usually
published right away.

Since the DataObjectManager was introduced I used DataObjects a lot for
smaller content-bits like "News" or "Events" etc. This is mostly due to
the fact that the Pages-Tree in the CMS isn't very flexible. It doesn't
properly support custom sorting (eg. by Date), there's no filtering and
it gets really cumbersome to use when having lots and lots of pages.
If I recall correctly, this was already discussed (and partially
implemented) back in the 2.2.x days but as far as I can tell, it never
saw the light of day.

AFAIK making DataObjects "versioned" (i.e. live and draft versions) is
possible with the current system but I think it overcomplicates things.
The user shouldn't have to "save and publish" every single DataObject..

I'd rather go back to a more Page-oriented approach, but the UI should
be fit for the task.

Cheers - Roman

On 11.11.10 07:52, Michael Gall wrote:
> The draft behaviour in Wordpress can be turned off by a wp_config.php define.
>
> Cheers,
>
> Michael
>

> On Thu, Nov 11, 2010 at 5:51 PM, Sam Minn�e <s...@silverstripe.com> wrote:
>> Yea, having a config option that disables the draft functionality might not
>> be a bad idea. Although personally I'd never use it - even wordpress has
>> draft behaviour.
>>

>> Sam Minn�e

[Sam Minnée]

My preference is to have the page and all subordinate dataobjects use staging and versioning, but that the user only needs to click the publish button on the parent page, and that this will trigger the publication of all the dataobjects on the page.

I think that the mapping from page to subordinate dataobjects would need to be explicit; following all has-many relationships will get us into trouble.

[Nicolaas Thiemen Francken - Sunny Side Up]

On 11 November 2010 20:19, Sam Minnée <s...@silverstripe.com> wrote:

No, i think the decision to include draft is a site decision, rather than a user decision. Also, permission codes should be kept as rights and not used to encode preferences.

yeah -sorry, I may have chosen my words badly, my rant boiled down to two independent ideas

1. ability to turn off draft site altogether using _config. 

2. setup security in such a way that you can create a user who can edit pages in CMS but not publish and another user who can do all that, but also publish.  The former user (junior staff member) will then be able to edit pages, while the latter user (manager) can log-in and click through pages on front-end deciding which pages are ready for publication and pressing the (on the front-end shown) publish button if he/she is happy with changes. 

Hope that helps

Nicolaas

[Sam Minnée]

> 2. setup security in such a way that you can create a user who can edit pages in CMS but not publish and another user who can do all that, but also publish. The former user (junior staff member) will then be able to edit pages, while the latter user (manager) can log-in and click through pages on front-end deciding which pages are ready for publication and pressing the (on the front-end shown) publish button if he/she is happy with changes.

You'll be wanting the cmsworkflow module ;-)

[Marcus Nyeholt]

One thing that I've started (but not quite finished) is the concept of a changeset. When a user edits content, the change is included in their current changeset. This covers all kinds of changes - new pages, edited pages, or deleting pages (note that this all happens in context of 'draft' content). When the user is happy with their changes, they can submit their changeset - this might be to another user for review, or directly publishing those changes. Implied actions are then executed - ie a changed or new page is published, whereas a page 'deleted from staging' is removed from the live site. So from the editor point of view, they're never thinking in terms of 'draft' or 'published' - just from the point of view of editing, then submitting all of their changes at once. 

This is really effective when you're editing multiple different pages that may be contextual to other edits on the site, and you don't want one to be published before the other. It's also very helpful in workflow situations where often a reviewer should be looking at a set of changes all at once, not being notified of an individual change. This gives better context to what is actually being done by content editors. From a historical point of view, these changesets also help build up a record of what's being changed in a site from a higher level view (much like source control systems). The other reason that I'm looking at this kind of structure is for detached editing and production environments, whereby a set of changes can be published to a remote SilverStripe installation in an almost-atomic step. 

I agree with Nicolaas in that publish ability should be a permission that someone has on content, but there's maybe a little more to it than just having another selection of users on the Access screen. At the moment I think there's a bit of a gap in SilverStripe's access control - you can assign roles (built up of permissions) to users (via groups), but they apply as a kind of global permission and don't have any context. You can apply specific access in context of an item or tree, but that's only read or write - you can't arbitrarily say "Grant groupA the Publisher role to all content under Corporate Finance" or something like that. In other words, be able to grant a certain Authority a specific Role to a contextual Node, with implied inheritance. Of course, the extra overhead of such a model aren't insignificant. 

Marcus

--

[Sam Minnée]

> One thing that I've started (but not quite finished) is the concept of a changeset.

...

> This is really effective when you're editing multiple different pages that may be contextual to other edits on the site, and you don't want one to be published before the other. It's also very helpful in workflow situations where often a reviewer should be looking at a set of changes all at once, not being notified of an individual change. This gives better context to what is actually being done by content editors. From a historical point of view, these changesets also help build up a record of what's being changed in a site from a higher level view (much like source control systems).

Aah, and thus our content versioning system moves from CVS to Subversion ;-). Seems like a good idea. In the current UI, the batch actions could be used to specify a multi-page changeset, with a bit of tweaking to recognise that 'publishing' a page deleted from draft is really a request to delete it from live. It's important, however, that it's still very straightforward to publish a single page and ignore the changeset stuff.

> The other reason that I'm looking at this kind of structure is for detached editing and production environments, whereby a set of changes can be published to a remote SilverStripe installation in an almost-atomic step.

In SilverStripe's current parlance, does this mean that the SiteTree_Live table is sitting in a different server/database than the SiteTree table? This would be a good idea, particularly if template/page-type-code update can be deployed in conjunction with content. Could be tricky to make robust, but worth trying.

> At the moment I think there's a bit of a gap in SilverStripe's access control - you can assign roles (built up of permissions) to users (via groups), but they apply as a kind of global permission and don't have any context. You can apply specific access in context of an item or tree, but that's only read or write - you can't arbitrarily say "Grant groupA the Publisher role to all content under Corporate Finance" or something like that.

Yeah, the relationship between Permissions, Roles, and the CanXXX relationships are a bit of a mess, particularly when you throw subsites into the mix. I would like to refactor this model in the following way:

* we have more permission codes for granular actions, View, Edit, Publish, etc
* let permission codes have a scope - to a specific page, section, subsite, etc, or to the entire application as they are now.
* replace the relationships shown on the Access tab with scoped permissions
* have a better concept of group-permissions - a permission code that implies one or more other permission codes. Right now, we have hard-coded this into admin "ADMIN" - it implies every other permission code - but there's no scope for making more permissions like this without messy core hacks.
* remove the current Role system and replace it with suitable group-permissions
* rename "permission codes" to "rights"

[Marcus Nyeholt]

Aah, and thus our content versioning system moves from CVS to Subversion ;-).  Seems like a good idea.  In the current UI, the batch actions could be used to specify a multi-page changeset, with a bit of tweaking to recognise that 'publishing' a page deleted from draft is really a request to delete it from live.  It's important, however, that it's still very straightforward to publish a single page and ignore the changeset stuff.

Yeah, it does take a source control type of model. Alfresco implemented a repository model based directly on SVN, where every user has a unique sandbox (analogous to Stages in SS). It worked okay, but I much prefer a global staging area, as individual changes are essentially useless without the context of other people's changes. It doesn't mean the changesets can't be scoped to individuals, but the overall view shows the results of everyone's changes. A nice side-effect of this is locking of content, meaning that only one person can edit at a time, though I've built into it the idea of being able to unlock the content, but still keep it in the original user's changeset. 

The other thing I'd be looking to add is the ability to have multiple changesets open at any one time. By default, a changeset is created as soon as you start editing. In some instances though, you might want to break up a series of edits into discreet changesets, either for publishing purposes (staging one set differently), or having them reviewed separately. Users could then move content between changesets if desired, or according to certain workflow rules or other <insert stuff here>

Publishing a single item would still be possible for users who have that right - it would just be removed from the changeset and published separately (or, if it was deemed that everything needed an associated changeset, a new changeset with one item would be invisibly created to manage that)

 

In SilverStripe's current parlance, does this mean that the SiteTree_Live table is sitting in a different server/database than the SiteTree table?  This would be a good idea, particularly if template/page-type-code update can be deployed in conjunction with content.  Could be tricky to make robust, but worth trying.

I'd been thinking down a couple of different threads - publishing just the items using static publisher or similar, and having those items sent/sync'd across, or sending the changes across into a new changeset on the remote system, and publishing that remote changeset instantly. It would be a completely standalone SS instance. Owen's done a little bit of research into a lower system level replication mechanism that would keep code / db / assets in sync, but that might be a topic for another thread...

[Sam Minnée]

> The other thing I'd be looking to add is the ability to have multiple changesets open at any one time. By default, a changeset is created as soon as you start editing. In some instances though, you might want to break up a series of edits into discreet changesets, either for publishing purposes (staging one set differently), or having them reviewed separately. Users could then move content between changesets if desired, or according to certain workflow rules or other <insert stuff here>

This strikes me as being in danger of becoming too complex. Is this something that's driven by authors' needs or a developers' sense of elegance? We're not building a CMS for ourselves, remember. ;-)

FWIW, in my mind I had assumed that the changeset would be created at publication time rather than when you start editing. This is analogous to svn - you can make whatever changes you liked but the changeset is created (in the server, and given a revision number) when you run svn commit.

-------
Sam Minnée | Chief Technology Officer
SilverStripe
http://silverstripe.com

Phone: +64 4 978 7334
Skype: sam.minnee

[Jason Stratford]

I like the idea of change sets a lot. We service a large financial organisation (unfortunately on another CMS) but one of the things that would smooth the workflow out a lot is the ability to have multiple change sets in play at a time that have different publication schedules and approval processes.

For Silverstripe to appeal more to larger organisations a change set capability would certainly help in some cases. So I think there is a definite real use case justification for a feature like this. Doesn't hurt that its technically very cool as well! :o)

Re-visiting earlier comments on the thread though, putting this type of feature into core will make the core much heavier for a lot of people who would have no need of this type of feature. Is this the sort of thing that could be modular? Is the core going to become 'open' enough to hook something as in depth as this in from a module? Is it the required core access that is actually more important to identify and get right so that this type of extension becomes easier to achieve by more people?

Jason

--

[Marcus Nyeholt]

> The other thing I'd be looking to add is the ability to have multiple changesets open at any one time. By default, a changeset is created as soon as you start editing. In some instances though, you might want to break up a series of edits into discreet changesets, either for publishing purposes (staging one set differently), or having them reviewed separately. Users could then move content between changesets if desired, or according to certain workflow rules or other <insert stuff here>

This strikes me as being in danger of becoming too complex.  Is this something that's driven by authors' needs or a developers' sense of elegance?  We're not building a CMS for ourselves, remember. ;-)

The initial usecases behind being able to split changesets were to address fringe cases of certain workflow processes, and if necessary, would largely happen invisibly to users (though make it possible for those 5% of users who like messing with that type of thing to do so). 

 

FWIW, in my mind I had assumed that the changeset would be created at publication time rather than when you start editing.  This is analogous to svn - you can make whatever changes you liked but the changeset is created (in the server, and given a revision number) when you run svn commit.

It actually grew out of wanting to provide a mechanism to exclusively lock content for a particular user, then lock a series of content items. To make it easier from a code standpoint, having an object representing the changeset up front was easier than figuring out exactly what you had edited from a particular time based on the state of the content in the system (and avoiding the _versions table :D). It also allows for different content types (non-SiteTree but with Versioned patched on) to be included in changesets. The actual objects related to the changeset aren't the content items themselves, but 'pointers' to the content items. Cancelling a changeset simply deletes the changeset object and these objects, which is different from Reverting (which undoes the changes to the content items). 

At some point I'll get something up on a demo site so that the actual behaviour can be seen. 

[Sam Minnée]

On 11/11/2010, at 11:09 AM, Jason Stratford wrote:

> I like the idea of change sets a lot. We service a large financial organisation (unfortunately on another CMS) but one of the things that would smooth the workflow out a lot is the ability to have multiple change sets in play at a time that have different publication schedules and approval processes.

I think that it would be okay if the multiple changesets were active, however, I think that:

* they should be created at the "request publication" point rather than as soon as people start editing, and
* I'm not sure that transferring changes between changesets is necessary.

> Re-visiting earlier comments on the thread though, putting this type of feature into core will make the core much heavier for a lot of people who would have no need of this type of feature. Is this the sort of thing that could be modular?

Right now the workflow functionality is modular but it makes the system very complex. One thing I'm wondering is if we keep the data model a bit more workflow-capable in the default install, and instead just have a simpler UI in the core product.

[Sam Minnée]

On 11/11/2010, at 11:16 AM, Marcus Nyeholt wrote:

> It actually grew out of wanting to provide a mechanism to exclusively lock content for a particular user, then lock a series of content items. To make it easier from a code standpoint, having an object representing the changeset up front was easier than figuring out exactly what you had edited from a particular time based on the state of the content in the system (and avoiding the _versions table :D). It also allows for different content types (non-SiteTree but with Versioned patched on) to be included in changesets. The actual objects related to the changeset aren't the content items themselves, but 'pointers' to the content items. Cancelling a changeset simply deletes the changeset object and these objects, which is different from Reverting (which undoes the changes to the content items).

OK so you're effectively talking about replacing the draft-site/published-site functionality with an arbitrary number of unpublished working copies that are created and destroyed at will. It's elegant, but it's a lot more complex than what we currently have. I think it's important that we keep the use-case which motivated this front-of-mind. Can you give a bit more context and detail about that use case?

[Martijn Van Nieuwenhoven]

If people want to publish pages right on to Live site, why not just hide/disable the Save button and let clients only use Save and Publish when devs want to, knowing that there is always versioning in the background ("Hi Dev, I removed a page!" "Hi Client, no problem ill get it back for you.").
We already have the Navigator bar to switch Draft and Live and if there is a need for frontend editting it should be a frontend 'copy' of how the CMS works (frontend calling CMS methods).
I prefer to not over complicate things and let developers build their special use case modules and extensions on top of basic code functionality.

Just KISS it :)

--

[Marcus Nyeholt]

> It actually grew out of wanting to provide a mechanism to exclusively lock content for a particular user, then lock a series of content items. To make it easier from a code standpoint, having an object representing the changeset up front was easier than figuring out exactly what you had edited from a particular time based on the state of the content in the system (and avoiding the _versions table :D). It also allows for different content types (non-SiteTree but with Versioned patched on) to be included in changesets. The actual objects related to the changeset aren't the content items themselves, but 'pointers' to the content items. Cancelling a changeset simply deletes the changeset object and these objects, which is different from Reverting (which undoes the changes to the content items).

OK so you're effectively talking about replacing the draft-site/published-site functionality with an arbitrary number of unpublished working copies that are created and destroyed at will.  It's elegant, but it's a lot more complex than what we currently have.  I think it's important that we keep the use-case which motivated this front-of-mind.  Can you give a bit more context and detail about that use case?

Nope, it would still work in the context of draft and published - you'd only ever have one instance of a draft piece of content. It's just that the system won't allow anyone other than the person who locked it have access to edit that content until the current editor submitted the content for publication, reverted their changes, or unlocked the content. The draft / publish model works exactly the same as it does now, however several changed pieces of content are associated with the modifying user in a changeset, and only that user can edit them. While in a changeset the versioning behaves the same as it currently does, and if a changeset is reverted, the change still exists in the page history. 

The intial use case isn't for a current client at all, but is something that I've come across several times. The specific one that was a critical selling point was a certain manufacturer who advertised certain things about their products on their website (where prices for most things would be $15,000 and up - they didn't do sales via the web, just advertising). They had many different departments filling out various bits of the content that would be aggregated into a single page, with some of that content driven by automated processes. Their process of updates didn't give them the ability to push through updates as a single set with a single person approving the final version of the page; on one occasion this lead to an image being displayed on the site with a slightly incorrect text description, alongside a slightly incorrect price. Due to complaints to the ACCC, this could have lead to huge fines, so one of their key requirements when redeveloping was being able to ensure publication of a specific list of content at once in an atomic manner. At the same time, no-one should be able to edit content that another person has started editing until that person has finished with the content. 

I've put up a demo of the functionality as it exists at the moment

http://playground.mikenovember.com/changesets/admin

Login as author:author and you'll see that you have access to edit the Home page, and on the Changes tab, can go through and submit or revert the changeset. Note however that you can't edit the About page, or Save and Publish other pages. Editing other pages will add them to the list of items in your changeset. Also note that after submitting / reverting a changeset, a new one is created automatically the next time you edit some content

If you log in as admin:silverstripe and check the 'Changes' tab, you'll see the About page in there, as well as the other users' changesets. Once you submit the changeset, the author user can then go and edit the About page. 

[Sam Minnée]

> Nope, it would still work in the context of draft and published - you'd only ever have one instance of a draft piece of content. It's just that the system won't allow anyone other than the person who locked it have access to edit that content until the current editor submitted the content for publication, reverted their changes, or unlocked the content.

Aah, of course, if you introduce the locking then any given draft page will only exist in 1 changeset. Gotcha.

> They had many different departments filling out various bits of the content that would be aggregated into a single page, with some of that content driven by automated processes.

...

> Due to complaints to the ACCC, this could have lead to huge fines, so one of their key requirements when redeveloping was being able to ensure publication of a specific list of content at once in an atomic manner.

This justifies the changeset system but not the locking that you've rolled into it. And, if the locking is unnecessary, the changeset can be created at publication time. The challenge, it seems, is that one person would need to be responsible for taking all of the changes from each department and rolling them all together into a single change-set.

This would be a good reason for providing tools to combine changesets together, but doesn't seem to have anything to do with locking, nor with the creation of changesets at edit time.

> At the same time, no-one should be able to edit content that another person has started editing until that person has finished with the content.

This statement has no justification. You appear to be taking this statement as self-evident, and I don't see why it is necessary to enforce this?

Certainly we don't want people overwriting each other's changes, so we we need something similar to the concurrentediting module where it prevents one change from overwriting another, but you seem to be suggesting that we extend that out so that the content is locked for the entire workflow step.

There are several disadvantages:

- People will forget to cancel changes and go on holiday, leaving the content locked and people unable to edit it.
- A common use-case is to log onto the system and review someone's changes, without using the workflow system. Remember that much of real life will happen outside the comforting but illusory flowcharts of a workflow system. This is no longer allowed.
- Collaboration on the draft content appears to be impossible.

I don't really see the advantage except for the "isn't it great? now the computer is your boss!" adage that is usually the starting point for Workflow Gone Mad(tm). If you look at where online editing tools are going they are allowing *more* concurrent editing, not less - eg, Google Docs.

This locking concept seems to be anti-collaborative, and that's not a direction I'd like to see SilverStripe go in.

> I've put up a demo of the functionality as it exists at the moment
> http://playground.mikenovember.com/changesets/admin

I expect that the UI you've come up with is just a mocked-up proof-of-concept, but it does illustrate the care we need to take when introducing these new features. The system in your demo is substantially more complex for authors than regular SilverStripe.

I would hate to see usability sacrificed on the altar of enterprise features. ;-)

[Marcus Nyeholt]

> This justifies the changeset system but not the locking that you've rolled into it.  And, if the locking is unnecessary, the changeset can be created at publication time.  The challenge, it seems, is that one person would need to be responsible for taking all of the changes from each department and rolling them all together into a single change-set.

The other thing to factor in though is that while you could figure out all the current changeset for a single user based on AuthorID and a set of queries against the SiteTree_versions table (I think?), including changes to other data objects into the same changeset becomes a bit of a problem because you need to query all other types to see if they also have changes. While doable, it was a lot easier to create the changeset as soon as someone made a single change - it never modifies other dataobjects, and has a minimal overhead. Makes querying for a list of changesets much easier too.  

> This would be a good reason for providing tools to combine changesets together, but doesn't seem to have anything to do with locking, nor with the creation of changesets at edit time.

> > At the same time, no-one should be able to edit content that another person has started editing until that person has finished with the content.

> This statement has no justification.  You appear to be taking this statement as self-evident, and I don't see why it is necessary to enforce this?

This was actually part of the requirements of that use case, that someone's changes were locked just to them, and that others couldn't come in and make other modifications. Basically a way of saying "this is my content for now, don't touch it". There are often cases where exclusive locking is a requirement, though I'd agree that it's not the usual usecase for SilverStripe... I'm not suggesting that it should be the default for SilverStripe either. It'd drive me nuts (not to mention 90% of users)! However, some clients do have those requirements. 

> Certainly we don't want people overwriting each other's changes, so we we need something similar to the concurrentediting module where it prevents one change from overwriting another, but you seem to be suggesting that we extend that out so that the content is locked for the entire workflow step.

> 

> There are several disadvantages:

> 

>  - People will forget to cancel changes and go on holiday, leaving the content locked and people unable to edit it.

Yep, there's definitely drawbacks to locking the content for the duration of the time that content's edited. Generally, the options are either dealing with conflicts when they happen (which is what the concurrentediting module does from what I can tell?) where you ask the user to figure out what's correct, or exclusive locking. For exclusive locking, having something like a lock timeout or forcefully acquiring the content lock (removing an item from a changeset) would be how I'd approach things. 

>  - Collaboration on the draft content appears to be impossible.

As far as collaboration goes, that's already possible (there's just no UI for it), by the user explicitly making a content item 'unlocked', but it is still associated with the user's changeset. 

>  - A common use-case is to log onto the system and review someone's changes, without using the workflow system.  Remember that much of real life will happen outside the comforting but illusory flowcharts of a workflow system.  This is no longer allowed.

Not sure what your point is here - the changesets don't impose any kind of requirement on workflow at all. In the demo site you can login as an admin and review all of the author user's changes from a single UI. Doesn't have anything to do with workflow? 

> I don't really see the advantage except for the "isn't it great? now the computer is your boss!" adage that is usually the starting point for Workflow Gone Mad(tm).  If you look at where online editing tools are going they are allowing *more* concurrent editing, not less - eg, Google Docs.

> This locking concept seems to be anti-collaborative, and that's not a direction I'd like to see SilverStripe go in.

Agreed about the slippery slope to workflow madness - having dealt with Alfresco and Matrix over the past few years, I've felt more than my fair share. The reality is that lots of businesses and government agencies *think* they need it, and often have draconian procedures in place that demand it with part of the game being to remove as much of it as possible. 

From a collaboration perspective, I'd like something where individual paragraphs of content were updated in realtime on a user's screen that had been contributed by other users to the document and automatically merged behind the scenes. I know a guy who did something similar for docx documents against the Alfresco repository, and the effect was awesome. Basically, a single content field gets temporarily broken up into multiple "Fragment" fields in the background based on a selector, eg a <p> tag. These were constantly updated realtime as different editors add to the document, and when they 'save', the fragments get reassembled into the actual content field. Combine that with a frontend editor that allows for editing on multiple different frontend fields from different data objects and it would make for a pretty impressive client demo :). 

> I expect that the UI you've come up with is just a mocked-up proof-of-concept, but it does illustrate the care we need to take when introducing these new features.  The system in your demo is substantially more complex for authors than regular SilverStripe.

The UI for the changeset section is definitely "put something in place to show stuff". Ideally there'd be visual indication of pages you've currently got unpublished, and a simple way of submitting all changes, directly in the Pages UI. But it's not something that is being followed through on without need :). And yes, I definitely wouldn't be pushing for this to become the default or a core behaviour of SilverStripe - it's definitely something that fits in the "Module" category. 

> I would hate to see usability sacrificed on the altar of enterprise features. ;-)

I figure that good usability is making sure that enterprisey features are so well presented users don't even know they're enterprisey :p.

 

[Sam Minnée]

> This was actually part of the requirements of that use case, that someone's changes were locked just to them, and that others couldn't come in and make other modifications.

...

> I'm not suggesting that it should be the default for SilverStripe either. It'd drive me nuts (not to mention 90% of users)! However, some clients do have those requirements.

...

> Agreed about the slippery slope to workflow madness - having dealt with Alfresco and Matrix over the past few years, I've felt more than my fair share. The reality is that lots of businesses and government agencies *think* they need it, and often have draconian procedures in place that demand it with part of the game being to remove as much of it as possible.

So, it seems that we're mostly in agreement, and that the auto-locking is generally something that appears in the early stage requirements lists of well intentioned but misguided corporates. ;-)

That being the case, I would suggest that the auto-locking feature is tacked on, rather than altering the design of the changeset system to support it. In particular, I mean that the changeset get generated when you kick off a workflow with "request publication" rather than when you first start editing.

Manual locking seems like a useful tool to have in the system, particularly if the new UI gives us a place to list less important actions that we use sometimes - the list of buttons along the bottom is getting unwieldy. I'd suggest that in the default package, "lock this page" is available as an explicit action that writes somewhere that has nothing to with changesets - for example, adds a row with SiteTreeID & MemberID to a DataObject called SiteTreeLocks.

For clients that want to automatically lock, we can add a couple of hooks that lock on first edit, and unlock at some point in the workflow. This would be the "tacked on" option.

I'm generally reluctant to include features in the system that everyone working on the product knows are a bad idea, just to keep the sales guys happy. Sometimes we need grin and bear this, but it seems a step too far to then change the system's architecture to support those glitter features.

> From a collaboration perspective, I'd like something where individual paragraphs of content were updated in realtime on a user's screen that had been contributed by other users to the document and automatically merged behind the scenes. I know a guy who did something similar for docx documents against the Alfresco repository, and the effect was awesome. Basically, a single content field gets temporarily broken up into multiple "Fragment" fields in the background based on a selector, eg a <p> tag. These were constantly updated realtime as different editors add to the document, and when they 'save', the fragments get reassembled into the actual content field. Combine that with a frontend editor that allows for editing on multiple different frontend fields from different data objects and it would make for a pretty impressive client demo :).

C'mon, let's go the whole hog and mimic google-docs! ;-) Seriously, though, live editing combined with front-end editing could make for a fantastic system, particularly for wikis, intranets, and other more collaborative sites. I'd be really keen to see what's possible there, although I don't think it's the #1 priority there.

[Nicolaas Thiemen Francken - Sunny Side Up]

Idea #12341787

Also worth considering setting up "quick" methods to

1. sort any dataobject (using drop and drag of course)

2. edit one field for all records (filtered) in a dataobject - I very much like this one

3. edit one field for one record. 

4. edit one record.

This should be a one line call and would probably just add the pop-up link.  This allows you to let the developer create very specific editing links in CMS and front-end.  Let me know if you would like to know of any use-cases and examples. 

Nicolaas

[Marcus Nyeholt]

So, it seems that we're mostly in agreement, and that the auto-locking is generally something that appears in the early stage requirements lists of well intentioned but misguided corporates. ;-)

That being the case, I would suggest that the auto-locking feature is tacked on, rather than altering the design of the changeset system to support it. In particular, I mean that the changeset get generated when you kick off a workflow with "request publication" rather than when you first start editing.

Yes, exclusive locking makes sense as completely separate module that is added only where specific requirements dictate its usage, not as a core piece of functionality - given this is a thread about SS3 core functionality, it was probably a bit confusing :). As far as changesets being created when you publish content goes, I'm still not convinced creation-on-submit is the best method, due to the need to explicitly query the *_versions table of every dataobject that is versioned to get a view of "what have I currently got edited?". Of course, without playing around with some code to see what's possible I'm not quite sure if it would actually be as 'yucky' as it sounds. Is there an easier way to get a snapshot of all current dataobject changes for a particular user (assuming here it's not just SiteTree that has Versioned applied). 

Either way, I think the concept of changesets would be a really nice piece optional functionality (core or otherwise), regardless of the implementation approach - it'd be great to pull up a page history and be able to see a list of OTHER pages that were changed and published at the same time the current item was, or be able to rollback all changes made to a particular point in time, instead of a single page. 

C'mon, let's go the whole hog and mimic google-docs! ;-)  Seriously, though, live editing combined with front-end editing could make for a fantastic system, particularly for wikis, intranets, and other more collaborative sites.  I'd be really keen to see what's possible there, although I don't think it's the #1 priority there.

I hereby request that Ingo and Hamish investigate live collaboration as #1 priority of the frontend editing research :D

 

[Sam Minnée]

> Of course, without playing around with some code to see what's possible I'm not quite sure if it would actually be as 'yucky' as it sounds. Is there an easier way to get a snapshot of all current dataobject changes for a particular user (assuming here it's not just SiteTree that has Versioned applied).

I would assume that the basic query would be something like:

SELECT SiteTree.* FROM SiteTree
LEFT JOIN SiteTree_Live ON SiteTree.ID = SiteTree_Live.ID
WHERE SiteTree.Version != SiteTree_Live.Version
OR SiteTree_Live.Version IS NULL

What that doesn't do is filter down to edits you were involved in, or edits you made exclusively. Of course, if changesets would only simplify the listing of changes that you made exclusively. If another user had made a change and then you had then contributed to the change, you would probably want it to be listed as an option, in which case the following query would give you what you need. It's not exactly simple but it's workable, and can be written as a DataObject::get() in the current system.

SELECT DISTINCT SiteTree.* FROM SiteTree
LEFT JOIN SiteTree_Live ON SiteTree.ID = SiteTree_Live.ID
INNER JOIN SiteTree_versions ON SiteTree_versions.Version > coalesce(SiteTree_Live.Version,0)
WHERE (SiteTree.Version != SiteTree_Live.Version OR SiteTree_Live.Version IS NULL)
AND SiteTree_versions.AuthorID = $currentMemberID

In practise, we would want to embed it as a built-in query for the Versioned dataobjects in the new ORM, so you call something like get('SiteTree')->DraftChanges() or get('SiteTree')->DraftChangesBy($currentMemberID).

You could switch between the two different sets of pages with an interface something like this ASCII art mock-up. This would let you request the publication of other people's changes if necessary; this wouldn't be the default option but would be handy for some.

Show:
(o) My changes on draft
( ) All changes on draft

[ ] Home
[ ] About Us
[x] Products
[x] Some Altered Page
[ ] Other Altered Page

Now, if a changeset was created at edit time, then you don't need to run those queries to do a simple publish action - publish everything that I have edited. However, in practise you're probably going to want to give some kind of interface to let users tweak the set of pages that are submitted for publication, which means you're going to need two things:

* You will need to run the above queries regardless, to generate the list of pages available to them
* You will need to manipulate the default that is generated.

> Either way, I think the concept of changesets would be a really nice piece optional functionality (core or otherwise), regardless of the implementation approach

Yeah, agreed. :-)

[Barry Swaisland]

Hi,

since this is such a hot topic I'm putting my comments in (apologies
if any have been mentioned before):

I'd suggest having a vote about modules/widgets that are most commonly
used and then having their basic functionality included for example
multiselect field
parts of the DOM
uploadify
gallery (e.g. combination of a lightbox / dom / uploadify)
blog
newsletter

AND/OR making the installation easier & more robust (yes I know it is
easy now once you have had trouble once)
but something like in magento where you can select a module and then
it is installed automatically
and silverstripe can hold information about "supported versions" so
that when you have 2.4.3 it knows which version it is compatible with
this could then be like a "module dashboard" that would list modules,
versions, etc for those "managed" and of course an area for custom
modules that are not "managed"
also that modules do not sit separately in the web root as this makes
things untidy when using many modules

the same as above for widgets, e.g. twitter, blog, newsletter sign up

All of this would mean it could be up to a CMS user to install and
configure a module or widget... which means more time for developers
to develop.

Other than this I find myself using ModelAdmin all the time so
additional functionality and styling of that to make it nicer for a
user...

*easier to scaffold the search form (for things like has_one /
has_many - this may have been done and I just haven't got it working)
*define the csv export to not just contain the summary fields
*edit a has_one in a popup (this can be done with HasOneManager in
DOM, but I'd prefer it to just edit the "one" selected with an edit
icon next to the dropdown

Lastly something in the CMS that was like MultiStepForm for creating
wizards - currently I have a couple of dataobjects that capture
information and generate actions in onAfterWrite - but this is
misleading because I do not really want the databoject and the form is
too tong because it contains every option, multistep form type
behaviour would mean I could show only the relevant fields and then do
the required action upon completion.

barry

[Marcus Nyeholt]

By "yucky" I was actually referring to the situation where it's not just SiteTree objects that are in the changeset (going back to the original usecase where there was image based content included). Searching all types that have a _versions table, then merging result sets, and all that business makes the pre-creation of the changeset much easier. I guess it ties in with the concept of making versioning and staging easier to add to non SiteTree objects - maybe part of the solution to that problem would help this problem and make it a lot easier to do changest creation on publish for multiple content types.

 

Show:
(o) My changes on draft
( ) All changes on draft

I really like that 'All changes on draft' option... it completely slipped my mind!

[Nicolaas Thiemen Francken - Sunny Side Up]

hi

just half a cents worth to be added here. I do think it would be important that in 3.0 you can at least get a thumbnail view of the images in assets.  This seems just a basic requirement that, in my humble opinion, it is long overdue.

Nicolaas

[John Milmine]

From the submissions so far, it sounds like the community is open to a
front-end CMS but don't want to sacrifice some of the other things. We
realise that you guys at Silverstripe don't have 24/7 open source time
and have plenty of other paid commitments to deal with.

Happy to have a module and agree with Jason, that it would be a nice
thing to potentially sell in. I definitely agree with spronk and
others that it's better in theory than practice, at least in the
systems I've tried.

My points of concern would be:
Template language decoupling.
Database abstraction layer.
Removal of prototype and only use 1 js library (jQuery)
Like the idea of DataList above

Also agree that SiteTree needs some improvements or added flexibility.
Although I LOVE the strict sitetree, it does have disadvantages when
it comes to things like tagging, blogging etc.

[John Milmine]

Agree.

On Nov 18, 4:11 pm, Nicolaas Thiemen Francken - Sunny Side Up

[Nicolaas Thiemen Francken - Sunny Side Up]

Here is another idea that might help:

http://www.mysite.co.nz/admin/show/47/#Root_Content_set_MyFunkyDataFields

should open the CMS for page with ID 47 (this works). But in addition, it should open a tab Root.Content.MyFunkyDataFields (not sure that this "set" part is for).

This would be a really neat feature for pointing clients in the right direction for editing this or that (you can also add this link in other parts of the the front-end / back-end CMS).   

Maybe the request should be more general.  A general "api" for linking to a place where a dataobject / page (or part thereof) can be edited. It is mostly there, but might need a bit of cleaning up.

Sorry if you are getting sick of all these little ideas.

Nicolaas

[aram balakjian]

I would love to see some work done on the UI for creating new pages as IMHO the 'create' tab is a little cramped and unprioritised for such a fundemental function of the CMS and the dropdown system gets a little clunky when you have a load of PageTypes. Some sort of Icon based selection and/or grouping and/or popup window for the Page Type selection might be worth exploring. I think Concrete 5 does a pretty good job of this.

Aram

Nicolaas

--

[Dan Rye]

Aram, I like the idea.  The first thing that jumped to mind was something like office has.  Think of Excel, you select New, get the New Workbook dialog.  Select Parent page types on the left and then see them, and all possible sub page types on the right, with nice large thumbnails.

Just an idea.

-Dan

[aram balakjian]

Yea exactly Dan, that's a great reference, it would give the user a far better understanding of what they were about to create.

Aram

[dospuntocero]

hey guys i think as all the other devs, we are wating for the packtpub
Open source Awards desition... while waiting, take a look to pimcore,
they have some really awesome features that would worth watching

http://www.pimcore.org/products-and-solutions/screencasts

i think in the examples it shows something like a front-end editing in
the backend. looks nice.

On 4 nov, 07:42, Fred Condo <fco...@quinn.com> wrote:
> On Wed, Nov 3, 2010 at 4:41 PM, Sam Minnee <sam.min...@gmail.com> wrote:
> > Felipe Skroki, SilverStripe's Creative Director, has gone back to the
> > drawing board with the SilverStripe UI.  One major outcome is that
> > we'd like to radically simplify the SilverStripe CMS user interface.
> > In particular, we'd like to use front-end editing much more heavily,
> > rather than having an entirely separate user interface.
>
> My initial reaction to front-end editing is -1, based on my experience
> with Plone. Front-end editing sounds like a great idea, but the UI/UX
> issues are insidious. Two of the major issues: 1) how to unobtrusively
> indicate that fields are editable without defeating the WYSIWYG; 2)
> when the Ajax front-end editing was enabled, editors & admins could no
> longer simply select text or click on links in editable fields (the
> field would go into edit mode on click).
>
> As well, it was extremely difficult to design templates deviating from
> the stock Plone layout that would work with front-end editing. The
> flexibility of SS templates is a major strength.
>
> The above notwithstanding, SilverStripe is not Plone (thank
> goodness!), and I'm interested in seeing the prototype and being
> proved wrong.

[Brice Burgess]

3.0 is very exciting & I am dearly looking forward to the work of the
SilverStripe team. A few things I recommend;

1. Quality 3rd party leverage (e.g. along the lines of Zend_Cache
integration in core, jQuery UI/[other] in CMS).
2. Performance Oriented (cache headers, javascript+css minification a
la [http://code.google.com/p/minify/], optimized DataObject queries/
methods for fetching random objects, etc.)
3. Forward-thinking & lovely asset management (sortable objects/
componentsets [something like http://code.google.com/p/silverstripe-briceburg/
*had to plug!*], Drag&Drop uploading, etc.)
4. Flexible CMS (e.g. update theme, breadcrumbs, custom field
validations [almost there!], shortcuts to common tasks/processes
[autodetection]).

Would love to help in any way possible!

~ Brice

[Martin Pales]

On Fri, Nov 19, 2010 at 2:07 PM, dospuntocero <f...@dospuntocero.cl> wrote:

hey guys i think as all the other devs, we are wating for the packtpub
Open source Awards desition... while waiting, take a look to pimcore,
they have some really awesome features that would worth watching

http://www.pimcore.org/products-and-solutions/screencasts

i think in the examples it shows something like a front-end editing in
the backend. looks nice.

There already is a SS plugin out there with a similar functionality. 

http://www.page-elements.com/

I really appreciate the modularity of SS and would welcome any 

UX enhancements in a form of modules instead of putting everything

inside the cms module. This way, further maintaining/enhancing of

those modules by the community would be far easier.

My vision for SS3.0+ is to have a rock solid sapphire framework

developed by the SS team and (plenty of amazing) modules submitted

by the community.

Also, there are several fundamental areas that need to be improved, 

including site searching and i18n/l10n (also in pages and dataobjects 

with relations).

Martin

[Simon J Welsh]

I thing I would really like to see is support for namespaces (http://php.net/namespace)

While I know that sapphire itself can't use them (I'm assuming you'd want to be at least 5.2 compatible), it would be nice if us developers could :)
---
Simon Welsh
Admin of http://simon.geek.nz/

Who said Microsoft never created a bug-free program? The blue screen never, ever crashes!

http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e

[Sam Minnée]

On 3/12/2010, at 3:17 PM, Simon J Welsh wrote:

> I thing I would really like to see is support for namespaces (http://php.net/namespace)
>
> While I know that sapphire itself can't use them (I'm assuming you'd want to be at least 5.2 compatible), it would be nice if us developers could :)

What would need to change for that to happen?

[Simon J Welsh]

I've had a very short poke around and found a couple of things:
- ManifestBuilder complains if two classes have the same name. This would need to be changed to same name in the same namespace
- ManifestBuilder can't pass classes that extend namespaced classes (class Controller extends /Controller)
- The autoloader gets passed a namespaced-qualified path (/mynamespace/MyClass), when called from inside a different namespace, which it can't find

That's all I've noticed so far.

[Sam Minnée]

> I've had a very short poke around and found a couple of things:
> - ManifestBuilder complains if two classes have the same name. This would need to be changed to same name in the same namespace
> - ManifestBuilder can't pass classes that extend namespaced classes (class Controller extends /Controller)
> - The autoloader gets passed a namespaced-qualified path (/mynamespace/MyClass), when called from inside a different namespace, which it can't find
>
> That's all I've noticed so far.

Well, it seems like a good change. I think we'd accept a patch that still worked on PHP 5.1 & PHP 5.2, and didn't slow things down too much.

[xeraa]

As I've understood it, SilverStripe 3 will introduce quite some big
changes. What about using this opportunity for switching to PHP 5.3+?
2.5 would be the version for people stuck with 5.1/5.2

According to http://www.php.net/archive/2010.php#id2010-07-22-1, the
release of 5.2.14:
"This release marks the end of the active support for PHP 5.2.
Following this release the PHP 5.2 series will receive no further
active bug maintenance. Security fixes for PHP 5.2 might be published
on a case by cases basis. All users of PHP 5.2 are encouraged to
upgrade to PHP 5.3."

For me that pretty much says: It's time to move on...
What I've always liked about SilverStripe was that it would use the
latest and greatest features of PHP without being limited by too much
backwards compatibility - like many other systems.

This is definitely a controversial issue, but I'd be very much in
favor for taking the next (logical) step.

[Marcus Nyeholt]

I think that given 5.2's end of support, which will force RHEL and Debian to move to 5.3, it's probably a good time to consider 5.3 for 3.0, and maintaining 2.X on 5.2. 

[Sigurd Magnusson]

xeraa, interesting that you've pointed out PHP 5.2 won't even get all security updates - thanks for raising that to our attention!

Sigurd.

[Simon J Welsh]

Yet PHP 5.2.15 was released on Friday. While active support has been stopped, the PHP group understands that there are a large amount of people and hosts unwilling to update to 5.3. Now that SilverStripe has a much larger user base than when it became PHP5 only, I would be hesitant to alienate such a large portion of potential users and their hosts. For instance, Debian 5 only comes with PHP 5.2, and that wont be changing.

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

---

[xeraa]

That's why there would be SilverStripe 2.5 for those stuck with PHP
5.2. Nobody would be left standing in the rain...
And I'd hope that the adoption of PHP 5.3 will be a lot higher in the
middle of 2011 - or whenever there will be the first release
candidates.

I still think that if major rewrite efforts are made, it's a good time
for such a change. I'd be very interested in Sam's opinion on this...

On 13 Dez., 00:14, Simon J Welsh <welsh.si...@gmail.com> wrote:
> Yet PHP 5.2.15 was released on Friday. While active support has been stopped, the PHP group understands that there are a large amount of people and hosts unwilling to update to 5.3. Now that SilverStripe has a much larger user base than when it became PHP5 only, I would be hesitant to alienate such a large portion of potential users and their hosts. For instance, Debian 5 only comes with PHP 5.2, and that wont be changing.
>
> On 9/12/2010, at 2:26 AM, xeraa wrote:
>
>
>
> > As I've understood it, SilverStripe 3 will introduce quite some big
> > changes. What about using this opportunity for switching to PHP 5.3+?
> > 2.5 would be the version for people stuck with 5.1/5.2
>

> > According tohttp://www.php.net/archive/2010.php#id2010-07-22-1, the

> > release of 5.2.14:
> > "This release marks the end of the active support for PHP 5.2.
> > Following this release the PHP 5.2 series will receive no further
> > active bug maintenance. Security fixes for PHP 5.2 might be published
> > on a case by cases basis. All users of PHP 5.2 are encouraged to
> > upgrade to PHP 5.3."
>
> > For me that pretty much says: It's time to move on...
> > What I've always liked about SilverStripe was that it would use the
> > latest and greatest features of PHP without being limited by too much
> > backwards compatibility - like many other systems.
>
> > This is definitely a controversial issue, but I'd be very much in
> > favor for taking the next (logical) step.
>
> > On 7 Dez., 02:13, Sam Minnée <s...@silverstripe.com> wrote:
> >>> I've had a very short poke around and found a couple of things:
> >>> - ManifestBuilder complains if two classes have the same name. This would need to be changed to same name in the same namespace
> >>> - ManifestBuilder can't pass classes that extend namespaced classes (class Controller extends /Controller)
> >>> - The autoloader gets passed a namespaced-qualified path (/mynamespace/MyClass), when called from inside a different namespace, which it can't find
>
> >>> That's all I've noticed so far.
>
> >> Well, it seems like a good change.  I think we'd accept a patch that still worked on PHP 5.1 & PHP 5.2, and didn't slow things down too much.
>
> > --
> > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.
>
> ---
> Simon Welsh
> Admin ofhttp://simon.geek.nz/

[Brice Burgess]

I think PHP 5.3 is great and worth moving to. Taking advantage of
features such as late static bindings and lambda functions would
*simplify* much of the core SilverStripe code (ORM layer, Extensibility,
etc.) and *speedup* the runtime. It would also create an entirely new
framework needing to be thoroughly tested despite its gracefulness --
which will *delay* a stable release.

SilverStripe core, as it is now, is working wonderfully & well tested.
2.4 solved a mission-critical issue in making performance
(requests/second) accessible through partial caching & other tweaks, and
it can now be used as a "no-brainer" for building your next web
presence. As such; I believe the focus should be on fixing current
weaknesses and lingering issues with 3.0 -- things like improving the
cms and abstracting existing functionality into an even greater set of
feature-full & extensible core modules. Some of these (e.g. complete
Javascript overhaul, form fields rewrite / validation, etc.) will take a
long time & need testing. These are *immediate* needs and necessary for
healthy evolution in the project's ecosystem. Shifting to PHP 5.3 while
this is all happening may be lack packing an entire pack of big-league
chew in your mouth & trying to chew.

I personally see the only necessity of a moving to PHP 5.3 would be to
support NameSpaces -- allowing SilverStripe to be *properly* embedded in
a much larger PHP 5.3 application. Perhaps work can be done in this area
for 3.0. An alternative boot/autoloader that automatically namespaces
all project classes could [perhaps] be introduced? A build utility could
be made but I think it would be more interesting to have an alternate
autoloader/manifest builter prefix all classes on-the-fly with a
configurable namespace (say "MySite"). This would be prep-work towards
PHP 5.3 -- although I have little experience here & not sure what is
possible.

Would love to hear what the core team is planning & how they plan to
benefit from PHP 5.3!

~ Brice

>>> On 7 Dez., 02:13, Sam Minn�e<s...@silverstripe.com> wrote:
>>>>> I've had a very short poke around and found a couple of things:
>>>>> - ManifestBuilder complains if two classes have the same name. This would need to be changed to same name in the same namespace
>>>>> - ManifestBuilder can't pass classes that extend namespaced classes (class Controller extends /Controller)
>>>>> - The autoloader gets passed a namespaced-qualified path (/mynamespace/MyClass), when called from inside a different namespace, which it can't find
>>>>> That's all I've noticed so far.

>>>> Well, it seems like a good change. I think we'd accept a patch that still worked on PHP 5.1& PHP 5.2, and didn't slow things down too much.

[Uncle Cheese]

I think it's more than just namespaces, though. If you look at how
much SilverStripe relies on static class variables and inheritance
thereof, late static binding is a huge game-changer that could clean
up a lot of the workarounds that we've grown to normalize over the
last few years.

How often do we see syntax like this: singleton("MyDataObject")-
>stat('some_var');

It's a little kludgy, and for someone new to the framework, bizarre
and confusing.

Also, right now the ORM layer forces us to use what are essentially
factory methods for running queries. Late static binding would allow
us to move that down to the DataObject descendants and have a "real"
model layer.

MyDataObject::get_all();

MyDataObject::get_by_id($id);

This is the kind of design pattern we enjoy with an ORM like Propel,
only the key difference is that its workaround for PHP's lack of
static support is to autocode all of the static methods in each class.
Ugh. I'll take Silverstripe's current approach any day!

But I digress... for me, late static binding is the key game-changer
for the SS ORM. Can't happen soon enough.

Also, with __callStatic() we could decorate static methods on existing
classes. I've found myself looking for that option on several
occasions.

> >>> On 7 Dez., 02:13, Sam Minn�e<s...@silverstripe.com>  wrote:

[Brice Burgess]

Aaron,

I completely agree -- as I believed was sufficiently stated in my first paragraph. My concern is that changing the underlying framework is going to further delay a release -- and that there are immediate needs that I believe the focus should be on. Things like rewriting the cms javascript (and the reworkings involved), improving requirements (css/js serving), etc. These changes are the springboard to new 3.0 SilverStripe development and the sooner they're in developer hands, the healthier the ecosystem.

I can't speak for the core team at all -- having never met or discussed SS with any of them -- so this will have to be their decision and I'm sure whatever path they choose will be an enlightened one. Eventually the change will come and refactoring will ensue -- so I guess the question has to do with timelines (when do we want a release?) and changes (how much do developers needs to learn / change?).

Interestingly enough Debian 6.0 is rounding the corner -- which is arguably the bellwether of what version to support. It comes packed with PHP 5.3. For SS: It may also be worth considering what requirements are of 3rd party frameworks. Personally I wouldn't switch before.

~ Brice

>> SilverStripe core, as it is now, is working wonderfully& well tested.

>> 2.4 solved a mission-critical issue in making performance

>> (requests/second) accessible through partial caching& other tweaks, and

>> it can now be used as a "no-brainer" for building your next web
>> presence. As such; I believe the focus should be on fixing current
>> weaknesses and lingering issues with 3.0 -- things like improving the
>> cms and abstracting existing functionality into an even greater set of

>> feature-full& extensible core modules. Some of these (e.g. complete

>> Javascript overhaul, form fields rewrite / validation, etc.) will take a

>> long time& need testing. These are *immediate* needs and necessary for

>> healthy evolution in the project's ecosystem. Shifting to PHP 5.3 while
>> this is all happening may be lack packing an entire pack of big-league

>> chew in your mouth& trying to chew.

>>
>> I personally see the only necessity of a moving to PHP 5.3 would be to
>> support NameSpaces -- allowing SilverStripe to be *properly* embedded in
>> a much larger PHP 5.3 application. Perhaps work can be done in this area
>> for 3.0. An alternative boot/autoloader that automatically namespaces
>> all project classes could [perhaps] be introduced? A build utility could
>> be made but I think it would be more interesting to have an alternate
>> autoloader/manifest builter prefix all classes on-the-fly with a
>> configurable namespace (say "MySite"). This would be prep-work towards

>> PHP 5.3 -- although I have little experience here& not sure what is
>> possible.
>>
>> Would love to hear what the core team is planning& how they plan to

[xeraa]

Regarding 3rd party frameworks, as some Zend elements are used in
SilverStripe:
Zend Framework's next version 2.0 will be 5.3+:
http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements#ZendFramework2.0Requirements-BeanexemplarofPHP5.3usage

Otherwise waiting for some "official" feedback like the rest ;-)

> >>>>> On 7 Dez., 02:13, Sam Minn�e<s...@silverstripe.com>    wrote:

[Michael Gall]

> Also, with __callStatic() we could decorate static methods on existing
> classes. I've found myself looking for that option on several
> occasions.

I think this is an approach that really should be taken. There are a
number of features in 5.3 that can exist without breaking the 5.2
compatibility (namespaces aren't one of these) namely __callStatic,
get_called_class (with a function_exists()) call and lambda/anonymous
functions with is_callable.

I think it would be a great way of moving into the brave new world by
making some use of these that benefit people on 5.3 and don't break
compatibility on 5.2

What do you think? I also think discussions of how to actually create
the APIs should be moved into a separate thread.

Cheers,

Michael

[Dan Rye]

Why not move forward with 3.0 as planned, the features already underway only.  Then move ahead to 4.0 to take advantage of PHP 5.3+.  As we move to GitHub we can easily branch and work on 4.0 alongside 3.0.  I think things like the javascript rewrite are too important to hold up for.  Lets keep things moving forward and if there is enough community involvement we can work in parallel.

[Sam Minnée]

Realistically, 4.0 is going to be a few years away so this sounds a bit counterproductive.

The fact that Debian, RedHat, and Zend are all moving towards PHP 5.3 is encouraging although it's a bit early to make a definitive call. According to http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky PHP 5.3 has 4% of the PHP market compared to 66% for PHP 5.2. As the article says, stable Linux distros bundling 5.3 in the near future will change things, but predicting the future is hard. Lucky, Ilia is attempting to get the stats generation set up as a monthly process, and he's going to be updating the world on his progress at http://ilia.ws/. I, for one, have subscribed. ;-)

I think that, while there are certainly plenty of things we could do to make use of PHP 5.3, we don't need to starting coding for them from day 1.

Regarding late static binding, frankly I think we should move more in the direction of reducing the prevalence of static method calls! They make code more difficult to test and make it harder decouple the various pieces of SilverStripe. To the extent that static methods are available, I would expect that they are included as a layer on top of primarily instance-based code.

Thanks,
Sam

[Dan Rye]

Sorry, I was just using the next major version number.  Call it whatever you want but my point still stands.  Get the features that are underway out, don't hold up the release for supporting all of php5.3+.

[Artyom]

Hi all.

I sympathize with Hamish and Martijn, but respectfully disagree.
I've had a couple of clients ask for a more rich front end
environment. Most recently, a non-profit with multiple projects in
Asia and elsewhere... they need less techy users to be able to just
add rich blog postings and news. (The current front-end blog
interface doesn't allow direct image / media uploads) I actually
started evaluating concrete5 for them.. it made me sad that I had to :
-)

Of course the SS CMS is really great for many things, and way better
than most, but there is and will always be a segment of users that
really need a more direct front-end capability. In answer to
modularizing it, most of the work would be invested anyway, so why not
make it general off the bat?

keep up the great word and dialog everyone. (New to the list, but
having built 20 odd commercial sites with SS now...)

best,
Artyom

On Nov 3, 4:49 pm, Martijn Van Nieuwenhoven <marva...@gmail.com>
wrote:
> I agree with Hamish..
>
> I really fell in love with the CMS UI (although I head to learn here some
> things so she does what I want), icm the Sapphire Framework.
> Adding it as a optional layer on top of (for example) BlackCandy so devs can
> choose to use it or not...
>
> Really, I almost never have to explain something to my clients, because its
> so logical..
>
> my 4c with tip...
>
> Martijn
>
> On Thu, Nov 4, 2010 at 1:30 AM, Hamish Campbell <hn.campb...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Two immediate thoughts:
>
> > 1. IMHO, your "other things" list is vastly more important to the
> > project than a CMS UI change.
>
> > 2. The first reason most people give me why the switched to
> > SilverStripe in the first place is the CMS. What is the rationale
> > behind such a significant paradigm shift?
>
> > A classic case was a presentation at our last Auckland PHP Users Group
> > Meetup. Keri & Craig from PixelFusion.co.nz talked about how they
> > switched from SilverStripe to Symfony because they were frustrated
> > with ORM & templating limitations, performance issues, the difficulty
> > of upgrading between even minor releases and a lack of community. They
> > talked about how they still wanted the CMS features and they
> > proeceeded to present a very slick CMS they're building in ExtJS that
> > has a similar look and feel to SS. Cue an impressed crowd.
>
> > I'm not against what is being proposed and I'll be very interested to
> > see what Ingo and Hamish come up with, but it doesn't feel like the
> > best use of resources. Surely once the underlying issues are resolved,
> > building a Font End CMS would simply be a case of creating a new
> > module that can work in tandem with the CMS that has made SilverStripe
> > so popular.
>
> > My 2c.
>
> > Hamish
>
> > On Nov 4, 12:41 pm, Sam Minnee <sam.min...@gmail.com> wrote:
> > > Hi everyone,
>
> > > We've made some mention of SilverStripe 3.0, and I thought it would be
> > > worth talking a bit more about what we have in mind.

>
> > > Felipe Skroki, SilverStripe's Creative Director, has gone back to the
> > > drawing board with the SilverStripe UI.  One major outcome is that
> > > we'd like to radically simplify the SilverStripe CMS user interface.
> > > In particular, we'd like to use front-end editing much more heavily,
> > > rather than having an entirely separate user interface.
>

> > > At one level, providing front-end editing is very simple, but one of
> > > the powerful aspects of SilverStripe is the ability to create any kind
> > > of template and content model that you like.  If front-end editing is
> > > going to be a successful replacement for the CMS, then we need to be
> > > able to deal with the edge cases that this raises.
>
> > > Furthermore, the ability to upgrade older sites to SilverStripe 3.0
> > > without too much fuss is a major concern.  We can't radically alter
> > > the template language or the way that you define your data objects and
> > > page types.
>
> > > So, we're experimenting.  Over the next few weeks, Ingo Schommer and
> > > Hamish Friedlander are going to be making a prototype to see what's
> > > possible.  The outcome of that is going to give us a more concrete
> > > idea of what's possible.
>
> > > That, of course, only one of the areas that we are looking at for
> > > SilverStripe 3.0.  Some of the other things on our radar are:
>
> > >  * Improved mobile support
>
> > >  * Improved interaction with social networks
>
> > >  * Separation of Sapphire & CMS
>
> > >  * Completion of the ORM rewrite
>
> > >  * Improvements to the handling of download, images, and other media
>
> > >  * Better tools for module and configuration management.
>
> > >  * Updating the template engine so that uses a more robust parser
>
> > > One of the reasons that we're announcing this at the same time as the
> > > GitHub migration is that we expect that GitHub will make it easier for
> > > the community to be involved with the development of SilverStripe
> > > 3.0.  This is a major release, and an opportunity for us to all make
> > > improvements to SilverStripe that we've been wanting for a long time.
>
> > > SilverStripe 3.0 will be the next release to come out of the current
> > > trunk.
>
> > > In addition, once we have migrated to GitHub, we plan to create a 2.5
> > > branch based on the current 2.4 branch.  This will be a place to make
> > > more minor feature enhancements.  We will do this because we want to
> > > the 2.4 branch to be limited to bugfixes only.  The 2.4 -> 2.5 upgrade
> > > path will be substantially easier than 2.3 -> 2.4; we don't plan on
> > > making significant API changes in 2.5.
>
> > > We don't have any details about timeframes at this stage, but we're
> > > starting to ramp up our efforts on SilverStripe 3.0 now.
>
> > > Thanks,
> > > Sam

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SilverStripe Core Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsubscrib e...@googlegroups.com>
> > .

[Matt Bower]

I think the frontend publishing idea is great, but I think it should be made into a separate CMS solution. SS works well with the backend publishing and I think adding the ability to choose which style you want should exist more along the lines of two separate pieces of software built on the same framework. I know EllisLab did this with their new ExpressionEngine release and new MojoMotor CMS where both are built on top of their CodeIgniter framework but one is massively scalable CMS with backend publishing and one is a lighter CMS with frontend publishing.

I'm just afraid that implementing the ability to backend and frontend publish in one piece of software will become too complex to the developer (needing to create 2 different sets of content editing fields and code) and the client ("If you want to edit the content on this page, you can go either here or here.").

On Nov 17, 2010, at 7:50 PM, John Milmine wrote:

> From the submissions so far, it sounds like the community is open to a
> front-end CMS but don't want to sacrifice some of the other things. We
> realise that you guys at Silverstripe don't have 24/7 open source time
> and have plenty of other paid commitments to deal with.
>
> Happy to have a module and agree with Jason, that it would be a nice
> thing to potentially sell in. I definitely agree with spronk and
> others that it's better in theory than practice, at least in the
> systems I've tried.
>
> My points of concern would be:
> Template language decoupling.
> Database abstraction layer.
> Removal of prototype and only use 1 js library (jQuery)
> Like the idea of DataList above
>
> Also agree that SiteTree needs some improvements or added flexibility.
> Although I LOVE the strict sitetree, it does have disadvantages when
> it comes to things like tagging, blogging etc.

>
> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.

> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.