Spread the Open Source ❤️ and get inspiration from Reservoir

[e0ipso]

Reservoir has many great things. Let's list the features that we like from the project and vote on them if we'd like to see them in Contenta CMS.

One feature per comment, please add your own! When you add a feature add both a 👍 and a 👎 so people can vote with a single click. Please add screenshots if applicable.

[e0ipso]

The dual-format view of a node in the back-end.

[e0ipso]

A 30 sec overview tour.

[dawehner]

Generate an oauth client by default

When you install it, you get a oauth client by default, without any command line vodoo needed: #56

[e0ipso]

The simplified admin settings (even for user/1).

[dawehner]

Editor/Developer role

When you install it, there is a role for both editors and developers. Make that separation is really helpful, IMHO: #57

[e0ipso]

• Default demo users: and all the logic that warns you to change it in production.
• Regrouping the User and Simple OAuth settings in a single page.

[e0ipso]

OpenAPI & ReDoc. We already have this in! No need to vote.

[e0ipso]

Simplified admin/content page without views (and without the features that the view adds).

[e0ipso]

Lack of a media library. We have one in Contenta.

[e0ipso]

Remove UI to change the Appearance and Extend.

Yes, it's redundant with #60 (comment) but from the opposite angle.

[e0ipso]

Contenta has a Knowledge Hub. Do you like it?

[e0ipso]

Add your suggestion!

[mortenson]

If we add default roles, I think that adding shortcut sets per role using https://www.drupal.org/project/shortcutperrole is a better option than simplifying the toolbar. Good permissions + good shortcuts really helps content editor UX.

[e0ipso]

https://vimeo.com/222271467 is a good feature overview of Reservoir.

[justafish]

For the the dual-format view of a node in the back-end - I really like it, but I think it's a terrible editorial experience so +1 if it goes onto a separate tab and the edit interface is the default.

Most decoupled projects I've worked on don't even provide the rendered node under the "View" tab, so even better I think would be the edit form with a JSON view that could slide in from the side.

[justafish]

Moved the above discussion to #61

[chris-hamper]

Re: @justafish I like the edit-centric approach on the backend. I'd envision having some other way of viewing the node in a quick and easy way via the actual frontend.

She had mentioned on #Contenta that her past approach was changing the "View" tab to be a link to the node on the frontend. I could see having some sort of plugin system that describes to the backend where the frontend is and how this mapping is done.

Capturing other ideas: open the frontend page in a separate tab / window, which is reused when another node is "View"-ed, or use an iframe approach to show the frontend, possibly with a slide-in drawer or toggle-able split view.

[justafish]

@chris-hamper we have this as a simple array in the Drupal settings file on the site screen-capped above (it's also able to fully control the URL structure so there's no need for any URL mapping)

[wimleers]

I love that the cross-pollination has already started!

And I love that pretty much all of the ideas of Reservoir appeal to Contenta users :) It almost make me wonder if we should move the reservoir_ui module into a separate project? Contenta offers a superset of Reservoir's functionality, so it could quite easily add on its own additional things?

(It took me quite a while to figure out how to generate an OAuth2 public/private key pair by default btw — #56 will benefit from that :) Note that it won't work on all environments though!)

• RE: Knowledge Hub: very useful!
• RE: no Views: I did that because if you can query/filter/sort using JSON API, then there's no more need for REST export views. And hence there's no more need to teach users how to set those up. I can see why you'd want to use views but not views_ui though: for better/richer listings. But then you need to make sure you don't expose those view config entities via JSON API!
• RE: OpenAPI: I see you imported it (yay!), but you haven't fully integrated it yet.
• RE: default roles: Reservoir doesn't use the Shortcut module because its experience is … less than ideal. Also, Reservoir reduces the UI surface so massively, that the 4 navigation links in the toolbar ("Content", "API', "Content modeling" and "Access control") bring you within 1 or 2 clicks of anything you might want to do. So there's far less of a need for the Shortcut module. And it's again one module less. Of course, Contenta should make its own choices. I'm just explaining the rationale I applied!
• RE: Vimeo link: I'm glad you like it! It took FAR too much time.
• RE: dual-format view: excellent point, @justafish! I was totally torn about it too. We decided to ship it like this and refine later based on feedback. I agree it's a bad editorial experience for many/most. OTOH I think that for some it might be pretty interesting to see it like that. I'm interested to hear more about how you think this should work. You say that most of the decoupled projects you've worked on don't even provide the rendered node under the "View" tab. So then what do they show there? A JSON view that could slide in from the side sounds very cool, but how do you ensure it's up-to-date, i.e. in sync with what the user has been writing? Do you save the entity to TempStore via AJAX and then use that to generate the "live" JSON view? Created Revisit/refine the dual-representation viewing of content acquia/reservoir#11 for this!

[wimleers]

Moved my reply to "dual-format view" to #61 (comment).

[dawehner]

(It took me quite a while to figure out how to generate an OAuth2 public/private key pair by default btw — #56 will benefit from that :)

The one thing I'm wondering, is this secure. I guess, but I have no idea

[e0ipso]

@wimleers, thanks for the feedback!

But then you need to make sure you don't expose those view config entities via JSON API!

Agree! See http://dev-contentacms.pantheonsite.io/api

[e0ipso]

RE: OpenAPI: I see you imported it (yay!), but you haven't fully integrated it yet.

#59 Should expose a link to it (or something similar), is that what you mean?

[e0ipso]

Reservoir doesn't use the Shortcut module because its experience is … less than ideal.

Any known gotchas? I haven't used it in a while.

[e0ipso]

RE: Vimeo link: I'm glad you like it! It took FAR too much time.

People underestimate how much effort video content is! <3

[e0ipso]

On a general note I have to say that I don't like the idea of the back-end server knowing anything about the front-end implementations. Not even to provide links to node pages:

• You cannot know, with certainty, about the existence of the front-ends (tricky if it's a public API).
• The front-end may not have a dedicated view action for that resource entity (only coincidental that resource entities match with entity types). Think about how there is no dedicated page for the embeddable text.
• The front-end can operate via links.
• …

One of the goals of Contenta is to provide best practices. The fundamental one is that the back-end doesn't know anything about the front-end. Not even its existence.

When evaluating these things I always imagine my API going public an someone implementing an Alexa skill (no concept of page or viewport) that I don't know about. It usually puts things in perspective.

[wimleers]

The one thing I'm wondering, is this secure. I guess, but I have no idea

It is and it isn't. This generates a unique key pair per site: not one key pair across all Reservoir sites. That's good. But it doesn't store it in an ideal place, it just stores it in sys_get_temp_dir(). I got that idea from \League\OAuth2\Server\CryptKey::saveKeyToFile().

[wimleers]

On a general note I have to say that I don't like the idea of the back-end server knowing anything about the front-end implementations.
I agree in principle, but in practice it's of course very valuable. At least for those sites where the "Content administrator" role is used very actively.

I think it could be configurable: a "content front end mapping URL", which accepts either node ID or node UUID, and then generates a front-end URL. Of course, this assumes that there's a single front end.

So another solution could be to make Reservoir/Contenta alter the oauth2_client add/edit form, and allow such a URL to be entered there. Then content administrators would be able to preview the same content in any front end they choose.

[wimleers]

Oh and regarding security: that means that https://twitter.com/michaellnorth/status/877202039394230272 definitely does not remotely apply here.

[dawehner]

<3 Wim Leers <notifications@github.com> schrieb am Mi., 21. Juni 2017 um 11:26 Uhr:

…

Oh and regarding security: that means that https://twitter.com/michaellnorth/status/877202039394230272 *definitely* does not remotely apply here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABz7qZH3M2h7rc8Ip7jwdlOfFFUEaJLks5sGO_JgaJpZM4N-4l6> .

[e0ipso]

Thanks for all the inspiration.