I'm sure this is easy and I'm just missing the point.
I have rules that are simple...
drupal:path -> foo/bar = my_theme_1
drupal:path -> foo/bar% = my_theme_2
But my site has multiple languages - I have pages at de/foo/bar and fr/foo/bar. They don't match and fire off the right rules. I tried...
drupal:path -> %foo/bar = my_theme_1
drupal:path -> %foo/bar% = my_theme_2
But that leads to matches that I don't want. I've read over the documentation as best I can and I still do not understand the use of drupal:path:wildcard for regex expressions so I can just do...
drupal:path:wildcard -> /^(.*?)foo\/bar$/ = my_theme_1
drupal:path:wildcard -> /^(.*?)foo\/bar(.*?)$/ = my_theme_2
...or something like that. What am I not understanding...?
Comment | File | Size | Author |
---|---|---|---|
#5 | 1394356.patch | 2.74 KB | mkalkbrenner |
Comments
Comment #1
mkalkbrennerI know that drupal:path and drupal:path:wildcard stuff is hard to understand. But there're multiple mistakes in your examples.
First "drupal:path = foo/bar% >>> my_theme_2" is not a valid rule. Path placeholders (aka wildcards) could only be used as complete part of a path like "foo/bar/%".
Second "drupal:path = foo/bar/% >>> my_theme_2" could never be reached because everything that matches this rule also matches "drupal:path = foo/bar >>> my_theme_1". You have to exchange both rules.
That's all described in the "properties explained" documentation for drupal:path.
"drupal:path = %foo/bar >>> my_theme_1" declares a wildcard named "foo" and matches "ANYTHING_ALPHANUMMERIC/bar". Wildcards could be accessed later in the rule chain using "drupal:path:wildcard foo = SOMETHING >>> another_theme".
Regular expressions have nothing to do with drupal:path:wildcard. They could be used for nearly any property and are activated using the "~" operator. See the "Operators explained" section of the documentation.
I recommend that you activate the ThemeKey Debug module and set "Trace rule switching" to see what's going on.
Now the last part. I never tested ThemeKey with language prefix paths. That's an interesting point. I guess that the prefix gets removed for the rule check. (I have to verify that later.) If this is the case you can cascade rules:
Comment #2
jschrab CreditAttribution: jschrab commentedI suspect language prefixes are NOT stripped out. As a workaround, I created about 3 times as many rules as I wanted to - I did something like this:
...etc
This DOES work but it's probably less efficient and bewildering to look at for maintenance reasons. I'd still like A Better Way.
I'd like a rule something like...
But then just "foo/bar" doesn't match.
To be clear, all my languages still go to the same theme. But I had to create all those rules to deal with "drupal:path = %/foo/bar" not matching on my "drupal:path = foo/bar" rule (and that's why I suspect that language prefixes do not get stripped out).
Thanks much for taking the time to think this through with me. And thanks for your work on Themekey! Themekey has bailed me out of what looks like a dead D7 development path for the Subsites module!
Comment #3
mkalkbrennerThanks for the feedback. Maybe it makes sense to strip the language prefix for drupal:path. For backwards compatibility it should be configurable. Turned on by default on a fresh installation but turned off on updates.
Meanwhile you could reduce your rules to two:
If you want to match "foo/bar" as well, you can replace the rules above by
These include the ones from above!
Comment #4
jschrab CreditAttribution: jschrab commentedThat WILL work. It is still twice as many rules as I would like - but that's better than *three times* as many rules! I was just wondering if was going about it the right way to begin with. I thought I would be able to come up with a regex that would handle ALL cases but the use of drupal:path:wildcard isn't clear to me.
Yes, I think language stripping as a future option would be a good idea and would get around such cases.
Comment #5
mkalkbrennerWow, drupal 7's flexible language negotiation caused complicated code to fix this issue ;-)
We don't need a configuration option. The patch should solve all cases!
Comment #6
jschrab CreditAttribution: jschrab commentedI strongly think you're right! I have a dev case where that's working as I expect! Woo! I can drop half my rules!
Thanks much!