Hi,
Before I start to irreversibly break things
, I would like to ask - is there any
specific reason why it includes scheme/host/port (which is propagated to all generated content)?
Thank you!
(2013-09-16, 10:53:01)aldem Wrote: [ -> ]... any specific reason why it includes scheme/host/port (which is propagated to all generated content)?
Probably not, in most cases. Is there a specific reason or use case why you don't want that? ;-)
(2013-09-16, 17:19:45)hameau Wrote: [ -> ]Is there a specific reason or use case why you don't want that? ;-)
Of course there is
Most common problem (which bites many) is deploying to production server after setting everything up on test server - $SITEUTL has to be adjusted. While by itself it seems minor (only one configuration change), it actually is a bit more annoying, given that some content links are also derived from $SITEURL, so they have to be changed manually (
example).
In most cases, it may (and should, I believe) be configured automatically (derived from $_SERVER['PHP_SELF']) with schema/host/port stripped, this way, it will work almost everywhere (I couldn't imagine where it couldn't). Bonus: URLs in all generated content are shorter
Of course, if one wants to make it absolute (though I couldn't imagine why), the option should be there.
(2013-09-16, 20:41:13)aldem Wrote: [ -> ]Of course there is
Just checking. I guessed that migration prompted your post. Not excusing the current state, but it's the way it is at the moment. See also:
this bug.
It is quite simple to make the required changes and it only has to be done once, but I agree that it could be better. My solution is to use
rpl. Simple and effective, requiring only Python, and the changes can be done either before or after migration. I run it in the /data/pages directory and on the /dats/other/components.xml file.
Alternatively,
Komodo Edit is a free, cross-platform editor with the ability to Search & Replace in a directory or directory tree. It can work with local files or via FTP or SFTP. (It isn't necessary to open each file for S&R.)
(2013-09-17, 04:32:55)hameau Wrote: [ -> ]I guessed that migration prompted your post.
Well, not exactly
I just want to know, are there any objections to change to relative and (semi)automatic $SITEURL, and it seems that the only reason why it is absolute is because no one did it relative - I am right?
I see some potential in GS, so I am trying to investigate how close my thinking is to thinking of GS developers and users - if close enough, I could share whatever I do to impove things, if not - then I simply will do it for myself and not bother anyone else
(2013-09-17, 08:35:17)aldem Wrote: [ -> ]I just want to know, are there any objections to change to relative and (semi)automatic $SITEURL, and it seems that the only reason why it is absolute is because no one did it relative - I am right?
You might want to try any suggestions in 'Developer Discussions'.
I was wanting to make a thread about site url myself, but the OP beat me to it. My workaround to it was to manually edit the xml file and put / in siteurl. It works fine.. until I need to change or update something on the settings page.
I tried to find the code responsible for the disability to save the siteurl as / but couldn't nail it. Help?
Just manually edit website.xml, or remove the type=url from the settings form input.
There is an issue on this in github asking for testing.