Colophon in WordPress-Themes

In manchen WordPress-Themes, zum Beispiel im Standard-Theme Twenty Eleven, findet man die ID colophon in style.css bzw. in footer.php. Es geht offensichtlich um die Angaben im Fußbereich, aber ich hatte das Wort Colophon, oder in deutsch Kolophon, noch nie gehört und recherchierte im Netz und in Wörterbüchern.

Der Begriff stammt aus dem Verlagswesen. Schon im Mittelalter wurde die Druckermarke, also das Signet des Druckers, auf der letzten Buchseite eingedruckt – in der Frühzeit des Buchdrucks war der Drucker oft gleichzeitig der Verleger und auch Buchhändler. Später wurden die Druckermarken durch die Verlagssignete ersetzt. Der Kolophon kann entweder auf der Rückseite des Titelblattes oder ganz am Ende des Druckwerkes stehen. Er enthält heute üblicherweise Informationen über Inhalt, Verfasser, Ort, Zeit, Hersteller, Auftraggeber und Produktionsdetails. Oft sind die Angaben auch aufgeteilt, sodass zum Beispiel Angaben zum Druck vorne platziert sind und hinten Kurzlebensläufe der Autoren oder Dankesworte zu finden sind.

Insofern kann ein Kolophon auch auf einer Website auftauchen. Es ist zu unterscheiden vom Impressum, das Pflichtangaben über den Herausgeber der Website, Kontaktdaten und oft auch weitere gesetzlich vorgeschriebene Angaben enthalten muss. Bei manchen Geschäftsbetrieben oder Freiberufen muss zum Beispiel die zuständige Aufsichtsbehörde genannt werden.

Im Kolophon hingegen findet man manchmal Informationen zu (X)HTML und CSS, Angaben zur Benutzerfreundlichkeit, verschiedene Qualitätssiegel oder einen Hinweis auf das eingesetzte Content-Management-System. Sehr gut eignet sich für all dies der Fußbereich. Der Betreiber der Website oder die Autoren des Blogs stellen sich aber oft auf einer ganzen Seite vor, die etwa Über uns oder About us genannt wird.

WordPress liegt somit nach meinem Verständnis nur teilweise richtig damit, Colophon zu dem Fußbereich zu sagen. Andere Inhaltsverwaltungs-Systeme nennen es allgemeiner Footer.

Quellen:
http://blog.templaterie.de/about/
Duden-Wörterbuch
Langenscheidt-Wörterbuch
http://de.wikipedia.org/wiki/Kolophon_(Schriftstück)
http://de.wikipedia.org/wiki/Geschichte_des_Buchdrucks

concrete5: Verlorenes Passwort in der lokalen Testumgebung

Es passiert immer mal wieder und es passiert wohl jedem mal (da schließe ich jedenfalls von mir auf die Allgemeinheit): man verliert oder vergisst ein Passwort und kommt nicht mehr ins entsprechende System hinein. Wie fast alle Content-Management-Systeme bietet auch concrete5 die Möglichkeit, sich einen Link per E-Mail zuschicken zu lassen, mit Hilfe dessen man ein neues Passwort eingeben kann.

Im Falle einer lokalen Installation auf einem Windows-Computer wird das nicht klappen, es sei denn, man hätte einen lokalen Mailserver installiert. Es gibt für diesen Fall verschiedene Lösungen. Als die einfachste erscheint mir die folgende:

1. Das Passwort-»Salz« (Erklärung siehe Wikipedia), das in der Datei [concrete5-Verzeichnis]/config/site.php steht, kopieren.
2. Mit einem Datenbank-Bearbeitungs-Programm (zum Beispiel HeidiSQL oder MySQL-Front) die in MySQL integrierte MD5-Funktion eingeben und als Query absenden:
UPDATE Users SET uPassword = md5('password:salt')
WHERE uName = 'username';

Für password setzt man das gewünschte neue Passwort ein, salt ist eben die Salt-Zeichenfolge aus site.php und username der Name des Benutzers, für den man das vergessene Passwort erneuern will. Das wird natürlich in aller Regel der Superadmin sein.

Danke an okhayat!
http://www.concrete5.org/community/forums/usage/local_install_lost_password/

concrete5: Absender im Kontaktformular (3)

Im gestrigen Artikel schrieb ich, wie man die standardmäßig vergebene Absenderadresse im Kontaktformular ändern kann.
Um den Absender auch für diejenigen Mitteilungen zu ändern, die zum Beispiel bei Registrierungen oder vergessenen Passwörtern übersendet werden, empfiehlt sich folgender Code, den man auch wieder in die Datei [root]/config/site.php einträgt (Beispielangaben bitte durch die echten ersetzen):

define('EMAIL_DEFAULT_FROM_ADDRESS', 'noreply@example.com');
define('EMAIL_DEFAULT_FROM_NAME', 'Maria Musterfrau');

Quellen:
www.concrete5.org/[…]/change-concrete5-noreplyyourdomain-com/
www.concrete5.org/[…]/change-email-for-user-registration/
Danke an alle, die ihre Lösungen im Forum veröffentlicht haben!

concrete5: Absender im Kontaktformular (2)

In einem älteren Artikel hatte ich eine Lösung vorgeschlagen zu einem Problem mit dem Form-Block, mit dem man Kontaktformulare erstellen kann. Standardmäßig wird nämlich immer die E-Mail-Adresse des Superbenutzers als Absenderadresse der Anfragen angegeben. Dies führt manchmal zu Verwunderung und Misstrauen bei den Kunden.

Meine damalige Lösung erforderte Eingriffe in den Block und war umständlich und unelegant. Aber man lernt ja immer dazu, und jetzt kann ich eine bessere Lösung präsentieren:

Fügen Sie eine einzige Codezeile zu [root]/config/site.php hinzu (»example« muss natürlich durch die echten Angaben ersetzt werden):
define('FORM_BLOCK_SENDER_EMAIL ','example@example.com');

Danke an Ekko!
http://www.concrete5.org/community/forums/usage/concrete5-forms/#349698

concrete5: Fehlermeldung beim Upload von Blöcken

Neulich setzte ich concrete5 in Version 5.6.0.1 in meiner Testumgebung komplett neu auf, weil das Upgrade von Version 5.5.2.1 fehlgeschlagen war. Eine Neuinstallation war in diesem Fall weniger aufwändig, als den Fehler zu suchen und zu korrigieren.

Als ich aber modifizierte Blöcke (blocks) wieder in den dafür vorgesehenen Ordner [root]/blocks/ hochgeladen hatte, wurden Fehlermeldungen angezeigt, die auf angebliche Fehler im jeweiligen Controller (controller.php) der Blöcke hinwiesen. Ich konnte in den Dateien aber nichts Fehlerhaftes entdecken, außerdem hatte ja auch vorher alles funktioniert. Kurzum, ich konnte mir keinen Reim darauf machen.

Im concrete5-Forum fand ich die Lösung: Man muss zunächst die Blöcke wieder aus dem Verzeichnis löschen, dann (über das Dashboard) das Caching (die Puffer-Speicherung) komplett ausschalten und den Cache leeren. Danach lädt man die Blöcke wieder hoch, und nun funktioniert alles.

Danke an yeetien fürs Veröffentlichen seiner oder ihrer Lösung!
http://www.concrete5.org/index.php?cID=377099

Online das Programmieren von Web-Sprachen lernen

In der Codecademy kann man das Programmieren lernen, zumindest das Programmieren in typischen Web-Sprachen. Als da wären:

  • JavaScript (in den Grundzügen)
  • JQuery (= JavaScript-Bibliothek)
  • HTML und CSS (aber das sind eigentlich keine Programmiersprachen)
  • und alles zusammen, um damit Webseiten zu erstellen
  • ach ja, und auch noch Python (ein Allrounder)

Ich musss gestehen, dass ich noch keinen Kurs davon ausprobiert habe. Bisher habe ich immer mit Hilfe von Büchern gelernt und bei speziellen Aufgabenstellungen mich in Foren nach Lösungen umgesehen. Aber dass bei der Codecadamy Python angeboten wird, reizt mich, denn diese Sprache wollte ich immer schon mal lernen. Ich fand bisher nur keine Zeit. Ob mich so ein Online-Lehrgang dazu bringt, eben doch endlich mal die Zeit zu investieren?

Wir werden sehen.

URL-Rewriting in lokaler Testumgebung

In meiner lokalen Testumgebung auf meinem Windows-Computer läuft als HTTP-Server Apache, natürlich PHP als Programmiersprache und MariaDB – das Datenbank-Management-System, das kompatibel zu MySQL ist. Alle Komponenten sind separat installiert, also nicht als XAMPP-Paket; aber das nur am Rande.

Natürlich betreibt man lokal keine Suchmaschinenoptimierung, und so ist es eigentlich egal, wie der URL geformt ist. Dennoch möchte man gern alles so testen, als liefe es auf einem Produktiv-Server »da draußen«. Als ich in einem CMS, das ich ausprobieren wollte, die »hübschen URLs« einschaltete, wurde auch die .htaccess-Datei korrekt erstellt. Aber die Website war nicht voll benutzbar, weil sich die Unterseiten nicht besuchen ließen. Es wurden Fehlermeldungen ausgespuckt: die jeweilige Seite sei nicht erreichbar.

Ich dachte zunächst an einen Fehler im CMS. Aber in einem Shopsystem, das ich daraufhin zum Testen installierte, trat genau dasselbe Phänomen auf. Also kam mir die Idee: Die .htaccess-Datei wird nicht ausgelesen oder deren Anweisungen werden nicht befolgt. Das Modul mod_rewrite war allerdings installiert. Ich wusste aber nicht, was in der Konfigurationsdatei des Apache-Servers falsch sein könnte.

Bei Stack Overflow fand ich die Lösung (danke an Sidney Veiga und todofixthis): In der httpd.conf muss man im zweiten Bereich Directory (dort, wo das Wurzelverzeichnis, DocumentRoot, angegeben wird) AllowOverride auf All setzen. Bei mir hatte None gestanden.

allowoverride-all.png

Admin-Passwort in osCommerce vergessen

Ich hatte vor einiger Zeit in meiner Testumgebung osCommerce installiert und wollte kürzlich mal daran weiter arbeiten. Doch ich hatte mir das Admin-Passwort nicht notiert, was mir eigentlich selten passiert. Erinnern konnte ich mich auch nicht.

Es gibt aber eine einfache und schnelle Möglichkeit, das Passwort auf einen Standard zurückzusetzen. Anschließend loggt man sich ein und gibt wieder ein sicheres Wort ein.

Man benötigt dazu ein auf dem Webserver installiertes phpMyAdmin, was eigentlich bei jedem Webhosting-Vertrag Standard ist. Man sucht sich die Tablle administrators heraus, die je nach Tabellen-Präfix natürlich zum Beispiel auch osc_adminstrators heißen kann. Die Passwörter sind verschlüsselt gespeichert. Im Passwortfeld überschreibt man den bisherigen Eintrag mit b5eb650d32fc4980284427104829b556:f6, was im Klartext admin heißt, und danach kann man sich wieder einloggen. Der erste Handgriff ist dann, wie gesagt, die Änderung des Passwortes.

Übrigens sollte man in einer Produktivumgebung den Admin-Benutzernamen als kleine Zusatz-Sicherheitsmaßnahme immer in einen möglichst nicht zu erratenden Namen umbenennen.

Einfache Datensicherung in WordPress

Ich habe lange nach einem Datensicherungs-Plugin für WordPress gesucht. Vor einiger Zeit fand ich DBC Backup, mit dessen Hilfe man Datenbank-Backups auf dem Webserver in regelmäßigen Zeitabständen speichern kann. Man kann auch zwischen verschiedenen Kompressions-Methoden wählen, je nachdem, was vom Server unterstützt wird. Und ein Backup lässt sich auch von Hand anstoßen.

Der Nachteil ist allerdings, dass keine direkte Download-Möglichkeit angeboten wird, denn manchmal möchte man ja direkt aus WordPress heraus die Datenbank auf den PC speichern.

Doch kürzlich habe ich ein Datenbank-Backup-Plugin gefunden, das mich rundum zufriedenstellt. Es nennt sich PressBackup und kann auf den Webserver speichern, aber auch nach Dropbox oder Amazon S3. Oder für 10 USD pro Monat nach PressBackup.com. Dies bietet sich an, wenn man sehr große Datenmengen sichern und viele Backup-Versionen gespeichert lassen will (bis zu 50 möglich).

Gefunden habe ich den Tipp zu PressBackup im Blog von Matthias Pabst. Vielen Dank!

Nachtrag:
Einen weiteren heißen Tipp gab Trickser (siehe Kommentarbereich). Danke dafür!

xt:Commerce nicht mehr als Community Edition

Das beliebte Shop-System xt:Commerce ist seit dem 01. Juni 2012 nicht mehr in der kostenlosen Community Edition erhältlich. Im kürzlich verschickten xt:C-Newsletter stand:

[…] Ab sofort stehen Ihnen 2 neue xt:Commerce Versionen — Professional für € 99 und Professional+ für € 299 — zur Verfügung. Die xt:Commerce Community Edition ist seit dem 01.06.2012 nicht mehr verfügbar. […]

Das sind immer noch äußerst moderate Preise. Da ich aber xt:Commerce »hinter den Kulissen« nicht gerade für ein übersichtliches System halte, und um meinen Kunden weiterhin ein kostenloses Shopsystem anbieten zu können, werde ich mich, sobald ich die Zeit dazu finde, mal in PrestaShop einarbeiten. Es ist Open-Source-Software und, wie gesagt, gratis. Man kann das Grundsystem mit Erweiterungen aufmotzen, die dann allerdings kostenpflichtig sind. Ob man zwangsläufig welche braucht oder ob man auch mit dem nackten Grundsystem schon auskommt, wird sich bei meinen Tests herausstellen.

http://www.prestashop.com/de/

Nachtrag:
Natürlich wäre osCommerce die vielleicht naheliegendste kostenlose Möglichkeit. Schließlich ist xt:Commerce ein Ableger davon, und so gesehen könnte man halt gleich auf das Ur-System zurückgreifen. Die 3er-Version, an der gerade programmiert wird, macht auch einen recht vielversprechenden Eindruck. Allerdings läuft sie erst ab PHP 5.3, und noch nicht alle Webhoster haben auf diese PHP-Version umgestellt. Demnächst mehr zu osCommerce.