Content forms are painfully slow if multiple sub-modules are enabled

This my variation for optimize form

Hi,

I experienced issues with cache / key-value keys.
I've added more verbose key-value store key, and also entity cache metadata to form.
I also fix a typo (mata tags).

I updated issue fork : https://git.drupalcode.org/issue/metatag-3057523, patch attached.

Dialog widget is a really cool feature indeed! Thanks @batkor

Fix issue with entities languages

@batkor did a great job here, thanks a lot!

But there is an issue: if you open two tabs in browser with different node's edit form and try to edit the metatags from the first tab and then edit metatagds on the second tab, the values in the second tab's modal will be the same as the first one.

This patch fixes this issue.

Hello guys,

Sorry I'm not agree with canvas solution, improve content first load but later if you have a big bunch of metatags groups the performance is very poor, on the other hand the async solution only open the metatag group that you need, I think that solution is better and UX/UI as well.

I attach a patch working with nesting robots following #95 solving a php warning when the user doesn't have permission to access metatag fields.

The last submitted patch, 103: 3057523-103-metatag-async-click-trigger-accessibility.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Sadly I had to remove this patch because it lead to losing all personalization of metatags.
First I saved a custom metatag title for the page and I was able to see the changes. Went back to the edit form, changed nothing and hit save. Got the following error and all the metatags are back to default.

Notice: unserialize(): Error at offset 0 of 40 bytes in Drupal\metatag\Plugin\Field\FieldWidget\MetatagAsync->extractFormValues() (line 209 of modules/contrib/metatag/src/Plugin/Field/FieldWidget/MetatagAsync.php).

Drupal\metatag\Plugin\Field\FieldWidget\MetatagAsync->extractFormValues(Object, Array, Object) (Line: 237)
Drupal\Core\Entity\Entity\EntityFormDisplay->extractFormValues(Object, Array, Object) (Line: 334)
Drupal\Core\Entity\ContentEntityForm->copyFormValuesToEntity(Object, Array, Object) (Line: 301)
Drupal\Core\Entity\EntityForm->buildEntity(Array, Object) (Line: 155)
Drupal\Core\Entity\ContentEntityForm->buildEntity(Array, Object) (Line: 186)
Drupal\Core\Entity\ContentEntityForm->validateForm(Array, Object)

$items->getString() on line 109 returned a json string with the personalized values instead of a serialized string.

This might be a bad interaction between the modules I use, I just want folks using this patch (I used 85 and 103) to perform thorough testing before deploying it anywhere.

With the schema modules enabled, every ajax request has around 800 items added to the payload. Removing metatags completely from display greatly improved our relationship with the content team. One of them even asked me out on a date.

For anyone reading this, our workaround was to have the metatag fields accessible only via a specific content form mode [called seo].

Editing meta tags is now done done via a separate local task that uses the seo form mode. This was enabled using https://www.drupal.org/project/form_mode_control →

@hdotnet: That'd make a good alternative UI, would you mind adding some details to this page on the setup?

https://www.drupal.org/docs/contributed-modules/metatag/frequently-asked... →

Thank you.

Yes, I will... this solution is still being worked on, once I have it in the wild+tested I'll give all the info. Implementing the form display can all be done in the UI but it still needs a custom module to add to local tasks.

Off topic: Google doesn't care about your FAQ/HowTo anymore

Updated #101 with #102 comments + usage of metatag_data_decode / encode (to allow v1 / v2 compatibility).

Hello,

I'm used Metatag with #103 → and client is happy because your site is quick with Paragraphs and Media Library and Schema.org Metatag. Otherwise, without the patch, his site is very, very slow.

@DamienMcKenna

I've updated the page. Kindly review.

https://www.drupal.org/docs/contributed-modules/metatag/frequently-asked-questions-problems/howto-alternative-ui-for-editing-seo-details →

Sorry it took such a shockingly long time.

You might consider adding an entry to the new page from here: Performance problems on entity (node) edit forms →

Here a problem with moderation state module:
1. Create node - set up some metatags, set "published" to node, save.
2. Edit node - update metatags, set "draft" to node, save.
3. Edit node again - metatags form loads default values from published version of node, but not from the last revision.

Re-roll patch with fixes, also create MR to 8.x-1.x.
It also needed to update issue fork and change target branch to 2.0.x

#103 Fixing/suppressing

unserialize() is insecure unless allowed classes are limited. Use a safe format like JSON or use the allowed_classes option.PHPCS(DrupalPractice.FunctionCalls.InsecureUnserialize.InsecureUnserialize)

Notice: unserialize(): Error at offset 0 of 207 bytes in Drupal\metatag\Plugin\Field\FieldWidget\MetatagAsync->extractFormValues() (line 209 of modules/contrib/metatag/src/Plugin/Field/FieldWidget/MetatagAsync.php).
Drupal\metatag\Plugin\Field\FieldWidget\MetatagAsync->extractFormValues(Object, Array, Object) (Line: 237)

Created a new MR over 2.1x-dev

Please work over the MR to follow the changes.

Before continuing we should choose the best approximation or integrate and document all of them.

Reading the comments we saw multiple options:

The first one was introduced by @Joyakas, extending the metatag_firehose widget to provide an async way to load the metatags, and @chr.fritsch mentioned on comment #3057523-70: Content forms are painfully slow if multiple sub-modules are enabled → the module metatag_async_widget to use the widget https://www.drupal.org/project/metatag_async_widget →

Batkor introduce the widget "metatag_dialog" on comment #3057523-98: Content forms are painfully slow if multiple sub-modules are enabled →

Comment from @jansete about the dialog widget #3057523-103: Content forms are painfully slow if multiple sub-modules are enabled → :

Hello guys,

Sorry I'm not agree with canvas solution, improve content first load but later if you have a big bunch of metatags groups the performance is very poor, on the other hand the async solution only open the metatag group that you need, I think that solution is better and UX/UI as well.

I attach a patch working with nesting robots following #95 solving a php warning when the user doesn't have permission to access metatag fields.

@hdotnet proposes to use a different form display because Schema have too many items to load them using Ajax #3057523-106: Content forms are painfully slow if multiple sub-modules are enabled →

Documentation:

https://www.drupal.org/docs/contributed-modules/metatag/frequently-asked... →

With the schema modules enabled, every ajax request has around 800 items added to the payload. Removing metatags completely from display greatly improved our relationship with the content team. One of them even asked me out on a date.

For anyone reading this, our workaround was to have the metatag fields accessible only via a specific content form display mode [called seo].

Editing meta tags is now done via a separate local task that uses the seo form display mode. This was enabled using https://www.drupal.org/project/form_mode_control →

Our conclusions

The metatag_async could help with the performance issue, but has its limitations with too many items, for example, using Schema.
The dialog widget could also affect performance if there are too many groups.

Maybe using a different display could be the best approach as it does not affect the content editing, and does not need to make "magic" with the widget form.