Robert J. Lang

Results 263 comments of Robert J. Lang

For the usage in `node.entity`, this theming is used for the "Read more" link in teasers, but since there's only one link, there's no delimiter. But modules could (via `hook_node_view`...

For the usage in `file.entity`, the links are themed inline, but the list of links is empty unless augmented via `hook_file_view` or `hook_entity_view`.

> I'm not sure if it's worth the effort to change all the places now. If we change the CSS that affects the read more/comments display, it will automatically affect...

> So you can say that that's an existing pattern we should retain I think. I agree. So, to recap...before: ![](https://user-images.githubusercontent.com/100206/29429319-25be0240-8345-11e7-96b8-4edaee6ab286.png) Updated PR: ![image](https://github.com/backdrop/backdrop-issues/assets/29214084/aee31025-8af3-4d67-9388-42be11d9b085)

I guess I don't have a strong opinion myself (though consistency, however tenuous, won the day for me here). Since we clearly have a difference of opinion, how shall we...

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)...

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?

As I think about how to try to explain this to users on the "Configure layout" page, given the differences between wildcards and placeholders and the limitations on the latter,...

If I may add one more bit of argument in favor of having both placeholders (`%`) and wildcards (`*`) in layout paths, versus using `*` for everything: I remember seeing...