Here is a great feature missing in Paragraphs and actually already available with the [Entity Reference + Inline Entity Reference + Nestedbox] workflow:

The ability to reuse previously created paragraph items across multiple nodes (even across one same node if needed).
The selection is made via autocomplete based on the administrative title.
Modifications on any of the occurrences are applied to all occurrences.
When deleting an occurrence, user can decide to keep it in the system even if not even referenced anywhere or completely remove it even if still referenced elsewhere.

One direct benefit is to allow clients to easily use paragraph items as "blocks".
This is better than using modules like Block Reference that would require the user to :
- first go and create the block in a separate location
- use the block create/edit interface that can be intimidating for some clients because of all the options

As far as I'm concerned, this feature will actually make me stick to the [Entity Reference + Inline Entity Reference + Nestedbox] solution until this is possible with Paragraphs, that's why I'm marking it as Major.

Actually it even makes me think that Paragraphs module should be better off using Entity Reference and Inline Entity Refence as dependencies so that we could actually benefit from all their advantages instead of duplicating them with a little less features.

By the way, are there reasons why you did not use them or you just had not realized they were doing the same thing at first?

Comments

frans’s picture

frans commented

I don't see why this is major, if there is another solution for the problem.

IMHO it makes it too complex. Paragraphs aims to be a replacement for the body field. Reusing paragraph items is strange from the content editor perspective. The content editor must have a complete understanding of paragraph items being objects and that he/she is changing the object, and not the content on the node.

The way I would solve it is by making a reference paragraph bundle. Make a special 'shared content' entity and reference it in the paragraph item. Personally I wouldn't use inline edit there, just to keep it understandable and not too heavy, but it can probably be done.

nicolas bouteille’s picture

nicolas bouteille commented
Title: Reuse existing paragraph items across multiple nodes » Reuse Paragraphs items + Give more power to end-user
Priority: Major » Normal

First of all, I think you're totally right about the major part and your argument makes complete sens. Just because it is important to me does not make it major in a Drupal perspective. There is an alternative to the feature already, so let's switch it back to normal.

Now, I still think this feature is important.

I don't know about the rest of the world, but here in France clients are not very good at using computers. They excel in their own field but you really need to hold their hand with Drupal and make the editing worflow as simple as possible.

So the people I work with and I, we try to provide our client with only one way of doing things... that's why for example we don't use Views's page display but embed Views in a Content Type instead. That way when they want to add text before and after, they don't need to go edit the view and modify its header and footer. That would be too complicated.

You say Paragraphs is just a better body field... I don't personally join you on that. I think the name of the module is not good enough and actually makes people think that... but behind it there is something bigger. Creating slideshows, adding blocks, adding views, adding forms, adding parallax images, accordions, tabs, choosing a view mode per item per node, wrapping some items in a configurable Masonry grid...
I truly belive modules like Paragraphs are "the new way of content creation" in Drupal... to quote the module's project page. And I think this new way is that all content creation can and should be done right from the node create/edit form.

And now that I think about it, this does not only include blocks, I really believe we should look for a way to make the user create simple views as well for example! Maybe even simple forms...

I mean, the Views interface is clearly meant to be used by us, site builders. But if we want Drupal to keep up with the competition, we need to give the end-user more power and freedom. So yes, really simple views bundles with a few options. And for really complex views that actually must be created by the site builders, we could still provide a way to edit simple configurations like the number of items per page or choosing between a load more or infinite scroll, display thumbnail or not, switching view mode... all this right from the node edit form where the view is referenced.

We often here: "I saw that Wordpress was really intuitive, will Drupal be the same?" and we often answer: "Yes sure." The truth is Drupal really has some work to do in order to become more end-user friendly. IMHO, giving more power to end-users through initiatives like Paragraphs is really important for Drupal's future.

frans’s picture

frans commented

Your arguments seem to support my point. My whole point is: Let's not make it too complex for the content editor. Just because it can be done, doesn't mean it needs to be done.

The concept of referencing content (paragraph items) on another entity is too complex. We cannot expect from a content editor to understand what he/she is doing then.

And as said, you already can do it now. Just make a paragraphs bundle with a entity reference field. From there you can reference any entity, including paragraph items. Put some smart widget over the entity reference field... and you are done.

Same goes for selecting view mode or publish/unpublish in the paragrahs item form. Just add the needed fields to your bundle, do something smart in hook_preprocess and you are done.

nicolas bouteille’s picture

nicolas bouteille commented

I take good note of the tips you gave at the end.

Now obviously we still disagree on one point... I personally believe it is not complex for the end-user to consider reusing somewhere else an already created item. The way you say it "referencing content on another entity" makes it look complex I agree, but when you just say "use existing item" it's already a lot simpler don't you think?

When I read between the lines of what you say, I have the feeling that for you, let's keep it simple for the end-user is related to the WHAT... meaning let's stick to basic stuff, basic features.
Me on the other hand, I wish to give the user more and more editing power, because I believe the end-user is totally clever enough to understand and deal with reusing blocks, creating slideshows, listings of stuff or simple forms. But he/she needs a simple workflow. For me let's make it simple does not concern the WHAT but the HOW. I said people were not good at computer science, not dumb. Clients are great ideas, great needs, they just don't understand how to use our tools.

How do we make it simple for the end-user: first by unifying the content creation process, the same way the translation process has been unified in Drupal 8. So as far as content creation is concerned, I believe everything should be created from the node. Complex components, reusable blocks, listings, forms. It's our job to make it simple to the end-user.

jeroen.b’s picture

jeroen.b commented

I personally think being able to use existing paragraph items makes things too complicated for end-user.
How would you ever pick one of the (on an average site) hundreds of paragraph items you have already created?

Paragraphs can't really be differentiated quickly without looking at it's content. Adding a label to every paragraph item will be too hard for the user (just think about how hard it would be to give a proper name to every paragraph item you create).

I agree with Frans here, if you want something like this, best way to go would be inline entity form reference field inside a paragraph bundle.

It's also hard to explain to users what happens when they use an existing item, or what happens when they edit one.

nicolas bouteille’s picture

nicolas bouteille commented

The way Inline Entity Form lets you add items is: you first choose what kind of item you want to choose on a select. Then on the right side you have two buttons "Create new item" and "Use existing item". If you choose to reuse an existing item, you get an autocomplete field based on administrative title.

As I already explained on another feature request, I personally think displaying Paragraph items closed on the node edit form the way Inline Entity Form does, with only the administrative title showing makes the node edit form cleaner and makes reordering items easier. I've used it on my own website and personally I don't think adding an administrative title for each item is a pain in the ass. On the contrary I find it a fair price to pay for the clarity and ergonomics you get in return.

Now we could also only make the administrative title required only if the user wants to reuse the block. So there could be a "Make it reusable" checkbox for example... which would make the Administrative Title appear and required...

I see your point when you say that users could not fully understand what they are doing when reusing items and modifying it... well I would personally add additional explanations and warnings such as: "The item will be shared across all nodes that use it. All modifications will be applied on all of them". We could then think about a way to desynchronize items... I still think this is all things the end-user is clever enough to understand...

But anyway I get it, we clearly don't see things the same way today, so let's give it some time, maybe I will change my mind in a few months, maybe you guys will... We'll see.

In any case, I know understand why you did not build on top of Inline Entity Reference since you wanted a different way of dealing with items... but what about Entity Reference? I guess this module is now installed on every Drupal 7 site... why isn't it a dependency of Paragraphs instead of replicating their code? Or maybe it is not the case... just making assumptions here...

jstoller’s picture

jstoller
he/him
commented

I have to agree with Frans and jeroen.b here. The two most used paragraph bundles in my current implementation are Body Copy and Media. I wouldn't want my users reusing body copy on multiple pages, even if the option was available, and the Media module already provides a central library for reusable media items. The other fields on my Media bundle—like layout settings and a caption—I need to remain unique to the host node, just as with the page copy. I could see wanting a reusable library of, say, photo slide shows, or customer testimonials, but as has already been suggested, those could be their own entities, referenced using an entity reference field on the paragraph bundle.

jstoller’s picture

jstoller
he/him
commented

Just a suggestion, but if what you're looking for is for every "paragraph" to essentially be a block, which can be placed and reordered within the content on any page, then maybe you should look at using Entity Reference + Inline Entity Reference + Bean. You can create different bean content types and each bean entity can quite literally be used as a block. You could then put a inline entity reference field, with an unlimited number of items, in the content area of your node, giving it access to all of your beans.

nicolas bouteille’s picture

nicolas bouteille commented

Yes as I said before that's the workflow I actually use so far except with Nestedbox instead of Beans but the result is the same in the end. However I believe we should focus on one module not two so that's why I am trying to add features I like from Inline Entity Form and Nestedbox into Paragraphs...

apmsooner’s picture

apmsooner commented

I want to offer an idea here for people that like to offer ability of reusing content. This doesn't suit every situation but paragraph module in my opinion provides some very useful functionality for me at least. I'm setting up text fields on the user profile for various snippets to serve as default text to populate elsewhere. Then using those same fields in paragraph bundles. With help from https://drupal.org/project/field_default_token, the user can select a paragraph item that contains a token for the default value in their user profile. Paragraphs module works awesome for this because you can basically have a dropdown list of all sorts of snippets to choose from defaulted to the user preference but still be modified directly. Just thought i'd mention it as a creative way to use this module.

jeroen.b’s picture

jeroen.b commented
Status: Active » Closed (won't fix)

When you want to reuse content, I think it's best to put an entity reference field inside a paragraph bundle and reference to the content you want to reuse in that field.

That way you put the editing of those re-usable content somewhere else so it's clear to the user that the content might me referenced in different places.

nicolas bouteille’s picture

nicolas bouteille commented

A few months have passed. I have reread the whole thread and even though I still pretty much agree with what I said, it seems that I kinda missed the alternative solution you guys told me about at least three times... and I have to admit that creating a Paragraph Bundle with an Entity Reference field so that I can reference other Paragraph bundles is a good solution :) And indeed makes it clear to the end-user he/she is reusing/editing one and only item. Sorry for not getting that sooner ;)