Problem/Motivation
When on a translated page, hit edit for a block. You'll get to edit the original text, not the translated text. The same applies also to any other kinds of configuration override, whether from settings.php or domain based or group based or time of day based or whatever. Not sure how could settings tray conceptually be ready for this, given the config system itself does not know either which parts of which config belong to which override source. It is clear though that for multilingual sites, the settings tray does not deliver on its promise and does not let you edit what you see (neither does it give you a way to find out where to edit that).
Screenshot from a site installed in English with https://simplytest.me/project/multilingual_demo/8.x-2.0
Proposed resolution
Don't know.
Remaining tasks
N/A
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Comment | File | Size | Author |
---|---|---|---|
#36 | settings_tray-2815709-36.patch | 10.29 KB | yogeshmpawar |
Comments
Comment #2
Gábor HojtsyComment #3
Gábor HojtsyComment #4
Gábor HojtsyComment #5
Gábor HojtsyComment #6
dawehnerThat sounds at least major for me.
Comment #7
Gábor HojtsyComment #9
tedbowOk. Here is rough patch that tries to solve this for translations:
Here is what it does so far:
Here a couple problems.
Some thoughts
Screenshots
Comment #10
Wim LeersI think you should make the current translation editable right away, otherwise the point of Outside In is mostly lost for all multilingual sites, which is a large fraction of Drupal sites…
But it may still be valuable to have some UI to link to the other translations. Just make the current translation immediately editable.
However…
I have an idea. To have config overrides, you need a
\Drupal\Core\Config\ConfigFactoryOverrideInterface
service that has aconfig.factory.override
tag. Therefore we could solve this problem as follows:outside_in
should add a container compiler pass that runs late.config.factory.override
-tagged service.outside_in
module can then check that that container parameter has only one entry:language.config_factory_override
. If that's the case, we can make multilingual work just fine.::loadOverrides()
on each of those config overrider services with the config data for the object that the user is trying to edit. If the empty array is returned, Outside In knows that this config override event subscriber is not overriding this, and hence it's safe for the Outside In module to offer its Outside In experience.Comment #11
Gábor HojtsyYeah, imagine you have organic groups (overrides per group for your block) and languages (overrides per language for your block). Linking to a different language may or may not have a translation but may still be different from the global config for the block due to the organic group override.
Comment #12
Wim LeersYep. But config translation is roughly used by >=50% of D8 sites. Organic Groups/Domain/… only on a single-digit percentage. Therefore, if Outside In could just support Config Translation, then it'd be usable on >=90% of D8 sites. So that makes this worthwhile IMO. I think the outline I sketched in #10 suggests it is feasible.
Comment #13
tedbowComment #14
Wim LeersI think
is kind of underselling it, no?I'd think incompatibility with Config Translation makes it "Outside In-critical"?
Comment #15
tedbowre @wim leers in #10
This patch is try at that.
Here is short video that shows the flow described below https://youtu.be/z3t-fBKdUaY
Here is block with current translation in effect.
We looking at example.com/es. There is spanish override for this block.
At the top of the form we embed the Config Translation for the language that is being used. This will only show if the block has override for the current language.
** this form won't actually work now but if we decide this is the way to go we can fix that
At the bottom is a closed fieldset "Other Translations".
When open it lists all other translation except the current override.
Clicking any of the links here will open up the form in the tray.
If we look at the same block but now but in the default language, English
We just see "Translation" fieldset collapsed at the bottom
Opening up shows all possible translations
Comment #16
tedbowWhoops forgot to attach the patch.
I think a big part of the issue is usability. Even if we can figure out how to surface all the overridden config if the user is thoroughly confused which I think could happen it really is not solving the problem.
I would say yes. Getting to work with config overrides in general is longer term goal.
Comment #18
Wim Leers#15 Nice! I think that works. Because there's basically nothing to configure for the Search block, I was fairly confused by what I saw in the video, simply because the majority of the UI elements were not for configuring the Search block, but for its translations. But I think it'll be clearer for e.g. the Menu block.
#16
Good point!
Comment #19
Gábor HojtsyI believe the settings tray is supposed to let you edit things with some more complexity, let's say some pulled-out pieces of views. Grabbing the config translation form does not work in that complexity that also needs fully custom forms for this case. (A views config translation form is huge). Even for the simple search block case, you get a lot of cruft in the translation form, eg. the non-editable original title that is there for the translation use case (and if the viewport allows is formatted normally in a separate column). It also let's you edit the original text here, which is not true for any other thing in Drupal. What else in Drupal core lets you edit multiple variants of a thing at once? OTOH the translation would not have features like a toggle for displaying the title, so I assume that is why both forms are displayed.
Anyway, overall I think wider feedback on this would be essential rather than trying to figure out what is the primary target to shoot for between the three Acquians of us Wim Leers, Ted Bowman and myself. Also even if that decision lands at translations only, it would need a more serious look at how does that look like, how would editing some of the config details that are not translations intermix with the things that are translations, etc. Also if there are more overrides that are not translations, this would still present you an editing UI that looks like you are editing something that is not what you see even with translation support, and there was/is no solution to let you know in that case what is the "error".
I am more concerned of a half baked implementation now than missing this feature initially. Drupal 8 can introduce new features but also needs to be backwards compatible with what has been released as stable/beta/rc.
Comment #21
tedbowChanging to new settings_tray.module component. @drpal thanks for script help! :)
Comment #22
tedbowNeeds reroll at least for changes in #2803375: Rename Outside-in module to "Settings Tray" for real
Comment #23
jofitz CreditAttribution: jofitz at ComputerMinds commentedRe-rolled.
Comment #24
jofitz CreditAttribution: jofitz at ComputerMinds commentedRemove redundant code.
Comment #25
jofitz CreditAttribution: jofitz at ComputerMinds commentedCorrections to patch in #24.
Comment #29
jofitz CreditAttribution: jofitz at ComputerMinds commentedComment #31
tedbow@Jo Fitzgerald thanks for these patches.
Here is patch that completes the reroll against 8.5.x
Comment #33
yogeshmpawarComment #34
yogeshmpawarAdded patch for 8.4.x branch because previous patch failed to apply.
Comment #36
yogeshmpawarAdded updated patch because previous patch having a syntax error.
Comment #37
xjmOuchy, this is probably a must-have.
Comment #38
tedbow@Yogesh Pawar thanks for the patches. but first we need to work on the 8.5.x patch and then after that is committed we will work on back porting to 8.4.x(if applicable)
@xjm ok. will work on it.
I chatted with @xjm and she said first pass for this issue may be:
This maybe should be broken out into a separate issue with this issue remaining to determine if we can provide another solution that allows showing the form.
Comment #39
tedbow@xjm I realize there was 1 key point I forgot to mention when we chatted about the issue.
I created #2919373: Prevent Settings Tray functionality for blocks that have configuration overrides but
In #10 @Wim Leers explained how it is possible to determine which modules provide configuration overrides. His suggestion was if the only language overrides then handle that.
UPDATE: chatted with @xjm again, she thinks #2919373: Prevent Settings Tray functionality for blocks that have configuration overrides is the way to go first then maybe look at the language only situation
Comment #40
Wim Leers#39 says #2919373: Prevent Settings Tray functionality for blocks that have configuration overrides should happen first, then this should happen. Updating issue status to reflect that.
Comment #42
tedbow#2919373: Prevent Settings Tray functionality for blocks that have configuration overrides was fixed!
So now back to the broader issue.
As part of #2919373 #2923004: Add method to check if any overrides are applied to \Drupal\Core\Config\Config was fixed which added
\Drupal\Core\Config\Config::hasOverrides()
Although
::hasOverrides()
was good enough to prevent showing the "Quick edit" links for blocks where they have config overrides and to not show related config form elements such as menu and site name when that configuration has overrides.But for this issue I don't think
::hasOverrides()
is enough. For instance if a block label is overridden because ofconfig_translation
we don't have good way to tell if the block label is overridden also by another config override for instance by settings.php. This is especially complicated because the other configuration could actually have same value for label .Originally in #2923004
getOverrides()
which would actually returns the actual overrides but it wasn't completely clear how that would work.but we should probably open up a follow up to create
getOverrides()
or something like itComment #43
andypost