On a recent project, I was struck by how the content editors used spreadsheets to manage their content. This wasn't just as a planning tool in the early stages; they had spreadsheets which essentially mirrored the content in Drupal, and this is where they kept track of who was responsible for sign-off on a piece of content, what stage it was at, and so on.
Leaving aside for a future post or many the matter that if editors are needing to use spreadsheets to manage their content, it doesn't speak well of the 'M' part of the CMS and that there are surely things we need to improve in Drupal, one thing I noticed was how content was listed.
The main identifier of content, the first column in the spreadsheet, wasn't the title, or the node ID, but the path. To these editors, the path was the starting point, it represented that piece of content.
This is completely add odds with how Drupal treats paths. Paths in Drupal are like an afterthought: tacked onto entities as second-class citizens. They're not even shown in the content admin pages, you're left to discover them for yourself by hovering over the content link.
But what if we could change that, and put path aliases first? What if we could make Drupal list content in the same way that these users have in their spreadsheets? It would be a first step in providing the sort of content overview and administration tools that Drupal is currently lacking for these users. Other things are needed too, such as a sign-off user content, and more complex statuses. But paths are the starting point.
Unfortunately, the flexibility of Drupal's path system is actually a problem
here: paths aren't just for entities, and an alias can be for any system path.
So there's no connection in the database from the path alias to the entity it
points to, and there's nothing on the entity either: the path alias field you
see on a node is a computed value, obtained by querying the path_alias table
for the node's canonical path.
Of course, this doesn't stop SQL: you can join two tables on anything, and Views provides a 'join' plugin type precisely for these sorts of weird cases.
So we can define Views relationships from the path_alias entity type to all
content entity types, using our special join plugin. The join clause then
looks like this for nodes:
... JOIN node
ON SUBSTRING(path_alias.path FROM 1 FOR 5) = 'node/'
AND SUBSTRING(path_alias.path FROM 6) = node.nid
What that's saying is that we only join if the path alias's real path starts with 'node/' and we join the numeric suffix to the node table row of the same value. We need the first part so that we don't join an alias for 'media/42' to node 42.
With this, we can make an admin view of nodes listed by their path aliases, with all the same features as the default Content admin view:
And the wrapped up result is the Path Alias Views module, which provides the integration to show path aliases in Views: fields, sort orders, and filters.
The Views relationship is generalised to work for any content entity type that has a canonical path
of the form 'something/ID'. If your custom entity type does something weird with its canonical
paths (such as include the ID of a parent entity; I've done that myself with
custom entity types), then you can use hook_views_data_alter() to change
the relationship from path_alias entities to your entities, so that it uses
your own custom Views join plugin.
The view shown in the screenshot is installed as default config, and if you also install the Client-side Hierarchical Select module, a more souped-up path component filter allows you to select the path prefix to filter on one path component at a time.
This can be used as a drop-in replacement for the default core Content Admin view, though of course it will only show nodes that have a path alias.
I'm sure there are other ways of showing paths. Replacing the URL aliases admin page with a view would be one. Reverse relationships from entity types to path aliases would open up other possibilities too. I'll be interested to see what people come up with this: do please let me know on Mastodon, in Slack, or in MRs in the issue queue.
Do you need help with doing something unspeakably twisted with Views queries? I've had plenty of experience with this sort of customisation, and I'm available for hire - contact me!