Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 0.9.1
-
Component/s: None
-
Labels:None
-
Request Controller:Please Select
-
External Supervisor:Please select
-
Executing Programmer:Please select
Description
I moved /libs/jquery-plugins/images/ folder in repo to the parent, but in the filesystem shadow.png which was in the images/ folder ends up in the root folder of the space
This is because the parent nodes are Folders not ContentDirectory nodes, and the algorithm to get the container to serve the file is using the full URI path, not the URI path including only ContentDirectory parents.
The behaviour in this situation is not clear to users. They would expect files to "exist" at the same location in the filesystem as they appear in the repository - for relative links to work from CSS nodes. This is currently ambiguous
If you have a stylesheet that is uploaded as a css file to /x/y/z/ (Folder nodes) then you would expect it could resolve relative images that point to ContentFile nodes. This will work currently as both files will be assumed to be at the "root" of the filesystem because the parents are Folders. However as soon as you start moving folders and files around the behaviour becomes confusing as the folder names are not considered.
Conversely we have the problem that a user may try to add a StyleSheet node (they can edit) under a ContentDirectory node so that they can link to the ContentFile nodes relatively.
Adding a mechanism to block unsupported hierarchies is part of the solution here, for now at least.
I've implemented a canAcceptChild hook on content, which prevents Folder or other content being dropped under ContentDirectory. This was causing problems where you could then use this to put another ContentDirectory under the folder and get a totally confusing situation. It also prevents you putting HtmlContent under a ContentDirectory node which currently makes no sense.