Problem/Motivation
Sometimes it is desirable to use a different name for paragraphs bundles in the edit form than what is used in the admin UI. For instance, take a node with two paragraphs fields: one for body content and one for sidebar content. Each of these fields may have an associated paragraphs bundle for adding images. These two fields need to be distinguished from one another in the admin UI, so their names might be "body image" and "sidebar image," but on the edit form they would ideally both just appear as "image."
Additionally, paragraphs bundles currently lack an administrative description field, which is customarily provided for entity types (nodes, vocabularies, beans, etc.). These descriptions—used in the admin UI—are useful for describing (briefly) the intended purpose of the bundle.
Proposed resolution
Add a "Label" property to all paragraphs bundles and use it in place of the bundle's name on edit forms. Set the initial label to the name value for all existing bundles on update.
Also add a "Description" property to all paragraphs bundles and update the paragraphs bundle overview page to display descriptions, making it consistent with how node content types are displayed.
Remaining tasks
Review and commit patch.
User interface changes
Admins will see a new "Label" field on the bundle edit page, giving them the option of setting a user-facing label for their bundle that is different from the bundle's administrative name. This option should improve the user experience for editors.
Admins will also see a redesigned bundle overview page that displays descriptions for each bundle.
API changes
None.
Data model changes
Adds 'label' and 'description' fields to the {paragraphs_bundles} table.
| Comment | File | Size | Author |
|---|---|---|---|
| #37 | paragraph_label.png | 52.47 KB | ParulB |
| #36 | add_label_property-2568601-36.patch | 12.18 KB | jstoller |
| #30 | paragraphs-labels.png | 118.9 KB | jstoller |
| #30 | add_label_property-2568601-30.patch | 11.44 KB | jstoller |
| #29 | Selection_937.png | 28.27 KB | jeroen.b |
Comments
Comment #2
jstollerThe attached patch adds 'label' and 'description' fields to {paragraphs_bundles}. The included update function will set the label of any existing bundles to the bundle name, maintaining the current behavior. The label will then be used in place of the name when paragraphs fields are displayed on edit forms. I also updated the Paragraphs bundle overview page layout, making it more consistent with how node content types are displayed.
Comment #4
jstollerAdded Features support for new fields and updated test bundle with values for label and description.
Comment #6
jstollerChanged title and updated issue summary for clarity and to reflect addition of description field.
Comment #7
arefen commentedHi. i patched module and drush updatedb after it.


now in edit paraghraph bundle i have 3 box. 1: name. 2: Lable 3: description
i filled all of box but in bundle list don't show name or lable
Comment #8
arefen commentedComment #9
arefen commentedin log messages iget bellow warning
Comment #10
jstoller@rfnbnkr, I'm not sure why you'd get that error. You'll find theme_paragraphs_admin_overview() on line 85 of paragraphs.admin.inc, and it's defined in paragraphs_theme() on line 1220 of paragraphs.module. Are you using the latest version of paragraphs? Are you sure the patch applied cleanly? Maybe try clearing the cache, or even rebuilding the registry to see if that clears it up. Here's what the paragraphs bundle overview page looks like on my install:
I did find a minor error in my last patch, causing an undefined variable error when creating a new bundle, so I'm posting the update here. This patch also removes an unrelated typo correction, which I'll post in its own issue.
Comment #11
arefen commentedThanks jstoller.
after patched i manually clear cache_form. then it's work
Comment #12
jstoller@rfnbnkr: Glad to hear it! Are you confident enough in this patch to mark it RTBC? I'd love to get this thing committed.
Comment #13
arefen commentedYes jstoller. i test it. and now it work properly
Comment #14
jstoller@jeroen.b, if you're watching, I wondered if you have any particular concerns about this patch or the issue it's solving? I don't mean to rush you, but if there's anything I can address to move this toward being committed, I'm happy to do so.
Comment #15
miro_dietikerSee also #2618376: Add an administration title to the paragraphs - possibly even duplicate.
Comment #16
jstoller@miro_dietiker Have you been added as a Paragraphs module maintainer? If not, then I would really like @jeroen.b to weigh in on this before the issue is summarily closed.
This issue predates #2618376: Add an administration title to the paragraphs, so if anything that is the duplicate. However, after reading through that issue it appears to be trying to address a completely different use case. It appears to be talking about adding a title field on individual paragraphs entities, so they can be referenced in views, while the patch here adds a user-facing label on the paragraphs bundle itself, to change how they appear in the select list when adding paragraphs items to a field. Without this bundle property my only recourse is to hack paragraphs using a form_alter hook and hard-code my labels into a custom module. That seems a little ridiculous to me.
I believe this to be an important UX improvement to Paragraphs. It has been requested by multiple users and has an RTBC'd patch. If you feel there is a problem with this patch—either in the problem it's trying to solve, or in my approach—then can you please explain your concerns so we might discuss them?
Comment #17
miro_dietikerAh, i see this is about bundle definition. Then i misread the issue. There are so many similar requests...
I'm the lead at MD Systems and we support the Drupal 8 port a lot and join discussion about architecture with our experts and help reducing complexity and cover complex aspects properly. We have added multilingual support for D8. I have been added as an ERR co maintainer. If a module like Paragraphs want to be successful with maintenance and evolution, we should not always rely on the maintainer. Still back to him about this. :-)
And removing the relation again. Thx for clarifying!
Comment #18
jstoller@miro_dietiker, in that case... I'm going to be stuck on D7 for a while yet and haven't had a chance to play with the D8 version of Paragraphs, but I'll be needing this same feature when I get there. Anything you can do to make that happen would be appreciated. :-)
Comment #19
scottsawyerHello, wanted to get some information about this issue and the patch. I ran into an issue and came looking here for answers and I think it's related.
I have a paragraph item, and an entityform with an entityreference field to the paragraph item bundle. However, when I try to enter a paragraph item into the entityreference field ( autocomplete ), I see a "restricted access" message where a label for the entity would normally be displayed. Looking at this issue, https://www.drupal.org/node/2153463, there is a problem with entityreference, entity_access will not pass if there is a NULL value for the entitylabel.
Now that I have installed the patch https://www.drupal.org/files/issues/entityreference-restricted_access-21... I don't see restricted access, I see nothing. If I switch my entityreference field to checkboxes / radios, the radios are displayed with the correct entity id, however, there are no labels, presumably because the paragraph entity does not have a label.
So, I am wondering if this patch will allow me to add entity labels to my paragraphs.
If yes, is this something that will likely not be committed / supported?
If no, is there an alternative solution I should consider?
Comment #20
jstoller@scottsawyer: The short answer is no. This patch lets you add a label to the bundles themselves, not the individual paragraphs items entities you create. So if you have a paragraphs field, you can change the names of the item types that appear in the select list on the edit form.
I suspect the root of your problem is the defaultLabel() function in ParagraphsItemEntity.inc. It explicitly does not display a label. Paragraphs item entities are not intended to be referenced outside their host entity. You'll see some discussion along these lines at #2250393: Reuse Paragraphs items + Give more power to end-user.
Comment #21
seanbJust to check:
If they have the same fields, why not create just 1 paragraph named 'Image' and use different display modes on it? That solves the problem if I understand you correctly?
If the paragraphs have different fields, then why give them the same name? This could be confusing for the end user imho?
Comment #22
jstoller@seanB: In my case the paragraphs bundles have slightly different fields. However, the two bundles would never appear as options in the same paragraphs field, so there's no real risk of user confusion. As far as the user's concerned, they're just adding an image to that section of the page. The options might be a little different depending on whether they're adding it to the main content, or to the sidebar, but they shouldn't have to care about that. All they care about is that they want to add an image.
Comment #23
jstoller@jeroen.b: Just a friendly request for comment, if you don't feel this is ready to commit.
Comment #24
jeroen.b commented@jstoller, sorry it took so long. Patch looks good to me.
Why did you switch around the edit/delete and fields/display links though?
Comment #25
jstoller@jeroen.b: I think I did that for consistency with other similar Drupal lists, like for nodes and beans. Here's an updated patch that moves "delete" to the end, after the fields/display links. That's how the node content type list does it.
Comment #26
miro_dietikerIMHO the image at #10 looks overloaded.
You repeat the label although it's the same.
I think we should be minimalistic and only list a label if it defines an override.
Also i like to point you to the D8 extend admin UI that tries to provide verbose information and still be clean in initial appearance. It add collapsibility on the description.

But most importantly, it also offers a JS based filter that also covers machine name and description.
I realise that by using Paragraphs for real rich content creation, you could end up with larger amounts of paragraph types.
Should we go that far?
Comment #27
jeroen.b commented@jstoller, thanks, that's great!
I agree with Miro that we should hide the override if it's the same as the label.
@Miro
I don't think we should go that far. There is way more information on the module page than on the Paragraphs overview. I think the paragraphs overview is still easy to go through even if you have 25 types. Else CTRL+F works fine too.
Comment #28
miro_dietikerYeah, i was just thinking into similar directions.
Fine with me if we remove the redundant clutter.
In D8 many cols are gone in favor of the operations button.
Another idea would be to follow more the bundle + field management table where the machine name is a separate column.
Also the redundancy of "Machine name:" and "Label:" adds clutter.
We could think of just removing these or at least "Machine name:".
Comment #29
jeroen.b commentedMaybe. But it'd want it to look like the Content Types overview. Which on D7 looks like:

On D8 it looks like this, so if we're going to port this, we probably should not directly port it but rather look at the look of the Content types page in D8.

Comment #30
jstollerHere's an updated patch on the latest dev. I now only show the label if it is different than the bundle name. As seen in the attached image, it is shown in brackets right after the bundle name, which I think removes some unnecessary clutter and gives it the prominence it needs.
Comment #31
jstollerComment #32
jstollerAny more issues with this one, or can we RTBC it?
Comment #33
Angel Blue01 commented@jstoller Might this feature be added to Paragraphs in the near future, or can the patch in #30 be applied safely to version 7.x-1.0-rc5 of Paragraphs?
Comment #34
jstoller@Angel Blue01: I have not yet tested this against the latest dev and have no control over when it is committed. If you could test it and report back, that would be fabulous. If there's a problem then I'll update the patch. If it still works, then maybe you could mark it RTBC and we can try to get the maintainer's attention again.
Comment #36
jstollerRerolled patch against latest dev.
Comment #37
ParulB commentedIt is working fine.
Comment #38
ParulB commentedComment #39
arx-e commentedI tried the patch in #36 against the latest dev 7.x-1.0-rc5+14-dev
It applies without any errors but it produces errors such as the following when editing fields settings in an content type that contains the paragraph:
Or these 2 when in Paragraph Bundles admin:
Comment #41
jstoller@arx-e, I've retested the patch and there doesn't appear to be any errors. My guess is that you didn't run the update script, so the label and description fields were missing from the database.
I've committed to the patch to dev and marking this fixed, but if anyone else is seeing errors, let me know.
Comment #43
karthi5053 commentedHi,
Facing this issue in Drupal 8.x.9.x as well. Im have a content type with 2 fields entity referenced to same paragraph type. In admin while content authoring its difficult to differentiate, since the field label are not displayed.
Please update if any solution available.