Problem/Motivation
We have something like 10 content types and ~150 other bundles. Around 120 of the entity/bundle from the whole list are translated.
Once we are at that point the page for management what content gets translated located on admin/config/regional/content-language
gets progressively slower current form submission is processed in 50-60 seconds (tracking by browser response time).
Proposed resolution
I think a refactoring is needed to have this single page UI separated to a multi-page solution.
Page 1 - have the content types enabled / disabled with links for the enabled ones to page 2.
Page 2 - have the list of bundles of the entity type just listed on a dedicated page with action links for each.
Page 3 - have a dedicated page to handle single entity/bundle multilingual settings in a small form.
Maybe change the link from field UI that suggest enabling translation to the correct bundle management page (3).
Remaining tasks
Discussion, direction, patch.
User interface changes
TBD. Depends based on the discussion.
API changes
None expected - only UI changes...
Maybe add couple of new forms.
Data model changes
None expected - same config entities.
Release notes snippet
TBD.
Comment | File | Size | Author |
---|---|---|---|
#4 | 3027607-timeout.patch | 2.68 KB | larowlan |
Comments
Comment #2
ndobromirov CreditAttribution: ndobromirov at FFW commentedComment #3
BerdirI agree it's too big, while that's a huge amount of bundles, it already gets very slow with a lot less.
The problem is that it's not just one form. It's a pretty simple form defined by language module that just has a bunch of settings per bundle and then content_translation comes and alters the hell out of it. So the form structure kind of *is* the API between those two modules. And I know that e.g. paragraphs and possibly other modules then also alter it. So not quite sure how to untangle it..
Per bundle enable/disable is already possible for common bundles in their settings page, maybe we could expand on that and add a local task similar to field UI that allows to manage per-field translation settings?
Comment #4
larowlanWhat if we use a batch callback instead?
Comment #6
BerdirInteresting idea, we can try that, but the slow part is in content_translation.module in submit function, that's what we'd need to batch :)
Comment #7
larowlanAh, so adding a
batch_set
call incontent_translation_form_language_content_settings_submit
instead..gotchaComment #8
ndobromirov CreditAttribution: ndobromirov at FFW commentedYeah but this is still breaking the site building UX...
Imagine the case - I want to add couple of new bundles and enable translations on them...
In that case I need to go in there add 1 bundle and go in translation UI enable and configure it there - wait 2 minutes for batch to finish.
Add the other one and wait 2 minutes for batch to finish.
In my proposal (even if it's a much more comples implementation) it will be go and configure the translation for the 2 exact bundles and save 2 small forms for each (way under a minute worth of time)
This was my assumption in the proposal. I get the idea that a batch operation will resolve the time-outs, but they will not resolve the wait time :( that is an awful UX in general.
Comment #9
BerdirSure, having what you suggest would be better for many cases, but it would likely also not replace this but just add another per-bundle form. It's also likely more work to get done.
The second thing to investigate would be to make sure that we only save things if they actually changed. If we do that, it shouldn't matter *a lot* that you have 100 bundles, if you only 10 fields or 3 bundles changed.
Comment #10
ndobromirov CreditAttribution: ndobromirov at FFW commentedUnless you hit the PHP's limit on max_input_vars at some point that defaults to 1000 and then you can not submit the form at all...
Maybe change the UI to have per-bundle form, so not a single submit in the bottom but a submit per bundle.Not liking the idea - the for is still going to be too big to navigate sanely in it.
Comment #11
ndobromirov CreditAttribution: ndobromirov at FFW commentedBig +1 :).
I like this one a lot, so no longer will be needed to leave the bundle settings UI. This can be an addition over the currently slow one that can take over it's role in near future.
Comment #12
Ghost of Drupal PastFor other people running into this issue, I posted a quick and dirty workaround module to https://gist.github.com/chx/d63ed7405b47255a0d4481d60dd33641 don't forget to weigh it to 11, at least here content translation is 10. It's quick and very dirty but it does solve our problem where we already hit the input vars limit.
Comment #13
Wim LeersHah!
@Charlie ChX Negyesi had opened #3076506: The custom language settings form does not scale, to which I responded at #3076506-2: The custom language settings form does not scale:
… which is pretty much exactly what the issue summary here is proposing! 🥳
Comment #14
Wim LeersComment #15
Berdir> I suspect this form was designed in Drupal 6 times, when having so many entity types and/or bundles was unheard of.
Entity types, Drupal 6? :)
No, this is all new in D8, nothing like it existed before. *but* as I commented above, the complexity comes from the fact that it is split in two modules. The language module provides *only* the entity type + bundle-level setting, that scales fairly well. Only when you also enable content_translation then you get the vast list of per-field-per-bundle checkboxes. Those two things were added at different times, and both pretty early in the D8 lifecycle.
Comment #19
joachim CreditAttribution: joachim at Factorial GmbH commentedIf #3076506: The custom language settings form does not scale is closed as a duplicate of this one, then this one needs rescoping to be about UX as well as performance.
Comment #20
joachim CreditAttribution: joachim at Factorial GmbH commentedI think the form needs breaking up, as mentioned above. Which is going to be complicated, as also mentioned.
But a really quick fix that would go some way towards making it more usable in the meantime would be to change the container elements for each entity type to collapsed details elements. I'll file a child issue for that.