Vorwort:

Ich möchte an dieser Stelle jetzt keinen Vortrag über ADS (Alternate Data Streams) im NTFS Dateisystem halten, dazu gibt es bereits eine Fülle von Informationen im Internet, wer hierzu nähere Informationen haben möchte kann diese über eine Internetrecherche mit der SDV (Suchmaschine deines Vertrauens) erhalten.

Hintergrund dieses Beitrags:

In letzter Zeit haben sich die Anfragen bei mir gehäuft, warum nach dem herunterladen aktueller DotNetNuke Versionen (4.9.X und 5.X) von Codeplex und dem anschließenden Entpacken des ZIP Archivs beim Öffnen der Visual Studio Solution ständig die Meldung “Der Projektspeicherort ist nicht vertrauenswürdig” erscheint, obwohl man die Projektdaten auf einem lokalen Laufwerk gespeichert hat und nicht (wo diese Meldung üblicherweise herkommt) auf einem Netzwerklaufwerk.

Zuerst sei einmal gesagt, dass dies weder etwas mit den neuen Versionen, noch mit Codeplex oder DotNetNuke zu tun hat.

Der Grund für diese Meldungen ist, dass beim herunterladen über einen Browser (Früher war das nur wenn man den IE benutzt hat, Heute ist es aber auch mit Firefox so) einer Datei auf ein NTFS Laufwerk sogenannten Alternate Data Streams erzeugt werden, die in diesem speziellen Fall eine unsichtbare Datei [Dateiname]:Zone.Identifier auf dem Laufwerk erstellt und fest verknüpft mit der heruntergeladenen Datei speichert.

Vereinfacht gesagt, teilt diese “unsichtbare” Datei dem Betriebssystem mit “Du Achtung die Datei kommt aus dem Internet und könnte gefährlich sein, gib lieber mal eine Warnung aus”.

Eine der Lösungen (die in diesem Beitrag beschriebene) ist:

Wir löschen die “unsichtbaren” Dateien [Dateiname]:Zone.Identifier.

Seit Vista gibt es zwar für den Kommandozeilenbefehl DIR eine neue Option /R welche diese “unsichtbaren” ADS Dateien anzeigt, aber leider habe ich noch keinen weg gefunden diese mit “Bordmitteln” löschen zu können (Außer die Daten auf ein nicht NTFS Laufwerk zu speichern und anschließend wieder auf das NTFS Laufwerk zu kopieren).

Aber wie so häufig gibt es dafür ein Freeware Tool (sicherlich gibt es auch noch andere, hinterlasst einfach einen Kommentar) welches genau das kann.

Das Programm AlternateStreamView von NirSoft ist so ein Tool (Das übrigens auch unter WIN 7 und da sogar auf X64 funktioniert).

Die Verwendung des Programms ist; denke ich selbsterklären.

Bei dem hier beschrieben Problem und deren BUGFIX handelt es sich um die DMX Version 3.5.X und dem Update eines DNN 4.9.X Portals auf DNN 5.X.

Sicherlich die einfachste Methode ist einfach ein Update des DMX Moduls zu erwerben und dieses Update zu verwenden.

Wer das aber nicht möchte und mit dem Funktionsumfang der 3.5.X Version zufrieden ist, kann mithilfe des hier einfach beschriebenen SQL Patches die Version 3.5.X unter DNN 5.3.X (und vermutlich auch höher) zum laufen bekommen.

ACHTUNG auch hier gilt:

Vor der Manipulation unbedingt eines Sicherung (in diesem Fall genügt die Sicherung der Datenbank) vornehmen.

Hier nun die Vorgehensweise, nachdem man vermutlich erst nachdem man das DNN Portal von 4.X auf 5.X aktualisiert hat, feststellt, dass das DMX Modul nicht mehr funktioniert.

Man meldet sich am Portal als Systemadministrator (host) an.

Im Systemverwalter wählt man nun den Menüpunkt SQL aus.

Dort kopiert man das nachfolgende SQL Script in die Eingabemaske:

IF EXISTS (select * from dbo.sysobjects where id = object_id(N'{databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
GO 

CREATE PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
    @PortalId Int
AS 

SELECT
    {databaseOwner}{objectQualifier}DMX_Extensions.[AccessRights],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Addon],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ControlToLoad],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Custom],
    {databaseOwner}{objectQualifier}DMX_Extensions.[DownloadUrl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[EntryTypes],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ExtensionKey],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon16],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon32],
    {databaseOwner}{objectQualifier}DMX_Extensions.[IsPrivate],
    {databaseOwner}{objectQualifier}DMX_Extensions.[MimeType],
    {databaseOwner}{objectQualifier}DMX_Extensions.[PortalId],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ResourceFile],
    {databaseOwner}{objectQualifier}DMX_Extensions.[SettingsControl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ViewByDefault], 
    {databaseOwner}{objectQualifier}DMX_Addons.Description AS AddonsDescription, 
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.Description AS PortalsDescription
FROM
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage INNER JOIN {databaseOwner}{objectQualifier}DMX_Addons 
     INNER JOIN {databaseOwner}{objectQualifier}DMX_Extensions ON {databaseOwner}{objectQualifier}DMX_Addons.AddonKey = 
     {databaseOwner}{objectQualifier}DMX_Extensions.Addon ON {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.PortalID = 
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId
WHERE
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId = @PortalId 

GO

achtet darauf das die Checkbox “Run as script” markiert ist betätigt den Link “Execute”

Das war’s auch schon

Wer übrigens mehr über den Hintergrund zu diesem Problem wissen will, kann in meinem Beitrag DotNetNuke 5.2.0 – Breaking Changes – Part I – Der Begin der echten Portal Lokalisierung mehr erfahren.

Eigentlich wurde ja bereits mit der Version 5.0 erwartet, dass DotNetNuke nun endlich mehr Internationalität erhält.

Dem war aber nicht so, und mit der Version 5.0 wurden keinen echten Schritte in die Richtung Mehrsprachigkeit gegangen.

Mit der Version 5.2 beginnt nun aber tatsächlich der erste große Schritt in “diese Richtung” ich wollte eigentlich “richtige Richtung” schreiben, aber da bin ich mir noch nicht sicher, warten wir es ab. Leider, oder wie ich sagen würde, wie erwartet, geschieht dies nicht ohne das es dabei zu gravierenden Änderungen (Breaking Changes) in der Datenbankstruktur kommt.

Mit der Version 5.2.0 wird nun folgende gravierende Änderung vollzogen:

Die Tabelle Portals wird International.

Alle Informationen der Tabelle welche Lokalisierbar sein müssen wurden, in eine neue Tabelle PortalLocalization verschoben und alle Einstellungen aus der Tabelle wurden zusammen mit einem Sprachcode in die Portalsettings Tabelle verschoben.

Das ganze führt bei einigen Programmen (Beispielsweise sei hier das Document Exchange Module von Bring2Mind genannt) dazu, dass diese nicht mehr ohne Update mit DNN 5.2.X und höher betrieben werden können.

Sollte ein eigenes Modul von einer solchen Änderung betroffen sein, so sollte man sich die ebenfalls neuen Views (ja DNN verwendet nun auch Views)

• vw_Portals (Alle Sprachen)
• vw_PortalsDefaultLanguage (Standard Sprache entspricht der Lösung vor DNN 5.2)

ansehen.

Durch Verwendung einer dieser Views kann man durch einfache Änderung des Zugriffs von der Portals Tabelle auf eine dieser Views die notwendigen Informationen für sein Modul erhalten, ohne gleich die gesamte Lokalisierungsfunktionalität zu implementieren.

Fortsetzung folgt!!!

Wenn man die Source Version von DotNetNuke Version 4.09.04 in Visual Studio ausführt und als Browser den Internet Explorer 8 einsetzt, kommt es beim überfahren der Menüs (Admin und Systemmenü) mit der Maus zu folgendem Fehler:

Dieser Fehler tritt in der Datei dnn.dom.positioning.js auf.

Die Zeile in welcher der Fehler auftritt lautet:

oIFR.style.zIndex=iIndex-1

Ich habe eine Lösung gefunden, die für mich funktioniert und nicht die Zeile einfach auskommentiert.

Die Lösung sieht wie folgt aus:

Ich füge am Ende der Datei dnn.dom.positioning.js die Funktion IsNumeric ein:

function IsNumeric(sText)

{
   var ValidChars = "0123456789.";
   var IsNumber=true;
   var Char;

 
   for (i = 0; i < sText.length && IsNumber == true; i++) 
      { 
      Char = sText.charAt(i); 
      if (ValidChars.indexOf(Char) == -1) 
         {
         IsNumber = false;
         }
      }
   return IsNumber;
   
   }

Und verwende diese Funktion wie folgt um den Inhalt der Variable iIndex zu prüfen und im Falle das darin kein numerischer Wert enthalten ist, führe ich die Subtraktion nicht aus.

Anstelle der Zeile (250) mit dem Inhalt oIFR.style.zIndex=iIndex-1;

füge ich nachfolgende 4 Zeilen ein, das sieht dann so aus:

if (IsNumeric(iIndex))
    oIFR.style.zIndex = iIndex - 1;
else
    oCont.style.zIndex = 1;

Nun einfach die Datei dnn.dom.positioning.js speichern und auch Fehlerfrei mit dem IE 8 und der Source Version von DotNetNuke arbeiten.

Wenn man versucht die Source Version von DotNetNuke 4.09.04 in Visual Studio 2008 zu öffnen und anschließend zu übersetzen, kommt es zu folgender Fehlermeldung:

Das Problem entsteht dadurch, dass versucht wird nach dem Übersetzungslauf die Datei System.Web.Extensions.dll aus dem Verzeichnis Controls\AJAX\bin\ in das BIN Verzeichnis von DotNetNuke zu  kopieren.

Dies ist aber gar nicht notwendig, da sich die Datei System.Web.Extensions.dll im GAC befindet.

Um den Fehler zu beheben, kann man die Datei DotNetNuke.Library.vbproj im Library Verzeichnis von DotNetNuke mit einem Texteditor öffnen, und nach dem Eintrag

<Copy SourceFiles="Controls\AJAX\bin\System.Web.Extensions.dll" DestinationFolder="..\Website\bin\" />

suchen, der Steht normal in der Zeile 987.

Diese Eintrag entfernt man und speichert anschließend die Datei ab.

Wenn man nun das Source Projekt mit Visual Studio öffnet und übersetzt sollte das Problem gelöst sein.

Letzte Nacht wurde ein weiteres Maintenance Release Version 4.9.4 der DotNetNuke Community Edition (CE Edition) veröffentlicht.

Neue Funktionalitäten sind nicht enthalten, es wurden einige Sicherheitsprobleme sowie einige kleinere Probleme beseitigt.

Die Version 4.9.4 kann wie immer hier von Codeplex heruntergeladen werden.

Soeben wurde eine Maintenance Release Version 4.9.3 von DotNetNuke CE Edition veröffentlicht.

Echte neue Funktionalitäten sind nicht enthalten.

Nach eigenen Angaben von DotNetNuke Corp sind die Major Highlights:

• Add Office 2007 File Extensions to default allowable file extensions in Host Settings
• Add reference to SQL Server 2008 to Install Wizard to make it clear that SQL Server 2008 is supported
• Moved Whats New Module/Page to Host menu as it contains content which is not applicable to the Administrator
• Corrected a problem with "Auto" installation option which would occur when using a non-dbo database user
• Inline updates to Text/HTML were not HTML encoded when stored in the database
• AppBrowser renamed to AppBrowsers in order for ASP.NET to recognize it incorrectly
• Pages in the navigation menu linked directly to a file no longer served the file correctly
• Can not delete Portal if search items exist in the database which are associated to the portal
• Removed None Specified option for Folders in Page Export feature as it could cause an error if a user clicked Export without selecting a folder.
• Fixed major performance issue when adding new portals which would cause the system to unload and reload all cached objects

Die Version 4.9.3 kann man hier auf Codeplex herunterladen.

Letzte Nacht wurde die erste CE Version von DotNetNuke Veröffentlicht, ein einfacher Stabilization Release, also nichts neues.

Mehr zu CE und was das soll gab es schon hier in meinem Blog Beitrag.

Die Version 4.9.2 kann man hier auf Codeplex herunterladen.

Und unter support.dotnetnuke.com findet man mehr zu der einen Hand voll Änderungen in dieser Version

Wer Vorgestern (Valentinstag) die Seite www.dotnetnuke.com besuchen wollte, wurde von einer netten Meldung “Diese Seite ist zur Zeit wegen geplanter Wartungsarbeiten nicht ONLINE, versuchen Sie es später” darüber informiert, dass irgendwelche Update Arbeiten durchgeführt werden. Das war sicherlich nicht das erste mal, dass diese Meldung auf www.dotnetnuke.com oder einer anderen Webseite zu lesen war, aber diese Meldung Vorgestern war dann doch etwas besonderes.

Denn plötzlich ist alles anders (oder doch nicht). –> DotNetNuke geht nun auch Professional (Das ging auch schon vorher und das sogar ohne die PE und ohne die DNN Corp.)

Ab sofort gibt es also 2 Versionen eine Community Edition (CE) und einer Professional Edition (PE).

Die Frage die sich stellt ist doch: Was ist denn der Unterschied zwischen den Versionen ?

Laut Aussage auf der Webseite www.dotnetnuke.com soll die Professional Edition folgendes sein:

• Stable (Stabil)
• Secure (Sicher)
• Certified (Zertifiziert)
• Supported (Unterstützt …)

Laut Aussage der DNN Corp. auf www.dotnetnuke.com soll aber auch:

Die CE und die PE keine andere Programmversion sein (Upgrade von CE auf PE ohne Programmupdate möglich)

Die PE ist eine zertifizierte Fehlerbereinigte CE Version – Dabei stellt sich mir die Frage von wem Zertifiziert ? – Von DNN Corp

Und nicht zu vergessen, man erhält auch noch Garantien zur Performance und …. noch eine Menge mehr Marketing Sprüche !

Ich finde es unglücklich dass man hier versucht ein Produkt zu erfinden, welches es “so” gar nicht gibt, wenigstens nicht dann, wenn DNN Corp. das macht was sie sagen/schreiben. Es wäre sicherlich richtiger dieses Produkt zum Beispiel:

DotNetNuke Professional Services (Kann ich diesen Begriff jetzt mit © H-P Schelian verwenden)

zu nennen.

Da wüsste man auch anhand des Namens gleich um was es sich eigentlich handelt.

Aber was hat diese “Neue” PE Version für Auswirkungen auf die Community und vor allem was hat das für Auswirkungen auf den nicht englisch Sprachigen (Insbesondere den Deutschsprachigen) Raum.

Da ich selbst seit vielen Jahren Professionelle Dienste wie Portal und Modulentwicklung, First und Second Level Support, Umsetzung von Mehrsprachigen Portalen sowie Hosting rund um DotNetNuke und vor allem im Deutschsprachigen Raum anbiete sehe ich dieser Entwicklung im Hinblick auf das Geschäft in eben diesem Deutschsprachigen Raum so gut wie gar nicht betroffen.

Wo ich das gerade aufschreibe, fällt mir auf, dass mit Ausnahme das ich noch nie versucht habe mich selbst zu zertifizieren , der Rest bereits nach DNN PE klingt.

DNN Corp. hat wie viele andere rein Amerikanische Unternehmen / Gruppierungen bis heute nicht verstanden was wir (in nicht englischen Sprachräumen) eigentlich wollen und benötigen. Sie verstehen das Theater um Lokalisierung und Mehrsprachigkeit von Anwendungen noch immer nicht wirklich, oder besser gesagt, es interessiert sie einfach nicht wirklich.

Also ich freue mich endlich mal eine stabile Version zu bekommen, ohne dass ich dazu noch eigene Änderungen am Code durchführen muss, der, selbst wenn ich ihn hundert mal einreichen würde nicht in das Core Produkt eingebaut bekommen würde, ich spreche halt die falsche “Mutter”Sprache.

To be continued … Entschuldigung – Fortsetzung folgt …

Nachdem man, Vorausgesetzt man hat das DotNetNuke Starterkit installiert, mit Visual Studio 2008 eine neue Webseite “DotNetNuke Application Framework” erstellt und konfiguriert hat, kommt es dazu (eventuell kommt es auch nur in bestimmten Fällen dazu), dass nach dem ersten Aufruf der fertig eingerichteten Webseite beim nächsten Start (Kompilierung) folgende 6 Fehler in Visual Studio angezeigt werden und die Webseite nicht mehr aufgerufen werden kann:

Da ich an dieser Stelle keine umfangreiche Abhandlung über die Gründe dieses Problems halten möchte folgt hier einfach kurz und knapp ein Workaround.

Man kopiert die Datei “DotNetNuke.FckHtmlEditorProvider.dll” aus dem BIN\Provider Verzeichnis der DotNetNuke Installation in das BIN Verzeichnis der DotNetNuke Installation.

Nun einfach das Projekt neu übersetzen “Webseite erstellen” – Fertig !!!!

Dieser Workaround trifft auf folgende Konfiguration zu:

• Windows XP SP3
• Visual Studio 2008 SP1
• DotNetNuke Version 5.00.00
• FckHtmlEditorProvider Version 2.0.2.1

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.

Nachdem bereits die letzten Versionen (seit über 2 Jahren) von DotNetNuke keine aktualisierte Dokumentationen enthalten haben, wird leider auch mit der aktuellen Version 5.0 eine weitere Dokumentation's Mogelpackung zum Download bereitgestellt.

Das mit DotNetNuke 05.00.00 Docs bezeichnete Download enthält nur alte Dokumentationen (letzte Aktualisierung am 21.06.2006) .

Dann werden wir wohl die dringenden Fragen doch im Forum der Deutschen DotNetNuke Community klären müssen.

Hierzu habe ich auch einen neuen Bereich im Forum eingerichtet.

Wie eigentlich nicht anders zu erwarten war, wurde der Final Release der Version 5.0, der Open Source Software DotNetNuke, am 24. Dezember 2008 und damit auf den Tag genau 6 Jahre nach der ersten Veröffentlichung, damals noch als IBuySpy Workshop, zum Download für die Öffentlichkeit bereitgestellt.

Nachdem ich selbst vor 6 Jahren an den Weihnachtstagen im Jahr 2002 diese erste Version des späteren DotNetNuke heruntergeladen und damit experimentiert hatte, war ich von dem Virus befallen, der mich bis Heute auch nicht wieder verlassen hat.

Wer mehr zur Historie von DNN (wie DotNetNuke in der Umgangssprache genannt wird) erfahren möchte kann dies in diesem Beitrag auf DotNetNuke.com nachlesen (Bericht in Englischer Sprache).

Von Januar 2004 an wurde alles was das Projekt an Versionen bereitgestellt hat, auf Sourceforge.NET veröffentlicht.

Die neue Version 5.0 und auch ein erstes Maintenance Release, Version 4.9.1, sind nun auf Codeplex, der Microsoft eigenen Open Source Plattform gehostet, was Microsoft sicherlich freuen dürfte und woran MS vermutlich auch nicht ganz unbeteiligt sein wird.

Hier geht es direkt zum Download der Version 5.0 auf Codeplex

Hier geht es direkt zum Download der Version 4.9.1 auf Codeplex

Übrigens sind alle Versionen ab 2004 nun auch auf Codeplex zum Download verfügbar. Das lässt vermuten, dass die Verbindung zwischen DotNetNuke und Sourceforge endgültig beendet ist.

Und nicht zu vergessen:

Ohne große Ankündigung und ohne genaue Beschreibung welche Probleme gelöst wurden, wurde vergangenes Wochenende ein Maintenance Release des Blog Moduls für DotNetNuke veröffentlicht.

Die Versionsnummer dieser Version lautet 3.05.01.

Die neue Version kann man hier herunterladen.

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.

Letzte Nacht wurde eine neue Version des Blog Moduls und eine neue Version des News Moduls für DotNetNuke zum Download bereit gestellt.

Hier geht es zum Download der Version 03.05.00 des Blog Moduls

Hier geht es zum Download der Version 04.00.01 des News Moduls

Letzte Nacht wurde die Version 4.09.00 der Open Source Internet Portal Software DotNetNuke veröffentlicht.

Die Version kann hier heruntergeladen werden.

Das Change Log findet man hier

Nur wenige Tage nach dem letzte Sicherheits Release des Open Source Projektes DotNetNuke wurde letzte Nacht erneut ein weiteres Sicherheits Release, die Version 4.8.4 veröffentlicht.

Informationen über die in dieser Version behobenen Sicherheitslücke kann man unter den folgenden Links (Englisch) nachlesen.

DNN 2008-8-L (11 Jun 08)

DNN 2008-9-L (11 Jun 08)

DNN 2008-10-L (11 Jun 08)

Die direkten Download's der neuen Version gibt es wie immer hier.

Download DotNetNuke Version 4.08.04

Letzte Nacht wurde der Sicherheits Release 4.8.3 von DotNetNuke für den öffentlichen Download bereit gestellt.

Nachdem während des Behebungszeitraums der Sicherheitslöcher weitestgehend stillschweigen über die tatsächlichen Probleme gehalten wurde, sind mit der Veröffentlichung der neuen Version auch die Einzelheiten der Sicherheitsprobleme die mit der neuen Version behoben werden sollen, veröffentlicht worden.

Nachzulesen sind diese unter den nachfolgenden Links:

http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno14/tabid/1159/Default.aspx

http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno15/tabid/1160/Default.aspx

http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno16/tabid/1161/Default.aspx

http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno17/tabid/1162/Default.aspx

Die direkten Download's der neuen Version findet man hier:

Download DotNetNuke Version 4.08.03

Letzte Nacht wurde die Version 4.08.02 der Open Source Internet Portal Software DotNetNuke veröffentlicht.

Die Version kann man hier herunterladen.

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.

Letzte Nacht wurde das Maintenance Release Version 4.08.01 des Open Source Projektes DotNetNuke veröffentlicht.

Die Version kann hier heruntergeladen werden.

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

Gestern Nacht war großer Release Tag bei DotNetNuke.

Folgende Module wurden neu bzw. aktualisiert veröffentlicht:

Modul Announcements Version 4.00.01

Das Modul setzt voraus das DotNetNuke Version 4.6.2 (also auch ASP.NET 2) oder höher installiert ist.

Die neuen Feature umfassen:

• Erfassen mehrerer Announcements in einer Instanz des Moduls.
• Implementierung der ISearchable Schnittstelle (DNN Suche und RSS)
• Basis Implementierung der IPortable Schnittstelle (Import Export von Inhalt)
• Verwendung von Platzhaltern / Systemvariablen möglich

Hier geht es zum Download

Modul Feedback Version 4.04.03

Das Modul setzt voraus das DotNetNuke Version 4.4.0 (also auch ASP.NET 2) oder höher installiert ist.

Hauptsächlich handelt es sich im einen Maintenance Release, es gibt nicht wirklich viel neues, außer man freut sich darüber dass man nun endlich einen funktionierenden Button zum löschen von Feedback Einträgen hat.

Hier geht es zum Download

Wer es genau wissen möchte kann aber hier mehr über die neuen Feature von 4.04.03 lesen (in Englisch)

Modul Chat Version 1.00.01 (Neues Modul)

Das Modul setzt voraus das DotNetNuke Version 4.6.2 (also auch ASP.NET 2) oder höher installiert ist.

Herzlichen Glückwunsch zur Veröffentlichung der ersten Version des Chat Moduls für DotNetNuke.

Hier geht es zum Download

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

Mit der Version 4.5.X wurde die Suche in DotNetNuke um die Funktion Web Suche erweitert. Das hat dazu geführt, dass aus dem Einfachen Eingabefeld für die Suche wie nachfolgend dargestellt:

Eine wesentlich komplexere Anzeige geworden ist (siehe nachfolgende Abbildung).

Wem diese Darstellung nicht zusagt, der kann durch die nachfolgend beschriebene Änderung die Darstellung der Suche wieder auf das ursprüngliche Aussehen zurücksetzen.

Hier nun kurz die Schritte zum deaktivieren dieses Feature:

• Man öffnet die ascx Datei des verwendeten Skins in einem Texteditor.
• Nun sucht man die Zeichenkette: <dnn:SEARCH runat="server" id="dnnSEARCH" showWeb="True" showSite="True" />
• Dort ändert man den Eintrag wie folgt: <dnn:SEARCH runat="server" id="dnnSEARCH" showWeb="False" showSite="False" />
• Datei speichern

Fertig !!

Dies funktioniert natürlich auch mit den Versionen 4.6, 4.7 und 4.8

Viele die mich kennen, wissen dass ich mich seit vielen Jahren intensiv um DotNetNuke und seinen Einsatz vor allem auch im Deutschsprachigen Raum engagiert habe.

Auch und gerade weil mir das Produkt am Herzen liegt muss ich aber nicht alles gut finden was die Herren in USA so an neuen Dingen vorstellen.

Vor einige Tagen ist mir nun die neue Version des DotNetNuke Blog Moduls unter die Finger gekommen. Für die, die es nicht wissen, das Blog Modul habe ich auf Basis, des leider aus der DotNetNuke Szene verschiedenen Michael Trefry hinterlassenen MyBlog Module für DotNetNuke, als Open Source Module für DotNetNuke 3.X entwickelt.

Damals, im ersten Halbjahr 2005 haben sich die Ereignisse dann überschlagen.

28.02.2005 erste Ankündigung des Blog Moduls

01.03.2005 erste Beta Version verfügbar

11.03.2005 Beta 2 des Blog Moduls mit dem Namen NewBlog verfügbar

und dann am

12.03.2005 der Schock, DotNetNuke 3.0.12 kommt auf den Markt und es enthält ein Forum und ein Blog Modul (war die ganze Arbeit umsonst ?)

Aber jeder Schock, Niederlage ist auch ein wenig Herausforderung und Neuanfang.

13.03.2005 das erste Final Release meines Blog Moduls wird als Open Source veröffentlicht

In den folgenden Wochen wird das Blog Modul NewBlog von Tausenden Leuten heruntergeladen und verwendet, die Reaktionen sind allgemein sehr positiv und es zeigt sich dass mein Blog Modul um Längen besser bei den Anwendern ankommt als das damalige Core Blog Module.

29.04.2005 Ich veröffentliche die zweite Version  (Version 3.1.5) des Blog Moduls

Das Highlight dieser Version war die integrierte Möglichkeit Bilder und Dateianhänge zu einem Blogeintrag zu speichern (so ähnlich wie das Heute auch von LiveWriter umgesetzt wird) und zu verwalten ohne den Dateimanager von DotNetNuke verwenden zu müssen, was übrigens nur von einem Benutzer mit Administrationsrechten gemacht werden konnte.

03.05.2005 DotNetNuke veröffentlicht eine neue Version seines Forum / Blog Moduls (wobei das Blog Modul keinen Deut besser wurde als es vorher war)

15.06.2005 Der nächste Versuch das DotNetNuke Core Blog Modul zu performen

20.07.2005 NewBlog wurde in 7 Wochen 2500 mal heruntergeladen

05.08.2006 Neue Version von NewBlog mit vielen neuen Feature veröffentlicht (mittlerweile über 3000 Downloads)

15.08.2005 Die Geschichte eines Moduls - Mein Blog Modul wird von mir als Core Blog Module zur Verfügung gestellt.

Ab nun begann mein Kampf mit den eingefahrenen Strukturen der US Boys. Da ich der erste Projekt Leiter eines Core Moduls war weder zum Core Team gehörte noch aus den USA stammte. Stimmte weder die Zeitzone noch die richtige Zusammenarbeit. In den folgenden Monaten habe ich um jedes Zugangsrecht und Freigabedatum kämpfen müssen, da es einfach keine festen Richtlinien gab, nach welchen man vorgehen konnte.

Trotz all dieser Widrigen Umstände konnte ich am

21.10.2005 Vermelden, dass die abschließenden Tests des ersten offiziellen Blog Moduls nach der Übernahme durch DotNetNuke abgeschlossen sind

Nicht das nun alles erledigt sei und das Modul veröffentlicht werden konnte.

24.10.2005 - Ich schreibe den Beitrag unendliche Geschichte (ein früher Vorläufer dieses Beitrags)

01.11.2005 Endlich ist es soweit die erste Version des neuen Blog Moduls steht zum Download zu Verfügung

06.11.2005 Nachdem das erst Release wirklich veröffentlicht ist, kann es voller Elan an das erst Update gehen

26.12.2005 Nach vielem hin und her (Die Herren des Core Team hatten Änderungen in DotNetNuke 4.0 eingebaut ohne mich zu informieren oder mir Zugriff auf die aktuelle Version zu geben, und dadurch lief das Blog Modul nicht mehr) ist es so weit die nächste Version des Blog Modul ist für den endgültigen Test fertig

28.12.2005 Ich veröffentliche eine Alpha Version des Blog Moduls 4.X das dediziert für den Einsatz für DotNetNuke 4.X erstellt wurde

29.12.2005 Die Blog Version 3.02.00 steht zum Download bereit

Mitte Februar 2006 melde ich mich von einer ersten krankheitsbedingten Auszeit zurück

Nach unergiebigen weiteren 12 Monaten beende ich meine aktive Projektarbeit am Blog Module mit einem offiziellen Schreiben im März 2007.

Der Neue Projektleiter wird Antonio Chagoury, jemand der bis dahin keinen eigenen Blog betrieben hat.

Aber warum habe ich eigentlich die Überschrift "DotNetNuke Blog Module - eine traurige Geschichte!" verwendet?

Der Grund der Überschrift ist, das entfernen einer der Kernfunktionen des von mir für DotNetNuke erdachten Blog Moduls

Unter dem neuen Projektleiter wurde die von mir mit der Version 3.1.5 integrierte Funktion zur Blog bezogenen einfachen Speicherung von Bildern und Anhängen einfach entfernt (Nein die DotNetNuke Standardfunktionen können dieses Funktionalität nicht bieten). 

Dieses Feature ist mit der Version 3.4.0 einfach verschwunden.

Aus Trauer über den Verlust dieser Funktion habe ich mir nicht mal die Mühe gemacht um zu sehen, was mit vorhandenen Beiträgen geschieht die dieses Feature verwendet haben (Ich vermute es bleiben einfach verwaiste Einträge bestehen). Ich weiß nur dass ich meine Blogs, die ich auf meinen DotNetNuke Web Seiten betreibe nun nicht mehr aktualisieren werde.

Auch wenn viele der "JA Sager" und "Alles ist Gut Jünger" von DotNetNuke sagen werden ich habe diesen Beitrag geschrieben weil ich mich persönlich auf den Schlips getreten fühle, dann ist das nicht so.

Ich bin einfach nicht glücklich über diese, meiner Meinung nach falsche Richtung, die man mit der Weiterentwicklung einschlägt. Und muss ich, nur weil ich mit dem Projekt mal näher betraut war, auf immer meine Meinung über etwas was ich selbst verwende zurück halten.

Nein, das werde ich nicht.

Vermutlich wird mich das ganze dazu bringen in absehbarer Zeit wieder eine eigene Version des Blog Moduls zu pflegen.

Aus anderen Beiträgen habe ich bereits erfahren, dass ich nicht der erste, und auch nicht der einzige bin, dem das entfernen dieses Feature vollkommen unverständlich ist.

Anstelle das Feature zu entfernen, hätte mir eher gewünscht dass man dieses Feature um eine LiveWriter Anbindung erweitert hätte.

Eigentlich nur der Vollständigkeit halber hier die Information das die Version 4.8.0 der Open Source Software DotNetNuke in den letzten Tagen des Jahres 2007 veröffentlicht wurde.

Die Version enthält keine neuen Feature oder Funktionen, es sind lediglich eine Reihe von Fehlern aus der Version 4.7.0 behoben worden. Einen Versionssprung auf 4.8 wäre deswegen sicherlich nicht notwendig gewesen, eine 4.7.1 hätte dafür auf genügt.

Die Version kann hier herunter geladen werden.

Seit Gestern (eigentlich schon vorgestern) steht die erste 4er Version (ASP.NET 2.0 Version) des Announcements Moduls für DotNetNuke zum Download zur Verfügung.

Zum Download der Install und der Source Version geht es hier

Mehr Informationen (in Englisch) gibt es hier

Bitte unbedingt daran Denken, diese Version benötigt ASP.NET 2.0 das bedeutet mindestens DNN 3.3.7 oder aber natürlich DNN Version 4.X

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

Happy Birthday - Alles Gute Zum Geburtstag - Ois guade zam Gebuaztog - Alles Gueti zum Geburtstag - Joyeux Anniversaire - Wszystkiego Najlepszego - Dogum Günün kutlu olsun - Feliz Cumpleaños -  Всего хорошего с днём рождения - Fortuna dies natalis!

Die Deutsche DotNetNuke Community DNNPortal.DE feiert Ihren Ihren 3.ten Geburtstag.

Vor 3 Jahren, genau am Nikolausabend des Jahres 2004 habe ich die Webseite der Deutschen DotNetNuke Community http://www.dnnportal.de frei geschaltet.

Die Community besteht heute aus über 4200 registrierten Mitgliedern.

In den Foren der Community findet man über 12000 hilfreiche Beiträge rund um das Thema DotNetNuke.

Weiter so !!

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.

In der letzten Nacht wurde die Version 4.7.0 der Öffentlichkeit zum Download verfügbar gemacht.

In der Version sind viele Bug Fixes enthalten und ein paar, noch in den Kinderschuhen steckende neue Funktionen, enthalten.

Zu den neuen Funktionen bzw. Erweiterungen gehören unter anderem:

• Sprachfilter für Rundmails
  In der Newsletter Funktion (Bulk Email) ist es nun möglich über einen Sprachfilter zu selektieren wer in welcher Sprache ein Mail erhält.
• Rundmails per Fax oder SMS
  In den Optionen zu Rundmails ist es nun auch möglich ein Fax oder SMS Gateway zu nutzen anstelle ein Email zu senden.

Eine noch in den Kinderschuhen steckende Erweiterung sind dann die Benutzerfreundlichen URL's  (Human Friendly URL's).

Auch wenn wir bereits seit vielen Monaten eigentlich nur noch über DotNetNuke 4.X (ja schon bald über die Version 5.X) reden, sind noch viele Installationen unter den Versionen 3.X vorhanden.

Viele dieser Installationen werden wohl auch noch lange Zeit stabil und sicher weiter betrieben werden.

Nun gibt es aber immer häufiger das Problem, dass Menschen die mit diesen Portalen arbeiten auch den Internet Explorer Version 7 einsetzen.

Nun kommt es bei der in DotNetNuke verwendeten Version des FTB Texteditors zu einer Unverträglichkeit mit dem IE 7. Dies führt dazu, dass anstelle des komfortablen Editors nur einfach ein freies einfaches Textfeld zur Eingabe zur Verfügung steht.

Entweder man stellt den Provider auf den FCK Editor, den neuen Standardeditor, um oder man kann wie nachfolgend beschrieben, dass Problem lösen.

Abhilfe kann man hier ganz einfach schaffen indem man auf einen, bereits seit langem verfügbaren, angepassten Provider zugreift.

Advanced FTB Provider Version 3.2.0

Einfach herunterladen, den Inhalt des ZIP Files entpacken und dann die beiden Verzeichnisse BIN und Providers in das Root Verzeichnis der DotNetNuke 3.X Installation kopieren.

Getestet ist das mit DNN 3.1.X. und DNN 3.2.X mit DNN 3.3.X sollte es aber auch funktionieren.

Einfach vorher das BIN und Providers Verzeichnis sichern, dann kann nichts passieren. Wenn es wirklich einen Fehler geben sollte nachdem man den Advanced FTB Provider installiert hat, kan man einfach die beiden Verzeichnisse wieder zurück kopieren.

Der Grund warum der von mir veröffentlichte Provider das Problem mit dem IE 7 löst, liegt daran, dass in dem Provider eine aktuellere Version des FTB Editors integriert ist.

Welches Format aus welcher CSS Datei wird wann und vor welcher berücksichtigt?

Diese Frage möchte ich mit diesem Beitrag ein wenig näher erläutern.

Hier die Reihenfolge in welcher die CSS Dateien von DotNetNuke verarbeitet werden:

1. module.css der jeweiligen Module auf der Seite werden geladen (wenn Module eigene CSS Dateien haben).
2. default.css aus dem Verzeichnis [DNNRoot]\Portals\_default
3. skin.css aus dem Skin Verzeichnis. Im Beispiel den DNN-Blue Standard-Skin ist das [DNNRoot]\Portals\_default\Skins\DNN-BLUE
4. container.css aus dem Container Verzeichnis. Im Beispiel des DNN-Blue Containers ist das [DNNRoot]\Portals\_default\Containers\DNN-BLUE
5. portal.css aus dem Portal Verzeichnis. Im Beispiel des Standard-Portals nach der Installation von DotNetNuke ist das [DNNRoot]\Portals\0

Was wenn nun gleiche Klassen in verschiedenen CSS Dateien unterschiedlich deklariert sind?

DotNetNuke macht keinen Gebrauch von der Möglichkeit sich ergänzender externer CSS Dateien, sondern die CSS Dateien werden von DotNetNuke alle in einer bestimmten bereits oben erwähnten Reihenfolge geladen.

Der Gewinner dabei ist, die Definition einer CSS Klasse in der letzten CSS Datei in welcher die Definition vorgenommen wurde.

Ein einfaches Beispiel:

für H2 wurde in der container.css folgendes definiert:

H2 {
  
FONT-WEIGHT: normal;
  
FONT-SIZE: 20px;
  
COLOR: black;
  
FONT-FAMILY: Tahoma, Arial, Helvetica
  
}

nehmen wir weiter an dass in der portal.css auch das H2 Attribut definiert ist und zwar wie folgt:

H2 {
  
FONT-WEIGHT: bold;
  
FONT-SIZE: 16px;
  
COLOR: red;
  
FONT-FAMILY: Tahoma, Arial, Helvetica
  
}

Dann wird die Ausgabe einer in H2 eingeschlossenen Tags in Roter Fetter Schrift in Schriftgröße 16px in unserem Browser dargestellt.

Hier so wird es aussehen !

und nicht so!

Der Grund dafür ist, dass die letzte Definition in der Reihenfolge der verwendeten CSS Dateien immer als gültig angewendet wird

Wenn mal jemand ein Sprachpaket (Language Pack) für DotNetNuke benötigt hat, wird er über kurz oder lang auf der Resource Seite von DotNetNuke landen.

Das sieht dann so aus:

Hier sind (Stand: 20.10.2007) 82 verschiedene Sprachpakete verfügbar. Und bis auf die Deutschen (Deutschsprachigen) Sprachpakete können diese auch alle (bitte ausnahmen melden) einfach direkt per Download bezogen werden.

Wie ich sagte, bis auf die Deutschen Sprachpakete, um diese zu bekommen muss man eine Zwangs-Registrierung auf der Webseite, der im Anfang diesen Jahres gegründeten, DotNetNuke Usergroup vornehmen.

Wenn man mit solchen fragwürdigen Mitteln seine registrierten Mitglieder nach oben treibt, dann sollte man aber doch wenigsten aus solche Schlagzeilen wir hier:

verzichten.

Die Frage die sich mir stellt ist:

Sind die Sprachpakete der Produkte für die sie erstellt sind, Schutzwürdiger als die Programme selbst?

Den anderen Autoren der Sprachpakete genügt es doch auch, dass man beim Download den Namen des Autors lesen kann und Ihn in Stille im Gedächtnis behält.

Wenn solche Praktiken sich nicht ändern, dann müssen wir wohl oder übel darüber nachdenken auf DNNPortal.DE dem unabhängigen Portal der Deutschen DotNetNuke Community ein eigenes Sprachpaket bereit zu stellen.

Gestern habe ich über die Verfügbarkeit der neuen DotNetNuke Core Module Bog. Forum und Store berichtet.

Aus den ersten Tests der einzelnen neuen Module möchte ich an dieser Stelle aber gleich eine Warnung vor dem Upgrade des neuen Forum Moduls geben.

Es wurden im Forum Modul sogenannte "breaking changes" vorgenommen aber leider wurde dabei vergessen, oder man hatte dazu keine Lust, auch die entsprechend aufwendigeren Update Routinen zu entwickeln.

Die Folge daraus ist unter anderem:

Sofern nicht das Default Theme von DotNetNuke in vollkommen unangepasster Version benutzt wurde, wird nach einem Update das Theme nicht mehr funktionieren. Nicht nur das man nun global einstellen kan (muss) ob man gif, jpg oder png Bilder zur Verwendung in seinem Theme verwendet hat, sonder man hat auch noch die Namen der einzelnen Bilder geändert.

So ist zum Beispiel aus s_settings_32px.gif ein s_settings_lrg.png geworden.

Dann gibt es neben einigen anderen neuen Settings auch noch den Schalter "Enable Toolbar Icons":

Ich habe selten etwas häßlicheres gesehen als das was dann als Toolbar im Forum angezeigt wird, Gott sei Dank hat man da wirklich durch den Schalter die Wahl anstelle der Toolbar einfache Text links zu verwenden.

Neben dieses rein optischen aber doch sehr störenden Problemen sind leider auch die Update Routinen betreffend der Sicherheits- Einstellungen nicht wirklich ausgetestet.

Man muss nach dem Update (und das noch bevor das Portal wieder ONLINE geht) auf jeden Fall alle Rechte Einstellungen des Moduls und der einzelnen Foren überprüfen, ob diese noch das bewirken, was man eigentlich wollte.

Ich hatte beispielsweise plötzlich in einem Intranet Test das Problem das "normale" Mitarbeiter in das Forum der Personalverwaltung zugreifen konnten. Da hätte sich der eine oder andere warm anziehen können.

Also unbedingt umfangreiche Upgrade Tests des Moduls in einem Test-Portal durchführen, verwendete Themes anpassen und dann erst das Live Portal aktualisieren wenn klar ist was und wie das Update durchgeführt werden kann.

In der Nacht zum 16.10.2007 wurden für die nachfolgenden Module neue Versionen veröffentlicht:

• Forum (Version 04.04.03)
• Blog ( Version 03.03.01)
• Store (Version 02.01.00)

Blog Modul:

Das Blog Modul erhält nach 4 Monaten eine neue Version mit ....

mit einer einzigen Fehlerkorrektur, als ob es nicht genügend zu korrigieren geben würde. Na dann warten wir halt weiter auf die dann sicherlich bahnbrechende Version 03.04.00.

Das Blog Modul ist übrigens das einzige Modul dieser Veröffentlichung was noch nicht auf den ASP.NET 2 Framework umgestellt ist und benötigt als Voraussetzung für den Betrieb die Installation einer DotNetNuke Version 03.o3.07 oder 04.03.07.

Download Link Blog Modul

Forum Modul:

Für das Forum Modul ist es notwendig mindesten die DotNetNuke Version 04.04.00 zu betreiben.

Im Forum gab es zur letzten Version 105 Änderungen / Erweiterung / Fehlerkorrekturen. Einzelheiten zu den aktuellen Änderungen findet man hier.

Download Link Forum Modul

Store Modul:

Das Store Modul setzt voraus das man mindestens DotNetNuke Version 04.04.01 installiert hat.

Information über die aktuellen Änderungen des Store Moduls findet man hier.

Download Link Store Modul

Im Zusammenhang mit einem DotNetNuke Update (Version 3.1.1 --> Version 4.5.3) welches ich für einen Kunden durchführe ist folgendes Problem aufgetaucht:

In der DotNetNuke Installation 3.1.1 war unter anderem das FAQ Module von SpohnSoftware in der Version 1.06.00 eingesetzt.

Während des Update des DotNetNuke Portals auf die Version 4.5.3 traten auch keine merklichen Probleme mit diesem Modul auf. Selbst bei den ersten Tests (es handelt sich um ein umfangreiches Portal) wurden zuerst noch keine Probleme festgestellt. Dann aber stellte man fest, dass beim Versuch durch anklicken der Frage die Antwort zu öffnen nur eine Meldung "Fehler auf dieser Seite" vom Browser ausgegeben wurde, aber der Antwort nicht angezeigt wurde.

Nach einer kurzen Recherche im Internet war klar, es gibt eine neue Version (mittlerweile die Version 03.00.00) die auch laut Angaben des Herstellers für DotNetNuke 4.X funktioniert.

Also neue Version des Moduls gekauft (wie sich kurz drauf herausstellen sollte, Gott Sei Dank gleich die Source Version) und auf einem Test-Portal installiert.

• Frage und Antwort eingegeben
• Seite aufgerufen
• Auf die Frage geklickt um die Antwort anzuzeigen

Und der Browser zeigt in der Statuszeile an: Fehler auf dieser Seite

Wie bereits erwähnt, ich hatte die Source Version gekauft. Also das Modul in einem Entwicklungsportal installiert und die Source in das Projekt integriert.

Fehlersuche......!

Nach einigen Minuten war klar, das Problem liegt daran dass beim Aufruf von Java Script Funktionen kein gültiges Objekt der Seite an diese als Parameter übergeben wurden, aber warum.

Aber auch diese Frage war nach kurzer Zeit geklärt:

SpohnSoftware hat in seinem Modul eine Funktion GetTableName die dazu verwendet wird den durch das APS.NET Framework generierten Namen für das Control zu ermitteln. Die Funktion sieht so aus:

        Public Function GetTableName() As String
            Try
                Return Replace(UniqueID & "_tblQA", ":", "_")

            Catch ex As Exception
                ProcessModuleLoadException(Me, ex)
            End Try
        End Function

Wenn wir uns nun den Replace anschauen sehen wir auch sehr schnell das eigentliche Problem:

Die UniqueID enthält den eindeutigen Namen, welcher vom NET Framework erzeugt wurde. Das NET Framework 2.0 verwendet hierbei zur Trennung zwischen den einzelnen Namen das $ Zeichen und nicht das : Zeichen.

Das kann nicht gehen und ich frage mich wie das Modul jemals funktioniert haben soll.

Hier nun die Funktion wie sie richtig ist und auch funktioniert:

        Public Function GetTableName() As String
            Try
                Return Replace(UniqueID & "_tblQA", "$", "_")

            Catch ex As Exception
                ProcessModuleLoadException(Me, ex)
            End Try
        End Function

Ich habe hierzu auch sehr intensiv im Internet recherchiert, konnte aber keine Erklärung finden, warum das jemals so funktioniert haben soll.

Mal sehen, eventuell gibt es ja jemand der meinen Artikel liest und mir darauf eine Antwort geben kann.

Nachdem nun die seit Tagen erwartete Version DotNetNuke 4.6.2 veröffentlicht wurde, habe ich mir diese Version mal etwas näher betrachtet.

Vorab die Essenz meiner Untersuchung:

Man könnte die Version 4.6.2 auch einfach als Pannenhelfer der Version 4.6.0 bezeichnen.

Nein es gibt nichts neues, keine neue Funktion und auch keine Fehlerkorrektur außer den Fehlern die man mit der Pannenversion 4.6.0 selbst erst erzeugt hatte.

Aber was wurde im Detail mit der Version 4.6.2 repariert:

• Man hat das Problem mit den Schreibgeschützten Eigenschaft ModuleId und TabModuleId wieder gelöst.
• Eine in der Version 4.6.0 vergessene Prüfung der CaptchaLogin hat man hinzugefügt.
• Ein End If an die richtige Stelle im Code verschoben, damit die Compression Configuration nicht mehr fehl schlägt.
• Die aktuelle Version 04.06.00 des HTML Moduls mit in das Package eingebunden
• Und dann kommt der dickste Hammer, man hat all die Fehler die man in dem SQL Upgrade der Version 4.6.0 eingebaut hat geändert. Das waren nicht weniger als 34 Änderungen in der Datei 04.06.00.SqlDataProvider.SQL.

Nicht dass man die Korrekturen in der Datei 04.06.02.SqlDataProvider vorgenommen hätte, so dass, sollte man bereits ein Update auf die Version 4.6.0 durchgeführt haben, nun mit dem neuen Update alle Datenbanken auf den gleichen Stand bringt, nein man hat doch tatsächlich das 4.6.0 Update Skript geändert.

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.

Nachdem wohl die DotNetNuke Version 4.6.1 die kürzeste Releasezeit aller Zeiten hatte, wurde letzte Nacht die wohl hoffentlich alle problemlösende Version 4.6.2 veröffentlicht.

Die Version kann wie immer von SourceForge herunter geladen werden.

Hier der Link zur Version 4.6.2

Am Freitag hatte ich in dem Beitrag DotNetNuke Version 4.6.1 vorübergehend nicht verfügbar über die Probleme mit der aktuellen Version 4.6.1 von DotNetNuke berichtet.

Es handelt sich wohl doch um ein größeres Problem, die nachstehend Meldung ist auch nach 2 Tagen noch immer auf DotNetNuke zu sehen.

Mal gespannt wann denn nun eine fehlerbereinigte Version fertig ist.

Je mehr von Qualitätssicherung, Beta Versionen und Release Candidates gesprochen wird, umso häufiger kommt es zu fehlerhaften Versionen die veröffentlicht werden.

Nachdem ich dann solche Meldungen (Wir denken Heute ein Lösung präsentieren zu können), über Tage im Web lesen muss, komme ich zu dem Schluss, dass ich mich getäuscht habe als Ich dachte, es wäre eine "Made in Germany" Eigenart der neuesten Zeit, dass Menschen glauben, schon alleine durch die Quantität Ihrer Aussagen zu einem Thema zum Experten zu werden.  Diese Eigenart gibt es auch außerhalb Deutschland's.

Eine Meldung wie der Titel dieses Blogs deutet eigentlich immer auf ein negatives Ereignis hin.

So auch in diesem Fall.

Schon in der Version 4.6.0 wurden gravierende Änderungen in den ModuleSettingsBase vorgenommen die dazu führten dass komplexe Module die tief in die DotNetNuke Trickkiste greifen, nicht mehr fehlerfrei ausgeführt werden konnten und erst recht nicht mehr gegen die aktuelle Version von DotNetNuke kompiliert werden konnten.

Als eines der wohl bekanntesten betroffenen Modul-Opfer sei hier exemplarisch das DMX Modul von Bring2Mind genannt.

Das Problem ist unter anderem dass mit der Version 4.6.0 plötzlich die Eigenschaften ModuleID und TabModuleId nur noch Schreibgeschützt sind.

Die nun vorübergehend nicht verfügbare Version soll dann doch schnell noch mal geändert werden, damit dann!

Wie es dazu Ausschnittsweise in der Originalmeldung auf DotNetNuke heißt:

"... corrects the breaking change to modulesettingsbase which was inadvertently introduced in 4.6.0."

Besonderes Augenmerk liegt dabei auf "inadvertently", was soviel wie, unbeabsichtigt oder versehentlich, heißen soll.

Na dann bin ich aber mal gespannt, wann die nachgebesserte Version der gefixten Version zur Verfügung steht und vor allem wie die Version dann letztendlich heißen wird

Übrigens ist die Version 4.6.1 über SourceForge die ganze Zeit verfügbar, nur der Link auf DotNetNuke wurde deaktiviert (was das bringen soll ?)

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.

Heute erst entdeckt. "Perpetual Motion Interactive Systems" hat einen Module Upgrade Wizard erstellt und veröffentlicht.

Die Veröffentlichung des Moduls hat zeitgleich mit dem letzten Release Version 4.6.0 stattgefunden. Der Grund warum ich und bestimmt auch viele andere dieses Modul nicht sofort entdeckt haben liegt wohl in der Tatsache begründet, das der Link zum Download nicht in der Kategorie der neuen Version (4.6.0) hinterlegt wurde, sondern in die Kategorie der Version 4.5.5 eingefügt wurde.

Um die Verwirrung komplett zu machen ist in dieser Kategorie auch ein neuer Download Link für eine Dokumentation (4.5.5) leider gibt es diese Dokumentation aber nicht, und man bekommt die "alte" 4.4.1 Dokumentation, was man sich dann sparen kann.

Nun aber eine erste kurze Information zum Module Upgrade Wizard.

Der Wizard soll es Entwicklern ermöglichen Ihre Module, welchem mit VS2003 unter dem NET Framework 1.1 entwickelt wurden, auf das NET 2 Framework zu migrieren.

Um das positive vorweg zu nehmen, der Wizard funktioniert prinzipiell sowohl für Module die in VB als auch in C# entwickelt sind.

Leider setzt er die Module in das neue Webseiten Modell von VS2005 um (OK der Vorteil ist das man diese Module auch mit dem kostenlosen Visual Web Developer bearbeiten kann), man hat aber keine Wahl (Option) das er das Modul in das Web-Anwendung's-Modell (wie in VS2003) umsetzt was ich für die Entwicklung von DotNetNuke Modulen vorziehe. Und mit dieser Meinung stehe ich nicht alleine da, alle mehr oder weniger professionellen Module siehe auch das DMX Modul arbeiten mit diesem Modell.

Was meiner Meinung nach aber noch negativer ist, ist dass dieser Wizard ohne Source Code Daher kommt, obwohl er unter NET 2, vermutlich mit VS2005, entwickelt wurde. Da der Wizard ohne Source kommt kann man keine Anpassungen und Erweiterungen an dem Wizard vornehmen.

Aber bildet euch selbst euer Urteil, den Download findet man nicht wie üblich auf Sorcefourge sondern nur wenn man auf DotNetNuke registriert ist auf der Download Seite.

Hier der Link

Trotz einiger Probleme die ich während der Tests mit der neuen Version DotNetNuke 4.6.0 hatte, habe ich mich am Wochenende dazu entschlossen die Version auf meinem Deutschen Portal zu installieren.

Ich werde sicherlich zu einem späteren Zeitpunkt mehr über die Änderungen und Probleme der neuen Version berichten.

An dieser Stelle soll aber bereits auf eine neue Einstellungen hingewiesen werden, die nach dem Update automatisch aktiviert ist, die man aber besser erst einmal abschaltet, es sei denn man möchte ganz gezielt diese Option einschalten.

Ich finde schon immer, dass es nicht gut ist, die neuen Optionen als Default einfach mal zu aktivieren und somit das Verhalten des Portals ohne expliziten Wunsch zu ändern.

Aber nun zur Einstellung die ich meine:

Die Einstellung befindet sich sowohl in den System als auch in den Portal Einstellungen und dort jeweils unter dem Menüpunkt sprachen.

Es handelt sich dabei um die Funktion des Sprachparameters in der URL. Wenn man diese Häkchen nicht ausschaltet, dann verändert DotNetNuke die ursprüngliche URL und fügt ein language/de oder ähnlich je nach Portalsprache, in die URL ein.

Mehr darüber eventuell später !

Ach so, hier geht es direkt zum Download

Letzte Nacht wurde die DotNetNuke Version 4.6.0 veröffentlicht.

Wie es aussieht, haben die Jungs vom Core Team endlich die Suchfunktion zum laufen gebracht.

Allerdings gibt es ein echtes Problem mit Child Portalen. Mehr dazu wonöglich in einem späteren ausführlicheren Blog Eintrag.

Hier geht es direkt zum Download

Nach nur ein paar Tagen schon wieder ein DotNetNuke Release !

Die DotNetNuke Version 4.5.5 ist da !!

Da hat es wohl laut gekracht, und das nach RC 1, RC 2 und einem nicht mehr geplanten RC 3.

Hier die die Info der Änderungen

Und hier der direkte Link zum Download der 4.5.5 Version

Ich bin gespannt in wie vielen Versionen ich noch einen Core-Hack implementieren muss um die Suche in DotNetNuke auch mit Deutschen Umlauten durchführen zu können.

Hier der Link zur DotNetNuke.DLL mit dem Core-Hack Deutsche Suche.

Mehr zum Thema und Hintergrund des Patches könnt Ihr hier in meinem ersten Artikel dazu lesen.

Übrigens nun auch schon in der X.ten Version ein Core-Hack um das leidige &base in der URL zu beseitigen wenn man auf das Portal Logo klickt.

Entweder hier klicken um das geändert File Logo.ascx.vb herunterzuladen oder einfach die Datei \admin\skins\logo.ascx.vb öffnen und dort die folgende Änderung vornehmen:
Im Page_Load event folgende Zeile suchen:
hypLogo.NavigateUrl = GetPortalDomainName(PortalSettings.PortalAlias.HTTPAlias, Request) & "/" & glbDefaultPage & "?base"

Und gegen die nachfolgende Zeile austauschen:

hypLogo.NavigateUrl = GetPortalDomainName(PortalSettings.PortalAlias.HTTPAlias, Request) & "/" & glbDefaultPage

Speichern --> fertig.

Letzte Nacht war es dann wirklich so weit. Die neue Version DotNetNuke 4.5.3 wurde nachdem es drei Release Kandidaten gab, nun für die Öffentlichkeit frei gegeben.

Hier geht es direkt zum Download

DotNetNuke 4.5.4 RC3 wurde letzte Nacht für den internen Test veröffentlicht. Nachdem eigentlich für den Gestrigen Tag der öffentliche Release 4.5.4 angedacht war, wurde überraschend noch ein weiterer Release Kandidat veröffentlicht.

Laut angaben von Shaun Walker war dies neben einigen Problemen mit dem SSL Support vor allem notwendig da Microsoft auf ein Sicherheitproblem hingewiesen hat, und für dieses Problem eine entsprechende Änderung sofort zur Verfügung gestellt hat.

Also wird nun noch einmal (vermutlich nur kurz) der neue Release Kandidat in eine neue Runde gehen.

Auf das wir dann bald alle das neue und dann noch sichere DotNetNuke 4.5.4 erhalten.

Nachdem ich mein eigenes Portal (das wo Ihr gerade drauf seid) auf die aktuelle Version 4.5.3 von DotNetNuke aktualisiert habe und mich auch ein wenig über den wesentlich besseren Editor FCK gefreut habe, wurde meine Freude aber doch schnell wieder getrübt.

Meine "alten" Beiträge wurden in der Suche und im Modul WhatsNew einwandfrei mit den Umlauten angezeigt und auch die Suchfunktion hat bei den Umlauten wunderbar funktioniert. Meine neuen Beiträge aber wurden alle verstümmelt dargestellt (In der Suche und in der Anzeige des Moduls WhatsNew).

Was war geschehen?

Ich habe ein wenig in den Datenbanken recherchiert und stellte fest, dass der FTB Editor der in der 3er Version von DotNetNuke als Standard eingesetzt war, die Umlaute anders kodiert hat wie dies der FCK Editor macht. Das sollte generell eigentlich auch kein Problem sein, aber das Problem war nachdem ich soweit gekommen war relativ schnell gefunden.

Beim indizieren der Inhalte werden alle zu indizierenden Texte durch eine Funktion  mit dem Namen StripEntities geschickt um HTML Fragment die   und ähnliche Zeichen zu entfernen. Leider wird hierbei ein Regex Filter eingesetzt der auch Zeichen wie ö oder Ü aus dem Text entfernt. Und genau hier liegt das Problem, durch die Funktion StripEntities werden die in HTML kodierten Umlaute aus den Texten entfernt. Aber dies ist kein wirklich großes Problem, nachfolgend zeige ich wie die Funktion im Original aussieht und welche Änderung man machen muss, damit die Umlaute nicht herausgefiltert werden.

Hier der Original Code:

Public Shared Function StripEntities(ByVal HTML As String, ByVal RetainSpace As Boolean) As String 
'Set up Replacement String            
   Dim RepString As String            
   If RetainSpace Then                
      RepString = " "            
   Else                
      RepString = ""            
   End If            
   'Replace Entities by replacement String and return mofified string            
   Return System.Text.RegularExpressions.Regex.Replace(HTML, "&[^;]*;", RepString)        
End Function

Und hier der Code nach der Änderung:

Public Shared Function StripEntities(ByVal HTML As String, ByVal RetainSpace As Boolean) As String 
'Set up Replacement String            
   Dim RepString As String            
   If RetainSpace Then                
      RepString = " "            
   Else                
      RepString = ""            
   End If            
   'Replace Entities by replacement String and return mofified string            
   Return System.Text.RegularExpressions.Regex.Replace(HTML, "&[^uml;]*;", RepString)        
End Function

Und wer keine Lust hat diese Änderung selbst zu machen, kann auch einfach dem nachfogeldenden Link folgen und die DotNetNuke.DLL einfach herunterladen. Es handelt sich dabei um die Version 4.5.3. Einfach runterladen in das BIN Verzeichnis der DotNetNuke Installation kopieren und fertig.

Hier gibt es die kompilierte Version der DotNetNuke 4.5.3 DLL

Fast fertig, denn die "falschen" Einträge sind bereits in der Datenbank vorhanden und müssen erst noch einmal erstellt werden..

Dies geht folgendermaßen:

Also als Host einloggen.

Im Menü Host den Menüpunkt SQL aufrufen und das folgende Script in das SQL Fenster kopieren.

---------- START Script-----------

delete SearchItem

go

delete SearchWord

go

delete SearchItemWord

go

delete SearchItemWordPosition

go

---------END Script-------------

run as script anklicken

und den Link ausführen betätigen.

Entweder kann man jetzt warten, bis der nächste Schedule Aufruf der Suchindex erstellung läuft, oder wenn man es eilig hat (wer hat das nicht) Im Host Menü den Menüpinkt Search Amdin aufrufen und Re-Index Content anklicken.

Heute wurde der erste DotNetNuke Release Candidate (RC1) der neuen Version 4.5.4 für den Beta Test veröffentlicht. Der Download der neuen Version steht zur Zeit nur einer begrenzten Benutzergruppe zur Verfügung.

Sollten keine gravieren Fehler auftreten, so kann mit einer baldigen Veröffentlichung gerechnet werden.

Nachdem die letzte veröffentlichte Version 1.0.15 des DNNPortal-Download Moduls nicht mehr unter den neuen DotNetNuke Versionen lauffähig ist, habe ich Heute eine neue Version 4.00.00 veröffentlicht.

Diese Version enthält keine neuen Funktionen, sie ist lediglich eine auf das NET Framework 2.0 migrierte Version der bisherigen Version.

Zur Verwendung der Version 4.00.00 müssen Sie eine DotNetNuke Version verwenden welche es ermöglicht das WEB mit dem NET Framework 2.0 zu betreiben.

Verwenden Sie diese Version auf keinen Fall mit einem DotNetNuke welches auf NET Framework 1.1 läuft.

Alle DNN 4.X Versionen verwenden NET Framework 2.

Bei den 3er Versionen sollten Sie vor dem Update sicherstellen, dass sie das NET Framework 2.0 für den Betrieb des Webs einsetzen.

Hier geht es direkt zum Download des Moduls auf dem Deutschen DotNetNuke Community Portal DNNPortal.DE

Für Probleme oder Anregungen bitte das Forum auf DNNPortal verwenden.

Und nun viel Spaß mit der neuen Version

Nachdem das Portal auf den NET Framework 2.0 im Zuge des DotNetNuke Portal Updates umgestellt wurde macht nun das Modul DNNPortal-Download (Version 1.0.15) probleme.

Die Anzeige der Vorschaubilder und der Download gehen nicht mehr, da ein Verzeichnisverweis in der Framework 2 Version anders initilaisiert wird wie dies in der Framework 1.1 Version der Fall war.

Ich werde also Heute die notwendigen Änderungen an dem Modul vornehmen, das Update dann hier einspielen und später die neue Version zum Download bereitstellen.

Nach nur einer Woche (das lezte Update hat immerhin fast ein Jahr gedauert) gibt es schon wieder ein Update des Repository Modulsm- Version 3.1.13. Das kann eigentlich nr bedeuten, dass im letzten Update das ein Jahr Entwicklungszeit beinhaltet hat wohl doch noch gravierende Fehler beinhaltet waren.

Hier geht es direkt zum Download des Hotfix

Nach fast einem Jahr ein Update des Repository Moduls. Doch wer gedacht hat es kommt nun bahnbrechendes wurde allein schon von der Versionsnunmmer 3.01.12 (die vor einem Jahr war 3.01.10) wieder auf den Boden der Tatsachen zurückgeholt.

Aber trotzdem,

hier gehts direkt zum Download !

Heute Nacht wurde überraschend schon wieder eine neue Version 4.5.3 der Open Source Software DotNetNuke veröffentlicht.

Na da muss die Version 4.05.02 aber supi Fehlerhaft gewesen sein, wenn schon nach 24 Stunden ein Hotfix Realease kommt!

Hier gehts direkt zum Download der "verbesserten" Version !

Heute Nacht wurde die Version 4.5.2 Open Source Software DotNetNuke veröffentlicht.

Hier gehts direkt zum Download der neuen Version

Seit dem letzten Sicherheitsupdate von Microsoft kommt es zu einem Fehler beim Einsatz des Blog Moduls wenn dieses auf einer 4er Version (also unter dem NET Framework 2.0) von DotNetNuke eingesetzt ist.

Der Fehler tritt auf, wenn man einen neuen Blog Eintrag erstellen, oder einen vorhandenen Eintrag bearbeiten möchte.

Die genaue Fehlermeldung lautet:

Fehler: Edit Entry ist zur Zeit nicht verfügbar.

ModuleControlSource: DesktopModules/Blog/EditEntry.ascx

InnerException: The server tag is not well formed.

RawURL: /Weblog/tabid/140/ctl/Edit_Entry/mid/576/EntryID/261/Default.aspx

Message: DotNetNuke.Services.Exceptions.ModuleLoadException: The server tag is not well formed. ---> System.Web.HttpParseException: The server tag is not well formed. ---> System.Web.HttpException: The server tag is not well formed. at System.Web.UI.TemplateParser.ProcessError(String message) at System.Web.UI.TemplateParser.DetectSpecialServerTagError(String text, Int32 textPos) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at System.Web.UI.TemplateControl.LoadControl(String virtualPath) at DotNetNuke.UI.Skins.Skin.InjectModule(Control objPane, ModuleInfo objModule, PortalSettings PortalSettings) --- End of inner exception stack trace ---

Die Lösung für das Problem liegt an einem Sonderzeichen welches sich in der Datei EditEntry.ascx befindet.

In der Zeile 21 wird das Wort ResourceKey falsch geschrieben.

Der Test in der Datei lautet ResourcêKey man achte auf das ê anstelle eines normalen e.

Also einfach die Datei öffnen das ê gegen ein e austauschen speichern - fertig.

Heute Nacht wurde die Version 4.5.1 Open Source Software DotNetNuke veröffentlicht.

Hier gehts direkt zum Download der neuen Version !

Letzte Nacht wurde nach langer Zeit des Wartens endlich eine neue Version (Fehlerbereinigte Version) des Forum Moduls für DotNetNuke veröffentlicht. Die Versionsnnummer lautet 3.20.9.

Hier gehts direkt zum Download !

Heute Nacht wurde die Version 4.5.0 Open Source Software DotNetNuke veröffentlicht.

Hier geht direkt zum Download der neuen Version !

Letzte Nacht wurde eine neue Version des DotNetNuke Moduls Events veröffentlich. Die Versionsnummer der neuen Version lautet 3.3.7.

Hier gehts direkt zum Download !

Letzte Nacht wurde die Version 4.4.1 des DotNetNuke Moduls Feedback veröffentlicht. Wo ist denn die 4.4.0 geblieben

Hier gehts direkt zum Download

Letzte Nacht wurde die Version 4.4.0 des DotNetNuke Moduls FAQs veröffentlicht.

Hier gehts direkt zum Download !

Letzte Nach wurde eine neue Version 3.4.0 des Announcement Moduls für die Portalsoftware DotNetNuke veröffentlicht.

Hier geht es direkt zum Download !

Heute Nacht wurde die Version 4.4.1 Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der neuen 4er Version !

Für alle die noch auf die letzte 3er Version 3.03.07 updaten wollen,

hier noch einmal der Download Link zur letzten 3er Version.

Letzte Nacht wurde eine neue Version 3.1.6 des Document Moduls für das Portal Framework DotNetNuke veröffentlicht.

Hier gehts direkt zum Download der neuen Version

Heute Nacht wurde die Version 4.4.0 Open Source Software DotNetNuke veröffentlicht. Dies ist die erste dedizierte nur 4er Version. Ab jetzt wird es nur noch neue Versionen mit der 4 oder höher vorne geben.

Adieu du gute alte 3er Version !

Hier gehts zum Download der neuen Version (4.04.00) !

Heute Nacht wurden die Version 4.3.7  und 3.3.7 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.6  und 3.3.6 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier zum Download der 4er Version !

Lezte Nacht wurde eine neue Version 3.3.6 des DotNetNuke Moduls User Defined Table veröffentlicht.

Hier gehts direkt zum Download !

Heute Nacht wurden die Version 4.3.5  und 3.3.5 der Open Source Software DotNetNuke veröffentlicht.

Hier geht zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.4  und 3.3.4 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier gehts zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.3  und 3.3.3 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.2  und 3.3.2 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.1  und 3.3.1 der Open Source Software DotNetNuke veröffentlicht.

Hier gehts zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurden die Version 4.3.0  und 3.3.0 der Open Source Software DotNetNuke veröffentlicht.

Hier geht es zum Download der 3er Version !

und hier zum Download der 4er Version !

Heute Nacht wurde die Version 4.0.3 der Open Source Software DotNetNuke veröffentlicht.

Hier geht es zum Download !

Heute Nacht wurden die neuen Versionen des Open Source Projektes DotNetNuke veröffentlicht.

Mehr erfahren Sie hier http://www.dnnportal.de/Weblog/tabid/177/EntryID/178/Default.aspx