Neue Version 3.10.01 des Core Forum/Blog Moduls verfügbar

hp@dnnportal.de — Wed, 15 Jun 2005 09:30:12 GMT

Seit Gestern Abend steht auf DotNetNuke.com eine neue Version des Forum/Blog Moduls zum Donwload zur Verfügung.

Es fehlt jeder Hinweis auf eine Beta Version, so dass man wohl davon ausgehen kann, dass dies die erste Final Release sein soll.

Somit können alle (Hard)Core)Modul anhänger nun endlich eine neue (hoffentlich) funktionstüchtige Version herunterladen.

Meine persönliche Meinung zu diesem mischmasch zweier Module in einem Paket habe ich ja schon an anderer Stelle kund getan.

DNNPortal auf DotNetNuke Version 3.1.0 umgestellt !

hp@schelian.de — Sun, 12 Jun 2005 20:58:10 GMT

Nachdem ich am Wochenende einige Tests mit der neuen Version 3.1.0 vorgenommen habe, konnte ich soeben das DNNPortal auf die Version 3.1.0 umstellen.

Die Umstellung verlief ohne jegliche Probleme.

Nun warten wirs mal ab, welche Problem noch im Echtbetrieb auftauchen.

Mein erstes PA

Sun, 12 Jun 2005 19:00:00 GMT

Gestern habe ich mein erstes PA erstellt. Als Grundlage habe ich dazu die Lernvideos von Hans-Peter (www.dnnportal.de) und die Lernvideos auf DotNetNuke.com benützt.
Das Erstellen der Projekt Strukturen mit den Templates von www.dnnjungle.vmasanas.net funktionierte soweit problemlos. Mit den CodeSmith Templates, ich habe dazu den CodeSmith Exploerer 2.6 benützt, hatte ich aber mehr Mühe. Der Produzierte Code musste ich an einigen Stellen nachbessern.
Das neue PA, ich habe mir da eine ganz einfache Aufgabe gestellt, es soll eine SiteMap angezeigen wobei man ein paar zusätzlch Einstellungen machen kann. Es läuft, aber bringt noch nicht das zufriedenstellende Resultat. Aber das Erfolgserlebnis ist da.
Wenn das PA einmal festig wird, was ich natürlich hoffe, habe ich vor es auch hier zu veröffentlichen.

DotNetNuke 3.1.0 Fehlerbereingte Distribution

hp@dnnportal.de — Sun, 12 Jun 2005 02:11:00 GMT

Obwohl wir lange auf die neue Version 3.1.0 warten mussten, kann man die freigegeben Version wohl nicht als besonders gelungen bezeichnen.

Das Core Team hat, ohne jegliche Information hierüber bekannt zu geben, einfach die Deutsche Lokalisierung aus der Standardinstallation entfernt.

Zudem wurde in den SQL Installationsskripten der Module ein Fehler eingebaut.

Ich habe nun, um den Mitgliedern unserer Community, die manuelle Nachbesserung der Source Distribution zu ersparen eine fehlerbereingte Version erstellt.

Diese Fehlerbereinigte Version enhält nun die Deutsche Lokalisierung (Die Lokalisierung wurde von Sebastian Leupold erstellt) und die Fehler in den SQL Installationsskripts wurden beseitigt.

Der Download steht für alle registrierte Benutzer im Downloadbereich zur Verfügung.

Hier geht es direkt zum Download Bereich

1000 registrierte Benutzer auf DNNPortal

hp@schelian.de — Thu, 09 Jun 2005 13:23:22 GMT

Nach nur 6 Monaten im Netz (DNNPortal Start am 06.12.2004), konnten wir Heute im Laufe des heutigen Tages den tausendsten registrierten Benutzer auf DNNPortal verzeichnen.

Auch wenn eine solche Meldung, an einem Tag an dem die neue Version 3.1.0 von DotNetNuke released wurde, eher als unwichtig erscheinen mag, kann ich mir es aber nicht verkneifen diese kleine Meldung zu schreiben.

Danke an alle Mitglieder und deren mithilfe, dieses Portal in so kurzer Zeit zur Deutschen Quelle Nummer 1 für das Theman DotNetNuke zu machen.

DotNetNuke 3.1.0 ist released

hp@dnnportal.de — Thu, 09 Jun 2005 13:13:00 GMT

Nach langer Wartezeit wurde Heute das neue Release Version 3.1.0 freigegeben.

Mit dem neuen Release wurden wie bereits erwähnt eine Menge Bug Fixes durchgeführt und als größte Neuerung soll nun die Unterstützung für Web Farmen implementiert sein.

Dann wollen wir mal sehen wie stabil diese neue Version ist.

ACHTUNG:

Bitte unbedingt die Hinweise im Installation Guide lesen. Die Datei ist zu finden unter DotNetNuke/Dokumentation/Public

ACHTUNG ACHTUNG:

Nach dem Update ist keine Deutsche Lokalisierung mehr vorhanden.

Ich möchte an dieser Stelle den Kommentar von Sebastian Leupold aufnehmen und darauf hinweisen, dass Sebastian das Sprachpaket für DNN 3.1.0 bereits fertiggestellt und zum Download zur Verfügung gestellt hat.

Vielen Dank Sebastian

Hier gehts zum Download des Deutschen Sprachpakets

http://dotnetnuke.gamma-concept.de/Default.aspx?tabid=156

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.

Archive