Während der Installation von DotNetNuke 5 wird die Verwendung von Ajax 1.0 automatisch eingerichtet.

Das geschieht unter anderem dadurch, dass eine System.Web.Extension DLL Datei in das BIN Verzeichnis von DotNetNuke kopiert wird.

Wenn man sich später am Portal als Host Administrator anmeldet und die Host Einstellungen öffnet findet man dort einen Link mit dem man das Portal auf das aktuelle Framework (Ajax Version 3.0 welches mit dem ASP.NET Framework 3.5 ausgeliefert wird) umstellen kann (siehe nachfolgende Abbildung).

Mit dem betätigen des Links werden 2 Dinge durchgeführt:

• Die Web.Config wird für Ajax 3.0 eingerichtet
• Die System.Web.Extension DLL wird aus dem BIN Verzeichnis von DotNetNuke gelöscht.

Das ganze funktioniert, soweit ich das bisher beurteilen kann, sehr zuverlässig.

Und trotz der Zuverlässigkeit dieser Funktion kann es später unter bestimmten Umständen sehr leicht zu folgendem Fehler kommen:

Die Ursache für dieses Problem ist. das nach der Umstellung des Framework, aus welchem Grund auch immer, die System.Web.Extension DLL Datei wieder im BIN Verzeichnis von DotNetNuke vorhanden ist.

Das geschieht natürlich nicht aus versehen oder von selbst, aber durch eine Sicherung die man zurückspielt oder durch Verwendung einer Versionsverwaltung kann das ganz schnell geschehen.

Abhilfe schafft das einfache löschen dieser System.Web.Extension DLL Datei aus dem BIN Verzeichnis von DotNetNuke.

Eventuell muss man noch den Applikation Pool abschießen oder alternativ einfach die web.config mit einem Editor öffnen und speichern, damit dadurch das Portal neu gestartet wird.

Das ist Neu, zum ersten mal auch ein Release Candidate einer DotNetNuke Version öffentlich für alle Zugänglich.

DotNetNuke Version 5.0 (RC2) steht seit letzter Nacht zum Download für die Öffentlichkeit zur Verfügung.

Aber Achtung, auch wenn die Version nun öffentlich zugänglich ist, sollte man diese Version nicht für den Live Einsatz eines Portals verwenden, welches man, nicht nachdem die endgültige Version fertiggestellt wurde wieder, löscht und mit der offiziellen Version neu aufbaut.

Ich erinnere mich noch an die Probleme die es, sowohl bei der 3er als auch bei der 4er Version, gab, wenn man die Beta Versionen später versucht hat mit einer aktuelleren Version zu aktualisieren. Da fehlte es hier und da, vor allem an Konsistenz in der Datenbank.

Also Finger weg vom Live Einsatz dieser Version.  Auf jeden Fall dann wenn man mit dem Gedanke spielt, diese nach Veröffentlichung des offiziellen Release weiter betreiben zu wollen.

Hier geht es zum Download der DotNetNuke Version 5.0 RC 2 (Cambrian)

In den letzten Wochen haben mir einige Leute, die in den Genuss der Beta Version bzw. des Release Kandidaten von DotNetNuke 5.0 (Cambrian) gekommen sind, über folgendes Problem bei der Installation berichtet.

Das Problem ist übrigens auch im offiziellen englischsprachigen DotNetNuke Forum beschrieben, allerdings ohne eine entsprechende Lösung für das Problem zu beinhalten.

Hier nun die Problembeschreibung:

Beim Versuch der Installation auf einem Windows XP Rechner erhält man plötzlich folgende Fehlermeldung:

System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.UI.Utilities.MSAJAX.Serialize(Object Obj) 
at DotNetNuke.UI.Utilities.ClientAPI.SerializeClientVariableDictionary(Page objPage, Dictionary`2 objDict) 
at DotNetNuke.UI.Utilities.ClientAPI.CAPIPreRender(Object Sender, EventArgs Args) 
at System.Web.UI.Control.OnPreRender(EventArgs e) 
at System.Web.UI.HtmlControls.HtmlInputHidden.OnPreRender(EventArgs e) 
at System.Web.UI.Control.PreRenderRecursiveInternal() 
at System.Web.UI.Control.PreRenderRecursiveInternal() 
at System.Web.UI.Control.PreRenderRecursiveInternal() 
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Wenn man die Fehlermeldung sehr aufmerksam ließt, dann erhält man eigentlich schon die Antwort auf das Problem beschrieben.

Das Problem liegt in diesem Fall daran, dass die ASP.NET Ajax Extension für ASP.NET 2.0 nicht oder nicht richtig installiert sind.

Die Ajax Extension für ASP.NET 2.0 kann man hier herunterladen.

Wenn die Ajax Extension noch nicht installiert sind, dann einfach die Extension installieren, sonst muss man zuerst die Ajax Extension deinstallieren und dann noch einmal neu installieren.

Ich möchte in diesem Beitrag nicht ergründen, ob das von mir geschilderte Problem durch DotNetNuke oder den Service Pack 1 für das NET Framework 2.0 verursacht wird. Fakt ist auf jeden Fall das dieses Problem in der von mir beschriebenen Konstellation auftritt.

Das Problem stellte sich bei mir wie folgt dar (Windows XP Rechner):

• Source Version von DotNetNuke 4.08.00 entpackt (C:\DNN_4_8_0).
• development.config nach web.config umbenannt (Alle Einstellungen belassen)
• Virtuelles Verzeichnis (dnn488) auf Localhost angelegt.
• Verzeichnisrechte (C:\DNN_4_8_0) für ASPNET Benutzer (ALLE Rechte) gesetzt.
• Internet Explorer, URL (localhost/dnn488) des virtuellen Verzeichnis eingegeben und aufgerufen.
• Installationswizzard mit Auto ausgeführt.
• Installation ist einwandfrei durchgelaufen.
• Nun Link zum Start des Portal aufgerufen --> Nix.

Im IE einfach nur warten...

Mit Firefox bekommt man eine Meldung dass man sich in einer Endlosschleife befindet und man nie ein Ergebnis erzielen wird

Nach einigen Recherchen und Versuchen (wenn man anstelle der development.config die release.config verwendet geht es übrigens) war klar wo das Problem liegt.

<trust level="Medium" originUrl=".*" />

Der oben dargestellt Eintrag für dazu dass man in ein ewiges Redirect Status Codes 302 gerät.

Auf einem Entwicklungsrechner kann man einfach diese Zeile in der web.config auskommentieren und schon funktioniert der Aufruf des Portals wie erwartet.

Das Problem hat übrigens nichts mit der verwendeten DotNetNuke Version 4.8.0 zu tun, es tritt sowohl bei den neuen Versionen 4.8.1 und 4.8.2 als auch bei früheren Versionen 4.5.3 und 4.6.2 auf.

Meistens verweise ich in den Foren auf Beiträge in meinem Blog. Nicht so  in diesem Fall und deshalb Heute einmal anders herum

Im Forum der Deutschen DotNetNuke Community habe ich heute eine ausführliche Antwort auf die Frage nach der Einrichtung von mehreren Portalen auf einem Client Rechner gegeben.

Meiner Erfahrung nach, bin ich mir jedoch sicher, das dieses Thema auch von allgemeinem Interesse sein könnte, daher hier der Link zum Forum Beitrag:

http://www.dnnportal.de/Default.aspx/tabid/178/g/posts/t/2583

Mit jeder Version von DotNetNuke gibt es Änderungen in der web.config, so natürlich also auch in der Version 4.8.0.

Was ist neu (gegenüber der Version 4.7.0) in der web.config von DotNetNuke Version 4.8.0.

Dieses mal Eigentlich nichts ...!

Mit Ausnahme des Supports für den IIS 7.

Hierzu wurde der web.config ein neuer Abschnitt <system.webServer> spendiert.

Der gesamte neue Abschnitt sieht wie folgt aus:

<system.webServer>
    <modules>
        <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
        <add name="Compression" type="DotNetNuke.HttpModules.Compression.CompressionModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="RequestFilter" type="DotNetNuke.HttpModules.RequestFilter.RequestFilterModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="Exception" type="DotNetNuke.HttpModules.Exceptions.ExceptionModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="UsersOnline" type="DotNetNuke.HttpModules.UsersOnline.UsersOnlineModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="DNNMembership" type="DotNetNuke.HttpModules.Membership.MembershipModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
        <add name="Personalization" type="DotNetNuke.HttpModules.Personalization.PersonalizationModule, DotNetNuke.HttpModules" preCondition="managedHandler" />
    </modules>
    <handlers>
        <add name="AJAX_ScriptResourceHandler" path="ScriptResource.axd" verb="GET,HEAD" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="AJAX_AppServiceHandler" path="*_AppService.axd" verb="*" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="AJAX_WebServiceHandler" path="*.asmx" verb="*" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="LogoffHandler*" path="Logoff.aspx" verb="*" type="DotNetNuke.Services.Authentication.LogOffHandler, DotNetNuke" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="RSSJandler" path="RSS.aspx" verb="*" type="DotNetNuke.Services.Syndication.RssHandler, DotNetNuke" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="LinkClickHandler" path="LinkClick.aspx" verb="*" type="DotNetNuke.Services.FileSystem.FileServerHandler, DotNetNuke" preCondition="integratedMode,runtimeVersionv2.0" />
        <add name="CaptchaHandler" path="*.captcha.aspx" verb="*" type="DotNetNuke.UI.WebControls.CaptchaHandler, DotNetNuke" preCondition="integratedMode,runtimeVersionv2.0" />
    </handlers>
    <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

Wer also bereits DotNetNuke 4.7.0 installiert hat und ein Update auf die Version 4.8.0 durchführen will, kann einfach seine web.config nehmen und diesen Abschnitt aus der neuen config in seine web.config kopieren (Einfach vor dem Bereich <system.web> einfügen).

Übrigens kann man diesen Bereich problemlos auch dann einfügen, wenn man (noch) mit dem IIS 6 arbeitet, dieser ignoriert diesen Bereich einfach.

Dann viel Spaß beim Update und Sicherung der Datenbank und des Applikationsverzeichnisses nicht vergessen

In diesem Beitrag geht es um die Einrichtung des Open Source Zugriffsstatistik Tool AWStats in Verbindung mit DotNetNuke.

Systemvoraussetzungen

Zuerst einmal die Voraussetzungen die erfüllt sein müssen, damit man dieses Analyse Tool zusammen mit DotNetNuke einsetzen kann:

• PERL Erweiterungen müssen installiert und aktiviert sein
• Internet Log Dateien im IIS müssen aktiviert sein oder/und
• In den Systemeinstellungen in DotNetNuke muss als Protokollspeicher das Dateisystem gewählt sein (siehe nachfolgende Abbildung)
  
  

Verwendung des IIS Protokolls

Wenn man das Protokoll des IIS verwenden möchte dann sollte man die nachfolgenden Einstellungen dazu verwenden:

Um den Speicherort der Log Dateien zu ermitteln (ja den brauchen wir später) genügt ein Klick auf Eigenschaften:

Dort können wir sehen wo die Log Dateien abgelegt werden und wie sie benannt werden. In unserem Hier abgebildeten Beispiel ist das:

Allgemeine Verzeichnis für Protokolle des IIS D:\Logs und das Unterverzeichnis in dem die Log Dateien dieses web abgelegt werden hat hier den Namen W3SVC1338318087. Also lautet der Zugriffspfad zu den Protokollen D:\Logs\W3SVC1338318087. Darin werden die Logdateien vom IE erstellt.

Verwendung des DotNetNuke Dateisystem Protokolls

Um die Einstellungen in DotNetNuke vornehmen zu können muss man sich als Systemadministrator (Host) anmelden. Dann muss man zunächst in den Systemeinstellungen kontrollieren ob, und gegebenenfalls die Einstellungen korrigieren, das überhaupt eine Loginformation erzeugt wird.

Um überhaupt eine Protokollierung der Seitnaufrufe in DotNetNuke zu aktivieren, müssen die beiden Einstellungen wie folgt vorgenommen werden:

Im Feld Protokollzeitraum muss mindesten der Wert 1 (1 Tag) angegeben werden damit ein Protokolleintrag erstellt wird.
Wenn der Wert 0 eingegeben wird, wird das Protokoll deaktiviert (es geschieht also gar nichts, weder in einem Datenbank noch in einem Dateisystem Protokoll).

Im Feld Protokollgröße sollte für normal stark frequentierte Seiten einfach eine 1 eingetragen werden, bei stärker frequentierten Seiten (> 500000 Zugriffe / Monat) sollte man mit höheren Werten experimentieren. Eine 0 in diesem Feld führt ebenfalls dazu dass keine Zugriffsprotokollierung erfolgt.

Um nun die Protokollierung in einem Format zu speichern, welches  von AWStats verwendet werden kann um die Zugriffsstatistik zu erstellen, muss noch die Einstellung Portalprotokollspeicher auf Dateisystem eingestellt werden.

Hinweis zur DotNetNuke Einstellung bzw. der Übersetzung der Einstellung

An dieser Stelle möchte ich einen Hinweis auf eine nicht richtig verstandene (übersetzte) Einstellung geben. Dazu schauen wir uns einen Teilbereich der Systemeinstellungen, einmal im Original (in  Englisch) an,  und einmal in der Deutschen Übersetzung:

Hier zuerst der Ausschnitt der Einstellung im Original:

Und hier in der Übersetzung:

Aus dem englischen "Site Log Buffer (Items)" wird Protokollgröße (Einträge).

Protokollgröße impliziert, dass man mit dieser Einstellung die Größe oder Anzahl der Einträge in der Protokolldatei einstellen würde.

Dem ist aber nicht so.

Mit dieser Einstellung gibt man vor ob die Daten des Protokolls gepuffert (Schreibvorgang erst nach Anzahl Einträgen durchführen) oder ungepuffert (nach jedem Eintrag sofort in die Log Datei schreiben) geschrieben werden. Außerdem führt ein Eintrag von 0 dazu dass die gesamte Protokollierung deaktiviert wird.

Technisch könnte man die Einstellungen wie folgt definieren:

• 0 bedeutet Protokollfunktion ist ausgeschaltet
• 1 ungepuffert (Protokoll wird bei jedem Eintrag sofort geschrieben) [Eventuell Performanceproblem bei Seiten mit vielen Zugriffen]
• > 1 Anzahl Einträge die gepuffert werden bevor ein Schreibzugriff stattfindet.

Nun aber zurück zu dem eigentlichen Thema dieses Beitrags "Wie richte ich AWStats zusammen mit DotNetNuke ein".

Nachdem die Einstellungen, wie hier beschrieben, vorgenommen wurden, wird das Zugriffsprotokoll nun im Dateisystem und nicht mehr in der Datenbank erstellt. Die Protokolle werden im Unterverzeichnis Logs des jeweiligen Portal Root Verzeichnisses angelegt (Beispiel wenn DotNetNuke auf C:\DotNetNuke installiert ist, dann findet man die Log Dateien für da Portal 0 (wenn man keine abweichen Benamung vorgenommen hat) im Verzeichnis C:\DotNetNuke\Portals\0\Logs). Diese Information benötigen wir später zur Konfiguration von AWStats.

Einrichtung und Konfiguration AWStats

AWStats kann komplette mit Source direkt von hier herunter geladen werden (Bitte das ZIP File herunterladen).

Die Beispiel Konfigurationsdateien für DotNetNuke kann man hier herunter laden:

Jetzt entpackt man das AWStats Archiv und kopiert alles aus dem Unterverzeichnis wwwroot ist in das Root Verzeichnis von DotNetNuke, das sind folgende Verzeichnisse.

Danach entpackt man die Dateien aus dem Konfigurationsarchiv direkt in das cgi-bin Verzeichnis.

Und jetzt sind noch folgende Anpassungen an den Konfigurationsdateien vorzunehmen:

Falls man den Namen der Konfigurationsdatei awstats.www.myDomain.de.conf nicht ändert, muss man in der Batch Datei Updatestats.bat keine Änderungen vornehmen. Wenn man die Konfigurationsdatei aber umbenennt, muss man den Namen in der Batch Datei anpassen.

Also die Zeile perl awstats.pl -config=www.MyDomain.de -update, so anpassen, dass der Name der Konfigurationsdatei richtig angegeben ist.

Die Konfigurationsdatei ist schon soweit vorbereitet, dass man lediglich für die Einrichtung mit der DotNetNuke Protokoll Datei die Herkunft der Protokolldateien, also den richtigen Pfad eintragen muss. Dazu öffnet man die Datei awstats.www.myDomain.de.conf mit einem Texeditor und sucht folgende Stelle:

LogFile="C:\DotNetNuke\Portals\0\Logs\ex%YY-6%MM-6%DD-6.log"

Hier ersetzt man nun den Teil  C:\DotNetNuke\Portals\0\Logs der Pfadangabe mit dem Pfad den wir aus unserer Installation ermittelt haben.

Nun sucht man den Eintrag:

SiteDomain=www.schelian.de und ersetzt www.schelian.de mit dem Namen der Domain für den AWStats eingerichtet werden soll.

Wenn man das Protokoll vom IE anstelle des DotNetNuke Protokolls verwenden möchte, muss man zusätzlich zum eben genannten Eintrag noch den Parameter LogFormat ändern.

Dazu sucht man den nachfolgenden Eintrag in der Konfigurationsdatei:

LogFormat="date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status"

und kommentiert ihn durch voranstellen eines # aus.

Anschließend entfernt man das Kommentarzeichen am Anfang der folgenden Zeile.

#LogFormat="date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken"

So dass diese Zeile gültig ist.

Nun richtet man im Windows Zeitplandienst (Scheduler) noch eine Aufgabe (Task) ein der Alle 6 Stunden die Batch Datei Updatestats.bat ausführt.

Damit ist die Einrichtung von AWStats soweit abgeschlossen, dass AWStats die Protokolldateien analysiert und umfangreiche Statistiken erstellt.

Anzeige der Statistiken

Was nun noch fehlt ist der Aufruf (die Anzeige) der Statistik.

Wenn die Domain www.mydomain.de heißt, dann lautet der Aufruf zur Anzeige der Statistik www.mydomain.de/cgi-bin/awstats.pl.

Noch ein Hinweis zum Schluss:

Sollte man bereits alte Protokolle haben, welche man durch AWStats abarbeiten lassen möchte, so kann ich hier auf einen früheren Beitrag hinweisen, der sich genau mit diesem Thema befasst.

Hier der Link zum Beitrag: http://blog.schelian.de/2005/02/06/AwstatsAlteLogDateienEinlesen.aspx

Ein etwas soliderer Titel wäre sicherlich:

FCK Editor - Individuelle Editoreinstellungen in DotNetNuke - Teil 1

Zur Systemumgebung die ich verwendet habe um diesen Beitrag zu erstellen, sei folgendes gesagt:

Die Einstellungen sind in einem System mit installiertem DotNetNuke 4.5.3 durchgeführt. Es sollte aber keine Änderung zu neueren Versionen geben. Den letzten Test habe ich mit der Version 4.7.0 durchgeführt. Ebenso sollten die Einstellungen bereits bei älteren Versionen funktionieren die als Standard Editor den FCK enthalten haben.

Vorab eine kurze Beschreibung des in diesem Beitrag behandelten Themas:

Nachdem man DotNetNuke mit seinem Standard Text Editor FCK installiert hat, stellt man ziemlich schnell und ebenfalls ernüchternd fest, dass bei der Eingabe und Formatierung von Texten im Editor Fenster des FCK leider während der Eingabe nicht die im Portal oder den Skins verwendeten CSS Formatierungen angewendet werden. Der Text sieht also nicht so aus, wie er später auf der Web Seite dargestellt wird.

Was wäre also wünschenswerter, als dass man bei der Eingabe des Textes auch die endgültige Formatierung (WYSIWYG) angezeigt bekommt.

WYSIWYG steht für What You See Is What You Get (oder mehr darüber auf Wikipedia)

Der FCK Editor Provider (Version 1.00.09) für DotNetNuke selbst stellt schon alles notwendige an Funktionen zur Verfügung was man benötigt um die entsprechende Anforderung umzusetzen (wenigstens so gut wie).

Anschließend nun die Beschreibung der Schritte die notwendig sind, um das Ziel WYSIWYG zu erreichen.

Schritt 1 (Die Vorbereitung):

Zuerst bereiten wir eine CSS Datei vor, welche alle von uns verwendeten CSS Definitionen enthält. Oder anders ausgedrückt, wir erstellen eine leere Datei (zum Beispiel mit dem Namen FCK.CSS) und kopieren von dem Skin.css und dem Portal.css oder wo auch immer wir CSS Definitionen vorgenommen haben, die Definitionen in diese CSS Datei. Diese Datei speichert man am besten im Portal Root ab. Wenn das geschehen ist, sind bereits alle Vorbereitungen abgeschlossen und wir können uns nun den Einstellungen widmen, die dann dazu führen, dass unsere in der Datei FCK.CSS Definierten CSS Formate im Editor Bereich des FCK Editor verwendet wird.

Schritt 2 (Einstellungen durchführen):

Schauen wir uns dazu mal einen Bildschirmausschnitt an (In diesem Ausschnitt sehen wir ein geöffnetes Editorfenster):

Wenn wir uns die linke untere Ecke des Bildschirmausschnitt's näher betrachten, dann sehen wir dort unter anderem einen Link mit der Beschriftung:

"Individuelle Editoreinstellungen"

Wenn wie diesen Link anklicken, wird das nachfolgend dargestellte Fenster geöffnet. Mal sehen, was es da zum Einstellen gibt.

Ich möchte an dieser Stelle nun nicht alle möglichen Optionen besprechen, sondern nur diese erwähnen, welche Notwendig sind um die gewünschte WYSIWYG Darstellung zu ermöglichen.

Die Einstellung, worauf es uns in diesem Beitrag ankommt, befindet sich in der Mitte des Bildschirmausschnitt's und hat den Namen "CSS für Eingabebereich"

Guckst du hier

Öffnen wir doch mal diesen Bereich der Editor Optionen und betrachten uns das einmal näher:

"CSS Generator": In der Beschreibung dazu heißt es: "Diese Option legt fest wie die CSS Datei generiert wird". Egal was auch immer das heißen mag, wir müssen als Option URL auswählen.

Unter "Individuelle CSS Datei" finden wir den Linktyp. Bei Linktyp wählen wir Datei (in Ihrem Portal) aus.

Nun können wir mit "Dateipfad" und "Dateiname" die von uns vorbereitete Datei, in unserem Fall die Datei FCK.CSS im Portal Root, auswählen.

Und nun ganz wichtig, guckst du hier:

Am unteren Rand des Fensters kann man für die eben durchgeführten Einstellungen noch angeben ob diese Einstellungen nur für dieses eine speziellen Editor Fenster (Instanz) oder für alle Editor Fenster dieses Moduls (Modul) oder für alle in diesem Portal (Portal)verwendeten Editor Fenster gelten soll.

Bei unseren Einstellung handelt es sich um eine Einstellung die wir für das ganze Portal vornehmen möchte, also müssen wir, bevor wir die Einstellungen speichern noch in der Auswahlbox auf Portal stellen und dann den Link übernehmen betätigen.

Fertig - Nun sollten die richtigen CSS Format bereits während der Eingabe von Texten verwendet werden und wir haben damit unserem Wunsch nach WYSIWYG erfüllt.

Noch eine Anmerkung zum Schluß:

Sollte, nachdem die von uns erstellte Datei FCK.CSS nicht in der Auswahlbox "Dateiname" zu sehen, sein, kann dies daran liegen, dass die Synchronisation zwischen der Dateistruktur und der Datenbank noch nicht, oder fehlerhaft war.

Um Abhilfe zu schaffen, genügt es meistens schon:

Einfach den Dateimanager zu öffnen und den Link "Ordner Synchronisieren" anzuklicken.

Wie ich bereits in meiner Ankündigung der Verfügbarkeit der neuen Version berichtet habe, wurde DotNetNuke in der Version 4.7.0 ein neues Feature spendiert:

Die Benutzerfreundlichen URLs oder wie sie in englischen heißen: Human Friendly URLs

Dieses neue Feature ist leider nur für eine ganze Installation und nicht für jedes Portal separat einschaltbar.

Wobei der Ausdruck "einschaltbar" etwas irreführend ist, da man nicht einfach dieses Feature durch einen Schalter aus der Systemeinstellung ein bzw. ausschalten kann.

Um dieses  Feature zu aktivieren ist es notwendig in dem Bereich friendlyUrl in der web.config dem Provider ein Attribut manuell hinzuzufügen. Man hat wohl irgendwie vergessen, oder keine Zeit mehr gehabt, den Default Wert in die web.config zu übernehmen, so dass man dann ziemlich einfach gewusst hätte wie man zwischen den Suchmaschinenfreundlichen und den Benutzerfreundlichen URLs umschalten kann.

Bevor ich nun zeige was man in die web.config eintragen muss um dieses Feature zu aktivieren möchte ich zuerst kurz erläutern wie sich der Einsatz dieser Funktion auf die URLs auswirkt.

In frühen Versionen von DotNetNuke, oder auch Heute noch ohne den Einsatz der Suchmaschinenfreundlichen URLs hat eine URL in DotNetNuke typischer weise so ungefähr ausgesehen:

http://www.schelian.de/default.aspx?tabid=257 (Diese URL führt auch dann noch zum Ziel, wenn man die Freundlichen URLs verwendet)

In den neueren Versionen von DotNetNuke hat man dann die Suchmaschinenfreundlichen URLs hinzugefügt, da Suchmaschinen nicht gerade über Parameter in der URL erfreut waren und häufig solche Seiten nicht indiziert haben.

Und was nutz der beste Content, wenn Ihn keiner findet - Nichts.

Die gleiche Seite wie im obigen Beispiel hat mit den Suchmaschinenfreundlichen URLs das nachfolgende aussehen bekommen:

http://www.schelian.de/Entwicklung/DotNetNuke/tabid/257/Default.aspx

Nun ist diese URL zwar ohne Parameter, aber wenn man diese URL manuell in einen Browsers eingeben oder sich merken will, dann ist sie auch noch nicht optimal.

Hier würde eine URL wie:

http://www.schelian.de/Entwicklung/DotNetNuke.aspx doch einiges erleichtern.

Und genau das ist das Ergebnis wenn man anstelle der Suchmaschinenfreundlichen URLs die Benutzerfreundlichen URLs verwendet.

Der Hasenfuß dabei ist aber, dass diese schönen URLs nur (bisher wenigstens) funktionieren, solange die Module keine eigenen URL Parameter mehr anfügen. Da bedeutet, die Benutzerfreundlichen URLs enden da wo es um den direkten Link zur Seite geht.

Da auch die Suchmaschinen sicherlich nichts gegen diese Art von URLs haben, würde ich diese Art der URL einfach als freundliche URL bezeichnen, sowohl Suchmaschinen als auch Benutzerfreundlich.

So nun aber mehr dazu, wie man diese Funktion aktivieren kann:

Mann muss DotNetNuke ab Version 4.7.0 installiert haben.

Dann öffnet man die web.config und sucht den Abschnitt friendlyUrl.

Der sieht im Original so aus:

<friendlyUrl
  defaultProvider="DNNFriendlyUrl">
	<providers>
		<clear/>
		<add
		  name="DNNFriendlyUrl"
	 type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules"
					includePageName="true"
					regexMatch="[^a-zA-Z0-9 _-]" />
	</providers>
</friendlyUrl>

In diesem Abschnitt muss man dem Provider ein neues Attribut "urlFormat" wie nachfolgend abgebildet hinzufügen:

<friendlyUrl
  defaultProvider="DNNFriendlyUrl">
	<providers>
		<clear/>
		<add
		  name="DNNFriendlyUrl"
		  type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules"
					includePageName="true"
					urlFormat="HumanFriendly"
					regexMatch="[^a-zA-Z0-9 _-]" />
	</providers>
</friendlyUrl>

Für das Attribut urlFormat sind die folgenden beiden Werte gültig:

• HumanFriendly
• SpiderFriendly

Zum Schluß sei noch bemerkt, dass die Umstellung auf die Benutzerfreundlichen URLs nicht dazu führt, dass die "alten" Links nicht mehr gültig sind, sondern die URLs werden auch nach der Umstellung noch auf die "richtigen" Seiten verweisen.

DotNetNuke selbst bietet keine Möglichkeit ein ganzes Portal zu kopieren (extrahieren) um es dann an einer anderen Stelle (anderer Web Server) zu betreiben.

Es gibt aber einen ganz einfachen Trick dies zu bewerkstelligen.

Anleitung zum kopieren eines DotNetNuke Portals

Sichern des (der) Portals (Portale)

Man kopiert das gesamte Verzeichnis unterhalb seiner DotNetNuke Installation.

Man erstellt ein Datenbank Backup der DotNetNuke Datenbank.

Neues Portal (Kopie) erstellen

Man erstellt eine neue Datenbank

Spielt die Datensicherung des zu kopierenden Portals in die Datenbank zurück

Erstellt ein neues Verzeichnis für die DotNetNuke installation

Kopiert alle Daten aus der Sicherung des zu kopierenden Portals hinein.

Passt nun in der web.config den (die) connection strings an (für díe neue Datenbank)

Startet das Portal

Wenn mehrere Portale in der Installation waren

Kann man nun in de System-Einstellungen von DotNetNuke das gewünschte Portal zum System-Portal machen und anschließen die anderen Portale über System Einstellungen Portale löschen.

Gestern wurde ich von einem neuen DotNetNuke Benutzer wieder nach folgendem Sachverhalt gefragt:

Bei der Einrichtung (Installation) von DotNetNuke (In diesem Fall Version 4.6.0) kommt sofort nach Aufruf der Webseite (localhost/dotnetnuke) der Fehler:

Ich könnte ja  nun sagen wer lesen kann ist im Vorteil , aber das wäre sicherlich nicht gerecht, also hier die einfache Erklärung dieser Fehlermeldung:

Die Ursache ist nicht, dass der Name "Config" nicht in der web.config definiert ist, sondern, dass es noch gar keine web.config gibt.

Bei den Versionen DotNetNuke_04.06.00_Upgrade.zip und DotNetNuke_04.06.00_Source.zip sind die web.config Dateien nicht direkt enthalten, sondern es muss je nach Anwendungsfall eine der beiden Dateien:

release.config

development.config

nach web.config umbenannt werden.