Add AJAX support to Paragraphs

Can you please elaborate with any logging errors for this issue ?
Copy and paste the error here please

Sure!
Also please try to download the last dev release for testing because the beta 6 has been known will plenty issues already fixed in the latest dev release.

I encountered the same problem. There are no errors in logs, but module does not works with paragraphs: just nothing happens and fields are independent. I dig into this problem and made some changes:
1. First of all remove usage on 'Entity' class from .module file, because this class is deprecated and condition

if ($entity instanceof Entity) {

will never fires, because this class is not used now. (Proof)
And this was the reason why there are no errors in log.
2. When we deal with inline forms, we should check if field has parents or not. And we should use field definition from entity associated with subform.
3. When update selects, we should remember that ID's could be changed by AJAX, so we should get elements by 'data-drupal-selector' selector attribute instead of 'id'.
4. Also when field is multiple, but select is empty, it will be rendered as single-value select, so we should change this in according to field cardinality settings. This is the reason why I changed 'UpdateOptionsCommand' class.

And here is a patch, that allows to work with paragraphs. May this needs some work to work with another nested entities, but now it works well with Paragraphs.

This patch worked perfectly for me! Thanks @gun_dose.

Sorry, I found one bug in my patch - it works good for new entities, but when edit existing entity, it causes validation error for dependent field in paragraph. I fixed it and here is new patch.

The patch in #7 works great!

Thanks @gun_dose.

Thanks for working on this. Here's a code review:

+++ b/src/Plugin/EntityReferenceSelection/BusinessRulesViewsSelection.php
@@ -159,6 +160,27 @@ class BusinessRulesViewsSelection extends PluginBase implements SelectionInterfa
+    // Inline form marker.
+    $inline_form = FALSE;
+    if (isset($trigger_field['#parents'])) {
+      $parents = $trigger_field['#parents'];
+      if (in_array('subform', $parents, TRUE)) {
+        $parent_field_key = array_shift($parents);
+        /** @var \Drupal\field\Entity\FieldConfig $definition */
+        $definition = $entity->getFieldDefinition($parent_field_key);
+        if ($definition->getType() === 'entity_reference_revisions') {
+          $inline_form = TRUE;
+          $delta = array_shift($parents);
+          $widget = $form[$parent_field_key]['widget'][$delta];
+          if (isset($widget['#paragraph_type'])) {
+            // TODO: find way to extract real paragraph to avoid of empty paragraph creation.
+            $entity = \Drupal::entityTypeManager()->getStorage('paragraph')->create([
+              'type' => $widget['#paragraph_type'],
+            ]);
+          }
+        }
+      }
+    }

There's a lot of nesting here. Can we maybe move this code into one or more (protected?) methods with descriptive names? It would help make the code cleaner as it's unreadable currently.

+++ b/src/Plugin/EntityReferenceSelection/BusinessRulesViewsSelection.php
@@ -214,14 +236,26 @@ class BusinessRulesViewsSelection extends PluginBase implements SelectionInterfa
+
+

Extra line of whitespace here.

+++ b/src/Plugin/EntityReferenceSelection/BusinessRulesViewsSelection.php
@@ -214,14 +236,26 @@ class BusinessRulesViewsSelection extends PluginBase implements SelectionInterfa
+        // Check if field is miltiple or not.

Typo in "miltiple".

+++ b/src/Plugin/EntityReferenceSelection/BusinessRulesViewsSelection.php
@@ -510,6 +544,16 @@ class BusinessRulesViewsSelection extends PluginBase implements SelectionInterfa
+      // Try to extract values from nested entities.
+      if (isset($handler_settings['entity']) && $handler_settings['entity'] instanceof EntityInterface) {
+        // Handle paragraphs.
+        if ($handler_settings['entity']->getEntityTypeId() === 'paragraph') {
+          $value = $handler_settings['entity']->get($field)->getString();
+        }
+        // Here may be processors for another entity types.
+      }

I think it would be best to create a new method for this stuff so the current one doesn't get too big. Maybe something like extractValueFromNestedEntities()?

patch in 7 did not apply to beta8 or dev. reroll

Patch 10 does not work for nested paragraphs. This patch fixes that problem.

Please include the missing interdiff. Thanks.

Patch #11 is only kinda working for me (I am not sure if I am doing anything correctly..)
I am using beta10 of bussiness_rules and applying the patch via composer.json is not working. (Error says 'cannot apply patch [...]')
When I try applying it with phpStorm I notice that it is not able to process line 116 from the patch ($subform = $form;).
I apply every other block fine and add $subform = $form; to the file manually, skip the block and everything works fine.
Also I am not sure on how to use the interdiff – Maybe that is what I am doing wrong?

Tried to add the patch to composer.json like so like all my patches that work fine:

"drupal/business_rules": {
      "Bussines Rules Paragraphs Ajax Fix": "patches/paragraphs-3040253-11.patch"
}

Patch rerolled for beta10. Also linked to Multi-valued dependent child fields are not saved since that requires this patch.

Thanks for the patch, it also fixes problem with not working dependent fields in Inline Entity Form widgets, issue about this is #2992273: Dependent fields not working in Inline Entity Forms?

As previous applied patch was failed to apply. Applying new updated patch.

I can confirm #21 solves a lot of 'ajax hassle' with this module. Before the patch i could not open forms in a modal (ajax would not work and javascript would throw an error).

After patch it works.

Thanks a lot!

New features go into HEAD, and can then be backported if there's interest.

And please don't forget about interdiffs.

Hi colan,
Attaching interdiff from #23 to #26 and also ported patch #26 to 2.0.
Please review.

If folks are interested in fixing tests (see the test results "Waiting for branch to pass" above), which would help with moving this issue along, please help with #3187013: Error: Call to a member function prepare() on null after updating to Drupal 9.1.0 / PHP 7.4.11.

Updated the issue summary to conform to the issue template; and added steps to reproduce, i.e.: a manual test case.

Note that when I perform the manual test case after applying the patch in #29, an AJAX spinner appears after changing the value of paratype1_termfield1, but paratype1_user1 remains empty, so I'm marking this as "Needs work" - but feel free to disagree if the manual test case doesn't match yours (I based my manual test case on my client site's desired behavior, but it may be more complex than it needs to be).

Ah! I figured out what was wrong by looking at the patch in #11... at some point, the line in \Drupal\business_rules\Plugin\EntityReferenceSelection\BusinessRulesViewsSelection::updateDependentField to set $subform went missing.

Here's a patch; reviews welcome.

Here's an initial attempt at codifying the test case in the issue summary into a FunctionalJavascript test. It was failing to find the values in the target field on my local for some reason - I suspect I'm not $page->waitFor()ing properly - but I'll have to figure that out on Monday.

***

On a related note, I found FunctionalJavascript tests to be failing with a PHP Fatal error: Uncaught PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal8.testNNNNNNNNkey_value_expire' doesn't exist

My gut says BusinessRulesProcessor::__destruct() runs after PHPUnit has deleted the table. Commenting out the line that tries to modify key_value_expire fixes the issue...

(EDIT: a code snippet used to be here, but was found to be a Really Bad Idea in #3187013-17: Error: Call to a member function prepare() on null after updating to Drupal 9.1.0 / PHP 7.4.11 so I've removed the code snippet for safety!)

... going to have to figure that one out on Monday too (and probably file another ticket to fix). The question is, why does that line exist and is it safe to delete? i.e.: will removing it cause key_value_expire to grow without constraints, like #2931611-11: Honeypot key value entries never expire (effectively)? 😱

Okay; here's a patch with a passing test (once $keyvalue->deleteAll(); is deleted/commented from src/Util/BusinessRulesProcessor.php::__destruct() - going to work on that next).

Several things were wrong; mainly that I was creating users and trying to assign values for the wrong field name (field_user_term) due to a typo when I originally captured the configuration for the test module. I also switched to using $this->assertSession()->assertWaitOnAjaxRequest(); instead of my own waitFor() logic (which was hard to get correct). And I captured the user's form display and modified the form display for the node type to make it easier when you install the test module for manual testing.

Reviews welcome.

Note that #3133687: Wrap keyvalue delete in BusinessRulesProcessor destruct includes a similar test; if that gets merged first, we should probably update this patch so the test itself and the test module says, essentially, "go look over there for a similar test that doesn't involve paragraphs" and vice-versa.

It was merged; so here's an updated patch.

The interdiff in the last comment got mangled because I hadn't rebased my old branch; sorry about that....

Turns out I also need to tell Testbot to install the paragraphs module in the test environment so it is ready for the tests that involve it.

Ah, yes, I'd forgotten about this... test_dependencies cannot be added in a patch...

From the documentation (emphasis mine)...

test_dependencies: a list of other modules (in the same format as dependencies) that are needed to run certain automated tests for your module on Drupal's automated test runner ("DrupalCI"), but not needed as module dependencies in general (or that are in development as module dependencies but not finalized yet). Note that you need to have the test_dependencies change committed to your Git repository before you try to run a test that depends on it – you cannot just put the info.yml change into the same patch as the new test. [...]

... so I daresay this is still cool, as it passes locally for me.

Marking as fixed as per @colan's commit.

This current topic is about the parent field inside the same paragraph with the dynamically dependent child field.

I am very interested to have the parent field outside the paragraph - directly inside a node - and the dynamically dependent child field to be inside the paragraph, together with other normal fields.

Any idea on how this scenario can be solved? Using what other modules? Thank you.