Invalid language parameter is treated as all languages #1246
Labels
🤩-release-highlight
Exciting change that should be highlighted in the release notes and celebrated by SPE fans.
🐞 bug
Oops! Sorry for the inconvenience.
impact-behaviour-change
Nothing to be worried about. Now even better than before!
Milestone
Expected Behavior
If I load item(s) via
Get-Item
,Get-ChildItem
etc. and accidentally provide an incorrect language parameter, I'd like SPE to give an error message and/or not return any results. Maybe the current behavior is by design, and I understand if this fix/change isn't worth doing. If an invalid language is provided to the-Language
parameter, it is silently accepted and is treated as*
(any language).Actual Behavior
If I provide an invalid language, it is treated as
*
or all languages. So if I want to perform an action on a set of items on a specific language layer and mistype the language parameter, the action will be performed on all languages. So basically, this problem only occurs when there is a typo/error in the provided script, but the consequence can be quite sever.Steps to Reproduce the Problem
I've tested this on 6.0 and 6.1.1, but haven't yet been able to test this on the latest version.
To reproduce the problem, an item with more than one language layer is required.
Get-Item -Path 'master:/sitecore/content/home -Language 'some-typo' | Format-Table
will return all language versions of that item, basically the same as providing-Language *
. I'd expect zero versions to be returned and/or that it gives an error. Right now I've tested this onGet-Item
andGet-ChildItem
, but briefly browsing the SPE code I assume this applies to more cmdlets.Browsing the code, it seems like the handling of
LanguageWildcardPatterns
inBaseItemCommand.cs
could be the source of this, but I may be completely wrong. A wild guess of the root cause could be theWildcardUtils.GetWildcardPattern
returning*
if name is null or empty. Is it as simple as name becoming null/empty if the input value cannot be parsed into aCultureInfo
object?Sample tests:
Get-Item ... -Language en,*
returns "en" plus all languages, so the "en" version is listed twice. Makes sense.Get-Item ... -Language en,en-US,*
returns "en", "en-US" plus all languages, so the "en" and "en-US" versions are listed twice. Basically the same as above. Makes sense.Get-Item ... -Language foo
where foo is not a registered culture, returns the same as *. This feels scary.Get-Item ... -Language en,foo
where foo is not a registered culture, returns exactly the same as en,*. This feels scary.Get-Item ...
without the language parameter returns data on the context language as expected.So basically, when a provided language string cannot be parsed into a culture, it treats it as a wildcard.
The text was updated successfully, but these errors were encountered: