Revisionable Layouts

indytechcook's picture

One of the requirements for the LSD initiative is that layouts themselves be editorial controlled. This means providing revisions to layouts with the ability to move the layout through an approval workflow.

I'm not proposing we put this functionality directly in core, but we provide a way for contrib to "easily" add the functionality.

In Drupal 7 this is achieved by attaching layout related settings to node and using the node revision system in conjunction with workflow modules (workbench, state_machine or workflow). This is the method panelizer, context fields (future version) and block references module use.

If we want to leverage the entity, we can use layouts within custom blocks or a new block plugin that links layouts with entities.

This is not a discussion on if the concept of revionable layouts in a single site is needed because it is. Saying "Just stick it in config/VCS" is not an acceptable answer either.

My goal is to begin discussion about how this would be possible. Once we have a little direction, I can open an issue for it.

Comments

I certainly agree with

jolos's picture

I certainly agree with :
'Saying "Just stick it in config/VCS" is not an acceptable answer either.'
But to me layouts are still an example of configuration and I would avoid putting configuration into entities. I consider entities as something that can be added on production, so things like nodes, comments and users are a good match for entities. On the contrary, I don't think you should be able to add layouts on a production website just like you would add a node. ( This is a personal viewpoint, everything changes if you do want to create and edit layouts as you would with nodes )

Saying : 'we need revisionable layouts ( which I agree on ) => entities are revisionable so layouts should be entities' is imo not sufficient to defend the choice for entities.
It would be similar to implementing views as an entity, for views as well it would be nice to have revisions. But that doesn't imply you should implement it as an entity.

I think that a lot of requirements are shared with the 'collections' concept, they both are meant to organize entities in some way. Layouts do this on a page level, collections do this on a website level. And both collections and layouts require revisions.

Using entities would be convenient as it gives you a lot of things for free, revisions, workflows, etc. But imho layouts are not entities and hence shouldn't be implemented as entities.

One of the statements made by

indytechcook's picture

One of the statements made by heyrocker was that data is either CMI or an entity. Entities in D8 are much lighter then a node. There is a lot of work going into making the entity system very robust and the stanard CRUD interface for drupal "content".

I consider entities as something that can be added on production

I'm talking about maying layout changes on production. This is currently a practice by several of the LSD stake holders along with several of our other clients (Estee Lauder and Energy.gov). The entire change process needs to occur on one site. This means the layout itself needs to be revisionable and can go through workflow. We really are turning configuration into content. So it does make sense as an entity.

I'm not saying turn all layouts into entities. Just a certain type of layout. They don't even have to be a "layout" in the same sense of what the scotch initiative calls a layout. A layout how I'm referencing it could really be a "block" with references to other "blocks". So basically an implementation of a Block Plugin

I have already made a block plugin that creates block instases that are entities. So extending that plugin is really doable.

I'm very open to other ideas, that's why I haven't opened a really issue or started coding.

Can you link to "One of the

Bojhan's picture

Can you link to "One of the requirements for the LSD initiative is that layouts themselves be editorial controlled." Because other than you posting it, I don't see any discussion around it?

Either way this seems totally achievable to support, if we get enough developers who are interested in this part. I suggest you get in touch with EclipseGc on how we can make this happen.

I agree with Bojan

tkoleary's picture

We need to coordinate efforts on workflow and layouts. In consultation with EclipseGc I have been working on UI for layouts that incorporates ideas from context, display suite, panels and blocks (prototype here: http://invis.io/R22O4KEZ).

I would be very interested in getting into a discussion on how we can make make revisionable layouts and w.orkflow seamless

Can you link to "One of the

indytechcook's picture

Can you link to "One of the requirements for the LSD initiative is that layouts themselves be editorial controlled." Because other than you posting it, I don't see any discussion around it?

These came out of my discussions with the LSD member along with Acquia.

@tkoleary, those are very interesting. I see you are using the concepts of templates. I've been spending lots of time in a few ruby/Rails based CMS and this seems to be a commonality. Showing revisions of layouts is very complicated. These CMS's are really focused on the page concept. You This probably is off topic but http://www.browsercms.org/ actually has built in workflow in layouts. You approve the entire page at a time. The page also get revisioned. I'm trying to get a quick demo site up.