Closed GustavoMarcante closed 6 months ago
dawehner
commented
7 years ago We ship with at least one component right now: The media support.
I tried to think of some others, but its a bit tricky. On a decoupled project you probably want to have a custom data model all the time, designing one which fits all could be really difficult.
e0ipso
commented
7 years ago I agree with @dawehner. @GustavoMarcante do you have any specific thoughts on this?
GustavoMarcante
commented
7 years ago @dawehner @e0ipso Thanks for the replies.
@dawehner What do you mean by media support?
@e0ipso Thoughts? I have a lot!!! But I'm trying to make them practical... As you exposed, after following the first four steps in Contenta (and I did it! probably one of the firsts to do it :smiley:), and go to step 5, Contenta looks like Reservoir, "a minimalist distribution for decoupling Drupal". One great "plus" Contenta offers, are the examples of content and front-end applications and the community discussions and knowledge around it. But:
In the same way as it is to front-end, also to back-end would be good to have a starting point - a selection of components or features. @dawehner I agree this is true for experienced users, but I do not think the same for whom is starting with "drupalities". I personally agree with Dries advice: put non-coders first.
This could be a second "plus", a selection of modules/functionalities - that already exists, is just a question of choosing the ones that fits better (better to use, less conflicts, closer decisions, etc.).
We can discuss what components would be, but nothing so different from what most of the CMSs (out-of-the box or using extensions) do and even Contenta is using:
This would make Contenta a starting point to develop a content repository with open source in a progressive decoupled strategy -- the best when you are developing the back-end planning front-end for the future. That would make Contenta a unique CMS (comparable to Hippo CMS, but more friendly). Note that current Contenta installation is a progressive decoupled example, as it shows the content before the consumers being ready.
I see four approaches for this:
1) The best one, build the Contenta site to be an example of Contenta use, approximately with the content models above, even not all being presented by the consumers (that is not a problem, it's a characteristic of a content repository, having more than what the front-ends show).
2) To start from another Drupal distribution - for example, Lightning or OpenSocial - and to "apply" Contenta to it. This can be done installing modules? It might be done manually?
3) To start from Contenta and install modules and themes selected by the user. How to know if they are compatible?
4) "Merge" distributions (I don't know if this is possible) or use sub-profiles (I don't know if this is possible with Drupal 8.3).
What do you think?
e0ipso
commented
7 years ago Building these features could be an interesting way to make Contenta CMS friendlier to non-Drupal people.
However I think this should sit on top of Contenta and not in Contenta itself.
Maybe we can focus on small feature (let's not get too ambitious, we may overwhelm people working on this).
@GustavoMarcante you seem to be very knowledgeable on what other CMS are doing, can you propose a very small set of features so we can work on a proof of concept / prototype?
dawehner
commented
7 years ago I could imagine it would be reallly nice if one could choose from a couple of features in the installer. This could then pull features from a features server, you know like people planned back in the days :)
On Mon, 17 Jul 2017 at 08:00 Mateu Aguiló Bosch notifications@github.com wrote:
Building these features could be an interesting way to make Contenta CMS friendlier to non-Drupal people.
However I think this should sit on top of Contenta and not in Contenta itself.
Maybe we can focus on small feature (let's not get too ambitious, we may overwhelm people working on this).
@GustavoMarcante https://github.com/gustavomarcante you seem to be very knowledgeable on what other CMS are doing, can you propose a very small set of features so we can work on a proof of concept / prototype?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/contentacms/contenta_jsonapi/issues/118#issuecomment-315680319, or mute the thread https://github.com/notifications/unsubscribe-auth/AABz7l35DdmucJDFAga3WsfMuGV32lLfks5sOwaZgaJpZM4OUbeX .
GustavoMarcante
commented
7 years ago Building these features could be an interesting way to make Contenta CMS friendlier to non-Drupal people.
Yeah, you got it!!! :tada: :confetti_ball: :tada:
However I think this should sit on top of Contenta and not in Contenta itself.
I could imagine it would be really nice if one could choose from a couple of features in the installer.
Great! Maybe "features" can have the same status as "example content", or maybe recipes example content can be one of the features (I like this way). And you choose if (or what) you want or not to install in installation phase and can install or uninstall later, as it is with content now (like common modules, but in a friendlier way, see bellow).
This could then pull features from a features server, you know like people planned back in the days :)
Yeah! What a "non-coder user" expects is a friendly way to select things. That is what Android/Google Play does, that became the "default" now, and what is already present in Ubuntu and many CMSs and ERPs, something more like a store. Look, I have a computer science background and even I got oppressed by a list of extensive list of modules that I must study weeks to understand what are aimed for.
I think that a nice interaction requires more than a good looking Javascript check boxes in the front-end, is about being friendly in the interaction. Sometimes developers are so immersed refining the tools that they loose the concept (I know 'cause I myself acted this way).
Maybe we can focus on small feature (let's not get too ambitious, we may overwhelm people working on this).
@GustavoMarcante you seem to be very knowledgeable on what other CMS are doing, can you propose a very small set of features so we can work on a proof of concept / prototype?
@e0ipso Why not, as I suggested, taking the ones of another distributions, like Lightning or OpenSocial, that are real needs? Or something like the list above (members, groups, articles, wiki, assets, events, basic elements that will be used even in Contenta site, plus "updates", an "horizontal integrator" content type already in use)? It is not about developing them, is about merging / joining / making available what already exists. Both distributions will benefit. I think this would be a "basic set", do you think it is too big?
GustavoMarcante
commented
7 years ago The challenge, I think, is that these modules have impact both in the back-end (content types) and front-end, because they came from coupled strategy.
Reservoir removed all references to front-end. Contenta kept them - what to a progressive decoupled strategy is necessary, because you will have the "coupled CMS channel". Issues 75 and 131 and pull request 147, for example, are about the "coupled CMS channel" installed with Contenta (what I think is very important).
I think that would be good if the admin menu could have an specific item to this "CMS channel" (or front-end), where current "appearance" item and the front-end part of "structure" item (like block layout) would be joined. Then, the rest of admin menu could be displayed more or less like Reservoir does, evaluating if the items "Contenta CMS" and "Advanced" of Contenta menu still being necessary ("advanced" looks more like a coupled Drupal reference, that is it?).
GustavoMarcante
commented
7 years ago Another possible approach to that would be:
stereoplegic
commented
6 years ago I am 100% on board with Gustavo's ideas. I think it would be worth collaboration with other distro creators. Right now I have decoupled use cases for Commerce Kickstart, Opigno (once D8 version hits RC at least), Open Social, and others.
Commerce Kickstart is a good example, actually, as they give you the option to stack it on top of other distros and enable other needed options to build a custom composer.json: https://www.commercekickstart.com/
e0ipso
commented
6 years ago It would be interesting to talk more about this with the devs at Commerce Guys maintaining Commerce Kickstart. Can you take the lead on that Mike?
[image: --]
Mateu Aguiló Bosch [image: https://]about.me/e0ipso https://about.me/e0ipso?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links
On Mon, Aug 27, 2018 at 3:17 AM Mike Bybee notifications@github.com wrote:
I am 100% on board with Gustavo's ideas. I think it would be worth collaboration with other distro creators. Right now I have decoupled use cases for Commerce Kickstart, Opigno (once D8 version hits RC at least), Open Social, and others.
Commerce Kickstart is a good example, actually, as they give you the option to stack it on top of other distros and enable other needed options to build a custom composer.json: https://www.commercekickstart.com/
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/contentacms/contenta_jsonapi/issues/118#issuecomment-416088489, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFoqmydZrhrjQ7dNUsJU1nZHnEn1JIWks5uU0iugaJpZM4OUbeX .
One of the biggest restrictions about using Drupal as a Content Management Systems (CMS) is the difficulty to start – it demands a lot of learning and definitions. According to Dries and others, this is because of its characteristic of being not exactly a CMS, but most a Content Management Framework (CMF). To make this entry point easier, Drupal offers the Distributions, that “make it possible to quickly set up a complex, use-specific site in fewer steps than if installing and configuring elements individually.”
One of the benefits of using Drupal instead of decoupled CMSs is the possibility of using progressively decoupled strategy – what is useful, for example, when you are building a site administering a content repository that will be consumed by other applications. What is my case.
Contenta was born to provide the modules and configurations to work with decoupled Drupal out-of-the-box, with examples of content and consumer front-ends build upon the most used Javascript frameworks.
As exposed in Contenta slogan issue, as who is in the “content side” of the decoupling, in my opinion would be important that Contenta could offer also a set of components or features out-of-the-box, selected from the vast amount of the possibilities offered by Drupal, as other distributions do, like OpenSocial, OpenEdu or Thunder and as other CMSs do, like Hippo CMS, or even ERPs, like Odoo. That would make much easier to start with Drupal.
As Contenta developers has a large experience in developing systems, I think that would be very useful. And, in my point of view, it would accomplish Contenta proposal: “From powering a single application, to multi-channel publishing, Contenta provides all the tools and configuration you need to get started with your Create Once, Publish Everywhere CMS.”
So, my question is:
1) Could be in the plans of Contenta offer a set of basic components / features, as other CMSs and distributions?
2) If not, which would be the best practice to build it? To choose one Drupal distribution and then have a way to “apply Contenta” in it? Or to install Contenta and import module by module? Is there a “easy and safe way” of doing these (to avoid conflict of dependencies versions, for example) and to have the benefits of continuous upgrading?
I’d like to point that it is a very important issue to me. And I’m posting it here because I think it can help other people interested in developing content repositories using Contenta.