Closed Bug 510620 Opened 16 years ago Closed 15 years ago

Add admin option for path

Categories

(support.mozilla.org :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: jsocol, Assigned: jsocol)

Details

(Whiteboard: tiki_feature)

Add an admin option for a base path, and make sure that variable is available in Smarty templates.
Blocks: 502093
M. I guess maybe it doesn't have to block it yet. We can decide if we want to support it on Monday :)
No longer blocks: 502093
Target Milestone: 1.3 → 1.5
Target Milestone: 1.5 → Future
Is this already in Tiki 4.x?
Whiteboard: tiki_triage
No, but +1 to this goal.
Whiteboard: tiki_triage → tiki_feature
Technically, there is no variable that I know of. However, there are smarty plugins to generate links. self_link sefurl query button ... others? The code in there is not great as it attempts to do too much magic, they act as a central place to generate URLs and are deployed to a significant portion of the code.
This is a simple way to ensure that not only links, but all URLs (style sheets, images, scripts, etc) always work, regardless of the installation directory.
OS: Windows XP → All
Hardware: x86 → All
In stock tiki, all links work independently of the installation location because all links are made relative. It causes problems with the different url scheme used in SUMO, but a simple <base> tag in the header might just do the trick.
I'd consider a URL scheme like ours a useful feature, and this small patch would make that much easier. If you're really against it, this is sumo_only.
After a check, a lot of code was already in place but would only show up under strange conditions. I just removed those. <base href="..."/> is now always placed in the header, meaning all CSS is pointed to correctly no matter what the path is. All links must be generated as relative URLs (as it was in tiki, not in SUMO). <a href="kb/en-US/SomePage">SomePage</a> (GOOD) <a href="/kb/en-US/SomePage">SomePage</a> (BAD) Commit number is 24314 and should be live on tiki-trunk within a few hours.
This will cause all manner of problems in our templates. I'm not sure why there's so much resistance to this idea. It's a very simple option. How exactly is the <base> tag configured? An explicit configuration option should be able to override the inferred URL.
The resistance is to make sure you don't have to fork all templates just to change the base URL. In upstreaming, all those hardcoded paths to / caused me some trouble, which is truly not required when conventions are followed.
Paths are built in: lib/setup/absolute_urls.php
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.