Consider the following setup:
Expected behaviour:
Actual behaviour
Relative paths will also increase page load performance, I believe.
I believe the setup I described is quite common, especially for static landing pages. Is this an oversight in the CMS design? Or have I missed a setting?
This is a change made quite recently. I think there is no such setting to change this.
The only change made recently was an inconsistency in how uploaded file attachments were returning the path to their location. The rest of the URLs can all be generated in different ways, so there isn't a centralized setting that you could 'flip' in a sense to trigger only outputting relative URLs.
We tried a relative link policy in the early days, the problem was being unable to detect a complete URL when using subfolders
Url::to helper says "Does link start with http[s]://?" if so, then the link is complete already, so just return it. This means:
Url:to(Url:to(Url:to('/home'))) outputs http://mysite.tld/homeIn relative mode with a subfolder of /mysite:
Url:to(Url:to(Url:to('/home'))) outputs /mysite/mysite/mysite/homeIt became too unreliable and it was obvious that the Laravel internals were not designed to handle it. In short, there is no reliable way to know which segment of the URL is the subfolder and prevent it from being duplicated.
However, there may be another way, we could revive relative mode. By targeting the function endpoints, for example the |page or the |theme filters, we could include a "strip protocol and hostname" process when in relative mode. This lets Laravel do its thing and at the very end, strips off the https://mysite.tld/ portion of the URL with a simple string replacement.
Things to consider here
Say your site has relative links everywhere, but you want to include an image in your meta:
<meta property="og:image" content="/relative/path.jpg" />
This will not work for obvious reasons, so a filter may be needed to convert back to fully qualified URL.
<!-- Proposed override -->
<meta property="og:image" content="{{ '/relative/path.jpg'|full_url }}" />
<!-- Alternatively -->
<meta property="og:image" content="{{ root_url() }}/relative/path.jpg" />
Then we need to consider when an endpoint has not been addressed and provide the inverse mechanism: to strip the hostname and protocol.
<!-- Remove the root URL -->
<meta property="og:image" content="{{ 'http://mysite.tld/relative/path.jpg'|url_relative }}" />
Lots to consider here. What do you think?
Good points.
I think the |theme way is the way to go here. Because this issue becomes urgent/critical when loading resources, and does not really affect how page URLs are generated. Since from what I see, |theme is used when loading all assets relative to the theme.
I propose something like this: the |theme will take in a optional parameter to force absolute url, which is defaulted to "false".
All the URL generation still works the same way, but at the very end, strip the current site protocal + hostname.
I believe this will take care of all major use cases.
in the og: use case, just pass true to preserve the absolute url
every endpoint is addressed invidivually already due every template using |theme already
Any thoughts?
As a quick workaround, is it possible to use {{ str_replace('/path/to/resource' | theme) }}
Is the syntax even possible?
@l3utterfly https://twig.sensiolabs.org/doc/2.x/filters/replace.html. I think it might be better if going the pass a parameter route to enable absolute by default since that's the current behaviour. If you want to change it, then you're the one responsible for triggering that change.
This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.
Related: #4082
This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.
Sorry to re-open this issue but it's still annoying for me in my use case:
I use Laravel valet (like many others I guess) and sometimes my clients ask me to show them the development website to be sure I'm on the right way.
To do that, I use the command valet share which provides me a temporary url so the client can see the work accomplished. In this case, all the static pages are linked with my local machine url: like http://sng.app/my-page where all other octoberCMS pages are like http://436aaef7.ngrok.io/my-page.
So frequently my client says "Hey, wait! The website is full of 404 pages!".
@RomainMazB Would you be able to clarify which URLs are using absolute paths? Is it all URLs or just the assets?
Would you be able to double-check if Valet sets up the APP_URL environment variable to use the generated ngrok URL?
I'm talking about the staticMenu url, here is my navbar template:
{% set items = staticMenu.menuItems %}
{% for item in items %}
{% if (item.items) %}
<div class="navbar-item has-dropdown is-hoverable">
<a class="navbar-link{% if this.page.title == item.title %} is-active{% endif %}" href="{{ item.url }}">{{ item.title }}</a>
<div class="navbar-dropdown">
{% for itemDropDown in item.items %}
<a class="navbar-item{% if this.page.title == itemDropDown.title %} is-active{% endif %}" href="{{ itemDropDown.url }}">{{ itemDropDown.title }}</a>
{% endfor %}
</div>
</div>
{% else %}
<a class="navbar-item{% if this.page.title == item.title %} is-active{% endif %}" href="{{ item.url }}">{{ item.title }}</a>
{% endif %}
{% endfor %}
Don't know how to check if Valet sets up the APP_URL yet, I'll check that later
@RomainMazB I would recommend using force for linkPolicy in config/cms.php and configure the url value in config/app.php to be based off the APP_URL environment variable. From what I've been able to read in terms of Valet configuration, they set this environment variable automatically. This should hopefully fix the URLs in the menu.
@bennothommo It works! Thanks for the tip.
Closing in favour of #4082
Most helpful comment
@bennothommo It works! Thanks for the tip.