Archiv der Kategorie: webEdition

webEdition: Bestehende Datenbankverbindung nutzen

In webEdition kann man viel machen, es ermöglicht einem wirklich sehr große Freiheit. Der große Vorteil diese Freiheit hat aber auch einen großen Nachteil: Man muss sich im System auskennen, um damit wirklich gute Seiten bauen zu können; ganz schnell kann man auch sehr langsame Seiten erstellen, die dann nicht nur den Besucher, sondern vor allem den Kunden verärgern.

Aus einem aktuellen Projekt stelle ich eine wirklich böse Fehlerquelle vor: Die mehrfache Datenbank Verbindung. Im Template ist es recht einfach, eine neue DB-Verbindung mit der bekannten (und veralteten) Funktion

$db = mysql_connect(...);

zu erstellen. Aber warum sollte man das machen? Wohl nur aus Unwissenheit, dass webEdition bereits eine Datenbankverbindung eröffnet hat und diese auch dem Entwickler bereitstellt.

Also, liebe webEdition-Entwickler, die bestehende, persistente und performantere DB-Verbindung könnt ihr recht einfach für eigene Zwecke benutzen:

$db = $GLOBALS['DB_WE'];
$stmt = $db->query('SELECT * FROM tblUser');
while ($data = mysql_fetch_assoc($stmt)) {
Zend_Debug::dump($data);
}

Muss man dann doch mal eine zweite Verbindung aufbauen – was im Einzelfall manchmal wirklich sein muss – dann ist dem Entwickler ja meist bewusst, was er da macht und ich hoffe, er benutzt dann dafür nicht die alten, langsamen MySQL-Funktionen, sondern entweder die MySQLi-Pendants oder eine PDO-Schnittstelle.

Leider stellt webEdition keine Instanz von Zend_Db bereit, so dass zwar die Generierung des Querys OOP stattfindet, aber es dannach mit den bekannten mysql-Funktinen weitergeht. Das ist ein recht großer Nachteil, da es die Möglichkeit nimmt, auf einem modernen (aktuellen) Niveau zu arbeiten und ich hoffe, dass dieses Manko bald durch ein aktuelles Release behoben wird.

Eine Liste aller Seiten mit webEdition

Eine Liste über alle oder nur bestimmte Seiten auf seinem Webspace ist immer nützlich, z.B. als Sitemap, als Übersicht der neuesten 10 Seiten, für’s RSS Feed oder oder oder.
Der Ablauf, wie man das ganze mit webEdition realisiert, ist im Prinzip immer der gleiche. Das Zauberwort bzw. we-Tag, welches man dazu braucht, nennt sich we:listview.

Mit einer we:listview erhält – mit einer der vielen „type“-Attribute – auch alle Dokumente, die einem bestimmten Filter entsprechen. Einzig zwingendes Attribut bei we:listview ist das „type“-Attribut, welches für den aktuellen Fall auf „document“ gesetzt wird.

Eins vorweg: we:listview erfasst Dokumente nur unter zwei Bedingungen:
Entweder die Dokumente haben in den „Eigenschaften“ das Attribut „durchsuchbar“ gesetzt oder man setzt das Attribut searchable des we:listview auf „false“.

Durchsuchbar vs. searchable
searchable ist der einfachste Fall, dabei werden allerdings alle Dokumente erfasst, die das entsprechende Feld „durchsuchbar“ auf „False“ haben. Das die Dokumente dieses Attribut nicht gesetzt haben, dürfte der normalfall sein. Dageben findet „searchable=true“ nur Dokumente, die das entsprechende Feld auch gesetzt haben.
Nun das für und wieder:
Im Fall „searchable=false“ erfasse ich alle Dokumente und kann mit setzen der Eigenschaft „durchsuchbar“ ein Dokument von der Suche ausnehmen. Sinnvoll, wenn nur wenige Dokumente _nicht_ in der Suche erscheinen sollen.
Im anderen Fall kann ich exakt steuern, welche Dokumente gefunden werden dürfen.
Welches von beiden man wählt kommt auf den Anwendungsfall an.

Filter nach Typ
Will man nur bestimmte Dokumenttypen erfassen – die we:listview benennt Dokumente nicht nur nach webEdition Dokumenten, sondern auch Bilder usw.; ein we:listview Dokument ist etwas, was physikalisch auf dem Server liegt – dann muss man „contenttypes“ setzen. Im Falle von „neueste 10 Seiten“ oder „Sitemap“ setzt man dies auf „text/webedition“. Dann erfasst man alle Seiten, die man auch mit webEdition erstellt hat und bearbeiten kann.

Filtern nach Verzeichnissen
Manchmal möchte man nicht „alles zeigen“, sondern nur Seiten aus bestimmten Verzeichnissen. Dann gibt man die ID der Verzeichnisse einfach im Attribut „workspaceID“ als komma-separierte Liste an. Möchte man zusätzlich noch Unterverzeichnisse einbeziehen, dann muss das Attribut „recursive“ auf „true“ gesetzt werden.

Startpunkt und Anzahl der Links
Schön zum begrenzen der angezeigten Links: „rows“ und „offset“.
Mit „rows“ legt man fest, wieviele Treffer gezeigt werden, mit „offset“ bestimmt man … nunja, den offset halt. Diese Einstellungen werden für z.B. für eine Blätterfunktion genutzt, der interessierte Leser liest dazu bitte das Beispiel auf der Referenzseite an und sieht bei den Tags „we:listviewPageNr“, „we:listviewPages“, „we:next“, „we:ifNext“, „we:back“ und „we:ifBack“ nach.

Sortierreihenfolge und -richtung
Braucht man eine Sortierreihenfolge, dann setzt man „order“ auf einen dieser Werte:
random() -> Zufällige ausgabe
we_creationdate -> Erzeugungsdatum
we_filename -> Dateiname
we_id -> Die ID
we_published -> Wann veröffentlicht
we_moddate -> Zuletzt geändert

Normalerweise werden die Einträge aufsteigend sortiert, benötigt man absteigende Sortierung, setzt man „desc“ auf „true“ (z.B. für die neuesten Seiten wichtig).

Weiteres
we:lisview bietet noch viele weitere Optionen, die ich selbst bisher nicht gebraucht habe und für dieses Beispiel einfach zu viel sind. Ich bitte den geneigten Leser, mal in der Doku zu we:listview nach zu schlagen … auch wenn diese bisweilen nicht so ergiebig ist, wie man es sich oft wünschen würde.

we:repeat und we:field
Um durch die Treffer zu iterieren, benötigen wir das we-Tag we:repeat, dass dann von „offset“ bis „rows“ die Treffer der Reihe nach ausgibt. Die Informationen zu den Treffern findet man in we:field, über dessen Attribute kommt man dann an alles, was benötigt wird.

Ein Beispiel
Auf einer meiner Seiten gebe ich die 5 Dokumente aus, die ich mit webEdition veröffentlicht habe, allerdings dürfen diese nur in bestimmten Verzeichnissen liegen und müssen dazu noch das Attribut „durchsuchbar“ gesetzt haben. So kann ich ganz genau steuern, welches Dokument dort auftaucht und welches nicht. Dieser Ausschnitt hier ist 1:1 und liegt in einem Template namens „listviewtest.tpl“









Ich kann nun die Darstellung der 5 neuesten Dokumente einfach mittels



oder



in meine Vorlagen einbinden.

Für eine Sitemap sollte man das Attribut „rows“ evtl. weglassen, so dass alle Dokumente angezeigt werden, ebenso kann man sich natürlich was für Darstellung überlegen.

Das hier soll nur ein Einstieg sein und ich hoffe, ich konnte euch das „rüberbringen“. Die Erstellung von Listen auf Basis der webEdition Dokumente sollte nun kein großes Problem mehr sein.

webEdition kann nicht gestartet werden. session.save_path = “

Aufruf des webEdition Login Fentsers und … *boom* Eine Fehlermeldung, aber was für eine:

WebEdition kann nicht gestartet werden: 0 – Die Variable session.save_path zeigt auf “. Dieses Verzeichnis gibt es nicht auf Ihrem Server!

*puh* Kramwühlsuch, warum, wieso, weshalb, ich hab doch nix verändert…*kopfkratz*

Nach langer Suche kontaktiere ich den Support meines Hosters, der löst das Problem in Sekunden:

In der Datei „/webEdition/we/include/conf/we_conf.inc.php“ muss ein Eintrag geändert werden, von

// Domain or IP address of the database server
define("DB_HOST","localhost");

auf diesen Wert

// Domain or IP address of the database server
define("DB_HOST","127.0.0.1:3306");

Aussage des Support-Mitarbeiters zu meiner Frage „Warum funktioniert das nicht mir localhost?“

Der Zugriff auf localhost ist aus Sicherheitsgründen deaktiviert!

Schön und gut, aber warum sagt die Fehlermeldung was über session.save_path?

Ganz einfach: webEdition versucht auf die Datenbank zuzugreifen, aufgrund der Blockade von localhost scheitert diese Verbindung. Allerdings gibt es dazu keine Rückmeldung, webEdition macht einfach weiter und liest die Konfigurationsdaten aus (zumindest versucht webEdition, dass zu machen). Unter diesen vielen Konf.-Daten ist auch die session.save_path, diese wird mit “ initialisiert. Da nun der Zugriff fehlschlägt, bleibt der Wert “ erhalten und nun prüft webEdition irgendwann, ob das Verzeichnis für die Sessions überhaupt vorhanden ist. Da dies nicht der Fall ist kommt o.a. Fehlermeldung – die natürlich völlig falsch ist.

Also, liebe webEdition-Leute: Bitte das ganze mal überprüfen, denn mit _dieser_ Meldung konnte ich nix anfangen. Ein Hinweis von wegen „Konnte die DB nicht öffnen, Fehlercode xyz“ wäre da um Längen besser gewesen.

RewriteRule nur für nicht vorhandene Dateien

… oder wie stelle dynamische Inhalte in statischen webEdition Seiten dar?

Die Apache RewriteRule kennt wohl jeder, der etwas mehr mit Webseiten macht. RewriteCond sollte auch bekannt sein, allerdings hatte ich bisher diese beiden Direktiven nicht in dieser Form miteinander verbunden.

Das Problem:

Ursächlich war, dass ich in webEdition Seiten dynamische Inhalte anzeigen wollte. Die Inhalte kommen von extern und somit wollte ich a) die Seite nur einmal bauen und b) einen Teil der Inhalte von ausßen dynamisch füllen (z.B. die neuesten Twitter-Feeds oder oder oder).

Nun merke ich schnell: Ist eine webEdition Seite einmal als “statisch” definiert, dann ist diese auch genau das: statisch. Es ist HTML, webEdition zieht alle Informationen die es braucht in dem Moment aus alles Quellen und schreibt eine .html-Seite. Mehr nicht. Aber genau das soll webEdition ja auch machen. Also kein Grund zum meckern … oder? Bedingt.

Ja, webEdition macht rein technisch alles richtig, nur will ich doch in einer Sidebar dynamische Inhalte haben 🙁

Okay, Seite auf “dynamisch” umstellen und dann: Lasse ich die Dateiendung auf .html, dann sehe ich nur PHP-Code.

Sicher, ich könnte nun die Dateiendung umstellen – auf .php funktioniert das ganze wie gewünscht – aber das ist weder Sinn der Übung, noch ist das gewünscht; Stichwort Kundenwunsch!

Lösungsvorschläge:

Also, hier der andere Weg: mod_rewrite.

Der einfachste Weg: Alles, was .php heißt in .html umleiten, aber Halt! Der erfahrende Mensch sieht: Das geht schief, denn es können durchaus .php Dateien auf dem Server liegen, die auch ausgeführt werden wollen.

Lösungsvorschlag 1:

AddHandler-Direktive nutzen.
Man könnte die AddHandler Direktive nutzen und allen .html-Code als PHP ausführen lassen. Bei statischen Seiten würde dies nur sehr geringen Zeitverlust bedeuten und es würden die .html-Seiten auch korrekt ausgeführt, die PHP-Code beinhalten (also unsere dynamischen webEdition Seiten).

Lösungsvorschlag 2:

Bedingtes Umleiten!
Funktioniert Lösung 1 nicht (warum auch immer) oder ist dieser Weg nicht gewünscht (der Kunde ist doch König), dann sollte man es so versuchen – und kommen damit wieder zur Überschrift zurück (was für ein Handlungsbogen).
Man leitet alle Anfragen auf .html-Seiten, die nicht existieren, auf .php-Seiten um, die exakt so heißen, wie die .php Version.

Schritt 1: Zuerst werden die webEdition-Seiten geparkt, als dynamisch markiert und dann als xyz.php gespeichert.

Schritt 2: In der .htaccess wird folgende neue RewriteCond mit folgender RewriteRule ergänzt … ich habe diese ganz ans Ende gepackt, kommt aber immer auf den individuellen Fall an:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.html $1.php [L]

So werden nun nur die .html-Aufrufe an .php-Scripte übergeben, deren .html-Datei nicht real auf dem Dateisystem des Servers existiert.

Viel Erfolg…

webEdition kann PHP nur eingeschränkt

Das webEdition – CMS ist bekannt dafür, dass es einiges kann und viel Arbeit erzeugen kann. Dafür ist es u.a. möglich, beliebigen PHP Code in die Templates zu schreiben.

Dachte ich …

Allerdings kann webEdition PHP nur eingeschränkt, was ich am Beispiel eines Quellcodes verdeutlichen will. Ebenfalls soll hier eine Liste entstehen, was ich wann entdecke und wann es ggf. behoben wird.

  1. [28.05.2010] && und AND
    Die Verkettungsoperatoren && und AND sind ja für die “normale” Programmausführung relativ gleich (es wird eine UND-Verknüpfung erstellt), lediglich der Rang der Operator-Rangfolge ist anders (&& ist “(ge)wichtiger”).
    webEdition kennt AND überhaupt nicht, obwohl beide zum PHP-Sprachkern gehören.
    Bringt man nun in einem webEdition Template z.B. eine if-Abfrage mittels AND ein, so gibt webEdition für alles nach (!) dem ersten Ausdruck true zurück. Wählt man den ersten Ausdruck also etwas unglücklich, kommt im betreffenden if immer true zurück und somit wird Code ausgeführt, den man eigentlich erst unter bestimmten Bedingungen ausführen wollte.

Mal schauen, wann das webEdition Team das ganze behebt. Eine Rückmeldung an mich wäre toll, da ich das ganze nicht jeden Tag gegenprüfe.

webEdition xmlfeed, xmlnode und xpath

Möchte Mensch in webEdition bei Benutzung der xmlnode mehr als nur die Standard Methoden aus XPath verwenden, muss Mensch wirklich aufpassen. Ein Fehler in der Verarbeitung der Eingaben führt zu einer Kuriosität, die Mensch wissen sollte.

Folgender Code zu Testzwecken:



Title:

Wer XPath kennt, der weiß, was passieren soll. Innerhalb des XML gibt es den Punkt “/rss/channel” , unter diesem Punkt existieren beliebig viele “item” Knoten, von diesen sollen nur die ersten beiden ausgelesen werden.

Allerdings: Der o.a. Code führt zu

Parse error: syntax error, unexpected ‚}‘ in /home/user/public_html/webEdition/we/tmp/c9dc681659bd7c5703d6223dfd485587 on line 186

Generell ist der Code aber korrekt, ein Fehler in webEditions Verarbeitung des “xpath” Attributs verhindert aber die Ausführung.

Der korrekte Code für die Zeile der 2ten xmlnode lautet:

Mensch sieht also sofort: Hier müssen die XPath Argumente HTML Encoded werden.

Nur zur Info …

Templates einbinden mit webEdition

Das schöne an webEdition ist, dass man sog. Mastertemplates verwenden kann. Das noch viel schönere ist, dass diese Mastertemplates wiederrum wieder Mastertemplates haben können – die Master rufen sich dann sozusagen rekursiv auf, bis es ein “normales” Template gibt, dass die Inhalte eingibt.

Auch schon gelöst ist, dass man in einem webEdition Template andere Templates einbinden kann – mittels we:include, dem man entweder die ID des Template gibt, dass eingebunden werden soll oder eben den sog. path, also den Pfad inklusive Namen und Erweiterung des Templates. Schöne Sache, das.

Weniger schön ist dagegen ein webEdition Projekt, welches – bedingt durch über ein halbes dutzend Sprachen und vielen, vielen Vorlagen – eine 3 stellige Template Zahl beinhaltet und das ist unzählbar vielen Ordnern. Wow.

Und nun der eigentliche Punkt: Ein Blick in das deutsche Mastertemplate zeigt:

Okay, und nun? Ich muss eine Änderung an diesem Template durchführen, aber welches ist nun Template 1308? Es bleibt einem nichts anderes übrig, als mit der Maus über jedes Element zu fahren, um im Hover dann die ID zu sehen. #Nerv.

Daher: Bitte, bitte, liebe webEdition Template Editoren: Benutzt NICHT das ID-Tag, nehmt das path-Attribut des we:include.

Ich finde, das hier sieht schon viel freundlicher aus und läßt sich, zumindest meiner bescheidenen Meinung nach, viel besser und schneller finden:

Ist zwar mehr Tipparbeit, aber grade im Team sehr hilfreich. Denkt auch daran, was passiert, wenn ihr nach 2 Jahren mal wieder so ein Projekt pflegen müsst und zwischendurch 18 andere Projekte bearbeitet wurden … ihr blickt wahrscheinlich selbst nicht mehr durch und fragt euch, welcher Idiot da das ID-Tag ben…oh, das war ja ich *ups*

In diesem Sinne…

webEdition Seiten umbenennen

Man kann keine webEdition Seiten umbenennen, so war mein Stand bis vor kurzem.

Dumm nur: Es geht und zwar so:

Auf die Seite, die Seiten unten “Parken”, dann umbenennen und wieder veröffentlichen. Fertig!

So einfach geht das …

Auch Profis machen Fehler *grins*

Ich wühle mich durch die Dokumentation zu den we-Tags von webEdition. Dabei fiel mir auf, dass auch gestandene Profis im Webbereich Fehler machen, die diese eigentlich nicht machen dürften.

Ein Beispiel aus der Doku zum we-Tag “we:keywords”:

Mit htmlspecialchars=“true“ werden Sonderzeichen in HTML-Entities umgewandelt (z.B. wird „&“ zu „&“). Ist htmlspecialchars nicht gesetzt, wird diese Umwandlung nicht vorgenommen.

Sicherlich ist gemeint, dass ein & zu einem & wird, aber da hat wohl der Editor dem Autor einen Streich gespielt und das & nicht richtig “escaped” und der Browser stellt das & (ganz korrekt übrigens) als & dar.

Also, liebe Profis bei webEdition, durchcrawled mal eure Doku und korrigiert dies bitte, damit auch Amateure den Mehrwert des Attributes “htmlspecialchars=true” kennenlernen dürfen.

Irgendwie bin aber doch beruhigt, dass sowas auch anderen passiert, sind also doch alles auch nur Menschen am anderen Ende der Doku *wink*

Umlaute in webEdition – ein Problem

Unser neues Kundenprojekt soll mit webEdition umgesetzt werden. Dabei setzen wir die Version 6.0.0.6 ein, die aktuellste und installieren das ganze mit Hilfe des Online Installers. So weit, so gut. (Anmerkung: Alle Einstellungen stehen, soweit möglich, auf UTF-8).

WebEdition ist installiert, eine Vorlage ist erstellt und ein paar -Tags sind auch gesetzt. Nun heißt es “nur noch den Inhalt einfügen”.

Im Inhalt aber befinden sich Umlaute, solch bösen ä´s und ü´s und ö´s und so weiter. Beim ersten Speichern sieht alles noch gut aus. Also veröffentlichen und ansehen.

*bumm* Alle Umlaute sind maskiert, sowohl in Firefox und IE, als auch in Chrome, Opera, Safari und Iron. Komisch, komisch. Also in webEdition die Seite wieder öffnen.

*argl* Die Seite ist völlig verwurschtelt (sagt man so am Niederrhein), also total unbrauchbar.

Stunden später finden wir im Team folgendes raus: Befinden sich Umlaute im Text, so schneidet der WYSIWYG-Editor von webEdition 6.0.0.6 den Text ab der ersten Position eines Sonderzeichens ab. Das zerhaut uns nicht nur unser Layout, sondern wir müssen nun lang und breit eine Lösung suchen.

Nachtrag von 13:30 Uhr:

So, wir haben uns den aktuellen Stand der Version 6.0.0.7 aus dem SVN gezogen, in dieser Version wurde nun der Umlautefehler behoben. Ein kurzer Test ergab, dass dies auch wirklich stimmt. Dann kann die Arbeit ja weitergehen …

Nachtrag vom 05.11.2009 09:26 Uhr:

Im trunk des SVN liegt eine neue Datei, die genau dieses Problem nun löst, die Datei heißt:

/webEdition/we/include/we_editors/we_editor_script.inc.php

und es handelt sich um die Revision 1409.

Mit Hilfe dieser war es uns nun möglich, den Editor wieder in Betrieb zu nehmen. Ein Hinweis noch: In webkit-basierten Browsern – wie Chrome, Iron, Safari, usw. – macht der Editor probleme. Es ist nicht möglich, die Schriftgröße zu ändern. Sobald man das entsprechende Feld anklickt, wird der selektierte Text auf maximalgröße gesetzt und läßt sich auch dannach nicht mehr ändern.

Aber immerhin funktioniert nun soweit alles im IE und FF, dass man damit etwas besser arbeiten kann.