Unless I've missed something, it appears images and other assets can only be saved within the portal root, or the Images folder (not withstanding the choice between Admin or Host).  I've tried testing folder arrangements in these areas, but the test-folders never appear as options in dialog boxes. Hopefully, I've just missed something basic and folders can be set-up independently.

Ideally, folders could be created and organized anywhere either:

• Within a specified spot in either the host or admin areas, with no restriction on creating folders, sub-folders, etc.  Materials can be grouped in folders/sub-folders according to project specs as necessary.  Dialogs placing folders can navigate to where materials are organized;
• Anywhere on the server HDD or domain (with appropriate permissions, of course).  The option to navigate anywhere on the server/domain would be the best solution.  This way material does not need to be created/saved in one spot, then uploaded to DNN, then manage as a copy in DNN.  Edits can happen in one step.  Working with materials directly on the server would be the "best," but the first option would work via use of NTFS junctions from the HDD organized within the DNN install (I tested symbolic links with DNN and they do work, so junctions should work, too ... if DNN can see the folder under images, root, or whatever other options might be available).

I've tried looking for an answer to these questions, but have not been able to nail-down anything conclusive.  Thanks very much for any information, or leads to information, providing a conclusion one way or another.  The DNN community is a treasure.

Thanks, Timo, for the response.  The questions are about changing where images can be referenced from a module, and in DNN host/admin spots exampled by the logo, favicon, or similar applications.  The HTML module might be the most important since that module is used often, but the ability to set where materials are located anywhere on a server or domain would be useful among other areas of DNN work, too.

As mentioned in the original post, use of NTFS junctions can assist matching server/domain folders/files with DNN locations.  Junctions can be placed in the portal root or images folder, but those folders (or new ordinary folders created in these locations) cannot be navigated to.  Individual symbolic links placed in DNN portal/images folders appear as available to DNN (which is helpful), but not NTFS junctions referencing whole folders.  The folders to junctions appear in the DNN structure, but cannot be navigated to or referenced in host/admin areas or from modules ... the only available options are the portal root or images folder.

While symbolic links referencing individual files are useful, junctions referencing whole folders would be ideal since many files can be available in a single junction to a folder on the server/domain outside the DNN install.  In summary, from admin/host functions and module examples including the HTML editor, it would be great to have an ability to specify management of materials in folders other than only the portal root or images folders.  Thanks, Timo.

Thanks, Timo.  So, now I understand why I couldn't find any documentation about the subject(s).  For responsible DNN technical/security reasons images/assets are limited to only the portal/root and/or portal/images folder.  Cool.  No problem.  At least I know I wasn't missing something looking for an answer.

Just to be clear, with the understanding materials must be in portal/root or portal/images, it is possible to create/access sub-folders within these locations? Is it possible to have these sub-folders available since the security restrictions would be the same as the parents?  I have created sub-folders in each location, but they are not available among any of the circumstances mentioned in the original posts.  Accessing sub-folders under portal/root or the images-folder would be a great help organizing materials.

If accessing sub-folders is also not possible, that's cool.  I just want to be sure about understanding what can / can't be done.  Thanks, Timo.