[MGNLSTK-723] Theme CSS files in /docroot are wrongly resolved Created: 07/Dec/10 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia Standard Templating Kit (closed) |
| Component/s: | base system |
| Affects Version/s: | 1.3.5 |
| Fix Version/s: | 2.0.x |
| Type: | Bug | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Date of First Response: |
| Description |
|
When configured in a theme, it seems that /docroot links are manipulated at some point to include the /<site-name>/ portion. This yields 404s, so I had to "hack" my configuration and use a "/../" hack (see attached screenshot) (I'm unsure in which components this belongs, please edit the issue as soon as this is found) |
| Comments |
| Comment by Magnolia International [ 17/Dec/10 ] |
|
Would be nice to get this out in 1.4.2 |
| Comment by Philipp Bärfuss [ 19/Jan/11 ] |
|
The Resources class should not be aware of the docroot, this has to be fixed elsewhere otherwise it will fail on any other exception. |
| Comment by Philipp Bärfuss [ 19/Jan/11 ] |
|
We are going to revert the current changes and will fix this issue later. In the meanwhile we found the reason for all this. The site-name is always added to the uri which is correct. The multi site filter then detects the site and sets the current uri. This works for css files in the resources workspace an in mgnl-resources but not for resources served by the container. The reason is that the container is not aware of the current uri but sees the original one which contains the site-name. This worked in former versions (before the multi site filter was introduced) because the resolution was done by a virtual uri mapping which made a forward. In this case the container saw the cleaned uri. We have few options to solve it: B) use the new WebContainerResources class to determine wether we should add the site-name or not C) the multi site filter could change the uri by wrapping the request I personally prefer B). |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |