Bill,
as I stated before, only links ending in .aspx and .ashx are routed by default to ASP.net, while links to images, documents JS and CSS are handled directly by the web server without involvement of the application. you might add rules to web server url rewrites, but I see little chance for this being implemented in DNN core due to not all users have necessary access to server settings. If you place your images on a CDN or use a different domain address pointing directly to your portal folder (e.g. cdn.mysite.com pointing to www.mysite.com/portals/0 folder), you may solve your íssue but need either use a custom folder provider or manually adjust all links.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

Hi Richard,

Of course portals are MORE than a good idea.  That was not my intention at all...

Abstraction... just like we abstract presentation from data, code from data and the dot net framework from the normal everyday graphic designer... we can as well abstract the underlying mechanics of DNN so that a resource is nothing but a part of the hierarchy removing any need for knowing that it is in underlying layers located within a DNN structure somewhere.

Maybe a example will help: 

mydomin / portalsdir / portalid / images / resource

1. has no value at all to a user...
2. is dilutes the relationship to the hierarchy
3. makes it impossible sometimes to directly adress a resource
4. Its a longer path
5. etc...

If we instead mapped a virtual path to all requests for downloadable images, pdfs, flash, videos, word documents etcc.. like

virtual dir root "/" = "mydomin / portaldir / portalid /" 

then we can tell someone to download a resources without having to define a long cryptic string, we could refer to the resource in higher level abtractions using a shorter more meaningful and relevant path, we could build on close proximity of resources with respect to spiders etc...

Another great example is to upload a file called test.zip for offshore graphics designers or customers even and then simply refer to the file as  mydomain / customers / download/ test.zip and even the CEO would be able to understand how to that :-)

It is purely logical... it is NOT nessesary to use portalID and PortalDIR until absolutely nessesary...  the only time that this is ever truely needed is in CODE.... and I am talking backend code.....

 Surprised this even needs to be debatted... its a no brainer....

Cheers,  Bill

Hey Sebastian,

I was thinking more that DNN itself would abstract the hierarchy... create a virtual root.  If DNN actually used a true virtual root, for all resources that was interpreted by the DNN Framework and translated behind the scenes (TRANSPARENT) then there would be no problems for anyone... even hosted DNN installations.

But you gave me an idea... not sure about this and you being the expert surely will be able to shed some light on this....  Can I created a virtual mapping under the portalDIR that is only visible to that individual portal and is accessible to DNN referencing in code ????

That would be a great work around to this issue....

Cheers,  Bill