Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.SEE DIFF HERE: https://git.drupalcode.org/issue/drupal-3446674/-/compare/11.x...3446674...
Problem/Motivation
A Drupal site does not tell the user anything about what domain name it is running under, or what domain will be the live one.
If you don't see the browser's URL, it is actually impossible to tell the difference between a live site and a copy unless the developers added Environment Indicator module or some other solution.
This idea originated in Site.module, and is a part of the effort to add a Site entity to core. See parent issue.
Steps to reproduce
- Load /admin/reports/status.
- Load /admin/reports/status on a cloned environment with the same server config.
- Note there is zero difference between these pages.
- Load any Drupal websites status page, and without looking at the browser URL, try to figure out what site you are looking at.
Proposed resolution
- Add "Canonical URL" to the Basic site information form.
- Display the "Canonical URL" on the "Status Report" page.
- If the current host is not the canonical URL, show an indicator in the admin toolbar.
I'm trying to improve UX/OX on the status report, so in addition I added site name in this MR.
Remaining tasks
Add Canonical URL to basic site information form and config.Add Canonical URL to Status Report page.- Add some kind of indicator if a site is NOT the canonical site.
- Figure out how to handle aliases of the canonical URL. If the site is running under multiple domains, we don't want to display an indicator saying the site is NOT canonical.
-
- Option 1: Make the field "canonical_urls" a textarea with one per line.
- Option 2: Add an additional "canonical _url_aliases" textarea.
User interface changes
Adds "Canonical URL" to basic site settings form.
Adds Site Name, "Main URL" and "Current URL" to Status Report page.
API changes
None.
Data model changes
Adds canonical_url to system.site config.
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Screenshot from 2024-05-13 10-32-48.png | 73.42 KB | jon pugh |
| #10 | Screenshot from 2024-05-12 14-59-14.png | 53.4 KB | jon pugh |
| #5 | Screenshot from 2024-05-11 12-37-06.png | 46 KB | jon pugh |
Issue fork drupal-3446674
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
jon pughComment #3
jon pughComment #4
jon pughComment #5
jon pughComment #6
jon pughComment #7
mglamanSeems reasonable. Canonical feels too developer
Laravel has this as well, `url`. It's used for CLI URL generation.
I'm sure other projects also have this. Would be nice for Drush when using the default site.
Comment #8
feroxUp!
Wil be an awesome feature.
Comment #9
jon pugh@matt: is the APP_URL for the current site? Or as a reference for the live site?
This is to store the live site so users can see it in status reports etc.
I think the screenshot is confusing. The default value is whatever site you are on, hence "localhost" because I was using PHP CLI server, but normally you would put in a separate domain.
Comment #10
jon pughComment #11
jon pughComment #12
jon pughComment #13
mglamanIt's the current site. So example.com or uat.example.com.
You're meaning it should always be the production URL?
Comment #14
jon pughComment #15
jon pughComment #16
jon pughMatt: I'm thinking Main URL is a good human label, but I really like the language "canonical" and "replica" screen thinking about this.
Comment #17
jon pughLike
SiteService::isCanonical() as a universal way to see if a site is "live" or not.
Comment #18
jon pughUpdate: After thinking a few days I think "Main URL" is the best human-readable name for this property.
"Canonical URL" is still good for the backend, I think. "Main URL" is a little vague when used in code.
Thoughts?
Comment #19
jon pughDevelopment on this feature has moved to #3446677: Add "system.site" service and SiteProperty plugins to improve the Status Report page and provide structured data about the site.. Keeping this issue for discussing the Main URL field specifically.
Comment #20
smustgrave commentedComment #21
smustgrave commentedTalking to a committer and this needs product manager sign off.
Comment #22
jon pughMatt: Yes, this is specifically for the prod URL. Can be used both for showing admin users in the status report page, and for detecting if a site is "live" or not.
Comment #23
mglamanOkay, so it is not the current site's URL but intended to reflect whatever is the live/production URL for the codebase.
Comment #24
jon pughI coincidentally installed metatags on my site yesterday, and it has a field "Canonical URL".
Did a little digging. Seems like this could be useful for printing these tags.
https://developers.google.com/search/docs/crawling-indexing/canonicaliza...
Comment #25
jon pugh@mglaman yep. I thought "Basic site info" would be a good place for it because email is there too. It feels like that form is the core identity of the site.
Also, if Drupal core had this feature, it could set DRUPAL_ENV to prod only if the URL matches. It would be a very simple way to detect environment on any system. No more if/then/else clutter in settings.php.
A comment by Ryan Price on linkedin brought up "trusted hosts"... Maybe we need a "trusted prod hosts"?
Comment #26
liberatrIf you want the site to report "this is my canonical public URL", it should be validated against trusted host patterns.
Comment #27
xjmThanks for working on this! I can see where this could be valuable in complex deployment scenarios that involve e.g. extensive testing on staging.
In this case, I think this issue might be a wontfix (or rather, wontfix for core and better implemented in contrib for sites that need it):
Having a new required field on every single Drupal site, especially one that does not affect the production user experience, seems like it is fixing an edgecase at the expense of the evaluator and site owner experience for all sites.
Adding additional form elements always inevitably causes a usability regression, so we should make sure the usability benefit of adding the element outweighs that regression.
It is also relevant for the product manager role because it affects the evaluator experience of Drupal. Adding an additional thing that must be configured (at site install maybe even?) is a non-trivial increase in the amount of configuration necessary to get up and running.
At a minimum, I think the field should be optional rather than required, and have a sensible default value if the user doesn't provide one. Furthermore, though, this could be addressed with a contrib module and might not even be appropriate for core.
If folks do still feel this belongs in core, then at a minimum, the field should be made optional. Then, that could be submitted for usability review (tagged "Needs usability review") once that change is made. After that, even if the usability team gives the addition a +1 (benefit outweighing negative UX impact), this would still require product manager signoff because it affects the evaluator experience of Drupal.
Also, there is not actually a merge request here ATM, so we would need that too before proceeding.
My personal recommendation is actually to mark this wontfix and support it via contrib, but it's outside the scope of my role as a release manager to make a final decision on that myself.
Adding a relevant related issue that might add a different way of addressing the root concern.