CodeIgniter: Emailversand über SMTP

Wie oft habe ich schon die Email-Klasse verwendet, nur um festzustellen, dass sie nicht funktioniert? Sicher… zwei mal 🙂 Deshalb: Sie funktioniert nicht. Stattdessen verwende ich PHPMailer, bzw. folgende Dateien davon:

Eingebunden werden die ein einem Helper (/application/helpers/email_helper.php):

mit entsprechender Config (/application(config/email.php, wird automatisch eingebunden):

Aufruf dann via:

HTH

“Morgenstund ist kein Zuckerschlecken”

  • Vorfreude ist dem anderen billig.
  • Besser den Spatz in der Hand als Arm ab.
  • Ein leichter Schlag auf den Hinterkopf studiert nicht gern.
  • Politik erspart den Zimmermann.
  • Nur der Tod gefährdet die Dummheit.
  • Klappe zu, Glück allein.
  • Die Letzten soll man nicht aufhalten.
  • Zeit ist das halbe Leben.
  • Was Hänschen nicht lernt, kann noch werden.
  • Was man nicht im Kopf hat, macht mich nicht heiß.
  • Papier ist Rückschritt.
  • Der frühe Vogel trifft keinen.
  • Alte Liebe ist Gold wert.

Diese und weitere Perlen der Weisheit jetzt im Sprichwortekombinator!

via Michael

Facebook API: Hochauflösende valide Image-URLs

Guten Tag.

Über die FB-API bekommt man vergleichsweise kryptische Image-URLs, nämlich die Direktlinks in deren CDN. Diese haben drei Probleme:

1. Die URL zeigt auf die gering aufgelöste Version des Bildes, zu erkennen am “_s.jpg” (“s” für “small). Der gängige Ansatz, um an die hochauflösende Version zu kommen, besagt, dass man “_s” durch “_n” (für “normal?) zu ersetzen (einige empfehlen auch “_o” für “original”). Das funktioniert meistens, aber eben nicht immer. Korrekt scheint dieser (selbstverständlich undokumentierte) Ansatz, der quasi analog zur Profilbild-URL funktioniert:

<object_id> kommt aus der API. Achtung: Das funktioniert nur für Posts vom Typ “photo”; Posts vom Typ “link” müssen nach wie vor über die URL im Feld “picture” gehen! Und damit kommen wir direkt zum nächsten Problem:

2. Facebook nutzt Proxy-Skripte zur Generierung der niedrig aufgelösten Bilder. Zu erkennen an …/safe_image.php?…&url=<url_codiert> oder …/app_full_proxy.php?…&src=<url_codiert>. Diese muss man rausfilter, die tatsächliche URL dekodieren:

3. Profilbilder von altersbeschränkten Seiten sind ebenfalls altersbeschränkt 🙂 Für Zugriff muss man den Access Token anhängen (Quelle finde ich gerade nicht mehr wieder):

ggf. benötigt man das auch für die unter 1. genannten Bilder.

HTH

CodeIgniter: “The model name you are loading is the name of a resource that is already being used”

Es gibt im Internetz verschiedene Ansätze für dieses Problem; die meisten basieren auf einem eigenen Loader. Meiner Erfahrung anch funktionieren die alle nicht (in allen Situationen), und leider scheint die einzige echte Alternative zu sein, alle Models ohne Namen zu laden. Also lieber

statt

🙁

MySQL vs. UTF-8 (vs. CodeIgniter)

MySQL kann UTF-8… falsch. Besser gesagt: Ungenau. MySQL kann UTF-8, aber das heißt da anders:

Ein Zeichen in UTF-8 ist (bis zu) vier Bytes lang, “UTF-8” in MySQL kann aber nur bis zu drei. Deswegen fällt der Unterschied oft gar nicht auf, oder erst beim ersten Zeichen, das vier Bytes braucht. Will man echtes UTF-8, muss man einiges umkonfigurieren; in Kurzform:

  1. SQL muss in der Version 5.3.3+ vorhanden sein, siehe Link oben
  2. Jede Datenbank, jede Tabelle (ggf. jede Spalte) müssen auf “CHARSET=utf8mb4 COLLATE utf8mb4_unicode_ci” umgestellt werden
    • Dabei zu beachten: InnoDB kann wohl nur 767 Bytes pro Index Schlüssel. Wenn man vier (statt drei) Bytes pro Zeichen rechnet, sind das bsplw. nur 191 (statt 255) Zeichen!
    • Das gilt auch für Typen wie TINYTEXT, die wohl nur 255 Bytes = 63 Zeichen bei 4 Byte/Zeichen speichern können. Ggf. ist hier ein anderer Typ zu wählen
  3. ggf. Server, Client, etc. umstellen (dabei hilft “SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';“)
  4. ggf. Datenbank reparieren und optimieren (war bei mir nicht nötig, ich habe alle Tabellen neu angelegt):

bzw.

Insbesondere bei Punkt 3 hängt es bei CodeIgniter, btw. Wenn man in der Datenbank-Config

 stehen hat, dann ist das ebenfalls nicht das echte UTF-8. Stattdessen korrekt ist:

Update

Das Problem betrifft auch mysqldump: Will man die eine utf8mb4-Datenbank dumpen, muss man das explizit sagen, denn mysqldump nutzt per Default nur utf8 (Quelle):

Das ist so tief verankert, dass auch Dumps über Tools wie Sequel Pro nur utf8 nutzen m(

Twitter API: Ziel der t.co-Short-URLs

Twitter kürzt URLs mit dem hauseigenen Dienst t.co. Die so (de facto) verschleierten URLs werden auf twitter.com zwar über den Link-Text (bis zu einer gewissen Länge) wieder aufgelöst, aber die URL dahinter bleibt die von t.co. Über die API bekommt man denn auch erst mal nur die t.co-Version. Im Netz kursieren Links zu “Unshorten”-Services (Beispiel), die aber gar nicht (mehr?) nötig sind: Der Parameter “include_entities” erweitert den Response bsplw. der Suche um alle Felder, die man benötigt (hier nur die Entities):

 

CardDAV-/CalDAV-Client “vergisst” Einträge

Mit meinem BlackBerry habe ich endlich die Möglichkeit, CardDAV und CalDAV zu nutzen, und das tue ich bei Posteo. Leider hatte ich das Problem, dass sowohl Adressbuch, wie auch Kalender immer wieder alle Einträge vergessen haben. Ein Sync half nicht, wenn überhaupt, dann nur ein Reboot. Aber auch das nicht immer.

Ich habe die Überschrift bewusst schwammig formuliert, weil ich nicht weiß, ob es letzten Endes an Posteo oder BlackBerry lag, aber die Lösung brachte die Deaktivierung der serverseitigen Verschlüsselung.

HTH