Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Upgrading DNN P...Upgrading DNN P...Some problem after moving to V9.xSome problem after moving to V9.x
Previous
 
Next
New Post
3/15/2017 3:29 PM
 

Hello,
I've moved a big (and very old) installation onto v9 last week (from 8.x). At the time, things seemed to be super smooth: new persona features looked good and much faster, I could edit pages, etc.

However, trying to learn how to use the new environment revealed some problems. I'll mention two and describe in detail just the one that looks more worrying.

1. Only way I could find to create pages in a given part of the tree is to use the "create multiple pages" function. The mask to add just one page only allows to add to the root. Is this by design? (As some of the comments I've read around here seem to suggest?)

2. "Site assets" and "Global Assets" both send me to an error page in the form of "https://domainname/cms/404b.htm?aspxerrorpath=/cms/cms/Default.aspx". Which is interesting, upon inspection (see below)!

 While investigating the second issue, I noticed that going directly to the tab that includes the FileManager (DAM)  (as in /cms/Default.aspx?tabid=XXX, bypassing the persona bar altogether) worked for "site/file management" (I assume equivalent to "Site Assets"), but not for "host/file management" ("Global Assets"?). The error returned for the latter is:

 Error: File Management is currently unavailable. DotNetNuke.Services.Exceptions.ModuleLoadException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.Modules.DigitalAssets.Components.Controllers.DigitalAssetsController.GetFolderViewModel(IFolderInfo folder) at DotNetNuke.Modules.DigitalAssets.Components.Controllers.DigitalAssetsController.GetRootFolder(Int32 moduleId) at DotNetNuke.Modules.DigitalAssets.View. (EventArgs e) --- End of inner exception stack trace ---

Indeed, looking at the database (and comparing with a clean v8 install I have in a test box) there was no entry for root folder (which I understand is "\portals\_default"). I've tried to add a record for it, only to find that upon visiting the tabid in question, the filemanager did show up, but displayed an error. Concurrently, the corresponding record in the Folders table gets deleted (?!?).

Thing I've noticed is that in the error path I see above (using the persona link) an additional "/cms" is added, which sent me to the IIS logs, where I could confirm that clicking on the two persona links in question is actually trying to open "/cms/cms/Default.aspx?tabid=xxx" which understandably throws a 404 error as the path is wrong and the file does not exist.

In short, issue 2 seem to contain two embedded issues: the first is that for some reason the "/cms" bit of the base URL gets repeated, the second is that I can't find a way to make the folder structure of the Global Assets reappear (believe me: I've tried in many different ways, omitted for brevity).

Any help appreciated!

Thanks,
Sergio

 
New Post
3/18/2017 11:29 AM
 
when browsing host page for File Management, you might add query string parameter for your website to apply proper security context, i.e. /portalid/0

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
3/20/2017 3:55 PM
 

Thanks Sebastian,

I've tried manually browsing to "hostname/cms/default.aspx?tabid=XXXX&portalid=0". Unfortunately, it didn't work: doing so without creating a new record for the root folder generates the same error as before. Doing the same after generating the row shows the file/asset manager with just the root. Trying to do anything therein makes an error "pop up", trying to reload the page generates the same exception as above.

On inspection, the new record I'm creating actually gets deleted the moment I visit the page. After that, I suppose it's not surprising that things don't work. So for me the question would be: "why does DNN remove the manually created record in the 'folders' table"?

Thanks again,
Sergio

 
New Post
5/25/2017 7:14 PM
 
After also upgrading to v9.. I have a similar issue in that all my API calls get 404 errors on almost all admin functions. If I try to use the file manager is a 404. If I try to edit a page, it's a 404. A fresh v9 site works, but my updated site is eating dirt at the moment.
 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Upgrading DNN P...Upgrading DNN P...Some problem after moving to V9.xSome problem after moving to V9.x


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out