Archiv der Kategorie: Webentwicklung

Die Syntax im WordPress-Title-Tag optimieren

Meta-Angaben, Seitentitel usw. für ein WordPress-Blog befinden sich ja im Head-Bereich der Theme-Datei header.php. Im Standardfall werden mittels WordPress-Funktionen der Blogname und der jeweilige Seitentitel im Browser ausgeben, was im Quelltext so aussieht:
<title><?php bloginfo('name'); ?> <?php wp_title(); ?></title>.

Wenn man jedoch nur den Titel, nicht aber den Blognamen ausgeben möchte und in den Quelltext
<title><?php wp_title(); ?></title>
schreibt, hat man immer im ausgegebenen Titel ganz links ein Leerzeichen. Vielleicht nicht tragisch, aber auch nicht wirklich sauber.

Gefunden habe ich eine Lösung im Blog des Webentwicklers Oliver Baty aus Chicago. Nein, eigentlich präsentiert er gleich mehrere Lösungen in einem einzigen Blogartikel, aber eine hat mir besonders zugesagt. Man muss nur wenige Zeilen Code in die functions.php im Theme-Ordner einfügen, um die Leerzeichen loszuwerden:

// Leerzeichen im Titel entfernen
function af_titledespacer($title) {
    return trim($title);
}
add_filter('wp_title', 'af_titledespacer');

Quelle: ardamis.com/[…]/optimizing-the-syntax-in-the-wordpress-title-tag/

Sechs tödliche Website-Sünden

Auf CMS Critic kann man die sechs schlimmsten Sünden nachlesen, die man begehen kann, wenn man eine Website betreibt und – eigentlich – damit Erfolg haben will. Ich möchte hier weder den ganzen Beitrag vom Englischen ins Deutsche übersetzen und schon gar nicht dem Autor, Daniel Threlfall, den Inhalt klauen, aber aufzählen möchte ich die sechs Sünden dennoch:

  1. Du hast keine sozialen Medien.
  2. Du hast kein responsives Design.
  3. Dein CMS ist veraltet, fehlerhaft oder umständlich.
  4. Deine Website braucht lange zum Laden.
  5. Die Suchmaschinenoptimierung kümmert dich nicht.
  6. Du hast keine rechte Lust, Inhalte zu schreiben.

Zweifelsohne gibt es noch mehr Sünden, die man begehen kann, aber dies sind ganz sicher die tödlichsten. Denn sie führen dazu, dass die Website entweder gar nicht erst gefunden wird oder dass sich die Besucher nicht wohl fühlen und gleich wieder weg sind. Kunden gewinnen kann man auf diese Weise natürlich nicht. Daniel empfiehlt daher, diese Probleme schnellstmöglich aus der Welt zu schaffen.

Und wenn ich so durchs Web surfe, dann stelle ich fest, dass es wirklich viel zu tun gäbe.

Nibbleblog statt FlatPress

Ein Kommentator, der meinen älteren Artikel über das datenbanklose Blogsystem FlatPress gelesen hatte, schrieb, dass FlatPress unter PHP 5.5 nicht läuft. Darüber hinaus gibt es seit Januar 2012 keine Updates mehr, und auch früher schon wurde das System nur sehr zögerlich weiterentwickelt.

Wenn man also über keine MySQL-Datenbank verfügt oder aus anderen Gründen nicht WordPress, Serendipity oder ein anderes der »großen« Blogsysteme verwenden möchte, sollte man statt ausgerechnet FlatPress vielleicht etwas anderes wählen. Ich bin heute auf Nibbleblog gestoßen. Ich habe Nibbleblog (v3.6.1 “Echo”) noch nicht ausgiebig getestet, aber ein bisschen was kann ich schon dazu sagen:

Die Installation ging sehr schnell und einfach vonstatten, den Administratornamen und das Passwort kann man frei wählen. Leider wird die Passwortstärke nicht bewertet. Das Backend macht einen sehr aufgeräumten Eindruck, man findet sich sofort zurecht. Das Bloggen wird einem einfach gemacht, es sind folgende Beitragsarten auswählbar: Einfacher Post, Videopost, Zitat. Drei einfache Designthemen sind enthalten, individuelle sollten sich recht leicht selbst erstellen lassen. Denn es handelt sich bei den Themen um normale PHP-Dateien, die allerdings die Dateiendung .bit tragen, und natürlich CSS-Dateien. Ich habe die meisten der üblichen Blogfunktionen in Nibbleblog vorgefunden, auch eine Spamabwehr (für die man sich einen API-Schlüssel besorgen muss) und einen Atom-Feed. Vermisst habe ich allerdings eine Möglicheit zur zeitgesteuerten Veröffentlichung.

Insgesamt macht Nibbleblog auf mich einen sehr guten Eindruck. Wer schnell ein datenbankloses Weblog auf die Beine stellen möchte, kommt hier quasi im Handumdrehen zum Ziel. Und wer sich mit HTML, PHP und CSS auskennt, kann recht einfach ein eigenes Design erstellen. Selbstverständlich gibt es nicht die Fülle an Erweiterungen und Designvorlagen wie bei bekannteren Systemen.

www.nibbleblog.com

Angriffe auf Joomla!-Systeme

Einer meiner Webhoster teilte vor wenigen Tagen per Newsletter mit, dass es in den letzten Monaten vermehrt zu Angriffen auf Joomla!-Systeme gekommen ist. Betroffen sind anscheinend vor allem Installationen, die vor Dezember 2012 gemacht wurden und den JCE (Joomla Content Editor) verwenden. Genaueres dazu ist unter folgenden Links nachzulesen:
www.joomla.de/[…]/171-sicherheitslücke-im-jce-editor.html
www.joomlacontenteditor.net/news/item/jce-231-released

Wie schon auf WordPress-Systeme kommt es nun auch vermehrt zu Brute-Force Angriffen auf die Joomla!-Administrator-Seite. Die sicherste Abwehr dürfte auch hier neben einem guten Passwort (sinnlose Zeichenkette aus mindestens zehn Zeichen, bestehend aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen) ein zusätzlicher Passwortschutz per .htaccess-/.htpasswd sein.

Angriffe auf WordPress-Blogs minimieren

Seit etwa Februar 2013 finden im diesmal extrem großen Stil Angriffe per Botnetz auf WordPress-Blogs statt. Darüber ist viel geschrieben worden, aber ein paar eigene Erkenntnisse möchte ich noch beisteuern.

IP-Adressen der Angreifer per .htaccess-Datei (im Falle eines Apache-HTTP-Servers) zu sperren hat keinen Sinn, es wurden schon über 90.000 verschiedene mit weltweiter Herkunft gezählt. Oft wird das Plugin »Limit Login Attempts« empfohlen. Diese Erweiterung verhindert Brute-Force-Attacken. Sie ist leicht zu konfigurieren und gehört für mich inzwischen als Muss zu jeder WordPress-Installation.

An vielen anderen Schwachstellen setzt »Better WP Security« an. Was mir besonders gut gefällt, ist eine Verschleierung des Login-Bereiches: über die gewohnten Dateinamen ist das Login nach entsprechender Einstellung nicht mehr erreichbar. Ferner kann man zum Beispiel die Anmelde-Möglichkeit auf bestimmte Tageszeiten begrenzen, das Tabellenpräfix ändern, die Benutzer-ID »1« (= standardmäßige ID des Administrator-Accounts) in eine andere Zahl umschreiben, die wichtigsten Dateien und Verzeichnisse per .htaccess-Einträge gegen Zugriff abriegeln und so weiter. Die Optionen sind wirklich beachtlich, aber man sollte auf jeden Fall vor irgendwelchen Änderungen ein Datenbank-Backup machen. Außerdem kann man sich im schlimmsten Fall selbst vom Blog aussperren. Man muss dann die .htaccess-Datei bearbeiten. Also bitte ein wenig Vorsicht walten lassen!

Es wird von den Angreifern übrigens nicht nur der Benutzername »admin« verwendet, wie man in manchen Blogartikeln lesen kann, sondern auch »Admin«, »administrator«, »Administrator«, »adminadmin« und womöglich noch weitere Variationen. Das Wichtigste ist also, keinen Benutzernamen zu verwenden, in welchem »admin« in irgendeiner Form vorkommt.

Um aber Angreifer gar nicht bis zum Anmeldebereich kommen zu lassen, habe ich mich entschieden, die Datei wp-login.php in Hauptverzeichnis des Blogs nur für meine eigene IP-Adresse freizugeben – genauer gesagt: für den IP-Bereich meines Internet-Service-Providers. Dazu sind nur ein paar Zeilen in die .htacess-Datei einzutragen:

# Adminbereich absichern
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from xx.xxx.
</Files>

Anstelle von »xx.xxx.« trägt man natürlich die ersten zwei Bytes des IP-Bereiches seines Providers ein. Hier kann man seine IP-Adresse ermitteln:
www.torstenkelsch.de/deine-ip.php

Weitere Informationen:
t3n.de/news/massive-angriffswelle-[…]
www.heise.de/security/meldung/Botnet-attackiert-Wordpress-[…]
www.golem.de/news/security-angriff-gegen-admin-konten-[…]

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