DotNetNuke – Nach Upgrade auf DNN 6.1.X – HTML Modul speichert keine Änderungen mehr

Heute Vormittag habe ich den Anruf eines Kunden erhalten der mir folgendes Problem geschildert hat.

Nach der Aktualisierung eines DotNetNuke Portals von DNN 5.6.X auf DNN 6.1.1 werden Änderungen die man an Texten im HMTL Modul vornimmt nicht gespeichert.

Keine Fehlermeldung, kein Eintrag im Ereignisprotokoll, einfach nichts!

Nachdem ich mir die Konfiguration genauer angeschaut hatte, konnte ich einen Fehler in der Konfiguration des System (IIS und App Pool) ausschließen.

Das Problem war aber trotzdem relativ schnell gefunden.

Mit dem “früher” als Standardeditor eingesetzten FCK Editor gibt es mit der aktuellen Version (Ich glaube schon seit Version 5.6.X) von DotNetNuke an einigen Stellen Probleme, unter anderem eben auch im Text/HMTL Modul.

Irgendwelche JavaScripte des Editors kollidieren mit anderen JavaScript aufrufen in irgend einer der vielen verwendeten JavaScript Frameworks.

JavaScript eben Smiley

Ich weiß schon warum sich meine Begeisterung für dieses (Java)Script Gedöns in Grenzen hält.

OK, aber lassen wir das.

Ob es einen aktualisierte Version des FCK Editors gibt, die mit DNN Version 6.1 und höher läuft, weiß ich nicht, sollte jemand näheres dazu wissen, würde ich mich über einen entsprechenden Kommentar freuen.

Um das Problem mit den Bordmitteln von DNN zu lösen kann man aber einfach den Texteditor umstellen und anstelle des FCK Editors den Telerik Texteditor, der aktuell als Standardeditor von DotNetNuke verwendet wird.

Hierzu öffnet man die web.config und nimmt folgende Änderung vor:

Den defaultProvider von “FckHtmlEditorProvider” (siehe Vorher) auf “TelerikEditorProvider” (siehe Nachher) ändern

Vorher:

<htmlEditor defaultProvider="FckHtmlEditorProvider">
  <providers>
	<clear />
	<add name="TelerikEditorProvider" type="DotNetNuke.HtmlEditor.TelerikEditorProvider.EditorProvider, DotNetNuke.HtmlEditor.TelerikEditorProvider" providerPath="~/Providers/HtmlEditorProviders/Telerik/" toolsFile="~/Providers/HtmlEditorProviders/Telerik/Config/ToolsDefault.xml" configFile="~/Providers/HtmlEditorProviders/Telerik/Config/ConfigDefault.xml" FilterHostExtensions="True" />
	<add name="FckHtmlEditorProvider" type="DotNetNuke.HtmlEditor.FckHtmlEditorProvider.FckHtmlEditorProvider, DotNetNuke.FckHtmlEditorProvider" providerPath="~/Providers/HtmlEditorProviders/Fck/" CustomConfigurationPath="~/Providers/HtmlEditorProviders/Fck/custom/FCKConfig.js" EnhancedSecurityDefault="false" SecureConfigurationPath="~/Providers/HtmlEditorProviders/Fck/custom/FCKConfigSecure.js" ImageGalleryPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" ImageUploadPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" ImageAllowedFileTypes="gif,png,bmp,jpg" FlashGalleryPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" FlashUploadPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" FlashAllowedFileTypes="fla,swf" LinksGalleryPath="~/Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx" DynamicStylesGeneratorPath="~/Providers/HtmlEditorProviders/Fck/FCKStyles.aspx" DynamicStylesCaseSensitive="true" DynamicStylesGeneratorFilter="controlpanel|filemanager|mainmenu|wizard" StaticStylesFile="~/Providers/HtmlEditorProviders/Fck/FCKeditor/fckstyles.xml" StylesDefaultMode="dynamic" DynamicCSSGeneratorPath="~/Providers/HtmlEditorProviders/Fck/FCKCSS.aspx" StaticCSSFile="~/Providers/HtmlEditorProviders/Fck/FCKeditor/editor/css/fck_editorarea.css" CSSDefaultMode="dynamic" spellCheck="ieSpell" AvailableToolbarSkins="Office2003,Silver" DefaultToolbarSkin="Office2003" AvailableToolBarSets="DNNDefault,Default,NoGallery,Basic" DefaultToolbarSet="DNNDefault" DefaultImageGallerySkin="Default" DefaultFlashGallerySkin="Default" DefaultLinksGallerySkin="Default" FCKDebugMode="false" UseFCKSource="false" OptionsOpenMode="ShowModalDialog" ShowModuleType="true" FixOldDNNPostback="false" CustomOptionsDialog="Admin" />
  </providers>
</htmlEditor>

Nachher:

<htmlEditor defaultProvider="TelerikEditorProvider">
  <providers>
	<clear />
	<add name="TelerikEditorProvider" type="DotNetNuke.HtmlEditor.TelerikEditorProvider.EditorProvider, DotNetNuke.HtmlEditor.TelerikEditorProvider" providerPath="~/Providers/HtmlEditorProviders/Telerik/" toolsFile="~/Providers/HtmlEditorProviders/Telerik/Config/ToolsDefault.xml" configFile="~/Providers/HtmlEditorProviders/Telerik/Config/ConfigDefault.xml" FilterHostExtensions="True" />
	<add name="FckHtmlEditorProvider" type="DotNetNuke.HtmlEditor.FckHtmlEditorProvider.FckHtmlEditorProvider, DotNetNuke.FckHtmlEditorProvider" providerPath="~/Providers/HtmlEditorProviders/Fck/" CustomConfigurationPath="~/Providers/HtmlEditorProviders/Fck/custom/FCKConfig.js" EnhancedSecurityDefault="false" SecureConfigurationPath="~/Providers/HtmlEditorProviders/Fck/custom/FCKConfigSecure.js" ImageGalleryPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" ImageUploadPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" ImageAllowedFileTypes="gif,png,bmp,jpg" FlashGalleryPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" FlashUploadPath="~/Providers/HtmlEditorProviders/Fck/fckimagegallery.aspx" FlashAllowedFileTypes="fla,swf" LinksGalleryPath="~/Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx" DynamicStylesGeneratorPath="~/Providers/HtmlEditorProviders/Fck/FCKStyles.aspx" DynamicStylesCaseSensitive="true" DynamicStylesGeneratorFilter="controlpanel|filemanager|mainmenu|wizard" StaticStylesFile="~/Providers/HtmlEditorProviders/Fck/FCKeditor/fckstyles.xml" StylesDefaultMode="dynamic" DynamicCSSGeneratorPath="~/Providers/HtmlEditorProviders/Fck/FCKCSS.aspx" StaticCSSFile="~/Providers/HtmlEditorProviders/Fck/FCKeditor/editor/css/fck_editorarea.css" CSSDefaultMode="dynamic" spellCheck="ieSpell" AvailableToolbarSkins="Office2003,Silver" DefaultToolbarSkin="Office2003" AvailableToolBarSets="DNNDefault,Default,NoGallery,Basic" DefaultToolbarSet="DNNDefault" DefaultImageGallerySkin="Default" DefaultFlashGallerySkin="Default" DefaultLinksGallerySkin="Default" FCKDebugMode="false" UseFCKSource="false" OptionsOpenMode="ShowModalDialog" ShowModuleType="true" FixOldDNNPostback="false" CustomOptionsDialog="Admin" />
  </providers>
</htmlEditor>

DotNetNuke 6.0 Final Release – Ein letztes großes VB.NET Projekt wird zu Grabe getragen

Mit dem Finalen Release 6.0 des Open Source CMS Frameworks DotNetNuke wird unter anderem auch eines der letzten großen VB.NET Open Source Projekte sein Ende finden.

Da eine Migration eines DotNetNuke 5 Portals nach 6.0 keine größeren Umstände bereiten sollte, ist zu vermuten und auch zu hoffen, dass mit der Version 5.6.3 die letzte VB.NET Version von DotNetNuke veröffentlicht wurde und die zukünftige Entwicklung komplett auf Basis der C# Version fortgeführt wird.

Die Highlights sind:

  • Umstellung des Framework von VB.NET auf C#
  • Die UI/UX wurden komplett überarbeitet (wem es gefällt)
  • Windows Azure kompatibel
  • SQL Azure kompatibel

DotNetNuke 6 kann direkt über das Open Source Community Portal Codeplex heruntergeladen werden.

Hier geht es direkt zum Download

DotNetNuke 6 RC (Release Candidate) steht zum Download bereit

Nach 8 Monaten Entwicklungszeit steht nun seit Gestern Abend der Release Candidat der Version 6, der ersten C# Version von DotNetNuke zum Download zur Verfügung.

Der Release Candidate hat die Build Nummer 2962 und kann auf www.codeplex.com heruntergeladen werden.

Hier geht es direkt zum Download auf Codeplex

DotNetNuke 6 Beta 2 seit Gestern verfügbar

Irgendwie scheint es die letzen Wochen nicht so viel interessantes gegeben zu haben über dass sich das Schreiben lohnen würde.

Gut Google+ wäre ein Thema, aber darüber haben schon so viele geschrieben, über MVC, Razor und HTML5 schreiben sowieso momentan alle, über die BlogEngine gibt es seit der letzten Version auch nichts neues zu berichten.

Und so kommt es, dass meine letzen Beiträge, und auch dieser wieder, über DotNetNuke handelt.

Nun gut, dann zum eigentlichen Thema dieses Beitrags.

DotNetNuke Version 6 Beta 2 ist steht seit Gestern Abend zum Download bereit.

Da ich diese Version selbst noch nicht getestet habe, hier der Link zum Download und einige Informationen die ich über diese Version bisher zusammentragen konnte:

Hier geht es zum Download

Unbedingt bei den Versionen auf die Build Nummer achten, die Beta 2 hat die Build Nummer 2756. Der Build 2300 ist Beta 1

Und hier die „signifikanten“ Änderungen zur Beta 1

  • Modal Popup nur noch standardmäßig für Core Funktionen aktiviert
  • Support für eine neue DNN 6 Manifest Struktur
  • Neue Standard Skins
  • Und hoffentlich ganz viele Fehlerbehebungen ( z.B. IE9 )
  • Installation von Multi-Language Packs

Ich werde sicherlich in den nächsten Tagen diese neue Version auch noch genauer unter die Lupe nehmen.

Und wenn es sich lohnt, werde ich darüber noch einmal ausführlicher berichten.

Übrigens: Im Bereich Mehrsprachigen Inhalt hat sich leider nichts getan.

DotNetNuke 5.6.3 seit letzter Nacht verfügbar !

Obwohl alle nur noch über DotNetNuke 6.0 sprechen geht vorerst die Entwicklung der 5. er Version weiter.

Letzte Nacht wurde eine neue Version „DotNetNuke 5.6.3“ zum Download bereitgestellt.

Diese Version war notwendig da es massive Probleme mit DotNetNuke 5.6.2 und dem Internet Explorer 9 (IE9 ) gegeben hat.

Unter anderem wurde in dieser Version das aktuelle Servicepack 2 der verwendeten Telerik Controls integriert.

Außer einer Reihe von Sicherheitsproblemen die gefixt wurden, gab es keine funktionalen Neuerungen in dieser Version.

Diese werden wohl erst wieder mit der Version 6 folgen.

Die Version 5.6.3 gibt es wie immer auf Codeplex.Com

Hier der direkte Link zum Download der Version 5.6.3

DotNetNuke – Mehrsprachige Portale auch mit der Version 6 noch immer nicht wirklich realisierbar

Vorab die Kernaussage dieses Beitrags für all diejenigen die nicht meinen ganzen Frust und viele Einzelheiten zu dem Thema „Mehrsprachige Portale mit DotNetNuke“ lesen möchten.

Auch mit DotNetNuke 6.0 werden im Core Mehrsprachige Portale nicht umzusetzen sein.

Ich hatte gehofft einen solchen Artikel niemals schreiben zu müssen, aber nachdem auch nach 9 Jahren, die DotNetNuke Mannschaft es nicht geschafft hat, DotNetNuke mit echten Mehrsprachigen Funktionalitäten auszustatten, denke ich, dass wir es wirklich aufgeben können, auf eine durchgängige Corelösung zu warten.

Ich hatte die Hoffnung, dass im Zuge der großen Umstellung von VB zu C# nun endlich die weichen gestellt werden, aber leider wurde diese Hoffnung nicht erfüllt.

Nicht jetzt und nicht mit diesem Konzept, dass sicherlich nur von Englischen Muttersprachlern über dem großen Teich verstanden und verteidigt werden kann.

Ich möchte nur kurz das Prinzip des Konzepts erläutern (ausführlicher Lohnt sich wirklich nicht)

  • Start Konzept
    • Es werden alle Seiten und alle darauf vorhandene Module für jede installierte und aktivierte Sprache dupliziert.
  • Ende Konzept

OK, ein klein wenig mehr hat man sich dabei evtl. schon gedacht, aber ich sagte ja, ich wollte nur das Prinzip beschreiben, und viel mehr ist es auch nicht.

Soweit könnte man sich aber mit dem Grundkonzept abfinden, da dieses Konzept zumindest einen Vorteil hätte:

Vorhandene Modul (die Meisten jedenfalls) wären ohne spezielle Anpassung lokalisierbar.

Die Implementierung selbst übertrifft aber an Unübersichtlichkeit alles was ich bisher gesehen habe. das fängt schon damit an, das die Umstellung auf Content Lokalisierung eine Einbahnstrasse ist.

Wer einmal sein Portal auf Content Lokalisierung umgestellt hat, der hat es umgestellt und kann diese Einstellung nicht mehr zurücknehmen.
Hier hilft nur ein Backup, oder sehr aufwendige manuelle Anpassungen und Änderungen in der Datenbank, welche, ich würde mal vermuten „außer mir“ noch maximal eine Handvoll Deutsche DotNetNuke Entwickler vornehmen könnten. (Etwas Werbung darf auch mal sein 🙂 )

Hinzu kommt, dass das Handling dieser Funktionalitäten so „unintuitiv“ sind, dass man alleine um diese Funktionalität einem Kunden zu vermitteln mehr Schulungsaufwand benötigen würde, als für alle anderen Funktionen inklusive Systemadministration zusammen notwendig wären.

Erschwerend kommt aber noch hinzu, dass bei diesem Konzept nachfolgende Themen völlig unberücksichtigt sind:

  • DotNetNuke Host Listen
  • Benutzergruppen
  • Taxonomie
  • Suche

Wie über den Teich zu hören ist, sind die Herren Walker und Co. der Meinung, dass alles, so wie es ist gut ist, und wollen an diesem Konzept festhalten. Man hört einfach nicht auf den falschen Weg weiter zu gehen.

Aber es ist auch kein Wunder, wenn man sieht das bereits seit 2003 immer wieder Team Mitglieder oder dem Produkt nahe stehende Entwickler die sich für echte Belange von Mehrsprachigkeit eingesetzt (und auch ausgekannt) haben keine langfristigen Karten im Core DNN Spiel hatten.

Ich erinnere mich, dass bereits im Jahr 2003/2004 eine Version 1.x gab die für den Deutschen (Mehrsprachigen) Markt angepasst war. Personen die an dieser Version mitgearbeitet haben, wurden damals nicht gerade positiv übern Teich betrachtet.

Es liegt nicht daran, dass DotNetNuke Grundsätzlich nicht mit dem richtigen Konzept Mehrsprachig gemacht werden könnte.

Aber eben mit dem richtigen Konzept, den richtigen Leuten  (denen die etwas davon verstehen) und einer notwendigen Lobby um diese Änderungen durchsetzen zu können.

Leider sind die Herren und Schöpfer von DotNetNuke auf diesem Ohr über Jahre hinweg und ich behaupte auch Heute noch immer vollkommen Taub.

Wenn das Konzept der Lokalisierung von statischen Texten in ASP.NET Anwendungen nicht so einfach und vom Framework vorgegeben worden wäre, dann würden wir, so glaube ich wenigstens, Heute noch darauf warten DotNetNuke für nicht Englische Webseite nutzen zu können.

Zumindest ohne ein Unikat zu erstellen, dass dann nicht mehr aktualisierbar wäre.

Natürlich gibt es Drittanbieter Lösungen für Mehrsprachige Portale mit DNN, aber ich finde keine dieser Lösungen funktioniert zu 100% und außerdem gehört dieses Thema nicht in die Hände von Drittanbietermodulen sondern in den Core eine Produkts.

Wenn ich Heute wirklich ein Mehrsprachiges Portal aufbauen muss, dann verwende ich entweder nicht DNN oder falls es DNN sein muss (wegen zu verwendender vorhandener Module), dann nehme ich eine Child Portal Lösung (Für jede Sprache ein eigenes Child Portal), das ist übrigens sehr nahe am „neuen“ Konzept der Version 6.0.

Doch mit dieser Lösung sind wenigstens das Taxonomie und Suchprobleme gelöst.

DotNetNuke 6.0 Beta – Ein erster schneller Eindruck

Nachdem vor 2 Tagen die erste Beta Version von DotNetNuke 6.0 veröffentlicht wurde möchte ich Heute kurz einen ersten Eindruck, zu den aktuellen Neuerungen und dem Stand der Umsetzung, abgeben.

Hier die Key Feature der Version 6.0

  • Bereits bekannt aber natürlich ein Riesenschritt (Umstellung des Core auf C#)
  • Verwendung von Razor möglich
  • Popup Fenster (JavaScript und noch mehr JavaScript)
  • Seiten Administration komplett geändert
  • Telerik Editor anstelle dec FCK Editors (mal wieder)
  • … und noch einiges mehr
  • Und eigentlich sollte auch mit 6.0 die Content Lokalisierung komplett implementiert sein (Hoffentlich ist das nicht dem Razor Wahn zum Opfer gefallen)

Nach der Installation fällt sofort auf,  dass nichts mehr ohne Javascript geht.

Hier ein Javascript, da ein Popup (wer es mag) und dort wieder ein Script !

Ich finde schon das JavaScript und Popup Fenster an manchen Stellen dezent eingesetzt die Useability erhöhen können, aber wenn es nur noch popt und tabed kann es auch leicht mal unübersichtlich werden.

So ganz sicher scheint man sich aber auch noch nicht zu sein, denn wenn man die neue Seitenadministration sieht, da hat man auf das ganze Popup verzichtet, oder hat man das einfach bisher vergessen 😉

Und natürlich musste auch bei DotNetNuke unbedingt Razor mit eingebaut werden, ich habe hierzu bereits meine Meinung im Beitrag über die BlogEngine 2.5 RC abgegeben.

Echt kritisch ist aber, dass die Administration eines Portals dieser Beta Version mit dem IE9 quasi nicht möglich ist. Mit Chrome scheint aber soweit alles zu funktionieren.

Ich werde mir in den nächsten Tagen die Beta Version auf jeden Fall noch genauer ansehen und sicherlich auch noch den einen oder wenn nötig auch anderen  Beitrag darüber veröffentlichen.

Stand Heute würde ich aber vermuten, dass dies nicht die letzte Beta Version war, bevor es dann irgendwann zum einem RC kommt.

DotNetNuke – Nach C kommt B oder anders gesagt, nach der CTP3 ist nun die Beta 1 Verfügbar

Heute wurde die erste öffentliche Beta Version von DotNetNuke 6.0 veröffentlicht.

Somit ist nach über 3 Monaten (da wurde die letzte CTP Version veröffentlicht) in der sich nichts neues ergeben hat, nun endlich eine aktuellere Version vorhanden.

Ersten Meldungen zu folge gibt es mit dieser Beta Version Probleme mit dem IE9, aber das ist leider nicht wirklich etwas neues.

Mit Chrome soll es diese Probleme übrigens nicht geben (auch nicht neues 🙂 )

Hier geht es direkt zum Download der aktuellen Beta Version DotNetNuke 6.0

Schauen wir mal was uns mit dieser Beta erwartet.

The URL ‚….. for Web project ‚….‘ is configured to use IIS Express as the web server but the URL is currently configured on the local IIS web server.

Die komplette Fehlermeldung die ich erhalten habe lautet wie folgt:

20110622 - IIS Express

Auch wenn dieser Fehler bei arbeiten an einem DotNetNuke Modul aufgetreten ist, kann dieser Fehler in jedem anderen Web Projekt unabhängig von DotNetNuke auftreten.

Was war geschehen.

Ich habe ein laufendes Projekt, von einem Windows 7 Rechner mit Visual Studio 2010 auf dem auch der IIS7 installiert ist, in ein Mercurial Repository gespeichert, und dann später auf einem zweiten Rechner geklont um auf diesem anderen Rechner einige Änderungen vornehmen zu können.

Nach dem Klonen des Projekts musste ich, da der Rechner auf dem ich den Klone erstellt habe, keinen IIS sondern nur den IIS Express installiert hat die Projekteigenchaften dahingehend ändern, dass das Projekt mit dem IIS Express funktioniert.
Was übrigens auch kein Problem war und einwandfrei funktioniert hat.

Bereits zu diesem Zeitpunkt hatte ich mir tatsächlich schon überlegt, ob es zu Problemen führen könnte, wenn ich das Projekt später wieder eingecheckt und dann auf dem ursprünglichen Rechner aktualisiere. Bin aber, da ich neben dem echten IIS auch den IIS Express auf dem ursprünglichen Rechner installiert habe zu der Überzeugung gekommen, dass es keine Probleme geben dürfte, was sich, wie man hier lesen kann nicht bewahrheitete.

Einige Wochen später, natürlich hatte ich mittlerweile vergessen, dass ich eine Umstellung von IIS auf IIS Express vorgenommen hatte, habe ich das Projekt aus dem Mercurial Repository auf dem ursprünglichen Rechner wieder ausgecheckt, bzw. eigentlich nur aktualisiert.

Und nachdem ich mit Visual Studio das Projekt geöffnet habe, kam es zu dem oben beschriebenen Fehler.

Mit der Fehlermeldung konnte ich erst überhaupt nichts anfangen. Dann fiel mir aber ein das ich ja diese IIS Express Änderungen an dem Projekt machen musste um es auf dem auf dem anderen Rechner zum laufen zu bekommen.

Das eigentliche Problem bei diesem Fehler ist, dass sich das Visual Studio Projekt nicht mehr öffnen lässt und daher auch keine Einstellungen geändert werden können. So dass man nicht einfach die Verwendung des IIS Express wieder ausschalten kann. (Ich hätte natürlich händig auch den IIS Express konfigurieren können, das hätte vermutlich auch geholfen)

Ich habe dann folgende Lösung entdeckt, und möchte diese für mich und gegebenenfalls auch für andere die ein solches Problem haben hier veröffentlichen, damit man,  wenn ein solches Problem wieder auftritt diese Lösung wieder finden kann und nicht wieder nach einer Lösung suchen muss.

So nun aber zur eigentlichen Lösung des Problems:

In der Konfigurationsdatei [Projektname].vbproj.user befindet sich unter der Region PropertyGroup folgende Einstellung:

<PropertyGroup>
       <UseIISExpress>true</UseIISExpress>
</PropertyGroup>

Diese Einstellung ändert man auf false, speichert die Datei, macht ein Reload der Projektdatei.

Und fertig.

DotNetNuke – Dateimanager Ordner Baumansicht wird nicht geöffnet

Auf einem DNN Portal das unter DotNetNuke Version 5.6.2 betrieben wird, kommt es plötzlich zu dem Problem, dass beim Klicken auf das Pluszeichen des Dateimanagers, die Unterordner nicht mehr angezeigt werden.

Die nachfolgende Abbildung zeigt dieses Phänomen:

Es sieht so aus, als ob endlos versucht wird die Verzeichnisstruktur zu lesen und darzustellen. Doch dies wird, wenn es erst einmal zu diesem Verhalten gekommen ist, nicht mehr geschehen, auch wenn man noch so geduldig ist.

Ich habe diese Verhalten auf verschiedenen Systemen gesehen und in einigen Fällen kommt es noch zur Ausgabe einer Fehlermeldung ähnlich der nachfolgenden:

„Laufzeitfehler in Microsoft JScript: Sys.ArgumentException: Cannot deserialize empty string. Parameter name: data“

In anderen Fällen, je nach Umgebung, eingesetztem Browser und Browsereinstellungen kann es aber auch vorkommen, dass keine Fehlermeldung ausgegeben wird.

Also nicht darauf verlassen, dass eine Fehlermeldung ausgeben wird.

Und unbedingt beachten: Dieser Fehler verursacht auf keinem mir bekannten Fall einen Eintrag im DNN Ereignisprotokoll.  Da es sich bei diesem Problem um ein Clientseitiges JavaScript Problem handelt, kann DNN von diesem Fehler nichts mitbekommen und dementsprechend auch keine Eintrag in das Ereignisprotokoll vornehmen.

Wenn dieses Problem auftritt, sollte man unter den Systemeinstellungen in den Erweiterten Einstellungen die Einstellungen der Leistungsoptimierung im Bereich kontrollieren,

Wenn dort als Kompressionseinstellungen „GZip-Kompression“ eingestellt ist, dann sollte diese Einstellung dahingehend geändert werden, dass „unkomprimiert“ ausgewählt ist.

Nun noch die Einstellung speichern und ich bin mir ziemlich sicher, dass der Dateimanager nun wieder funktioniert.

Übrigens scheint dieses kein neues Problem in der Version 5.6.2 zu sein, sondern schon in älteren Versionen vorzukommen.

Also wenn ein solches Problem mit einer älteren Version auftritt, auf jeden Fall die Einstellungen prüfen und gegebenenfalls ändern.