[UX] Using * or % as a wildcard in layout paths does not have expected behavior

[jenlampton]

bug report from email:

I have result pages where I need the full page width for content. Created custom layout, one column, picked the url string (results/*) as a page identifier, saved. Cleared all the caches. But the standard layout is still used on those pages too. Is it me? Is it the default theme? Hard to guess.

Most users would expect that entering a path with an asterisk into the layout path field would function as though a second "default" layout were created that applied to all pages under that path. Is there any way we can make this happen automatically when someone enters an asterisk?

---

This issue has grown in scope considerably since it was originally opened. Documenting potential use-cases for shared layouts here:

1. I want different Layout Pages to use the same configuration. I have three stand-alone "layout pages" at /modules, /themes and /layouts on backdropcms.org. These pages are identical, with the exception of a single block in the content area. I would like to manage these pages as a single "Layout" with three blocks in the content area, with each block using visibility conditions. (Technically: this layout would be responsible for three menu router config files, but only a single layout config file.)

2. I want several Views Page Displays to use the same layout I have three views page displays at /foo, /bar, and /baz that all have different content in the "content" area, but I want them to share the same blocks everywhere else. (Technically, This layout is responsible for zero menu router config files, and only a single layout config file)

3. I want several Views Page Displays with contextual filters to use the same layout I have three views page displays at /foo/%, /bar/%, and /baz/% that all have different content in the "content" area, but I want them to share the same blocks everywhere else. (Technically, This layout is responsible for zero menu router config files, and only a single layout config file) --- The context on these three pages is always a string pass-through (never an object like user, node, or term) so will not present a problem.

4. I want all my 'user' pages to use the same layout. I want my user/login, user/password and user/% page to use the same layout. (Technically: this layout would be responsible for zero menu router config files, and only a single layout config file) -- The required user context for only one of these paths presents a problem.

[Graham-72]

I am wondering whether it may be necessary to also positively exclude results/* on the standard layout? I feel sure I have done something similar and will check.

[Graham-72]

Ah no, of course, you have to use % not * as the wildcard.

[maxmeno]

My fault - email report was wrong, I actually used % as a wildcard, it doesn't work.

[jenlampton]

I think part of the problem is that people expect both the placeholder (%) and wildcard (*) to work like a wildcard (*) did in Drupal 7, and stand-in for anything at all. But that's not how it works. Instead, the % is a placeholder only for a context. So user/% will only work when the % is a user ID, so user/1 and user/3 will match, but not user/login.

[jenlampton]

Here's a use-case that was reported via e-mail as having trouble:

I'm trying to set-up my site to use a specific "layout" for these paths:
user/login
user/[UID]/edit
user/[UID]/content

I think the only current solution for this is to have three different layouts, one at user/login, one at user/%/edit, and one at user/%/content.

I tried to set up a single layout at user/%/% where the second context was a string pass-through. This should have worked for both user/[UID]/edit and user/[UID]/content, but that didn't work. I think this is a bug, see #1672

[jenlampton]

Needing multiple layouts for multiple paths sounds like a shortcoming in layouts, so I have created #1671

[JugglingCoder]

"Here's a use-case that was reported via e-mail as having trouble:"
That was me, thank you Jen for posting this. Yes, the only "work-around" I could come up with was "add Layout" (and use the same layout) for each path. Optimal would be of course: "user/*" and all paths under "user" would use that layout.

But... I'm still confused as to why there is also a "path" in "Add visibility condition"... ??
If the "path" is "user/*" (or "user/%") why would I need a 2nd "path" in visibility conditions?

[klonos]

I think the only current solution for this is to have three different layouts, ...Needing multiple layouts for multiple paths sounds like a shortcoming in layouts, so I have created #1671

👍 I would have done it if you haven't beaten me to it.

[docwilmot]

I've started a solution for this and here documenting my thoughts:

Background
When you visit a page Backdrop checks the path in layout_get_layout_by_path(), to see if there is a layout matching exactly that path.

If you visit company/dept, then layout_get_layout_by_path() will be passed exactly that as the path, so a layout with path company/% will not match.

But entity load paths (such as node/3 or user/5) are passed to layout_get_layout_by_path() with the wildcard, so when you visit node/3, the function gets node/% as the path, so if there is a layout with path matching node/% that layout will match.

So what this PR attempts to do is to breakdown a path passed to layout_get_layout_by_path() into possible wildcard options, then check to see if there is a layout matching this option. So for a path company/dept/secretaries/sheila, we'd check for layouts with a path

• company/%/secretaries/sheila
• company/dept/%/sheila
• company/%/secretaries/%
• company/dept/%/sheila
• company/%/%
• company/%
  etc

So if a person visits path company/dept/secretaries/sheila:

• if there is a layout: company/% this path should match that layout
• if the same site has a layout company/%/secretaries this should not match
• if the same site has another layout company/%/secretaries/% this should match
• if the same site has a layout company/%/% this should match

Need to do more on the cascading of these paths.

Also, related, a path node/%/edit is not matching a layout node/%/% because Backdrop is finding both the Admin default and the node/%/% layout as designed, but the Admin layout has a higher weight so its chosen first.

Would be good to consider as well matching by aliases, but perhaps another PR.

[jenlampton]

I suspect that everyone is likely confusing a * with a %.

• A star (*) is a wildcard and means anything that matches
• A precent (%) is a system-placeholder and means that there is a known backdrop system menu router that matches that pattern (including the %) exactly.

This confusion is happening because in the Layout UI the description text on that field actually says that the % is a wildcard, when it is not. (The term wildcard is also used in the Block visibility description text to mean *)

I don't think that we should expand the meaning of of % to also include the meaning of *. I think that's going to confuse people even more. I also don't think the right approach here is to try to explain to people what the percent actually means. The percent is used in code, and is a developer-concept, and I don't believe it belongs in the UI.

I'd prefer to re-do that field to use a star instead of the percent, and then do all the expected checking, as though it were a true wildcard (as explained in the previous comment - but with * in place of %)

@docwilmot would it be had to adjust the above to use a star instead of a percent?

[docwilmot]

Not so sure about this. Fact is everyone may be "confused" because a % symbol seems intuitive for this purpose. I think conversely adding a new cryptic symbol is more confusing.

Right now to the end user node/%/% means "a path that starts with 'node' followed by any two things". I think that's a benign assumption. Backdrop can simply handle the context stuff in the background.

Would welcome more opinions.

[jenlampton]

I think conversely adding a new cryptic symbol is more confusing.

Yes! This is exactly my point :)

We added a % when Layouts went in. Switching to this new cryptic symbol confused everyone, because what they were already familiar with was a *. (And worse, because we called it a wildcard which is what the * was called before)

Now everyone thinks the % should behave like a * and are confused when it doesn't.

The proposed suggestion above changes how it behaves so that it would behave more like a * but without actually replacing the new cryptic symbol (%) with the old cryptic symbol we are changing it to behave like (*).

I think it will make things even more confusing if we have two different symbols that do the same thing. If we do this, people will wonder why a wildcard is represented by a * everywhere except this one Layouts interface, where for some reason it is a %.

Right now to the end user node/%/% means "a path that starts with 'node' followed by any two things".

Exactly! But what "a path that starts with 'node' followed by any two things" should really be is node/*/*. But since the star is not supported in layouts, people try to use the percent instead, which leads to frustration. :(

Backdrop can simply handle the context stuff in the background.

I'd rather Backdrop handle the context stuff in the background without people needing to understand the difference between a % (here in Layouts UI) and a * (in every other place wildcards are used). If we can do that by using a single cryptic symbol (preferably the * people already understand) instead of two, with subtle differences, that's a win :)

[docwilmot]

I understand all of this, but point is we already have the %.
For a path node/NID/ANYTHING what is your suggestion that we adopt to enable this functionality in Backdrop going forward?

1. node/%/%
2. node/%/*
3. node/*/*

[jenlampton]

For a path node/NID/ANYTHING what is your suggestion that we adopt to enable this functionality in Backdrop going forward?

Any path that has an ANYTHING needs to use a star, so my preference would be node/*/*, or even node/* would work.

Is this possible right now? IIRC we can only do the pre-defined paths at node/%/% (which does not handle the ANYTHING part -- the %s would need to be one of the strings Backdrop already knows about)

[docwilmot]

So are you proposing we change the symbol used in layouts totally to an asterisk?

[jenlampton]

Yes. If we're going to change it to work like an asterisk (which I think we should -- that's what people expect) then it should be an asterisk.

[docwilmot]

Interesting: seems @jenlampton makes more sense after a 9-month break and two cups of coffee: I agree wholeheartedly with your recommendation now ma'am. Well played. 😃

[bugfolder]

There's still a difference between placeholders (%) and wildcards (*), though; it might be useful to maintain the distinction.

• Wildcards (as they are used in URL Path visibility conditions) can appear anywhere within a path: foo* is a meaningful wildcard expression, but foo% is invalid as a layout path.
• Paths could potentially begin with a wildcard, e.g., * to match anything; but % is not allowed as a layout path.
• Placeholders can provide context. Wildcards presumably couldn't.
• Mixing wildcards and placeholders would make it pretty difficult to provide context for the placeholders: */% would be problematic to handle for providing context for the placeholder.

So how about supporting them both in layout paths, but with the proviso that you can't mix * and % in the same expression?

And then maybe a "more info" link or tooltip could help explain to newcomers what the distinction is and why one would choose one over the other.

[jenlampton]

The wildcard should be able to handle the use-case for the placeholder too.

I'd rather Backdrop handle the context stuff in the background without people needing to understand the difference between a % (here in Layouts UI) and a * (in every other place wildcards are used). If we can do that by using a single cryptic symbol (preferably the * people already understand) instead of two, with subtle differences, that's a win :)

We might still have to support both to make this change in a way that is backwards-compatible, though I'd still prefer not to.

[bugfolder]

Ah. If we only use *, then /*/ or /* (at the end) would be interpreted as a placeholder, and any other form would be an ordinary wildcard. Reasonable?

[indigoxela]

There's still a difference between placeholders (%) and wildcards (*), though; it might be useful to maintain the distinction.

I agree with that! The "%" placeholders mean something different (to me). Keep in mind, that % has a special meaning in hook_menu(). Think of "%node", which loads the node object. That's something totally different than "node/*" which translates to paths like "node/1", "node/2", ... "node/749".

Using "%" and "*" as equivalent might cause more confusion, a placeholder that loads an object is not the same as a wildcard on paths.

[bugfolder]

I think they would both work to "reduce" the situations in which a layout could be used.

No, they're complementary. The layout URL paths field expands the situations in which a layout can be used (when you add an entry, the layout works on more paths); the visibility URL paths field narrows the situations (when you add a visibility condition, it reduces the number of paths the layout could apply to).

And that's the case for both normal paths and alias paths.

In particular, the layout URL paths field lets you apply the layout to multiple unrelated menu router paths, like foo, bar, and baz. There's no way to do that with just visibility conditions (unless we start to allow layouts whose primary path is a wildcard, like *. Or a setting for layouts "instead of providing a path, use this layout on any path (make it "default-like"), and then it will be limited by visibility conditions.") (Which would be yet another way of addressing this issue.)

So could we simplify down the purpose of the new field from handling both internal paths and aliases to just handle internal paths? And would that deviate from the original purpose of this issue?

I couldn't think of any situation where one would use an alias in a layout URL path that couldn't be reproduced by using just normal paths there and visibility conditions that involved aliases. But my motivation for including aliases was that visibility conditions on layouts and blocks based on URL paths accepted both normal paths and aliases, and I thought that to preserve the consistent "mental model," layout URL paths should, too.

[bugfolder]

I couldn't think of any situation where one would use an alias in a layout URL path that couldn't be reproduced by using just normal paths there and visibility conditions that involved aliases

That's the behavior of the "Alternative paths" field that Layout Wildcard adds to the layout; it only handles normal paths, not aliases.

[quicksketch]

Sorry, I didn't write that clearly. The "URL Paths" field definitely expands the paths that the layout matches. I meant to say that when using aliases within the field, it works the same as visibility condition. Using internal paths expands the places the layout is applied, but specifying aliases will always only reduce the places it's used.

[bugfolder]

when using aliases within the field, it works the same as visibility condition. Using internal paths expands the places the layout is applied, but specifying aliases will always only reduce the places it's used.

I'm sorry, but that's not the case, and I've put a counterexample in the Tugboat sandbox.

• I've created a View with three pages: cat, dog, and rabbit.
• Then I created an alias bunny for rabbit.
• Then I created a layout with primary path cat and URL paths dog and bunny.
• The layout is used on all three pages provided by the View. So in this case, adding the alias bunny to the URL paths field increases the places it's used.

Admittedly this is a somewhat contrived example, contrived to address this particular point. I can certainly see the argument that accepting aliases in this field is unnecessary because the same outcome could be obtained by other means. But I don't see how adding an alias to that field could "reduce the places [the layout] is used."

[yorkshire-pudding]

Hi @bugfolder - l've tested this and I like it. I've always found it weird that the layout paths were nearly all node/% and can see that the combination of expanding scope together with the existing visibility tools to narrow scope would allow lots of flexibility

[bugfolder]

Having seen generally positive comments about the "URL paths" PR and its approach, I'm going to move on to the missing item I mentioned above: the problem of layout ordering when URL paths are in effect. To give a concrete example, suppose we have two primary paths and three layouts:

• path cat
  • layout 1 with URL path = foo
• path dog
  • layout 2 with URL path = foo
  • layout 3 with URL path = foo

In the absence of URL paths, with the normal ordering of layouts, if the request path is dog, layout 1 won't be considered, then layout 2 will be considered, then layout 3 will be considered.

If we turn on URL paths, then if the request path is foo, in the current PR, the order that the layouts would be considered is, first, layout 1 (because its primary path cat comes first alphabetically), then layout 2, then layout 3. The problem is that there is no way for the user to specify that layout 2 or 3 should be considered firs. Layout 1 will always be considered first, because its primary path comes first alphabetically. So there needs to be a way that a user can override the alphabetical ordering of the primary paths if we're considering URL paths, where any non-default layout could potentially be used.

Currently, within a primary path, the layouts can be reordered. So one could imagine letting one impose an overall global order on layouts, rather than grouping them by primary path. So, for example, if we wanted layout 3 to be considered first, we might end up with this:

• path dog
  • layout 3 with URL path = foo
• path cat
  • layout 1 with URL path = foo
• path dog
  • layout 2 with URL path = foo

However, breaking up the grouping by primary path seems like it would introduce confusion, since the benefits of grouping would be lost for everyone, but only the (minority of?) people who use URL paths would benefit from this global ordering.

So, the thing I'm leaning toward is adding a second field to each layout, "URL paths weight", whose default value is 0. A non-zero value of URL path weight would override the ordering, and a nonzero/non-empty value would only be allowed if the URL paths field is non-empty. That is, since only URL paths break normal ordering, only non-empty URL paths get to take advantage of URL paths weight.

So then one could do something like this:

• path cat
  • layout 1 with URL path = foo, URL paths weight = 0
• path dog
  • layout 2 with URL path = foo, URL paths weight = 0
  • layout 3 with URL path = foo, URL paths weight = -1

And this setting would then allow layout 3 to be considered first with request path foo since it has the lightest weight.

And yes, that would allow users to do self-foot-shooting by doing pathological things like

• path fish
  • layout 1 with URL path = foo, URL paths weight = 0
  • layout 2 with URL path = foo, URL paths weight = -1

where now they've just overridden an ordering by using URL path weights when they could have just reordered the layouts under the path in the usual way. We could address that with some warning on the field instructions: "Don't mess with this unless you're sure of what you're doing." I suspect the vast majority of use cases wouldn't need to use weights, since it seems very rare that someone would have multiple competing layouts with the same URL paths where ordering would matter.

The current PR displays the URL paths on the layout listing page. We'd also list the URL paths weight (if nonzero) so that (again) the user can tell most of what's going on in terms of layout path matching and ordering from what's shown on the layout listing page.

So how does that sound?

[bugfolder]

Summary of two points discussed in the Weekly Design/UX meeting:

• Regarding the order question, the use cases where someone would use the same URL path for two different menu router paths are very rare (we couldn't think of any); so we don't need to add an additional solution like "URL paths weights."

• The problem of dealing with mismatched contexts when menu router paths have placeholders (e.g., using the same layout on node/%node and user/%user) could be pretty confusing to people, and the most common use cases would be menu router paths with no contexts. So let's only allow URL paths to be added for menu paths that don't contain placeholders. Use AJAX to show/hide the "URL paths" field appropriately. We can add support for menu router paths with placeholders in the future, after we've gotten some usage and feedback.

[argiepiano]

So let's only allow URL paths to be added for menu paths that don't contain placeholders

Well, one of the most common use cases for me is a views path that has arguments (I use String passthrough in the Layout). I was looking forward to this being in core, since I want to use the same layout for several related views that use the same arguments but have different URLs. This decision essentially precludes this use case (which I want to believe is pretty common?).

[bugfolder]

Hmm, that use case is good to know about, so maybe we should reconsider that decision. Or think about finding an intermediate case between "no placeholders" and "placeholders that result in specific object contexts." Certainly string pass-throughs would be pretty innocuous.

That comes back to one of the ideas I mentioned in the meeting: have a setting in the layout that says "allow placeholders, and I promise to configure URL paths so that the layout will only be used on paths that have placeholders in the right place."

Meanwhile, I've updated the PR per the above, and also made some UX changes (improvements, I hope), which I'll lay out in the next comment.

[bugfolder]

In the new PR, here's what the layout listing looks like. I had originally just added the URL paths as an item list to the layout description, but here I've used a sentence so that the language on the layout mirrors the language used for visiblity conditions.

Here's what the URL paths field looks like for override paths without placeholders (i.e., it is enabled). Note the expandable "Show more/Show less" section, which I think is important to help users understand how this works. It's normally collapsed, but shown here expanded.

And here's what it looks like when the field is disabled. I show it disabled, rather than fully hidden, so that users thinking "hey, where's the URL paths field?" would know why they can't use it.

[docwilmot]

So, the thing I'm leaning toward is adding a second field to each layout, "URL paths weight"

This scenario, comment #1602 (comment), I would imagine should be quite unusual. I imagine if you really want path foo to use layout 2, you should create a layout with primary path foo.

[bugfolder]

This scenario, comment #1602 (comment), I would imagine should be quite unusual.

Yes, I'm dropping the "url path weights" idea for that reason. Thanks for the F/B!

I do have a new iteration in progress, hope to have something to post fairly soon.

[bugfolder]

The scenario that @argiepiano describes above sounds common enough that it seems like it should be accommodated "out of the box" with this PR. So I've restored URL path matching for menu router paths that have placeholders, but enforce that the load functions (if any) must match between the router item of the layout path and the router item of the request path.

As I was trying this out for various scenarios, I found that a not-uncommon hack for making URL paths useful for paths with incompatible load functions (like node/% and user/%) was creating a "dummy" page whose path was used as the primary path for the layout (even though the page at the dummy path was never actually loaded). This seemed useful enough that I've made it an official part of the module, and I'm calling it the "layout null path". (Certainly open to other names.)

As an example of its utility, if you create a layout with primary path null and URL paths node/* and user/*, you get a layout that applies to both node pages and user pages. (The null path value (null) is configurable.)

So URL paths make layouts pretty powerful, but as much as we strive to make things discoverable from within the admin website UI (and I've added a lot of conditional explanation there), there really needs to be some extensive documentation for the whole story. So I've written a documentation page, intended to go on the docs site (which would be linked from the website UI). For now, I'm attaching it to this comment. Please read through it. It includes examples of several scenarios that I think would be common use cases. (If you can think of other use cases that should be addressed and/or explained, please add them.)

There is the beginnings of an automated test helper module, "Layout URL Paths Tests", which is (temporarily) not hidden; if you enable it, you can see the four examples described in the documentation.

The PR is updated (and rebased); please give it a whirl.

Documentation of URL Paths.md

[jenlampton]

Well, one of the most common use cases for me is a views path that has arguments (I use String passthrough in the Layout). I was looking forward to this being in core, since I want to use the same layout for several related views that use the same arguments but have different URLs. This decision essentially precludes this use case (which I want to believe is pretty common?).

So I've restored URL path matching for menu router paths that have placeholders,

I don't understand how these two things are related. The menu router paths for these views page displays do not have placeholders. What am I missing?

[bugfolder]

The menu router paths for these views page displays [a views path that has arguments] do not have placeholders. What am I missing?

That those menu router paths do indeed have placeholders. Try this.

Create a View with a contextual filter whose page path is myview/%.
Go look at the {menu_router} table. There will be an entry whose path field is myview/%.

The use case that @argiepiano describes is the case "A dynamic View with multiple page displays" described in the documentation document.

[bugfolder]

Note from today's meeting: it would be nice to give instant feedback, or instant in-place correction, if someone tries to use a "*" in the layout's primary path (or, for that matter, tries to use a "%" in the URL paths field).

Another comment from today's meeting: a suggestion that a UI akin to Context's popup dialog for adding additional paths one-at-a-time (rather than a textarea field like URL paths in visibility conditions) might be preferable. (H/T @quicksketch.)

[jenlampton]

Create a View with a contextual filter whose page path is myview/%

I don't think I've ever done this. Do you just put the percent symbol in the "Path" field on the page display? (and also, why would you ever do this? Is this an 80% use-case?)

To test, I created a views page display normally, and added contextual filters. The path I used was foo. I checked the {menu_router} table to be sure views wasn't adding a placeholder because of the contextual filter, and it was not.

The use case that @argiepiano describes is the case "A dynamic View with multiple page displays" described in the documentation document.

Yes, I saw that and added it into the description of this ticket also. But as I said, there were no placeholders in the {menu_router} table after I tested that use-case, hence my question.

[yorkshire-pudding]

Hi @jenlampton it's on the site that you worked on before me. It uses it for different taxonomy filters. For example publications/%

[jenlampton]

@yorkshire-pudding But adding a % at the end of the path is completely unnecessary for views contextual filters... so why do people do it? Is it a mistake, or is there a use-case? Or, maybe it's a left-over from previous versions of Drupal? Maybe it's just a habit? (I'm going back and looking at some of my older Drupal 7 sites -- upgraded from Drupal 5 or6 -- to see if I can find any examples of this)

[bugfolder]

I don't think I've ever done this. Do you just put the percent symbol in the "Path" field on the page display? (and also, why would you ever do this?

I've done it for years in D7, and it's on my main live site. For example, I have a node type of "Class", which has fields of "Year" and "Season", and there is a View that provides a listing of classes at, for example, path classes/2022/3 (for all classes in the 3rd season of 2022).

And yes, you put a '%' in the page path of the menu item for each of the Views contextual filter arguments.

Is this an 80% use-case?

Well, it's all over Views in core. Do a search for views_handler_argument_ through core, and you'll find a whole slew of handlers that are intended to work with exactly this type of path. [EDIT: I had long assumed this was the primary use case for contextual filter arguments in Views, but I gather from the above that that is not the case.]

I also solicit @argiepiano to say more about his use case(s).

[docwilmot]

Does this PR actually enable wildcards (*) now? I dont see how it would. And its not working in the sandbox.

[argiepiano]

Sorry, I've been busy and not paying much attention here. It's true that you don't really need placeholders in Views paths when you are dealing with paths that contain contextual filter(s) as the last parts of the path (placeholders not needed in the views path for my-path/% or my-path/%/%), but you do need them when you are creating multiple paths where the last part is a string, for example my-path/%/foo or my-path/%/bar. And those will create menu router items with placeholders, thus my concern.

[bugfolder]

Does this PR actually enable wildcards (*) now? I dont see how it would. And its not working in the sandbox.

It does, and it's working in the sandbox (at least, for the documented cases). I enabled the test module that creates the use cases referred to in the documentation.

I see you (or someone) has created a layout-created page that overrides another layout-created page (and so they're both listed as layout-created pages in the listing). That's a use case I hadn't considered, and that we briefly touched on the design meeting. I think the consensus there is that this is a case that ought to be supported, and so the PR will need to be updated to handle that case.

And also the case of a View with contextual filters that don't include placeholders. (After all these years, I'd just assumed you needed the placeholders and so had always used them.)

[bugfolder]

I think the consensus there is that [a layout-created page overriding another layout-created page] is a case that ought to be supported, and so the PR will need to be updated to handle that case.

And in pondering how to handle this...the reason I didn't originally allow layout-created pages (LCPs) to be used to override other non-layout-created pages via URL paths was that the former don't have the "Main content" block, and I thought it would be really confusing for a user to create a LCP, give it a URL path of node/*, and then when they visited node/1, they'd see their layout but no node.

So maybe the right behavior is that LCPs with URL paths can only override other LCPs. But then that means more quirks that need to get documented in the documentation.

(Maybe it's best instead to stuff all the functionality into Layout Wildcard module, and let the resolution of this issue go back to its original title: do instant-feedback/correction if a user tries to use a * instead of a % in the primary path of the layout.)

[docwilmot]

This issue has become so complex because we're trying to add:

• wildcard support
• multiple layout paths
• layout path alias support

I believe the last two tasks had previous issues somewhere. This issue started for the first task. Maybe we should tackle fewer than 3 at a time? If this gets bogged down I'd recommend we tackle the 2nd task first (I think that might be the more complex UI and API task), then come back to this one.