Archiv der Kategorie: Webentwicklung

Ein besonderer Fall trat neulich beim Upgrade von 5.4.x auf 5.5.x auf. Das Upgrade wurde zwar einwandfrei durchgeführt, es gab also keine Fehler wegen der geänderten Datenbank – aber als ich mich nach Abschluss des Vorganges erneut einloggen wollte, war kein Dashboard zu sehen. Der Platz für die obere Admin-Leiste war aber offensichtlich reserviert, oder anders gesagt: die Seite erschien ein Stück nach unten verschoben.

Man kann dennoch ans Dashboard dran kommen, nämlich indem man in die Adresszeile des Browsers http://www.meine-domain.de/dashboard oder http://www.meine-domain.de/index.php/dashboard eingibt. Dort kann man dann einen eventuell eingeschalteten Wartungsmodus wieder auf Normalmodus stellen oder nach sonstigen Auffälligkeiten suchen.

Wenn es das alles nicht ist, gibt es noch eine weitere Möglichkeit, die man ausprobieren kann. In meinem Fall war das der ausschlaggebende Punkt. Und zwar prüft man nach, ob in der Footer-Datei des eingesetzten Themas, also in der Datei /themes/mein-theme/elements/footer.php, folgende Angabe im Quelltextes vorhanden ist:
<?php Loader::element('footer_required'); ?>.
Wenn nicht, fügt man die Zeile ein, und zwar weit unten, direkt vor dem schließenden </body>-Tag.

Quelle: http://www.concrete5.org/[…]/cant-log-in-after-update-to-5.5/.
Danke an Andy Adiwidjaja für diesen wertvollen Hinweis!

Das CMS concrete5 wurde ja vor einigen Monaten (Dezember 2011) komplett runderneuert. Die 5.5er-Versionen unterscheiden sich nicht nur in Aussehen und Bedienung des Dashboards von den 5.4ern und einem neuen Standard-Theme mit Gewichtung auf der Blogfunktion. Nein, es wurden auch Änderungen an einigen Datenbank-Tabellen vorgenommen.

Und das kann bei manchen Webhostern bzw. in bestimmten Server­kon­fi­gu­ra­tio­nen zu Problemen beim Upgrade führen. Im schlimmsten Fall ist die Website nach dem Upgrade nicht mehr erreichbar und spuckt Fehler­meld­un­gen aus. Man kann zwar die Datenbank von Hand nachkonfigurieren, aber das ist sehr aufwändig. Und nach meinen Erfahrungen treten immer wieder neue Fehler auf. Bei kleineren Websites geht da eine komplette Neuinstallation schneller von der Hand.

Auf jeden Fall sollten kurz vor dem Upgrade Datensicherungen durchgeführt werden! Speichern Sie den Datenbank-Dump (Dashboard > Verwaltung > System & Wartung > Sicherung & Wiederherstellung) sowohl auf dem Werbserver als auch auf Ihrem PC ab. Und vorsichtshalber kopieren Sie auch alle Dateien per FTP auf Ihren lokalen PC.

Wie gesagt: Im Regelfall wird wohl alles glatt gehen. Aber wenn nicht, ist es gut, wenn man Backups zur Hand hat und erst mal schnell die Website wieder in den vorherigen Zustand zurück versetzen kann.

Die Datumsnavigation (Date Navigation) in concrete5 kann zum Beispiel die Artikelüberschriften eines Blogbereiches nach Erscheinungsdatum sortiert ausgeben. Das Problem ist nur, dass PHP die als Wort ausgeschriebenen Zeit- und Datumsangaben nur in englischer Sprache kennt. Man kann das normalerweise mit Hilfe eines Arrays, der den englischen Monatsnamen die deutschen zuordnet, zwar übersetzt ausgeben lassen, aber im Falle dieses DateNav-Blockes habe ich das nicht hinbekommen.

Und in der deutschen Übersetzungsdatei (/languages/de_DE/LC_MESSAGES/messages.po), die man bekommt, wenn man die deutsche Entwicklerversion von c5 über Github herunter lädt, sind weder Monatsnamen noch Wochentage eingepflegt.

Man kann aber selber eine Sprachdatei anfertigen. Man erstellt sich eine PHP-Datei, die einfach nur den folgenden Inhalt hat:

<?php
print t('Monday');
print t('Tuesday');
print t('Wednesday');
print t('Thursday');
print t('Friday');
print t('Saturday');
print t('Sunday');

print t('January');
print t('February');
print t('March');
print t('April');
print t('May');
print t('June');
print t('July');
print t('August');
print t('September');
print t('October');
print t('November');
print t('December');
?>

Diese Datei speichert man zum Beispiel als datumsangaben_de.php auf dem heimischen Rechner. Dann legt man mit Poedit (kostenlos für Windows®, Mac OS X® und Linux erhältlich) einen neuen Katalog an und liest die genannte Datei ein (Menü > Katalog > Aus Quelltexten aktualisieren). Die englischen Wörter kann man nun übersetzen. Anschließend speichert man die Übersetzung zum Beispiel als datumsangaben_de.po ab. Dabei wird auch automatisch eine bis auf die Dateiendung gleichnamige, aber kompilierte Datei erzeugt, also in unserem Fall datumsangaben_de.mo. Diese lädt man in das Sprachverzeichnis von concrete5 hoch, genauer gesagt in /languages/de_DE/LC_MESSAGES/datumsangaben_de.mo.

Beim nächsten Seitenaufruf, zumindest nach einem Leeren des Cache in concrete5 und im Webbrowser, werden nun die deutschen Da­tums­be­zeich­nun­gen angezeigt.

Und hier sind die fertigen Dateien (Zip, 2,2 KiB).

—
Danke für den Tipp an Tomislav Huic im concrete5-Forum.

Ich hatte kürzlich das Problem, dass eine mit dem CMS concrete5 erstellte Website sowohl ohne das www. davor als auch mit angezeigt wurde. Suchmaschinen können das als unerwünschten doppelten Inhalt werten.

Ich hatte im Dashboard die »Pretty URLs« eingeschaltet und zusätzlich in der Datei .htaccess einen permanenten Redirect eingerichtet, aber seltsamer Weise ohne Wirkung (»domain« muss im Beispiel unten natürlich durch den richtigen Domainnamen ersetzt werden):

# --- Doppelten Content vermeiden ---
RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain.de\.de$
RewriteRule ^(.*)$ http://www.domain.de/$1 [R=permanent]

Normalerweise führt das dazu, dass immer auf die Subdomain www. umgeleitet wird. Dass sie eigentlich unnützer Ballast ist, soll an dieser Stelle nicht diskutiert werden. Es hat sich so eingebürgert, und mancher Benutzer ist vermutlich befremdet, wenn es fehlt. Doch wer will, kann ja genau umgekehrt vorgehen, also von mit www. auf ohne umleiten.

Jedenfalls, wie gesagt, nützte das nichts, was ich sehr seltsam finde. (Ich hatte allerdings schon mehrmals das Problem, dass unter concrete5 bestimmte, normale Angaben in der .htaccess in bestimmten Serverumgebungen nicht funktionieren oder zu Fehlern führen.) Nach langer Suche fand ich endlich die Lösung. Eine Zeile zusätzlichen Quelltextes in der Datei /config/site.php brachte den gewünschten Erfolg:

define('BASE_URL', 'http://www.domain.de');

Der Quelltext der /config/site.php sollte übrigens kein schließendes ?> enthalten und keine Leerzeilen am Ende, weil das auch wieder in bestimmten Umgebungen zu Fehlern führen kann.