auch schlafen ist eine form der kritik

Links nach Hause holen, aber wie?

Web 2.0 — das bedeutet auch: eigene, wie auch immer geartete Daten, aus der Hand geben. Das mag auf der einen Seite unheimlich bequem sein, all diese Dinge unter einem einzigen Dach vereint vorzufinden und recht nahtlos nutzen zu können. Andererseits ist es eben genau das: ein fremdes Haus, ein fremdes Dach und wer weiß schon, was für Pläne der Besitzer für die nächsten Wochen so hat. Was spricht also dagegen, die Sachen ins eigene Haus zu holen?

Die Bequemlichkeit, mal wieder. Die Feedfutter-Liste hier läuft über del.icio.us, meine Links liegen somit also bei Yahoo. Das ist suboptimal, denn wenn schon mein Vertrauen in z.B. google nur soweit reicht, dass ich denen lediglich Spam-Mails anvertraue, warum sollte Yahoo meine gesammelten Links beherbergen dürfen? Wer jetzt denkt, sind doch nur Links — was soll’s, der möge den vorherigen Satz nochmal lesen. Auch vermeintlich kleine Sachen sollen ihren Platz hier im eigenen Haus haben.

Nur, wie stellt man das am |dümmsten|besten an? WordPress bietet eine Linkverwaltung, das ist schonmal ein guter Ansatzpunkt. Problem: wieder die Bequemlichkeit und die zwingende Verbindung zum WordPress-Backend. Bei Code Candies werden die in WP gespeicherten Links als eigene Einträge gepostet. Wäre auch nicht in meinem Sinne: zu prominente Positionierung, für (zumindest dann bei mir) tendentiell (eigen-)inhaltslose Links. Überhaupt ist man dann wieder zeitweise aufs WP-Backend angewiesen. Denn für del.icio.us nutze ich eine Firefox-Erweiterung, mit der ich innerhalb von zwei Klicks die aktuell im FF aufgerufene Seite abspeichern kann. So sollte es sein.

Aber WP insgesamt dafür zu nutzen, das scheint unausweichlich zu sein. Die Frage des Wie bleibt allerdings. Ich glaube mich zu erinnern, dass es bei WordPress mal die Möglichkeit gibt/gab, Links (oder waren es Einträge?) per javascriptbasiertem Link im System abzuspeichern. Hm. Vielleicht gibt es ja eine Möglichkeit, die Links in WordPress zu bekommen, ohne die geliebte gewohnte Bequemlichkeit der del.icio.us-Extension einbüßen zu müssen? Anyone? Jedenfalls mal schauen. Die Änderung muss aber in jedem Fall kommen, wie auch immer.


30 Antworten

  1. Ich bin ja völlig schmerzfrei dabei, mich zu wiederholen. Aber mit Drupal sollte das nicht so schwer sein. Da muss man sich nur für eine Lösung entscheiden. Was es wirklich schnell und gut benutzbar macht sind allerdings in der Tat sie Bookmarklets. Das steht für mich auch immer noch auf dem Programm: Modul machen, das Bookmarks über ein Bookmarklet speichert.

    Leider ist Bookmarkletprogrammierung Javascript und damit hab‘ ich’s ja nicht sooo.

    Nebenbei: ein RSS-Importer wäre fast noch geschickter. Da bastelt gerade der Konnexus dran. Dann kann man weiter Delicous nutzen, bekommt aber alle Bookmarks trotzdem ins System. Uuuund dann könnte man auch nicht den Google-Shared-Items Feed mitimportieren.

    Öhhhhm … überhaupt, es gibt doch den Blog-Service von Delicious, der täglich die neusten Items ins Blog pumpt. Ist zwar nicht ein Post pro Bookmark, aber he, man nutzt ja doch nur die Volltextsuche.

  2. Hehe, ich bin da im Gegenzug auch völlig schmerzfrei: F-a-u-l-h-e-i-t. Noch.

    Der Importer wäre eine Idee. Einer weiteren Nutzung von delicious spräche nicht soviel entgegen, wenn man wenigstens im Gegenzug die Items „auf Vorrat“ selbst beherbergen könnte. Aber: egal ob Javascript, PHP oder sonst was — ich hab’s ja mit allem nicht so. Wäre also nett, wenn Konnexus da was zusammenbasteln könnte. Lässt du es mich wissen, wenn er da was serienreifes hinbekommt?

    Das daily blog posting Feature habe ich mal kurze Zeit ausprobiert. Ne, nicht das, was ich möchte, denn a) will ich Links nicht mit Einträgen durchmixen und b) finde ich es nicht wirklich optimal, die Links in Eintragsform zu haben. Gerade in Hinblick aufs „auf Vorrat haben“ bzw. aufs „für alle Fälle“. Macht bei möglichen späteren Vorhaben wohl eher mehr Arbeit.

  3. Dann als Bonusinformation: Bei Mr. Code Candies sieht das nur so aus, als gäbe es „normale“ Artikel und Lesezeichen. Defakto unterscheidet er die nur über ein Kategorie und hat das Layout der Startseite entsprechend von Hand angepasst. Wenn ich mich nicht irre.

  4. Jap, dachte ich mir schon. Unterscheidung nach Kategorie und auf der Startseite für die „Bookmarks und Lesebefehle“-Spalte sicherlich ’nen zweiten Loop, bei dem keine Titel angezeigt werden. Also eben die Verquickung von Links und Einträgen, die mir nicht ins Haus käme.

  5. Für eine Weiterverwendung von Delicous gibt es sogar gute Argumente – wenn es eine parallele „Daheim“ Speicherung gibt: Social Tagging offenbart ja mitunter spannende Emergenz Effekte.

    Ach ja und ganz nebenbei: habe mich mal umgehend and Feedimporter Modul gemacht und es ist schon fast fertig. 🙂
    That’s the Power of Drupal.

  6. Mich lässt die Sache mit dem rss-Import jetzt nicht mehr los und Geduld war noch nie meine Stärke. Daher gerade angefangen, mir selbst was zu stricken. Ein rss-Parser ist ja bei WordPress schon dabei und auch wenn ich keinen blaßen Schimmer mehr von XML habe (da war nur vor langer Zeit mal der Kurs von Andreas), mag ich mich da nun irgendwie dran fest- und durchbeißen.

    Mal schauen, wie lange das dauert und was für Schrott bei rauskommen wird — wenn.

  7. Erster!
    Ich bin schon fertig. Muss ihn zwar noch ein bischen testen und konfigurierbar machen. Aber Funktionalität ist hergestellt.

    P.S.: sind doch immerhin 400 Zeilen Code geworden. Musst erst die verfluchten Namespaces aus dem Feed rausfiltern. Hab’s dann gleich so generisch programmiert, dass man bei jedem Node-Type eine URL mitspeichern kann und außerdem schnell andere Quellen als Delicious hinzufügbar sind. Eigentlich müßte ich das jetzt noch so machen, dass jeder User seinen eigene Delicious Import hat. Das wäre kuhl. Ich glaub, das ist kein großer Akt mehr…

  8. … ich wäre ja schon froh, wenn ich am Ende „x-ter!“ rufen könnte. Da sind zwei Welten, die weit — sehr weit — auseinanderliegen 😉

    Edit

    … 😉
    Ich übe mich dann mal in Bescheidenheit und gebe zu Protokoll, dass die _grundlegende_ Funktionalität hier inzwischen auch hergestellt ist. Das bedeutet für mich und meine bescheidenen Fähigkeiten sowie Absichten, dass der Feed abgerufen wird und die neuesten Items gespeichert werden. So ganz gefällt mir das mit der Datenbank allerdings nicht. Hm.

    Was jedenfalls noch reinmüsste, wäre zuallererst der Import aus der *.html, die delicious bei Wunsch als Backup aller Items ausspuckt oder aus der all.xml. Aber alles der Reihe nach.

  9. So. Nachdem mich gestern noch die Arbeit gestoppt hat, gehören mir jetzt wieder alle (alten) 282 Links.

    Erstmal nur der Import aus der delicious backup-html (das Parsen der all.xml von delicious ist für mich als blutiger Anfänger einfach zuviel Krampf gewesen) und das Einlesen neuer Items ausm Feed. Aber reicht ja auch vorerst. Die Tage noch eine eigene Export-Funktion zusammenhauen, über die man die Links strukturiert auch wieder aus der Datenbank bekommt.

  10. RESPEKT! Und wo und was sind sie jetzt? Haste die als Links, oder als Posts importiert, oder als was ganze anderes. Entwickler-Details!

  11. Ich hab’s erstmal mit einer eigenen Tabelle — u.a. deshalb will ich bald die Export-Option — für die Links gehalten: Titel des Eintrags, Entität (= Seitenname/Autor), URL und Datum, klar. Das alles als WP-eigene Links zu importieren, darüber hatte ich nachgedacht. Aber eine eigene (simple) Tabelle erscheint mir praktischer, wenn es um ’ne etwaige Weiterverarbeitung ginge.

    Ein universal-einsetzbares Pluggie ist das alles aber bei weitem nicht. Liegt neben dem _sehr_ kruden Zusammenbau (LeSven — wie du — würde über den Quellcode wohl bittere Tränen vergießen und zugleich ungeahnt aggressiv werden :]) auch daran, dass ich bei delicious nen Format a la „Entität || Titel“ verwende, damit ich da wie bei deinem ex machina einen „Urheber“ angeben kann.

  12. Nebenbei bemerkt. Ich mag ja Code produzieren, der inhaltlich wie formal einer Explosion gleicht, aber eines mache ich bei eigenen Plugins immer: eine Deinstallation-Möglichkeit, die alle vom Plugin geschriebenen Daten restlos entfernt — also auch diese verstreuten Krümel in der *_options-Tabelle. Genau das wegzulassen, ist nämlich eine Unart vieler WP-Plugin-Schreiber, die mich regelmäßig ankotzt.

    Wenigstens dafür habe ich einen Pluspunkt verdient, glaube ich :]

  13. Jetzt die spannende Frage: wo und wie werden die dann aus der Tabelle wieder rausgeholt und dargestellt? Ich hab‘ ja beinahe Gedankenkrebs bekommen, als ich mal versucht habe eine eigene URL wie bspw. http://blog.fymmie.de/bookmark/titel-des-bookmarks zurechtzubasteln.

  14. Ach ja und: mach Dir keinen Sorgen um Deinen Code! Du hast ja a) dafür kein Geld von irgendwem haben wollen und b) ja nicht erwartet, dass jemand, der sein Geld damit verdient arbeiten muss.

    Jetzt wo wir beide die gleiche Funktion programmiert haben, kann ich ja mal erklären, was daran bei Drupal so geil ist:
    1) Ich hab einfach einen neuen Node-Typen „Bookmark“ definiert. Anders als WordPress – das nur Posts und Pages kennt – die Drupal dafür ausgelegt neue Node-Typen mit extra Funktionen schnell und einfach zu bauen.

    Ich kann die Bookmarks jetzt genauso wie Storys/Pages bearbeiten.

    2.) Ich hab natürlich auch eine eigene Tabelle dafür angelegt. Das macht man in Drupal über ein Array, dass die Tabelle beschreibt. Der Vorteil: die wird automatisch gelöscht, wenn man das Modul wieder deinstalliert.

    3.) Eigene URLs für Booksmarks werden ebenfalls über eine einfache URL definiert. Zucker.

    Soviel für’s erste… 😉

  15. @Daten wieder rausholen: Soweit bin ich noch gar nicht bzw. so weit hatte ich überhaupt noch nicht gedacht.

    Aber im Grunde würde ich es bei erstem Überlegen halt so belassen, wie es jetzt ist. Sprich: immernoch eigene Feedfutter-Seite, die dann aber gleich über das eigene Plugin laufen könnte.

    (Bisher macht das ein anderes Plugin, dass den delicious-Feed ebenso ausliest und mit ein paar Modifikationen (siehe mein delicious-„Format“) ausgibt.)

    Könnte nun also weg und die Links direkt per eigenem Pluggie aus der eigenen DB geholt werden. Da das Feedabholen im Pluggie derzeit nur manuell abläuft, müsste ich das ganze automatisieren. WP hat ja so eine pseudo-Cron Funktion, wenn mich nicht alles täuscht. Ich denke, da werde ich mich mal umschauen und versuchen, sie einzubauen.

    Für Anregungen/Ideen, was mit der Linksammlung noch so ginge, bin ich natürlich offen — nur mag ich, wie geschrieben, nicht diese Verquickung von eigentlichen Einträgen/Inhalten und Links. Auch wenn das bei Drupal nach bequemer Handhabung par excellence klingt.


    Ist das eigentlich pathologisch? Man startet mit kleinen, sehr eingegrenzten, Zielen & Absichten und immer mehr gesellen sich mit der Zeit hinzu. Macht mir ein wenig Angst, hat aber bisweilen was von Euphorie. Igitt, ist das etwa Ehrgeiz?!

  16. Geschrieben, getan.

    Nun ist alles, was auf der Feedfutter-Seite steht, aus der eigenen DB. Eventuell neue Links werden per pseudo-Cron alle 3h abgeholt. Und weil ich gerade dabei war, habe ich noch ne kleine Logging-Funktion der Feed-Abrufe geschrieben und die Aufmachung der Feedfutter-Seite aktualisiert (hoffe zumindest, dass das nun etwas besser ausschaut).

    Ist ja doch ein wenig mehr geworden als das, was ich mir zuerst vorgenommen hatte. Und weil ich nicht gedacht hätte, dass ich das mit meinen dürftigen Kenntnissen so hinbekomme, gestatte ich mir jetzt einen kurzen Moment der Zufriedenheit.

  17. Ist die Feedfutterseite ein Page, die Du von Hand angelegt hast und in die Du dann die Daten über ein extra Template reinpumpst?

  18. Jap, gespeicherte Seite und Aufruf über Template-Tag mit Limit-Angabe der zu zeigenden Links. Also ganz simple Sache, das. Warum? Ginge da was Feineres?

  19. Naja. 🙂
    In Druuuuuupal, geht sowas halt schöner. Aber ich kenne den Weg in WordPress natürlich gut, habe ich ihn doch selber mehrfach beschritten. 😉

  20. Hehe. Drupal und WordPress — dein ganz persönliches Samsara, was? Ich hoffe wider besseren Wissens auf eine Fortsetzung, hat schließlich einen gewissen Unterhaltungswert gehabt :]

    (und der eigentlich sinnlose Kommentar hier nur, weil die „19“ bei der Kommentar-Anzeige meinen momentanen Ordnungsfimmel beeinträchtigt. 20, 20 — so eine runde schöne Zahl ;))

  21. Als hätte ich geahnt, dass das alles doch nicht so ganz tut, wie ich es will. Verdammte Zeichensätze: die automatisch importierten Items werden als utf8 in eine latin1-Datenbank eingefügt (soweit ich das sehe). Bei der Ausgabe des vorletzten Items auf der Feedfutter-Seite ergibt das häßliche Symbole/Platzhalter.

    Naja, ein utf8_encode in die Ausgabe reingehauen und es mag zumindest hier ordentlich dargestellt werden. Nicht ideal, muss wohl aber reichen.

  22. Ah. Econding. Die Geisel aller Webentwickler und ein weiterer Pluspunkt für Drupal: Alles UTF8, immer, sicher. Keine Kompromisse.

  23. Damit hat WP ja normalerweise auch nicht so das Problem. Das ist eher die Datenbank von all-inkl, denke ich. Das Ding kennt einfach kein UTF8 bzw. bietet es zumindest nicht von sich aus an und kennt standardgemäß anscheinend nur latin1. Warum auch immer… Speichert vielleicht die Daten trotzdem in utf8 und so kommt es dann zu den Problemen bei der Ausgabe? Keine Ahnung…

  24. Das ist mir schon bei haufenweise WordPress-Installationen untergekommen: MySQL nimmt in der Regel als Default einen ISO Kollation und WP sorgt bei der Installation nicht für eine UTF8 Kollation sondern pumpt das UTF8 da einfach so rein, weil die irgendwann auch dazu übergegangen sind, alle Dateien und Formulare in UTF8 zumachen. Dann liegt das ganze Zeug ziemlich zerquetscht in der DB und erst nachdem WP da mit etlichen und nicht rekonstruierbaren Filtern drübergelaufen ist, kann man damit wieder was anfangen.

    Das ist der wichtigste Grund, warum es noch kein WP3Drupal Modul gibt: Man kann schlicht nicht ohne Knoten im Hirn den Datenbankinhalt weiterverwenden.

    Oh Mann! Ich sollte mir echt ein Liste mit dem ganzen Ärger machen, den ich mit WordPress schon hatte und auf die ich jedes Mal draufgucke, wenn ich wieder auf die Idee verfalle, zurückzuwechseln. 🙂

  25. Als kleiner Shared Webspace Kunde kann ich die Kollation der DB wohl nicht einfach so selbst festlegen, nehme ich an? Zumindest wird sie mir nirgendwo zur Auswahl aufgeführt. Wie kann dann ein Skript die erzwingen bzw. sich übers Server-Default hinwegsetzen?

    Und warum zum Teufel macht WP das dann nicht, wenn doch eh UTF8 dort Standard ist? Bei den Umzügen zurück auf Drupal hast du es ja aber offensichtlich geschafft – alle aus der WP-Datenbank importierten Posts einzeln nach utf8 umgewandelt oder wie?

  26. Nope. Das lustige: der WordPress eigenen XML-Export wird vorher auch durch alle Filter gejagd, so dass das XML prima sauberes UTF8 ist. Leider reicht die Prozessorzeit bei den meisten Hostern nicht aus, um den Export komplett durchzuführen, deswegen hab ich das lokal machen müssen. Ging aber.

  27. Der Export? Meinst doch den Import im letzten Satz, oder?

    Apropos, die Export-Funktion steht, macht aber nicht glücklich. Wie zu erwarten: wieder Probleme mit den Zeichensätzen. Kommen wohl nicht einheitlich in die Datenbank und da jetzt alle möglichen Filter ect. hinzuzufügen… ne, fehlt einerseits die Fähigkeit und andererseits viel stärker die Lust. Demotivierender Dreck, die WP-Datenbank 😉

  28. Heisa! Die Umlaute machten bisweilen immernoch Probleme, so dass ich dann händisch in der Datenbank nacheditieren musste. Hat mich immer mehr gestört, so dass ich gerade eben einen neuen Behebungsversuch gestartet habe.

    Mit ein „bisschen“ Hilfe (das RSS-Import-Plugin von Bueltge enthält eine convert-Funktion mit umfangreichen Array) und einigen Anpassungen scheint (Finger kreuzen!) nun alles sauber utf8ig in die Datenbank zu kommen. Und noch schöner: die eigene Backup-HTML mag nun auch sauber ausschauen. Hoffentlich von nun an kein Nacheditieren mehr…

  29. Sollte ich Bookmarks kommentiert haben, werden diese „Notes“ nun ebenso importiert und angezeigt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert