🇺🇸United States @jumpsuitgreen

@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?