🇺🇸United States @jumpsuitgreen

@Wylbur, in addition to this change, we need to make the engine field available so users can switch between Playwright and Puppeteer.

@beccapossible we've been working away at this heavily the past couple months to finish up the new 2.0 release (been a long time coming). @Wylbur is giving a presentation on it this Friday. So the official release will happen this week.

@helianthropy, Thanks for posting that! A quick fix.

Patch #13 worked for me as well, both for editing and creating nodes.
Thanks!

@johnv, @Eric Heydrich, Here is the problem when using the office_hours field in a Paragraph entity. The JavaScript runs only once on document.ready. If the office_hours field is used on the node itself, the elements (add, remove, copy links) are part of the document when the script runs. When used in a Paragraph, this isn't necessarily the case. If the field referencing the Paragraph is configured to display closed on the Edit form, the elements aren't added to the HTML until the Paragraph is opened by the user for editing. But the JS script doesn't run again to pick up those elements which is why the links direct back to the home page.

As a temporary solution

You can configure the field referencing the Paragraph entity to display "Open" in the Edit mode (see screenshot). That way, the elements are part of the HTML when it loads and the JS can act on it. HOWEVER, if the Paragraph is collapsed and reopened again, the links won't work as intended and will route you to the home page instead.

I have tried the latest version of the module (1.17) using the field in a paragraph, and it is not working. I'll do a little digging to see if I can come up with a solution, but for now, using the field in paragraph doesn't work. The links all direct back to the home page.

@Michelle Thanks for posting. Your patch (#14) resolved our issue.
We have a D10 site with migrations using the URL source plugin to fetch XML file elements. Empty elements would trigger this error:
Migration failed with source plugin exception: Serialization of 'SimpleXMLElement' is not allowed in /var/www/web/core/modules/migrate/src/Row.php line 391 After applying patch #14, the migration runs smooth.

Disregard,
I figured it out. Somewhere in my process I failed to update the database drush updb after updating the module code.

The MailchimpAdminOauthSettingsForm::getMiddlewareUrl() method is retrieving the 'mailchimp.settings' configuration and returning the 'oauth_middleware_url' key. When I look at the config in the database and the exported configuration file, there isn't a key for 'oauth_middleware_url'.

The documentation doesn't detail how to set this value. Can you assist?

jumpsuitgreen → created an issue.

I had custom Webforms that weren't working on a site with the Antibot module enabled and protection enabled in the Webforms settings. Once I included {{ element.antibot_no_js }}{{ element.antibot_key }} in the form Twig template, everything worked fine. I only needed to include it once in the template and I did so at the very bottom with some of the other hidden fields like form_token and form_id. This bit of information is no where in the documentation unless I missed it somewhere. Preferably, the module page and the README file. Here is what my block looks like the the bottom of the webform Twig template:

            <div class="row">
                <div class="col-md-2 offset-md-1 offset-lg-2">
                    {{ element.elements.message }}
                    {{ element.elements.url_redirection }}
                    {{ element.form_build_id }}
                    {{ element.form_token }}
                    {{ element.form_id }}
                    {{ element.elements.actions }}
                    # Antibot keys to render.
                    {{ element.antibot_no_js }}
                    {{ element.antibot_key }}
                </div>
            </div>
        </div>
</form>

@larowlan
That makes sense. Here is what the code looks like now.

buildForm()
Your original code is there but now preceded by a language check of the media entity. If not the default language, it calls the parent form function and returns early.

submitForm()
Again, your original code is there but now preceded by a language check of the media entity which returns early if the media entity is not the default language.

Here are the local steps I went through for testing:

1. Created a new media item in default language
2. Created a translation without uploading a translated file
3. Deleted the translation
4. Created a new translation and uploaded/associated a translated file
5. Deleted the translation
6. Verified the associated, translated file was demoted to "Temporary" status
7. Created a new translation and uploaded/associated a translated file (again)
8. Deleted the media item entirely (default language and translation) including the associated file
9. Verified the default language file had been deleted
10. Verified the second translated file was also demoted to "Temporary" status

Let me know if there are any other manual tests I should run through.

@weseze,
In the submitForm() function, I reversed (again) the checks in the if() statement which puts them in their original order. I then wrapped the whole if() block inside a check of the media to ensure it only runs on the default language. When I test locally through the UI, I can

1. create a new media item in default language
2. add a translation of the media entity
3. delete the translation the media entity
4. create a new translation of the original media entity
5. upload a translated file to the translation
6. delete the translation which sets the translated file to temporary (since it is no longer is referenced)
7. delete the original media entity and associated file

The buildForm() function checks the media to determine if it is the default language and only adds the option to delete the associated file if isDefault() returns true. In short, deleting the associated file is only allowed if the media being deleted is the default language. Translations don't provide the option at all relying instead on trash collection to remove the file since it may be difficult to tell by the name if the file is a translated version or not.

Let me know if this helps, or if I'm still missing something.

Thanks, @weseze. Regarding the "…more difficult debug issues" are those caused by the reversing of the conditions in the if() statement of the submitForm()? The only thing I added happens in the buildForm() function of the MediaDeleteForm class—it checks if the media item being deleted is in the default language. If not, the option to delete the related file when deleting the translation is removed. It doesn't prevent the deletion (or creation) of the translated media item itself. If a translated file has been uploaded to the translated media item, its status will be marked as temporary if the translation referencing it has been deleted. Let me know and I'll rework.

Attached is the patch I'm using in production in case anyone needs it.

jumpsuitgreen → made their first commit to this issue’s fork.

@Murz,
I became really hopeful when I came across this patch. I have the need to send the dynamic value from one form field as a parameter in the autocomplete route for a second field. Your patch proposes to allow this, but what syntax do I need to make it work? Can you provide an example of the '#autocomplete_route_options' structure as well as the my_module.routing.yml file?