Permalink

“Obligatorische” WordPress-PlugIns

Gleich vorweg: Nein, das ist keine Liste von WordPress PlugIns die ich für zwingend notwendig halte :-)

In diesem Artikel möchte ich ein kleines WordPress-Feature vorstellen das so gut wie unbekannt ist. Nehmen wir mal folgendes (relativ übliches) Szenario: man entwickelt für einen Kunden eine Seite auf WordPress-Basis und möchte bestimmte Tweaks einbauen (z.B. um die überflüssigen Sprachen aus der Rechtschreibprüfung zu entfernen, den Admin-Bar zu verstecken, usw.). Man kann diese Funktionen natürlich alle in die functions.php des Themes packen (wo sie meiner Meinung nach nicht unbedingt hingehören) oder man erstellt sich ein entsprechendes PlugIn. Problematisch wird das in dem Augenblick, wo der Kunde Administrator-Zugang hat. Schnell ist da mal ein PlugIn deaktiviert. Da hilft auch ein beherztes "FINGER WEG!" als PlugIn-Beschreibung nicht.

Aber wie das bei WordPress oft so ist, gibt es für diesen Fall eine eingebaute Lösung. Diese nennt sich "obligatorische" PlugIns (oder im englischen: "Must-Use") und werden hier im WordPress-Codex genauer beschrieben. Legt man im wp-content-Ordner ein Verzeichnis mu-plugins an und kopiert sein PlugIn dort hinein, erscheint in der PlugIn-Übersicht ein neuer Auswahlpunkt "Obligatorisch" unter dem man zukünftig sein PlugIn wiederfindet.

PlugIns in diesem Verzeichnis verhalten sich allerdings ein wenig anders als von normalen PlugIns gewohnt und unterliegen bestimmten Beschränkungen / Regeln:

  • PlugIns in Unterordnern werden nicht geladen
  • alle PlugIns in diesem Verzeichnis sind automatisch aktiviert und können nicht deaktiviert oder gelöscht werden
  • über den eingebauten Editor können keine Veränderungen an den Dateien vorgenommen werden
  • es werden keine (automatischen) Updates eingespielt

Muss man also ein solches PlugIn aus irgendeinem Grund aktualisieren oder löschen, geht das nur über einen direkten Zugriff auf Verzeichnisebene (FTP, Shell, etc.) – meiner persönlichen Meinung nach sollte man sich dort also auf gut getesteten Code beschränken. Nützlich ist dieses Feature aber auf jeden Fall (finde ich zumindest).

Permalink

“WP HTTP Error: Zu viele Weiterleitungen” im WordPress Dashboard

WordPress bindet normalerweise zwei RSS-Feeds im Dashboard ein, wenn man zur Installation die Version von WPDE benutzt. Das wäre einmal der Feed “WordPress-Blog” und einmal “Weitere WordPress-News”.

Bei beiden Feeds habe ich teilweise das Problem, dass sie (je nach installierter Version und Server) mal funktionieren und mal nicht. Funktionieren sie nicht, äussert sich das durch die Fehlermeldung “RSS Fehler: WP HTTP Error: Zu viele Weiterleitungen”. Die Ursache dafür ist relativ leicht nachzuvollziehen. Klickt man bei den Widgets auf “Konfigurieren” sieht man die URL, von der aus der RSS-Feed eingebunden wird. Und genau hier kommt der “Trick”: ruft man nun die jeweiligen URLs im Browser auf stellt man fest, dass man weitergeleitet wird und die Feeds letztlich von einer komplett anderen URL geladen werden.

Im Moment sieht das fann z.B. so aus, dass die URL des “Weitere WordPress-News”-Feeds mit http://channel.wordpress-deutschland.org/rss-dashboard.php angegeben ist und letztlich zu http://planet.wordpress-deutschland.org/de/small-feed umleitet. Trägt man dann entsprechend diese URL im Widget ein, verschwindet auch der HTTP-Fehler.

Ähnlich ist es bei dem “WordPress-Blog” Feed. Dafür habe ich z.B. schon die URLs http://blog.wordpress-deutschland.org/feed/ und http://blog.wpde.org/feed/ gesehen. Richtig scheint im Moment allerdings http://blog.wpde.org/feed (ohne abschliessenden Slash) zu sein.

Ihr merkt schon: ich benutze in diesem Artikel öfters “im Moment”. Ich weiss leider nicht, ob sich die URLs nicht in Zukunft noch öfters ändern – worauf die Konstruktion mit den Redirects schliessen lässt. Auf jeden Fall könnt ihr die Fehlermeldungen so prinzipiell umgehen.

Wer z.B. bei Installationen für Kunden sicherstellen will, dass diese Fehlermeldung nie auftaucht sollte am Besten einfach ein kleines Proxy-Script basteln, welches man entweder auf dem Kundenserver selber oder bei sich auf einer Domain ablegt und das dann den RSS-Feed selber runterlädt. So verhindert man, dass WordPress irgendwelche HTTP-Umleitungen zu “sehen” bekommt und entsprechend kann der Fehler auch nicht mehr auftauchen. Man würde also in der Konfiguration dann dieses Script angeben und nicht mehr die Original-URLs.

Permalink

MySQL und Währungsbeträge – FLOAT vs. DECIMAL

Bei einem Projekt an dem ich gearbeitet habe, wurden Euro-Beträge in einer Datenbank gespeichert und mit diesen dann Berechnungen durchgeführt. Normalerweise würde man denken “So schwer kann das ja nicht sein” aber dummerweise gibt es da einen kleinen Fallstrick den vielleicht noch nicht jeder kennt.

Denkt man darüber nach Beträge mit Nachkommastellen in einer Datenbank zu speichern stolpert man schnell über die üblichen Datentypen wie FLOAT, DOUBLE oder DECIMAL. Und wenn man unbedarft an die Sache herangeht, sieht das auch erst mal vollkommen problemlos aus. Nehmen wir mal die folgende kleine Test-Datenbank:

CREATE TABLE `test` (
`test_float` float(10,2) NOT NULL,
`test_decimal` decimal(10,2) NOT NULL
);

In diese fügen wir dann zwei identische Werte ein:

INSERT INTO `test` (`test_float`, `test_decimal`) VALUES (5.43, 5.43);

Schaut man sich die Datenbank nun z.B. in phpMyAdmin an, sieht alles genau so aus, wie man es erwartet. In beiden Feldern scheint der Wert “5,43” zu stehen. Ihr merkt schon: das entscheidende Wort ist hier “scheint”.

Quizfrage: welches Ergebnis erwartet ihr nach Ausführung von

SELECT (test_float * 1.0000000) AS f, (test_decimal * 1.0000000) AS d FROM test

(das 1.0000000 führt dazu, dass MySQL mehr Nachkommastellen anzeigt) ? Wer mit f = 5.4299998 und d = 5.430000000 geantwortet hat liegt richtig.

Eigentlich erklärt schon das MySQL-Handbuch warum das passiert:

Die Datentypen FLOAT und DOUBLE werden zur Darstellung annähernder numerischer Datenwerte verwendet. Für FLOAT gestattet der SQL-Standard optional die Angabe der Genauigkeit (nicht aber des Bereichs des Exponenten) in Bits, die dem Schlüsselwort FLOAT in Klammern folgen.

und

Die Datentypen DECIMAL und NUMERIC werden zur Speicherung exakter numerischer Datenwerte verwendet.

FLOATs sind also keine exakte Repräsentation eines Wertes sondern lediglich eine Annäherung daran. Werden dann z.B. nur 2 Nachkommastellen angezeigt erscheint der Wert so wie man es erwartet. Bei Berechnungen benutzt MySQL aber intern den “echten” Wert der leicht von dem erwarteten Wert abweicht. Je mehr Daten nun in eine Berechnung einfließen, desto stärker wirken sich diese Abweichungen aus. Bei dem oben angesprochenen Projekt waren das z.B. letztlich 4 Cent die gefehlt haben (bei knapp 20000 Datensätzen die in die Berechnung eingeflossen sind).

Das mag z.B. noch akzeptabel sein wenn man in einer Website die durchschnittlichen Werbeeinnahmen der letzten 12 Monate als Information anzeigen möchte. Nutzt man diese Werte aber für Rechnungen, etc. dann wird es kritisch. Man sollte also in diesen Fällen auf DECIMAL setzen.

Permalink

Herzlich Willkommen

Ich möchte alle Besucher ganz herzlich hier auf dem Blog begrüßen :-)

Eigentlich sollte die Seite schon vor einigen Tagen online gehen – was leider durch einen ziemlich fiesen Bug im hier verwendeten WordPress-Theme verhindert wurde. Beim netzgere.de-Blog fiel auf, dass es den Internet Explorer 8 unter Windows XP zum Absturz brachte. Nach viel Gefluche und Gesuche kam ich dann dahinter, dass der Fehler in der verwendeten Version von respond.js in Kombination mit der import-Anweisung in einer CSS-Datei begründet lag. Nach ein paar kleinen Experimenten habe ich aber dann zum Glück eine Lösung für das Problem gefunden.

Hier im Blog werdet Ihr in Zukunft jede Menge nützliche Artikel rund um Alles was das Internet “lebendig” macht finden. Das können z.B. Artikel zu JavaScript, PHP, WordPress, Typo3 oder anderen Web-Techniken sein (woraus sich übrigens auch der etwas “seltsame” Name des Blogs ergibt: es geht hier um das “Gewebe” welches zwar nicht die Welt, aber das Netz zusammenhält ;-))

Ich wünsche Euch viel Spaß und hoffe, dass Ihr hier öfters nützliche Sachen findet die euch bei Euren Projekten helfen.

Da sowohl netzgere.de als auch netzgewe.be auf dem gleichen Theme aufbauen gilt natürlich auch für das Blog hier: es sollte auch auf Smartphones und Tablets vernünftig aussehen und bedienbar sein.

PS: Ein paar weitere Hintergründe zum Blog findet Ihr übrigens hier.

Seite 2 von 212