DNNSubscriber Version 3.0.2 (Update)

hp@dnnportal.de — Fri, 27 May 2005 03:22:00 GMT

Vor einigen Tagen hat mir Daniel Müller per Email ein Problem (und auch gleich die Lösung) mit dem Modul DNNSubscriber gesendet.

Das Problem (ein Performance Problem) hat zwar keine echten Auswirkungen auf die Funktionstüchtigkeit des Moduls, allerdings könnte man das Problem als echte Performance Bremse ansehen.

Folgendes habe ich da (warum auch immer) in der Methode IsUserInRole eingebaut:

protected bool IsUserInRole(string RoleName)

{

RoleController objRoles =new RoleController();

ArrayList strUserRole;

strUserRole = objRoles.GetUsersInRole(this.PortalId,RoleName);

foreach(UserRoleInfo uri in strUserRole)

{

if (uri.UserID == this.UserId)

{

returntrue;

}

}

returnfalse;

}

Warum auch immer ich diesen Code eingebaut habe (eventuell war es wieder mal zu spät) der Code ist natürlich eine Peformance Bremse wenn einige hundert oder tausend Benutzer registriert sind.

Der Code wird also wie folgt abgeändert:

protected bool IsUserInRole(string RoleName)
{
return DotNetNuke.Security.PortalSecurity.IsInRole(RoleName) ;
}

Wie man sieht, kürzer, besser, effektiver.

Danke Daniel.

Die neue Version 3.0.2 ist ab sofort im Download Bereich verfügbar.

DotNetNuke.Com läuft unter Version 3.1.0

hp@dnnportal.de — Fri, 27 May 2005 01:13:00 GMT

Nach dem Motto "Eat your own Dogfood" läuft das Portal DotNetNuke.Com seit Gestern Abend mit der Version 3.1.0.

Somit kann erwartet werden, dass die Version 3.1.0 wohl bald als Download verfügbar sein wird.

Wirkliche Änderungen gab es in der Version 3.1.0 nicht als einzige echte Erweiterung wurde die Unterstützung für Web Farms hinzugefügt.

Und sonst gab es wohl ganz viel Bug Fixing. Wer mehr darüber erfahren möchte was denn alles so getan wurde an der Version 3.1.0 kann sich die Roadmap auf Gemini anschauen.

Hier der Link

YAF und DotNetNuke 3.X Critial Error

hp@schelian.de — Wed, 25 May 2005 08:00:37 GMT

Nachdem ich vor einigen Wochen das DNNPortal auf DotNetNuke 3.X umgestellt habe und in diesem Zuge auch das YAF Forum auf eine neue Version aktualisieren musste, bekam ich in den letzte Wochen immer wieder mal eine Meldung von einem Besucher, dass wenn er das Forum aufruft einen Kritischen Fehler (Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Trotzt aller Versuche ist es mir nicht gelungen diesen Fehler zu reproduzieren.

Gestern nun habe ich von Ueli (Ulrich Jenzer) den Entscheidenden Hinweis bekommen.

Wie mir Ueli in einem Mail mitgeteilt hat, tritt der Fehler dann auf, wenn in den Regions und Sprachoptionen von Windows z.B. Deutsch (Schweiz) eingestellt ist.

Mit diesem Wissen konnte ich nun das Problem auch auf meinem Testsystem reproduzieren.

Also schnell mal (von wegen schnell) eine Entwicklungsumgebung für das YAF Forum aufgebaut und ran an den Debugger.

Es war sehr schnell klar das der Fehler in der Lokalisierungs Funktion von DotNetNuke erzeugt wird, nur da konnte der Fehler ja eigentlich nicht liegen. Da für das YAF Forum unter DotNetNuke die Lokalisierung von DotNetNuke eigentlich gar nicht greift war ich ziemlich überrascht.

Nach einigen vergeblichen Versuchen den Fehler einzukreisen ist es mir dann doch gelungen.

Schauen wir uns doch mal das Problem und die Load Methode der Klasse ForumPage an:

Zur besseren Übersicht habe ich hier nur der ersten Teil (der ist auch entscheidend) dargestellt.

private void ForumPage_Load(object sender, System.EventArgs e)
{
if(m_bNoDataBase)
return;

#if DEBUG
QueryCounter.Reset();
#endif

// Set the culture and UI culture to the browser's accept language
try
{
string sCulture ="";
string [] sTmp = HttpContext.Current.Request.UserLanguages;
if (sTmp !=null)
{
sCulture = sTmp[0];
if(sCulture.IndexOf(';')>=0)
{
sCulture = sCulture.Substring(0, sCulture.IndexOf(';'));
}
}
else
{
sCulture ="en-US";
}

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(sCulture);
Thread.CurrentThread.CurrentUICulture =new CultureInfo(sCulture);
}
#if DEBUG
catch(Exception ex)
{
thrownew ApplicationException("Error getting User Language."+ Environment.NewLine + ex.ToString());
}
#else
catch(Exception)
{
}
#endif

Also was geschieht denn hier in dieser Methode:

Die Culture des aktuellen Thread wird auf die Culture des Benutzers gesetzt. Das sind die lokalen Einstellungen des Besuchers also zum Beispiel de-CH oder en-CA.

Das ist sicherlich auch schön und gut für eine YAF Installation die nicht unter DNN läuft, aber für eine in DNN integrierte Version ist das tödlich.

Warum tödlich: Eigentlich ganz einfach, in DNN wird die Culture bereits durch die Standardeinstellung für das Portal oder falls es ein registrierte Benutzer ist aus den Profileinstellungen des Benutzer ermittelt. Mit dieser Information wird die Culture des aktuellen Thread gesetzt. Nun verwenden alle Loaklisierungsfunktionen genau diese Information um eine in DNN installierte Resource Datei zu verwenden und die Sprachspezifischen Texte auszugeben. Genau das schlägt aber fehl, wenn YAF hier an dieser Stelle die Culture des aktuellen Thread auf eine nicht in DNN installierte Sprache einstellt.

Also wie sieht die Lösung aus, ganz einfach:

Wir kömmentieren einfach den gesamten Teil für das setzen der Culture für den aktiven Thread aus.

Das sieht dann so aus:

// try
// {
// string sCulture = "";
// string [] sTmp = HttpContext.Current.Request.UserLanguages;
// if (sTmp != null)
// {
// sCulture = sTmp[0];
// if(sCulture.IndexOf(';')>=0)
// {
// sCulture = sCulture.Substring(0, sCulture.IndexOf(';'));
// }
// }
// else
// {
// sCulture = "en-US";
// }
//
// Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(sCulture);
// Thread.CurrentThread.CurrentUICulture = new CultureInfo(sCulture);
// }
//#if DEBUG
// catch(Exception ex)
// {
// throw new ApplicationException("Error getting User Language." + Environment.NewLine + ex.ToString());
// }
//#else
// catch(Exception)
// {
// }
//#endif

Jetzt noch schnell die YAF.DLL neu kompiliert und das Problem ist ein für allemal beseitigt.

Und die Datenbank wird größer und größer !

hp@schelian.de — Mon, 23 May 2005 11:35:36 GMT

Nach dem Update von DotNetNuke 2.12 auf DotNetNuke 3.0.13 beobachtete ich in den folgenden Wochen ein überdurchschnittliches wachstum der Datenbank.

Mit Überdurchschnittlichem wachstum meine ich in nackten Zahlen ausgedrückt:

Datenbankgröße beim Upgrade 212 MB. (Das war auch in etwa so vor derm Upgrade)

Datenbankgröße 6 Wochen nach dem Update 380 MB

Kann es sein, dass ich so fleißig war und fast 170 MB an Content in die Datenbank geschafft habe ?

Wohl eher nein !

Also musste ich mir doch mal die Datenbank genauer ansehen.

Bei meiner Untersuchung der Datenbank stellte ich fest dass die Tabelle ScheduleHistory doch fast 70 MB groß war, und die SiteLog Tabelle ist auch auf beträchtliche 90 MB angewachsen, leider weiß ich nicht mehr was die während des Updates für eine größe hatte (bin jetzt auch zu faul das Backup auszupacken und irgendwo einzuspielen).

Also gut die größe SiteLog kann ich mir auch noch erklären, ich habe auf den drei Hauptportalen die auf dieser Datenbank laufen keine Beschränkung für die Aufbewahrung der Log Informatinen angegeben, also muss diese Tabelle immer weiter wachsen, aber was ist mit dieser ominösen Tabelle ScheduleHistory.

Diese Tabelle speichert für jeden Schedule Job der ausgeführt wird einen Protokolleintrag und dass sind wenn man es richtig betrachtet doch eine ganze Menge.

Schauen wir uns doch mal die Schedule Einstellungen des Hosts an:

DotNetNuke.Entities.Users.PurgeUsersOnline, DotNetNuke aktiv und Jede minute 1 mal.
DotNetNuke.Services.Log.SiteLog.PurgeSiteLog, DOTNETNUKE aktiv und 1 mal am Tag.
DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DOTNETNUKE aktiv und alle 12 Stunden.
DotNetNuke.Services.Log.EventLog.PurgeLogBuffer, DOTNETNUKE aktiv und jede Stunde.
DotNetNuke.Services.Log.EventLog.SendLogNotifications, DOTNETNUKE aktiv und alle 5 minuten.
DotNetNuke.Services.Search.SearchEngineScheduler, DOTNETNUKE aktiv und jede Stunde 1 mal.

Wenn wir das mal ein wenig berechnen dann sieht das so aus:

Dann haben wir ca. 1500 Eintrgäge je Tag im Protokoll, das macht immerhin 45000 Einträge im Monat 90000 Einträge in 2 Monaten usw.

Nach einger Suche ist mir dann aber die Einstellung (Protokollzeitraum in Tagen) in den Erweiterten Einstellungen in den Systemeinstellungen aufgefallen. Hier kann man einstellen für welchen Zeitraum in Tagen die Protokolleinträge in dieser Tabelle gespeichert werden.

Also Eintrag von -1 auf 14 eingestellt und einfach gewartet bis der Scheduler die Funktion SiteLog.PurgeSiteLog das nächste mal aufruft und die älteren Einträge (älter als 14 Tage) wurden aus der Tabelle gelöscht.

In MB hat das bei mir ca. 40 MB freien Speicherplatz in der Datenbank gebracht.

DotNetNuke Gallerie Neue Version verfügbar

hp@dnnportal.de — Thu, 05 May 2005 03:25:00 GMT

Seit Heute ist eine neue Version des Gallery Moduls auf DotNetNuke.com verfügbar. Das Modul ist weiterhin Beta und ist als installierbares PA und als Source Code verfügbar.

http://www.dotnetnuke.com

Neue Versionen Forum/Blog und Gallerie verfügbar

hp@dnnportal.de — Tue, 03 May 2005 16:38:00 GMT

Seit Heute stehen auf http://www.dotnetnuke.com neue Versionen der Module Forum/Blog und Gallery zum Download bereit.

Skin Problem auf DNNPortal.DE

hp@schelian.de — Tue, 03 May 2005 04:53:00 GMT

Wegen eines aktuellen Problems mit dem Skin von DNNPortal, musste ich das Skin kurzfristig auf ein Standard Skin ändern.

Es wird Heute wegen der Skinänderung zwischendurch immer wieder zu Skin Änderungen kommen.

Ich bitte für diese Maßnahme um Verständniß

Registrieren eines PA (DotNetNuke Modul) in DotNetNuke 3.X

hp@dnnportal.de — Mon, 02 May 2005 04:58:00 GMT

Als Fortsetzung des Lernvideos "PA Erstellung mit DNNJungle Templates" habe ich ein weiteres Lernvideo erstellt.

In diesem fortführenden Lernvideo "Registrieren eines Private Assembly" wird demonstriert wie man ein DotNetNuke Modul (Private Assembly) unter DotNetNuke 3.X manuell registriert.

Die manuelle Registrierung eines Moduls ist notwendig wenn Sie eigene Module für DotNetNuke entwickeln wollen.

Das Lernvideo ist unter dem Titel:

Lernvideo Registrieren eines Private Assembly

im Download Bereich bereitgestellt.

Das Lernvideo ist als Flash Film erstellt und liegt kompiliert in direkt ausführbarer Version vor.

Laden Sie einfach das ZIP File aus dem Downloadbereich herunter und starten die darin enthaltene EXE Datei.

PA Erstellung mit DNNJungle Templates

hp@dnnportal.de — Mon, 02 May 2005 02:10:00 GMT

Nachdem ich immer wieder gefragt werde wie man den am besten beginnt um ein DotNetnuke 3.X Modul (Private Assembly) zu erstellen, habe ich nun auf Basis der DNNJungle Templates für DotNetNuke 3.X ein Lernvideo erstellt, in dem die Grundsätzliche Erstellung mit den Templates in Visual Studio erläutert wird.

Das Lernvideo ist unter dem Titel:

Lernvideo PA Erstellung mit DNNJungle Templates

im Download Bereich bereitgestellt.

Das Lernvideo ist als Flash Film erstellt und liegt kompiliert in direkt ausführbarer Version vor.

Laden Sie einfach das ZIP File aus dem Downloadbereich herunter und starten die darin enthaltene EXE Datei.

NewBlog Version 3.1.5 (Erstes Update)

hp@dnnportal.de — Fri, 29 Apr 2005 15:16:00 GMT

Ca. 6 Wochen nach dem erste offiziellen Release geht Heute das erste Update Version 3.1.5) von NewBlog an den Start.

NEUE FEATURE:

Eintrags bezogene Bilder und Attachment (mit Upload)

NEUE SPRACHEN:

Sprachfiles Rusisch
Sprachfiles Spanisch

FEHLERBEREINIGUNG:

Datumswerte nun alle Universal Time
Permalink jetzt auch Spider freundliche URL
Blog Beschreibung nun validiert (Pflichtfeld)
Multi/Single Blog Einstellungen entfernt, Einstellungen erfolgen über Berchtigungen
Zusätzlich Beschreibung zu den Upload Optionen hinzugefügt
URL im Notification Email berichtigt
Kommentar Link hat mit SFU nicht funktioniert
Exception Handling in URI Funktionen hinzugefügt
Installationsroutine geändert, nun mit Resource.ZIP
Eintrag bearbeiten Link im View Vontrol hinzugefügt
Fehlende Lokalisierung bei Kommentar Benutzernamen hinzugefügt
Löschen von Anonymen Kommentaren berichtigt
Fehler Objekt ist nicht gesetzt bei Blog Ländereinstellungen beseitigt

Archive