Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submitting Form Causes Error #675

Closed
lutronicdeveloper opened this issue Jun 5, 2019 · 3 comments
Closed

Submitting Form Causes Error #675

lutronicdeveloper opened this issue Jun 5, 2019 · 3 comments

Comments

@lutronicdeveloper
Copy link

I have a contact form built in a UserForm Element. Upon submitting ElementalContentControllerExtension throws a User Error. Element $id not found for this page. the issue only occurs when the form element inside a Elemental List block.

@lutronicdeveloper
Copy link
Author

closing

@jinjie
Copy link

jinjie commented Sep 18, 2019

Related to dnadesign/silverstripe-elemental-userforms#27

In ElementalContentControllerExtension.php

...
        foreach ($elementalAreaRelations as $elementalAreaRelation) {
            $element = $elementOwner->$elementalAreaRelation()->Elements()
                ->filter('ID', $id)
                ->First();

            if ($element) {
                return $element->getController();
            }
        }
...

Since $element is getting the elements directly from the owner, it actually doesn't look for more nested elements. Therefore, it can't find the element and returns the error.

Changing
$element = $elementOwner->$elementalAreaRelation()->Elements()
to
$element = BaseElement::get()
works...

@muskie9
Copy link

muskie9 commented Jan 31, 2020

I've tested the a number of the solutions for this and I think it comes down to the expectation of supporting nested elemental areas, or whether there is an expectation to support non-pages (DataObject's) with ElementalAreas in the getPage() method.

I was able to get submissions to track by updating the $elementalAreaRelations loop to the following:

        foreach ($elementalAreaRelations as $elementalAreaRelation) {
            $elements = $elementOwner->$elementalAreaRelation()->Elements();
            $element = $elements->filter('ID', $id)->first();

            if (!$element) {
                $embedded = $elements->filterByCallback(function ($element) {
                    return $element->hasMethod('getElementalRelations')
                        && $element->getElementalRelations() != false
                        && !empty($element->getElementalRelations());
                });

                foreach ($embedded as $embed) {
                    foreach ($embed->getElementalRelations() as $relation) {
                        $subElements = $embed->$relation()->Elements();

                        if ($element = $subElements->filter('ID', $id)->first()) {
                            return $element->getController();
                        }
                    }
                }
            }

            if ($element) {
                return $element->getController();
            }
        }

While the above may work in my use case (within the elemental list), there are other cases such as virtual elements that would likely follow a different logical pattern to detect and serve the proper controller. The other support area this likely doesn't cover from a structure standpoint is recursive lists or elemental areas deeper than two levels.

The Elemental List is currently one of the more flexible options from a layout perspective and the Virtual Element solves for having to re-create blocks over and over for content authors.

I guess my question to the maintainers is whether it's worth the time digging into this, or if there are other solutions planned for. I'm willing to put forward PR's as we do have quite a few use cases for both the list and virtual blocks.

Patches may span across a few modules, so I'm not sure how that would be handled from a release perspective and whether they would need to be coordinated or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants