Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Abstract the code from block visibility for language check to be a condition plugin.
Eclipse
Parent Issue:
Comment | File | Size | Author |
---|---|---|---|
#23 | 1921550-23.patch | 7.9 KB | EclipseGc |
#23 | 1921550-interdiff.txt | 2.65 KB | EclipseGc |
#20 | 1921550-20.patch | 7.86 KB | EclipseGc |
#20 | 1921550-interdiff.txt | 926 bytes | EclipseGc |
#18 | 1921550-18.patch | 7.88 KB | EclipseGc |
Comments
Comment #1
EclipseGc CreditAttribution: EclipseGc commentedComment #2
larowlanSnagging this after clearing with EclipseGc on irc
Comment #3
larowlanFirst cut, needs more tests - will tackle those tomorrow.
Comment #4
larowlanSo this adds more unit tests and is ready for a serious look
Comment #5
podarok$langcodes_options looks like not previously defined
possibly we should...
all other looks good for me
+1RTBC
Comment #6
podaroklooking at the test
$default_language
never used hereLooks like it should be removed or used in tests )
Comment #7
larowlanlangcode_options is defined here
Comment #8
larowlanComment #9
larowlanbump
Comment #10
EclipseGc CreditAttribution: EclipseGc commented#7: condition-language-1921550.7.patch queued for re-testing.
Comment #12
EclipseGc CreditAttribution: EclipseGc commentedok, I didn't provide an interdiff on this just because of my workflow and I didn't think I'd need one. if that makes reviewing it easier, then I can do that, but I removed the language type stuff from the plugin because the plugin doesn't dictate what type of language it is, it just validates whether the language passed to it matches the configuration. So now there's a language context, and the implementation will have to inject the language that's relevant to the use case.
Eclipse
Comment #13
twistor CreditAttribution: twistor commentedCould this be handled cleaner with '#access' => language_multilingual()?
Why is building an options list done 2 different ways here? I love me some closures, but a foreach would be simpler.
I have to look at the condition implementation, but this seems to suggest that this plugin will always evaluate, even if it was never configured. Is that correct?
This should have been the name :)
Comment #14
EclipseGc CreditAttribution: EclipseGc commentedThere's enough stuff happening in the if statement that tests that that I'd prefer to not mess with that stuff outside the if in favor of an #access property. I typically prefer the #access property as well since we'd actually have the form elements there. Still you wouldn't want these form elements if you didn't have a multi-lingual site, so this is one of the few edge cases where I don't mind an if statement around my form elements.
Actually I deleted all the language type stuff and just missed this. Thanks for catching it.
Yes if you add this plugin and don't specify a limitation of a particular language(s) then we aren't going to deny access. You can of course deny access by negating the return.
Not sure what you were saying here unless you were calling out the capitalized TRUE, in which case, I fixed it in this patch.
Thanks for the review!
Eclipse
Comment #16
EclipseGc CreditAttribution: EclipseGc commentedmisnamed the interdiff so it failed.
Comment #17
Gábor HojtsyIs this only going to be used for blocks?
Is it commonplace / accepted now to use inline functions like this? I have not seen this much in Drupal core :)
The commas at the ends do not fit our code style AFAIS, we don't include them if the array is all in one line.
You can/should language_load('it') instead to avoid repeating properties from above.
interface language (vs language interface :D)
Also I don't see how is this different from checking the content language, since they are negotiated for the same value in this test. Merely changing the default language and reiniting the language manager will change both. So this is not really testing what happens if the interface language and the content language are different. That would need separate setup for them in the test instead of changing the default language and re-initing the manager.
Comment #18
EclipseGc CreditAttribution: EclipseGc commentedOK, changed everything asked for in #17 except the anonymous function. That is getting to be pretty common in a number of places in D8. Unless we really feel that it's detracting from this plugin, I'd prefer to just leave it since it works very nicely.
Eclipse
Comment #19
Gábor HojtsyLooks good. Only one note then.
Is this not shown to regular users on the UI? "Returns TRUE" sounds like the least useful text if this ever ends up on a front facing UI.
Comment #20
EclipseGc CreditAttribution: EclipseGc commentedok, trying to fix that too, how's this? (thanks tim.plunkett for the text, I was drawing a blank.)
Comment #21
Gábor HojtsyLooks good to me now. I cannot vouch for the correctness of the condition API use, but the language stuff looks good.
Comment #22
tim.plunkettShould be {@inheritdoc} now
I think this could use some more inline docs. The internal part of array_reduce, and both the if and else.
I'm pretty sure this is redundant, since both are wrapped in empty, you only need one.
Could just be:
return !empty($this->configuration['langcodes'][$language->langcode]);
Comment #23
EclipseGc CreditAttribution: EclipseGc commentedFair enough!
Eclipse
Comment #24
tim.plunkettThose comments really help, thanks!
Comment #25
alexpottCommitted 4e833c9 and pushed to 8.x. Thanks!
I think the conditions change notice might need an update...
Comment #26
larowlanUpdated change notice here http://drupal.org/node/1961370.
Comment #27
larowlanComment #28
larowlanComment #29
jibranRemoving tag.