Allow to select a default paragraph type that will be shown for an empty field

Yeah, that would be a nice UX improvement!

Not sure if it is possible, but it would be a great UX improvement to be able to set a multiple-item default value, so that (for example) a standard "create page" form can be pre-populated with ready-to-edit paragraph:image and paragraph:text forms.

Added select options and raw in summary.

Stopped to work on this because the HEAD are failing.

The widget label and description are repeating and lacking and don't help users understand about its purpose.

Also can't see any test coverage.

BTW for more complex cases such as prepopulating multiple paragraphs, we will have a library and a template, see references.

Tried to add paragraph but not success. @yongt9412 should apply patch to debug.

Showing default paragraph type and wrote test coverage.
But still we need first to fix HEAD fails before this issue.

We need to careful: Changing the allowed paragraph type could cause this setting to be out of sync. How are we dealing with this situation?

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -4,7 +4,6 @@ namespace Drupal\paragraphs\Plugin\Field\FieldWidget;
-use Drupal\Core\Entity\Entity;

@@ -658,8 +678,29 @@ class InlineParagraphsWidget extends WidgetBase {
-

Unrelated change

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -112,6 +112,20 @@ class InlineParagraphsWidget extends WidgetBase {
+      '#description' => 'Default paragraph type '

Use $this->t()

Changing the allowed paragraph type could cause this setting to be out of sync. How are we dealing with this situation?

Had a discussion with @toncic, there are more options to fix this:
When trying to change allowed type (which is set as default)
1. Update the default settings and set default paragraph type to 'None'.
2. Warn the user that the paragraph type is set as default and to change it there first.

Fixed test fails and added check if type is allow before showing paragraph.

Fixing test failing and extract code for testing in new method in ParagrapsAddModesTest class.

Cleaning patch.

Looks good to me.

Ok. now we want to remove button if is single type allowed and remove description from summary if we don't have default_paragraph_type.
And of course test coverage.

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -675,6 +693,30 @@ class InlineParagraphsWidget extends WidgetBase {
   +    if ($max == 0 ) {
   ...
   +      if ($default_type !== '' && $this->isTypeAllowed($default_type)) {
   

   This logic should only be triggered for new host entities, not for updates.

   Make sure to test cover this, so also do an edit and verify no extra paragraph is added.

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1206,4 +1248,57 @@ class InlineParagraphsWidget extends WidgetBase {
   +  public function isTypeAllowed($default_type) {
   

   This should not be needed. The getDefaultParagraphTypeMachineName should already check for allowed ones and never return invalid values.

3. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1206,4 +1248,57 @@ class InlineParagraphsWidget extends WidgetBase {
   +  public function getDefaultParagraphTypeLabelName(){
   ...
   +  public function getDefaultParagraphTypeMachineName() {
   

   No public, protected if we need it for our widget only.

4. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1206,4 +1248,57 @@ class InlineParagraphsWidget extends WidgetBase {
   +    if ($this->getDefaultParagraphTypeMachineName() !== '') {
   

   We should avoid '' and instead refer to NULL for emptyness.

5. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1206,4 +1248,57 @@ class InlineParagraphsWidget extends WidgetBase {
   +      return key($allowed_types);
   

   So even if the selection is "- None -" we propose a default machine name...

There are some UX problems.

I first thought: Yeah, let's always add a default paragraph it only one type is selected and even remove the setting.
But for some optional rarely used paragraphs, this is bad UX. Also we have some other problem (see below).
So we could make auto-add a default setting. But if explicitly set to none, we need to respect that too.

Now the harder part:
If a paragraph is prepared and added by default and the user doesn't fill out any of the fields, we now still save it with empty values.
This is an unexpectedly complex problem. We would need to flag auto-added instances and check the visible fields for emptyness. If all are empty (and it has no children), we could skip creating it. But this check needs to be limited to the auto-added since other paragraphs could have no field at all. For some intentionally added paragraphs, this might not be true and all fields could be empty.
We can put this whole problem into a follow-up. :-)

Added items_count instead to check if is new host entity, but still not sure what we want to do with setting. I discussed shortly wit @Berdit and we should continue tomorrow. Test is still failing.

Yes, the special case for single type is tricky. Might be a good reason to keep that to the separate issue for this that was created for it. I can see that there might be a use case to not have a default even for single type use cases. But it prevents us from hiding the setting completely for that case and also means we either need to force users to explicitly select the default always (then we can drop the code for this completely but it is more work and gets us further away from the field_collection default behavior) or we need to be able to differentiate between "user didn't decide anything explicitly, so apply single-type default" and "user explicitly opts out of default type". So we need a _default and _none special options.

Best option might really be to drop that part of the logic here and discuss in #2829572: Allow default opt-out for single paragraph type.

5. The way it was implemented (didn't check last patch) was that we would default-select the type for single case and show that in the summary. and wouldn't show anything if none is selected for multi-type.

Now the harder part:
If a paragraph is prepared and added by default and the user doesn't fill out any of the fields, we now still save it with empty values.
This is an unexpectedly complex problem. We would need to flag auto-added instances and check the visible fields for emptyness. If all are empty (and it has no children), we could skip creating it. But this check needs to be limited to the auto-added since other paragraphs could have no field at all. For some intentionally added paragraphs, this might not be true and all fields could be empty.
We can put this whole problem into a follow-up. :-)

I don't think that this is a problem we need to solve. What we need to solve is to be able to expllicitly *remove* the default, so there is nothing shown, which I tested with @toncic and it doesn't work yet. This is very easy to solve on site building level. Make the field in your paragraph type required, then you force the user to decide between having a field and not, instead of saving something that is empty?

Added new function for testing that we can set default paragraph type to none. Test are failing because of limited number.

Fixed a lot of test failing, there is one more in ParagraphsFieldGroupTest function. Uploading patch that @yong9412 can test it localy.

I'm continue to write test coverage for other functionality.

Added test for testing remove default paragraph type.
Logic for single type is not good here, but we deal to discuss that in related issue Add default paragraph for single paragraph type.

No, we can discuss the single logic in the other issue.

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -112,6 +113,21 @@ class InlineParagraphsWidget extends WidgetBase {
   +//      '#default_value' => $this->getSetting('default_paragraph_type'),
   

   remove commented lines.

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -112,6 +113,21 @@ class InlineParagraphsWidget extends WidgetBase {
   +      '#description' => 'Default paragraph type '
   

   missing t() and skip it as it's repetitive.

3. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -675,6 +697,33 @@ class InlineParagraphsWidget extends WidgetBase {
   +    if ($max == 0 ) {
   ...
   +      if ($default_type) {
   

   Still only add a new paragraph when creating a new host entity. We never want to have them added when editing existing ones.

Any chance of this being backported to D7?

I don't think we will work on a D7, but I would assume that it shouldn't be too complicated to do.

Tagging, so we can keep the issue open after commit.

Implemented comm #38 and add test case for new host entity.

Committed with a bunch of clean-ups.

This patch is creating other issue - I have an optional paragraph with a single possible type.

Now, on the edit form - I see a new empty paragraph added, even so I've selected not to add a default one.

@@ -1216,6 +1263,41 @@ class InlineParagraphsWidget extends WidgetBase {
+    if (count($allowed_types) === 1) {
+      return key($allowed_types);
+    }

Issue lives here. This behavior is undesirable.