WordPress Version herausfinden leicht gemacht

WordPress Version herausfinden

WordPress Version - Montage: T.Bortels/cpu20.de

Manchmal muß man einfach schnell mal wissen, welche WordPress Version man eigentlich gerade verwendet. Gründe dafür gibt es viele – zum Beispiel um abschätzen zu können, ob  eine halbwegs aktuelle WordPress Version installiert ist und wie weit man ggf. von der aktuellen WordPress Version entfernt ist. Oder man möchte die Kompatibilität eines Plugins oder eines Themes im voraus prüfen. Oder man hat einfach nur eine technische Frage hat und will die WP-Version gleich mit der Frage angeben. Viele technische Fragen und Fehlermeldungen lassen sich einfacher nachvollziehen, wenn die verwendete Version bekannt ist. Insbesondere in Hilfe-Foren sollte man daher am besten immer auch gleich die verwendete WordPRess-Version sowie ggf. auch die Versionen der beteiligten PlugIns und Themes angeben.

WordPress Version im Administrationsbereich finden

Am einfachsten läßt sich die installierte WordPress Version herausfinden, wenn man im Administrationsbereich angemeldet ist. In früheren Versionen wird die Versionsnummer unten rechts angezeigt – in aktuelleren Installationen ist die Version im Dashboard unter „Auf einen Blick“ angezeigt – also zum Beispiel “ Version 4.9.8″.

WordPress Version mithilfe von readme.html / liesmich.html herausfinden

Es gibt aber auch Möglichkeiten, die WordPress Version herauszufinden, wenn man nicht angemeldet ist. Bei deutschen WordPress-Installationen gibt es im Stammverzeichnis die Datei „liesmich.html“ die man einfach direkt im Browser aufrufen kann: meinedomain/liesmich.html – und je nach Version kann diese Datei auch Informationen zur Version beinhalten und preisgeben.

Wordpress Version herausfinden

WordPress Version in liesmich.html

Wenn es sich nicht um eine deutsche WordPress-Installation handelt, sollte wenigstens folgende Datei im Stammverzeichnis zu finden sein, die quasi bei jeder Installation unabhängig von der Sprache mitinstalliert wird: readme.html. Auch diese Datei läßt sich direkt im Browser aufrufen: meinedomain/readme.html

Man sollte allerdings anmerken, dass manche Experten diese readme-Dateien für ein potentielles Sicherheitsrisiko halten und daher empfehlen, diese Dateien nach erfolgreicher Installation zu löschen. Angreifer könnten über diese Datei erfahren, welche WordPress Version installiert ist und geziehlt eventuell vorhandene Sicherheitslücken für Angriffe nutzen. Ich halte diese Argumentation aus zwei Gründen aber für undramatisch: Erstens sollte man grundsätzlich seine Wodpress-Installation aktuell halten und so dafür sorgen, dass eventuell vorhandene Sicherheitslücken schnellstmöglich geschlossen werden. Und zweitens gehe ich davon aus, dass die meisten WordPress-Angriffe sowieso automatisiert sind und sich kaum ein Hacker die Mühe machen wird, die readme-Datei aufzurufen.

Ein Blick in die Datei wp-includes/version.php

/**
 * The WordPress version string
 *
 * @global string $wp_version
 */
$wp_version = '3.8.4';

WordPress Version im Quellcode ablesen

Im Quellcode (HTML) lässt sich die aktuell installierte Version gleich an mehreren Stellen ablesen. In den meisten Standard-Installationen wird die WordPress Version als „Cache Breaker“ oder „Cache Buster“ z.B. an den Pfad von CSS-Dateien gehängt.

Daneben gibt es aber auch das Meta Tag „Generator“, das explizit die aktuell verwendete Version anzeigt – soweit diese Anzeige nicht durch ein Plugin unterdrückt wird. Das sieht dann zum Beispiel so aus:

<meta name="generator" content="WordPress 4.8.3" />

WordPress Version per PHP bzw. WordPress-Funktion herausfinden

WordPress bringt die Funktion get_bloginfo() mit, die viele verschiedene Details über die verwendete  WordPress-Installation verrät. Das kann vor allem für WordPress-Entwickler interessant sein – zum Beispiel, wenn man dynamisch die WordPress Version herausfinden möchte um sie entweder direkt anzeigen zu lassen, oder um beispielsweise die Kompatibilität eines Themes oder eines Plugins zu testen.

Die Funktion sieht prinzipiell wie folgt aus:

 <?php $bloginfo = get_bloginfo( $show, $filter ); ?> 

Dabei bestimmt $show was angezeigt werden soll und $filter wie es angezeigt werden soll. Für eine einfache Abfrage der WordPress Version wäre folgender Code ausreichend:

<?php 
    $wordpress_version = get_bloginfo('version'); 
    echo("Wordpress Version: ".$wordpress_version);
?> 

Wenn man diesen Code-Schnippsel beispielsweise in eine Template-Datei einfügt, zeigt WordPress die aktuell verwendete Version an.

Mehr zu der Funktion get_bloginfo(); hier im Codex:
https://codex.wordpress.org/Function_Reference/get_bloginfo

Social-Media-Buttons-Nutzen – oder nicht nutzen?!

Vor kurzem bat mich ein Kunde, doch bitte noch ‚diese kleinen Knöpfe‘ in seine Webseite einzubauen, bevor diese dann freigeschaltet werde. Ich rat ihm davon ab – er reagierte zunächst etwas verdutzt.

Ich mußte ihm meine Empfehlung, auf Social-Media-Buttons zu verzichten, natürlich erst mal etwas genauer erläutern. Das war zuerst nocht ganz einfach. Aber letztendlich ist die Frage, warum man keine Social-Media-Buttons nutzen möchte, ähnlich schwierig zu beantworten, wie die Frage nach dem Sinn und Zweck: Was bringen Social-Media-Buttons eigentlich? Und wem bringen sie was? Was sind die Vorteile – und was sind die Nachteile?

Social-Media-Buttons Nutzen

Beliebte Social-Media-Buttons mit Zähler

Zuerst muß man anerkennen, daß Social-Media-Buttons sehr populär sind. Wenn man sich im Internet umsieht, kann man den Eindruck bekommen, dass so gut wie jede Webseite wenigstens drei bis vier Schaltflächen anbietet, über die die Besucher die Inhalte ‚ganz einfach teilen‘ können: Twitter, Facebook und Google+ gehören fast schon zur Standardausstattung. Und der vermeintliche Nutzen ist ja auch verlockend: mit einem Klick kann ein Artikel direkt weiterempfohlen werden, neue Leser erreichen, Klicks generieren. Und der Preis dafür? Grundsätzlich ist die Einbindung von ‚Like-Buttons‘ erstmal kostenlos.

Social-Media-Buttons sind mir zu teuer

Aber beim Wort ‚kostenlos‘ gehen bei mir schon die Alarmglocken an – erfahrungsgemäß zahlt man immer einen gewissen Preis. Als erstes fällt mir dazu ein, dass man wenigstens einen Teil der Webseite mit den Social-Media-Buttons ‚belegt‘. Das wäre vielleicht erstmal nicht weiter schlimm, aber es handelt sich bei den Knöpfen ja in der Regel um Miniaturen des jeweiligen Firmenlogos. Egal, ob jemand den Knopf klickt oder nicht – das Firmenlogo ist in jedem Falle sichtbar. Man verschenkt also im Printip Werbefläche, ohne dass man sich darüber wirklich bewußt ist.

Man verschenkt aber nicht nur Fläche / Werbefläche – man gibt auch einen Teil der Gestaltung auf. Sicherlich lassen sich Social-Media-Buttons mehr oder weniger elegant ins Layout einer Webseite integrieren – aber letztendlich handelt es sich immer um Fremdkörper, auf deren Gestaltung man kaum Einfluß hat.

Ein dritter Punkt, der meiner Meinung nach gegen die Verwendung von Social-Media-Buttons spricht, ist die Sache mit der Ladezeit. Button-Befürworter mögen argumentieren, dass dieser Faktor zu vernachlässigen sei – man kann die Bilder ja auch direkt auf dem eigenen Server speicher oder auch gleich per CSS generieren – und auch bei ‚Share-Code‘ kann man sich auf eine Minimallösung beschränken. Man kann es drehen und wenden wie man möchte: zusätzlicher Code ist und bleibt zusätzlicher Code – und der muß geladen werden.

Als vierten und letzten Punkt möchte ich aber das ‚Image‘ anführen – vermutlich der wichtigste Punkt. Webseitenbesucher, die Social-Media nutzen, werden sich kaum an den bunten Knöpfen stören. Es gibt aber auch Webseitenbesucher, die gegenüber sogenannten Sozialen Medien kritisch eingestellt sind und die schon fast allergisch auf die entsprechenden Firmenlogos reagieren – sei es wegen Datenschutz-Bedenken oder einfach aus Prinzip.

Wenn jemand seinem Facebook-Freundeskreis eine Webseite oder einen Artikel empfehlen möchte, kann er/sie das natürlich trotzdem tun: einfach den Link kopieren. Und bei der Gelegenheit kann man vielleicht auch noch ein paar nette Worte dazu schreiben.

Mehr zum Thema:

Backup-Strategien zum Welttag des audiovisuellen Erbes

AM 27. Oktober wird der Welttag des audiovisuellen Erbes gefeiert – ein guter Tag, um sich mal Gedanken über die eigene Backup-Strategie zu machen.

Den Welttag des audiovisuellen Erbes gibt es bereits seit 1980 – wir feiern dieses Jahr also auch den 35 Jahrestag des Welttags des audiovisuellen Erbes.  Damals hat hat die UNESCO eine Empfehlung zum Schutz und zur Erhaltung bewegter Bilder verabschiedet. In Deutschland beteiligen sich zahlreiche Museen, Filmarchive und Stiftungen am UNESCO-Welttag. Es geht darum, das audiovisuelle Kulturerbe stärker in das öffentliche Bewusstsein zu bringen und auf die Notwendigkeit hinweisen, dieses entsprechend zu schützen, zu konservieren.

Viele Museen und Archive digitalisieren mittlerweile ihre Bestände – und inzwischen liegen viele audiovisuelle Kulturgüter digital vor. Aktuelle Filmproduktionen werden zu Teil komplett digital umgesetzt und man man spricht in diesem Zusammenhang dann eher von Backups.

Natürlich reicht es nicht, einen ehemals analog vorliegenden Film beispielsweise einmal zu digitalisieren und dann auf einem vermeintlich sicheren Datenträger zu speichern. Wer sich einmal ernsthaft mit einer Backup-Strategie beschäftigt hat weiss, die Konservierung bzw. Archivierung von digitalen Medien ist ein weites Feld. manchmal wir die Bedeutung einer funktionierenden Backup-Strategie allerdings erst dann verstanden, wenn es bereits zu spät ist.

Ein Datenverlust kann eine schmerzliche Erfahrung sein. Wenn ein Datenträger verloren geht ist häufig viel Arbeit einfach ‚weg‘. Diplomarbeiten, Filme, Interviews, Artikel, Manuskripte – als hätte es sie nie gegeben.

Bei einem einfachen Festplatten-Crash besteht immerhin die Hoffnung, dass es einen Experten gibt, der die verlorenen Daten wieder herstellen kann. Sollte ein Datenträger aber durch Diebstahl, Feuer oder ähnliche Ereignisse verloren gehen, ist am Ende alles einfach weg – es sei denn, man hat vorgesorgt.

Das Thema ‚Backup‘ ist natürlich auch für jeden Webdesigner und jeden Web-Entwickler wichtig – auch wenn häufig die wirklich wichtigen Dateien immerhin wenigstens auf einem Server als Kopie vorliegen (es sei denn, man arbeitet direkt auf dem Server). In will im folgenden kurz meine persönlichen Backup-Strategien darstellen und hoffe, damit den einen oder anderen dazu zu bewegen, eine eigene Backup-Strategie zu entwickeln – und umzusetzen.

USB-Stick

USB-Sticks gelten bei uns als rein temporäre Datenträger. Am besten man speichert gerade immer nur die Daten, die man gerade aktuell von A nach B transportieren möchte. Zu groß ist das Risiko, einen USB-Stick zu verlieren – zu grpß das Risiko, dass Unbefugte Zugriff auf die auf dem USB-Stick gespeicherten Daten bekommen.

Backups über ‚Time-Machine‘

Die Backup-Lösung Time Machine eignet sich vor allem, um einen bestimmten Computer schnell und unkompliziert wiederherstellen zu können. Um über Time-Machine einen Computer wiederherstellen zu können, verwendet man am besten eine dafür reservierte Festplatte. Diese sollte von der Kapazität her um einiges größer sein, als die Festplatte des zu ’schützenden‘ Computers. Man sollte sich aber darüber im klaren sein, dass die Verwendung von Time-Machine zwar eine gute Idee sein mag, aber keine wirklich wirksame Backup-Stategie darstellt. bei einem Einbruch besteht beispielsweise die Gefahr, dass ’natürlich‘ nicht nur alle Computer, sondern auch alle lokal vorhandenen Backup-Platten geklaut werden.

Lokale Backups: Computer, Festplatte, Arbeitsverzeichnissen

Bei uns gibt es eine verhältnismäßig große Backup-Platte, die ausschließlich dafür da ist, die Daten aller anderen Festplatten speichern zu können. Wir arbeiten zwar auf Mac OS – verzeichten aber bei dieser Festplatte bewußt auf die Verwendung von ‚Time-Machine‘. Stattdessen verwenden wir zurzeit (immernoch) Carbon Copy Cloner, bei dem sich einzelne Verzeichnisse auswählen lassen, die von Zeit zu Zeit gesichert werden sollen. Damit hat man eine relativ schnelle und kostengünstige Lösung, mit der sich beispielsweise gezielt Arbeitsverzeichnisse sichern lassen.

Diese Backup-Platte wird dann in größeren Abständen selbst gesichert. Alternativ kann man die beiden Backup-Platten auch einfach austauschen. Dafür haben wir eine zweite Backup-Festplatte, mit derselben Kapazität. Diese zweite Festplatte sollte unbedingt physisch an einem anderen Ort gelagert werden – nur so läßt sich Risiken wie Diebstahl, Feuer und Überschwemmung effektiv begegnen.

Backup von Webseiten und Web-Datenbanken (mySQL)

Grundsätzlich sollte man sich bei der Wahl des Webhosting-Anbieters auch nach deren Backup-Strategie erkundigen. Viele Anbieter haben inzwischen sogn. redundante Systeme installiert, bei dem die Webseiten und Datenbanken von vorneherein auf zwei Festplatten gespeichert sind. Fällt eine Festplatte aus, wird automatisch auf die andere Festplatte umgeschaltet.

Redundante Systeme sind eine gute Idee, aber noch keine Backup-Strategie. Je größer und Umfangreicher eine Webseite wird, desto wichtiger wird es, eine funktionierende Backup-Strategie einzusetzen. Bei Totalverlust haften Webhosting-Anbieter meistens nur für den materiellen Schaden. Da man den Webspace in der Regel nur mietet, beläuft sich der erstattete materielle Schaden in den meisten Fällen aber auf 0,- Euro.

Man sollte also von Zeit zu Zeit wenigstens händisch alle Dateien sowie einen Datenbank-Dump vom Server herunterladen und lokal sichern. Das mag zunächst ein wenig umständlich erscheinen, ist aber als Minimal-Lösung sehr effektiv. Für größere Webseiten dürfte diese Strategie allerdings auf Dauer unpraktikabel sein.

Automatisierte Backups für WordPress, Drupal, mySQL

Für Content Management Systeme gibt es inzwischen ein Fülle von nativen Backup-Lösungen und es würde einfach den Rahmen sprengen, in diesem Artikel die vielen verschiedenen Plugins und Add-Ons für WordPress und Drupal miteinander zu vergleichen. Stattdessen seien hier nur zwei Backup-Lösungen genannt, die ich selbst hin und wieder verwende – aber am Ende muß jeder für sich selber herausfinden, ob er mit diesen Tool umgehen möchte / umgehen kann:

  • Drupal: Backup and Migrate
    Das Drupal-Modul Backup and Migrate eignet sich wie der Name schon suggeriert zum Sichern und/oder Umziehen von kompletten, komplexen Webseiten, die mit Drupal erstelt wurden. Vom spontanen jetzt-und-hier-und-alles-Backup bis hin zu ausgeklügelten Backup-Zeitplänen von dezentral gespeicherten automatisierten Backups ist so gut wie alles möglich.
  • WordPress: WP-DM-Backup
    Das WordPress-Plugin WP-DM-Backup bzw. „WordPress Database Backup“ ist eine eher relativ rudimentäre Backup-Lösung für WordPress. Man kann das Plugin wie eine komfortable WordPress-Schnittstelle für phpmyAdmin verstehen: es lassen sich alle manuell sichern oder auch automatisch beispielsweise einmal monatlich per Email verschicken. Ich nutze bei kleineren Seiten die Automatik und nehme die Backup-Mail dann zum Anlass, Dateien direkt per FTP zu sichern. Immerhin.

Grundsätzlich gilt: ein Backup-Plugin ist immer nur so gut, wie das Backup, das es am Ende erstellt. Eine einfache Standard-Lösung kann einen in falscher Sicherheit wiegen, wenn man in Wirklichkeit eine hochkomplexe und individuell angepasse Webseite mithilfe von WordPress oder Drupal vorliegen hat. Oder konkret ausgedrückt: Was bringt einem ein schnelles und unkompliziertes Backup-Tool, wenn es die individuell angelegten Content Typen, Eingabefelder und Nutzerprofile nicht sichert?

Die einzige wirklich verläßliche Backup-Lösung für Webseiten, die mithilfe eines Content Management Systems erstellt wurden, erscheint mir daher nach wie vor die direkte Sicherung der eigentlichen Datenbank in Verbindung mit der direkte Sicherung der eigentlichen Dateien. Das ist natürlich etwas mühsam – aber immernoch einfacher, als nachträglich alles per Hand neu anzulegen.

Spontane Webseiten-Backup-Lösung für zwischendurch

Zu guter letzt noch eine Backup-Lösung, die eigentlich gar keine ist. Dazu zunöchst die passende Geschichte: Ein Kunde rief mich vor einer Weile spät abneds an, wegen eines Missverständnisses mit seinem bisherigen Hosting-Anbieter sei seine Domain nun gekündigt und bereits in der Lösch-Phase. Es sei damit zu rechnen, dass die Domain, der Webspace und alle Daten in den kommen 1-2 Stunden gelöscht werden würden. Ich war zu dem Zeitpunkt nicht im Büro – hatte aber meinen Rechner sowie einen mobilen Internetzugang dabei.

Ich hatte weder FTP-Zugang zu der Webseite, noch irgendwelche Datenbank-Passwörter – geschweige denn einen Login zum CMS. Stattdessen habe dann den kleinen Helfer SiteSucker gestartet und innerhalb weniger Minuten alle öffentlich zugänglichen Seiten heruntergeladen.

Der Webspace war kurze Zeit später wirklich komplett gelöscht. Die Domain konnten wir zum Glück schon am nächsten Tag reaktivieren und anschliessend das statische Backup einspielen. Das Webseite sollte sowieso rundum erneuert, das CMS dewechselt werden. Die Inhalte mußten daher sowieso mehr oder weniger komplett neu angelegt werden. Nach außen, also für die Webseiten-Besucher war die Internetseite aber immerhin nur für ein paar Stunden nicht erreichbar.

Siehe auch:

  • Alles weg“ – Artikel in der Berliner Zeitung zum Total-Verlust der SPEX-Homepage 2001

Dedicated Hosting: gute Gründe für einen Managed Server

Dedicated Hosting / Managed Server – Webserver im Rechenzentrum bei All-Inkl

Webserver im Rechenzentrum bei All-Inkl – Foto / Copyright: ALL-INKL.COM

Es ist ja kein Geheimnis: ich mag Dedicated Hosting – und daher haben wir einen sogn. Managed Server. Natürlich steht der Server nicht direkt hier bei uns in Berlin – unsere ‚Kiste‘ steht bei All-Inkl in Friedersdorf, Sachsen. Also – Serverstandort Deutschland.

Wir sind seit vielen Jahren Kunde bei All-Inkl und wir sind sehr froh darüber. Kein Stress, ein meiner Meinung nach hervorragendes Preis-Leistungs-Verhältnis, und vor allem: kein Stress.

Warum Dedicated Hosting? Webdesign ist ein bisschen wie Kochen

Ich bin zwar kein besonders guter Koch, bzw. zumindest kein rutinierter, aber der Vergleich sei trotzdem erlaubt: Webdesign ist ein bisschen wie Kochen. Die Qualität einer guten Mahlzeit setzt sich aus vielen verschiedenen Faktoren zusammen: gute Zutaten, gutes Werkzeug, ein Team, das mit den Zutaten und dem Werkzeug umgehen kann – und eine Umgebung, in der das Team gut und gerne arbeitet, weil sie auf die eine oder andere Art die Arbeit erleichtert.

Beim Kochen ist diese Umgebung die Küche, das Restaurant, der Herd – die Infrastruktur des Kochens. Bei Webdesign besteht diese Umgebung bzw. die Infrastruktur meistens aus  einem Schreibtisch, einem Computer, verschiedenen Programmen – und einem Webserver.

Natürlich kann wohl jeder Koch auch in einer fremden Küche arbeiten – und natürlich kann ein Webdesigner / Web-Entwickler auch auf fremden Servern arbeiten, soweit die gegebenen Bedingungen dies eben zulassen. Aber wie schon das alte Sprichwort sagt: Eigener Herd ist Goldes wert. Man muss nicht rätseln und nicht suchen – man weiss einfach, wo alles ist, und wie es funktioniert. Man kann einfach machen.

Warum ein eigener Weberver? Vorteile von Dedicated Hosting

Für unsere Kunden bieten wir im Prinzip das ‚komplette Paket‘ an. In erster Linie erstellen wir natürlich Webseiten – also das Webdesign (Frontend) und ein passendes Content Management System (Backend). Daneben hat sich aber bewährt, dass wir für viele Kunden auch gerne ‚die Details‘ klären – das bedeutet, dass wir von der Domain-Bestellung über die Webserver- bzw. Webspace-Einrichtung bis hin zum Einrichten von Email-Konten und Statistik-Tools alles anbieten, was man so braucht, um eine Webseite betreiben zu können. Wer bei uns ein „Pflege- und Support-Paket“ bucht, muss sich nicht um die wohlmöglich ‚lästige‘ Technik kümmern und kann sich stattdessen voll und ganz auf seine Inhalte konzentrieren.

Im Prinzip sind wir also selbst Hosting Anbieter, wobei unser ‚Kerngeschäft‘ aber natürlich die Gestaltung und Erstellung von Webseiten ist. Als Designer verstehen uns aber auch als ‚Problem-Löser‚ – also als Dienstleister, die sich eben um ‚alles‘ kümmeren – soweit das eben gewünscht ist.

Für uns bringt es viele Vorteile mit sich, dass wir auf unserem eigenen Webserver arbeiten. Um es kurz zu fassen: wir kennen unseren Server – und unser Server kennt uns.

Beim Shared Hosting bzw. einem Shared Server teilt man sich den Server mit x unbekannten Nachbarn – oder sogar ‚Mitbewohnern‘ – also vielen unbekannten Webseiten, unbekannten Skripten. Wenn ein Nachbar ein anspruchsvolles Skript installiert, kann es bei einem Shared Server durchaus mal passieren, dass der gesamte Webserver in die Knie geht. Allerdings vermute ich mal, dass das bei All-Inkl so gut wie nie vorkommt – schon beim günstigen Hosting-Tarif „All-Inkl Privat“ teilt man sich einen Server mit maximal 100 Kunden.

Bei einem Dedicated Hosting bzw. einem Managed Server hat man hingegen Freiheiten, die in der Wohngemeinschaft eines Shared Servers einfach nicht möglich wären. Rechenpower, Speicherplatz und Bandbreite werden bei uns quasi je nach Bedarf vergeben – und wenn mal ein Spezial-Skript oder eine bestimmte PHP-Version benötigt wird, dann wird eben ein Spezial-Skript oder eine bestimmte PHP-Version installiert.

Brauche ich einen Managed Server?

Natürlich braucht nicht jeder Webseite bzw. jeder Webseiten-Betreiber gleich einen eigenen Managed Server – für die meisten Webseiten wäre das sicherlich zu viel des Guten. Und so ein Managed Server ist auch ein nicht ganz so billiges Vergnügen. Übers Jahr gerechnet kommt für die Server- und Servicegebühren ein durchaus beeindruckender vierstelliger Betrag zusammen.

Für uns hat sich aber nie die Frage gestellt, ob wir uns das leisten können – die Vorteile überwiegen ganz einfach: Unsere Kunden-Webseiten laufen auf einem zugegebener Maßen etwas überproportionierten Server, der mehr als genug Rechenpower, Speicherplatz und Bandbreite zur Verfügung stellt. Wir sind glücklich und zufrieden – und unsere Kunden sind es (hoffentlich/vermutlich) auch.

Ich kann Dedicated Hosting – und insbesondere All-Ink daher nur empfehlen! Der Support ist großartig, freundlich und zuvorkommend, und der Server läuft einfach rund. Es kommt so gut wie nie zu technischen Problemen – und wenn dann doch mal was langsam läuft, liegt es eigentlich immer an einem problematischen Skript und der Fehler ist schnell gefunden und behoben.

Ja, dieser Beitrag sollte sich eigentlich ums Hosting und die Vorteile eines Managed Servers drehen – ist nun aber ein bisschen zum Lobgesang auf All-Inkl geworden. Kein Wunder: für uns ist beides direkt miteinander verbunden. Daher erlaube ich mir  an dieser Stelle auch ausnahmsweise mal, einen Affiliate-Link zu All-Inkl zu setzen: http://all-inkl.com/?partner=507552. Wenn Sie über diesen Link bei All–Inkl ein Hosting-Paket beauftragen, wird mir eine gewisse Provision gutgeschrieben. Ach ja: natürlich laufen nicht nur unsere Rechner hier in Berlin, sondern auch die Webserver bei All-Inkl dank Ökostrom CO2-neutral.

PHP: Multidimensionalen Array beliebig umsortieren (array_multisort)

Um das Thema habe ich mich erfolgreich längere Zeit herumgedrückt – aber jetzt wollte ich es dann doch mal ganz genau wissen: Wie kann ich einen multidimentionalen Array beliebig umsortieren?

Häufig habe ich mit multidimentionalen Arrays zu tun – aber in den meisten Fällen reicht es, wenn ich schon bei der eigentlichen mySQL-Abfrage vorgebe, wie bzw. wonach der Array sortiert sein soll. Inzwischen sind ‚hier‘ aber auch ein paar komplexere geschichten am laufen, und ich will die mySQL-Abfrage nicht für jede abweichende Abfrage anpassen. Stattdessen will ich ‚lediglich‘ den Ergebnis-Array entsprechend bestimmter Vorgaben umsortieren.

Ein Beispiel: meine mySQL-Abfrage liefert mir folgendes Ergebnis:

Array
(
    [0] => Array
        (
            [id] => 369
            [name] => Peter
            [year] => 1969 
        )

    [1] => Array
        (
            [id] => 368
            [name] => Paul
            [year] => 1975
        )

    [2] => Array
        (
            [id] => 367
            [name] => Mary
            [year] => 1977
        )

)

Nun möchte ich den Array zum Beispiel nicht nach der ID, sondern alphabetisch nach dem Namen sortieren. Dafür kann man den Array folgendermaßen auseinandernehmen und dann mithilfe der PHP-Funktion array_multisort geziehlt umsortieren:

$sortArray = array();

        foreach($entryArray as $entry){
            foreach($entry as $key=>$value){
                if(!isset($sortArray[$key])){
                    $sortArray[$key] = array();
                }
                $sortArray[$key][] = $value;
            }
        } 
    $orderby = "name";
    array_multisort($sortArray[$orderby],SORT_ASC,$entryArray); 
    
return $entryArray;

in diesem Fall ist $entryArray mein ursprünglicher Array, der das Ergebnis der mySQL-Abfrage beinhaltet. Das sieht vielleicht erst mal etwas kryptisch aus, funktioniert letztendlich aber erstaunlich problemlos. Nach dem Umsortieren bekomme ich also folgenden Array:

Array
(
    [0] => Array
        (
            [id] => 367
            [name] => Mary
            [year] => 1977 
        )

    [1] => Array
        (
            [id] => 368
            [name] => Paul
            [year] => 1975
        )

    [2] => Array
        (
            [id] => 369
            [name] => Peter
            [year] => 1969
        )

)

Sehr praktisch.

Siehe auch:

  • PHP-Handbuch > Funktionsreferenz > … > Array Funktionen > array_multisort

Umlaut-Punkte Ä zu nah am Buchstaben (Mac-Firefox)

Das Problem tritt zunächst nur in Firefox (40 und 41) auf Mac OS auf: die Umlaut-Punkte des großen Ä sind zu nah am Buchstaben – die Punkte haben keine ‚Luft‘, keinen Abstand zum „A“, der Letter sieht ‚matschig‘ aus. In Chrome und Safari tritt das Problem nicht auf – die Umlaut-Punkte haben genug Abstand zum eigentlichen Buchstaben.

A-Umlaut-Punkte zu nah am A

Ich verwende die Webfont „MuseoSans“ – aber auch bei Verwendung der Webfont „Equip-Light“ tritt dasselbe Problem auf. Bei Verwendung von „Helvetica“ sieht hingegen alles normal aus.

Das Problem ist auch nicht wirklich bei den Umlauten Ö und Ü zu beobachten – das liegt aber ggf. nur an der ‚Architektur‘ der Lettern. Ausserdem tritt das Problem nur dann auf, wenn der Letter per CSS text-transform: uppercase; quasi künstlich zum Großbuchstaben gemacht wird. Bei natürlichen Großbuchstaben tritt das Problem nicht auf – der Buchstabe wird korrekt gerendert.

Meine Vermutung zur Ursache des Problems:

die Webfont und/oder Firefox sind nicht sauber programmiert (bzw. gebaut).

Vorübergehender Lösung des Problems:

Überschriften und Zwischenüberschriften, die eigentlich per CSS text-transform: uppercase; formatiert sein sollten, werden nun im CMS direkt in Großbuchstaben eingegeben. Im Code und im kopf ist das nicht wirklich die schönste Lösung,  aber auf der Webseite sieht es nun richtig aus.

Update:

Das Problem scheint (mal wieder) mit einem falsch formatierten PDF-Dokument zusammenzuhängen. Wenn man die Umlaute ‚einfach‘ neu schreibt, also die korrupten Umlaute ‚über-bügelt‘, ist das Problem behoben. Alternativ kann man den text über Text-Edit kopieren – allerdings scheint das nicht immer das Problem zu beheben.

Anmerkung: Dies ist eigentlich nur eine Notiz um das Problem und den dazu passenden Lösungsansatz festzuhalten. Im Laufe der Zeit werde ich diesen Beitrag dann hoffentlich auch wieder mit weiteren Lösungsansätzen vervollständigen können, so dass das ganze dann in Zukunft auch anderen bei der Problemlösung hilft.