auch schlafen ist eine form der kritik
Der Rückzug aus den Massenmedien kann nie völlig gelingen, aber selbst die unvollständige Entsagung ist konsequent, ist richtig und fühlt sich passend an. Das wirklich öffentliche Publizieren aus dem inneren Exil ist so gemeinschaftlich wie unser aller solitäres Dasein. Nun verläuft es linksbündig. Die Grundlinie wird in ihrer Unschärfe suggeriert.
Ah. Schön. Grundlinienraster muss ich mir wirklich auch mal zu gemüte führen. Und was ich gerade erst gehen habe: Blogoff! Was ist das? Wie kommt es dahin? Warum weiß ich nichts davon?
Nebenbei: Das Kommentarformular sieht komisch aus. Da ist ein bisschen wenig Platz, um Email und Homepage anzugeben.
Komisch aussehende Sachen schaffen ist, was ich tue. Aber ja, da haben sich im Kommentartemplate ein paar Zeilen beim Tippen verirrt. Kommt davon, wenn man nicht bedenkt, auch einmal im ausgeloggten Zustand drüberzuschauen. Die Eingabefelder sollten jetzt außerdem breiter sein. Merci für den Hinweis.
Der Freund des Grundlinigen ist übrigens wie gehabt der „?grid=display“-Anhang. Zumindest in FF und Opera sollte das unscharf-grundlinig passen. Hoffe ich.
Wegen blogoff: Vielleicht ist es Twittern im inneren a-sozialem Exil? Vielleicht ist es zu kurze Kurzschlußhandlung? Oder oder. Was es genau ist, weiß ich (und das blogoff selbst) auch nicht so richtig. Und das ist gefühlsmäßig eine paradoxerweise beruhigende und ebenso passende Sache.
„Komisch aussehende Sachen schaffen ist, was ich tue.“ – Zitat des Tages
Zum Bloggoff: Aber ich verstehe es nicht. Der Quelltext weist WordPress als urhebende Plattform aus. Ich verstehe, dass Twitter zu Texten führt, die anders sind als Blogtexte. Und ich sehe mich auch danach, so wieder zu bloggen. Aber ich verstehe nicht, warum das nicht hier passiert und warum mit WordPress.
Hm. Hmm. Ich verstehe es ja selbst kaum. Denn ehrlich gesagt, habe ich mir darüber noch keinen großen Gedanken gemacht. Mal ansetzen:
Ich begreife „mein“ Blog (auch) als Konstrukt und die darin versammelten Texte als Indikatoren — manche von denen üben diese Funktion stärker aus, andere weniger. Zumindest weniger, als mir lieb wäre. Nichtsdestotrotz allesamt Indikatoren.
Und dieser Umstand sorgt (paradoxerweise, ich weiß) dafür, dass diese anderen Texte, die blogoffs, von mir hier schon gedanklich und ganz irrational erstickt werden würden. Viele von diesen kurzen Abrissen hätten es hier nicht einmal zum Draft-Status gebracht. Das aber nicht, weil ich sie als Abfall oder als Rest sehe (wobei, manche…). Das Konstrukt hätte sie einfach verhindert oder besser gesagt das, was sich über die Jahre hier unbewusst, in meinem Hinterkopf und geradezu selbstständig als Konstrukt geformt hat. Sie würden sich zumindest gegenwärtig für mich einfach als zu unpassend anfühlen.
Ja, das ist inkonsequent. Das ist im Prinzip aufgedrückte Selbstgeiselung, aber wenn es sich einfach unpassend anfühlt, was kann man dagegen schon machen?
Da ist einfach (noch?) eine gedankliche Schranke im Weg? Vermischen dieser zwei Varianten unter dem einen (Distributions-)Weg der Blogtext-Variante? Erscheint mir auch nicht sinnvoll und potentiell unscharf, unbestimmt und fade. Ich kenne das selbst aus meinem Feedreader, wo es mir mit einigen Blogs schon so erging.
Und die nächste Frage wäre dann auch: Möchte ich überhaupt, dass das – das „wieder so bloggen“ – hier passiert? Warum sollte man das? Hmm.
Das ist alles ziemlich wirr und ich sollte mich da nochmal randenken, wenn mir nicht die Arbeit allen Willen aus den Knochen gesaugt hat.
Ach, eins noch: warum mit WordPress? Schlicht und ergreifend Faulheit. Ehrlich. Zum Zeitpunkt, als ich das blogoff aufsetzte, war das einfach die schnellste und unkomplizierteste Variante. Und die naheliegenste. Außerdem hat der Name noch einen lakonischen Unterton vertragen können 😉
Auch wenn’s aus meinem Mund wohl komisch klingt: Ich weiß was Du meinst. Twitter förderte durch sein „Konstrukt“ Texte aus mir heraus zu Tage, die mein Blog derzeit verhindert. Das sind ja auch Texte, die man den – inzwischen normalen – Blogleser eigentlich nicht zumuten will, weil sie die Verständlichkeit und das Sendungsbewußtsein der „normalen“ Artikel vermissen lassen.
Aber immerhin habe ich den Anspruch beides in einem CMS zu haben. Auch wenn es ungleiche Geschwister sind. Allein zwei Steine – die mich stark an Deine erinnern – liegen mir im Weg: Wie ins Blog integrieren, einfach vom Layout her, ohne dass die Jüngeren von den Großen unterdrückt werden? Irgendwie muss das ja in ein Layout, mehr oder weniger.
Und – und das ist wohl eher mein Problem als Deines – wie das Backend gestalten, dass solche skurilen Texte auch wieder aus mir herausgegraben werden können. Twitter lehrt: Die Hürden senken. Einfacher, einfacher, einfacher machen. Mit Drupal ließe sich das vielleicht hinbiegen, mit Heimweh wohl noch besser … sicher bin ich mir da aber nicht. Ganz und gar nicht.
Freut mich, dass es wohl trotz aller späten Wirrheit verständlich war.
Nun, letzteres Problem dürfte wohl auch unweigerlich meins sein bzw. werden. Die Illich-Lektüre wird dafür schon sorgen. Denn auch wenn es bei mir (noch) eine gedankliche Schranke ist, weiß ich ja, dass eine entsprechende technische Voraussetzung/Verfügbarkeit (in dem Falle also die Aufmachung, die technisch-funktionelle Aufmachung des Backends) durchaus fähig wäre, diese Schranke fallen zu lassen. Die Technik prägt und formt den Umgang.
Ersteres Problem schreit allerdings nach einer Lösung und solange die nicht in Sicht ist, weiß ich nicht wie sinnvoll es überhaupt ist, sich gleichzeitig über ein neues Backend den Kopf zu zerbrechen…? Hm.
sehr interessant das alles. erlebe ich nämlich auch. und die selbe verwirrtheit, fym. ich schätze bei mir wird es darauf hinaus laufen, dass blogoff-einträge mit ins blog kommen, aber als ein separates node-typ, und nicht für alle sichtbar (was auch die meisten nicht interessiert). trotzdem kann ich die blogoffse anbinden an meine taxonomie, die mir lieb und teuer ist.
Das ergeht mir beim Feedfutter übrigens genauso. Das ist alles so unschön von allem anderen abgekapselt, zugleich aber momentan noch nötig.
WordPress macht es einem auch nicht einfacher, dass anders umzusetzen (WP-eigen kategoriemäßig). Wenn ich nur daran denke, welche Krämpfe die Sichtbarkeit von Kategorien in Zusammenspiel mit Pagebar verursacht… Würde mich die wohl nötige Eingewöhnungszeit für Drupal (bis ich mich dort wenigstens annähernd so „sicher“ fühle, wie aktuell in WP) momentan nicht dermaßen abschrecken, wäre ich vorgestern schon migriert.
oh, ok. hab gedacht du wärst mit dem blog schon auf drupal (war zu faul im quelltext nachzugucken). offensichtlich gehe ich bei zu vielen leuten davon aus, dass sie – nur weil sie ben_ kennen – auf drupal bloggen.
so, hab’s bei mir umgesetzt. könnt ihr leider noch nicht sehen, da die site im moment im offline-modus ist. aber ich werd bei gelegenheit berichten, wie sich das anfühlt, zu bloggen und zu blogoffen …
Von nichts kommt ja nichts (heh!), also wenigstens schonmal Grundlage für den Migrationsbeginn geschaffen. Lokal Drupal 6 installiert (mal wieder) und jetzt einfach nach und nach versuchen, ob ich das so versuchsweise einigermaßen fertigbringe. Das lerrraum-Theme werde ich wohl zuerst versuchen zu portieren.
Wie ich drüben beim ben_ schon in den Kommentaren erwähnte: Es wäre ganz praktisch, wenn ich ein paar Richtungsweiser zur Hand hätte. Also z.B. welche der Basis-Module ich auf jeden Fall benötige/nicht benötige, welche zusätzlichen Module unverzichtbar wären, was „ihr“ Drupaler (hmm) da für Inhaltstypen eingestellt habt und ähnliches. Keine idiotensichere Anleitung/Hilfe – das würde ich gar nicht verlangen wollen – aber halt ein paar Stubser in die richtige Richtung für den mehr-minder unbedarften WordPress-Umsteiger. Wäre sehr fein.
oh,
einfache blog-beiträge schreibst du mit dem node-typen „Story“.
module:
* ‚mollom‘ gegen spam
* ‚pathauto‘ für schöne urls
mehr brauchst du IMO nicht, um anzufangen.
Ja. Das wichtigste hat Konnexus ja gerade schon geschrieben: Obwohl Du mit Drupal bloggen willst, läßt Du das Modul „Blog“ das zum Kern gehört unaktiviert und stellst stattdessen Nodes vom Typ Story her. „Blog“ ist dazu da, wenn man mit Drupal eine Community betreibt, jedem User ein persönliches Blog anzubieten.
Bei der Konfiguration des Kerns würde ich noch dringed empfehlen, Taxonomy, Path, Locale, Upload, Statistics, Search, Update Status und Comment anzuwerfen.
Bei der Einstellung des Node-Typen kannst Du dann entscheiden ob der per Default auf die Startseite soll oder nicht und wie die Kommentare gehandhabt werden.
admin/content/types
admin/content/node-type/story
An Third-Party Modulen habe ich eigentlich immer (zusätzlich zu „mollom“ und „pathauto“) noch Archive für das Chronologische Archiv und Poormanscron (für die Suche wichtig) an.
http://drupal.org/project/archive
http://drupal.org/project/poormanscron
Da waren wohl zuviele Links in meinem Kommentar. Auf jeden Fall ist er nicht hier, seine URL aber: #comment-22305.
Noch eine Ergänzung. Das Theme Zen gilt als guter Ausgangspunkt für eigene Themes.
http://drupal.org/project/zen
Inzwischen würde ich davon aber abraten, weil Zen inwzischen auch ganz schön aufgeblasen ist. Ich glaub ich zimmere die Tage mal ein minimalistisches Theme nur zu dem zweck um daraus „richtig“ Themes zu basteln zu können.
ich kam mit „zen“ auch nicht zurecht. diese vererbungen muss mal erstmal verstehen. ich mochte es eher etwas einfaches zu nehmen und einfach umzubiegen für meine bedürfnisse, statt dasd abstrakte zen zu erweitern.
@ben_:
ich kann leider nicht nachvollziehen, was du mit #comment-… meinst und wo dein kommentar dann ist. muss ich die #comment-url zusammenbasteln?
Noch zu Nodetypen: WordPress kennt ja nur zwei „Node“-Typen. Pages und Posts. Die kann man durchaus als äquivalent zu Pages und Storys in Drupal betrachten. Jede weitere Klassifikation macht man in WordPress ja in der Regel über Kategorien, Tags oder Metadaten. In Drupal fällt mir das auch nicht immer leicht zu entscheiden, wann ich einen neuen Node-Typen brauchen. Es hilft, sich das wie einen Dokumenttypen vorzustellen. Oder, wie Zettel unterschiedlicher Farbe im Zettelkasten.
Grundsätzlich gilt, wenn Ich im Artikel-Anlage-Dialog bzw. Node-Creation-Form für bestimmte Nodes etwas anders machen möchte als für andere Nodes, dann erstelle ich dafür einen neuen Node-Typen.
@Konnexus: Ich bin nach dem Abschicken des ersten Kommentars zu einer URL mit dem Anker #comment-22305 weitergeleitet wordem, das darauf schließen läßt, dass der Kommentar zwar angekommen ist, WordPress aber entschieden hat, ihn nicht darzustellen.
Ich hab die Codex Seite inzwischen auch massiv ergänzt:
http://anmutunddemut.de/codex
Kommt aber noch mehr dazu. Ich meld mich wieder.
(Ja, den „ersten“ Kommentar von ben_ hat WP ins Spamfach verfrachtet, ist oben nun sichtbar.)
Danke schön! Besonders für den erweiterten Codex, ben_. Die Hinweise helfen der Orientierung schon einmal.
Die Erstellung eines Templates ist für mich erstmal gewöhnungsbedürftig (Garland als Vorlage benutzt, hätte ich wohl besser nicht machen sollen…?). Sind die ganzen Variablen (insbesondere die Pfade z.B. in der Ausgabe von check_url($logo)) festverdrahtet? Hat da einer eine Übersicht parat? Das Drupal Center finde ich hinsichtlich solcher Fragen nämlich noch weniger hilfreich, als den WP-Codex. Ansonsten erinnert leerraum auf Drupal schon nach den ersten kurzen Versuchen heute entfernt an den WP-leerraum. Immerhin.
Und eine Verständnisfrage hätte ich da noch: Wenn ich schon Nodes erstellt habe, dann etwas am Template/den Einstellungen ändere – z.B. die Nodes in voller Länge und nicht angeteasert darzustellen – greifen diese nur für neue Nodes. Das Verhalten ist für mich an WP gewöhnten Menschen ziemlich unverständlich. Gibt es da einen Kniff, die aktuellen Einstellungen auch für die ältere Nodes zu verwenden?
Ich sehe schon, die nächste Woche werde ich wohl erstmal intensiv Schmökern müssen…
Garland ist kein gutes Theme um damit anzufangen.Zum Anfang würde ich eines der Tabellen-Themes empfehlen, die im Core mitkommen. „Mies“ und „Wehmut“ basieren auf Bluemarine. Die Tabellen lassen sich ziemlich schnell entfernen.
Und ja: Das ist „normal“ in Drupal, dass realtiv viel in den Templates als komplette Variablen kommt. Drupals Flexibilität liegt in den Modulen und der template.php in der Du jene Funktionen, die das Aussehen des HTMLs beschreiben überschreiben kannst. Als Einstieg ins Theming ist der Drupal 6 Themeguide zu empfehlen:
http://drupal.org/node/171194
Sehr hilfreich ist die Drupal API:
http://api.drupal.org/api/group/hooks/6
Insbesondere die Type-Ahead-Suche.
Wobei ich dringend raten würde, mir das Konzept von Subthemes
für später aufzuheben. Das macht nur Knoten in den Kopf.
Der Codex ist jetzt nochmal deutlich erweitert. (Dank an die Deutsche Bahn, dass die Strecke Hamburg-Berlin jetzt 2,5 statt 1,5 Stunden dauert!)
Das mit den Teaser ist in Drupal in der Tat anders: Wenn Du mal einen Blick in die Datenbank in die Spalte (node_revisions – Drupal kann unterschiedliche Versionen einundderselben Node verwalten!) wirfst, wirst Du sehen, dass Drupal eine extra Spalte „teaser“ hat, der nur bei jeder Änderung der Node angepasst wird und Standardmäßig auf Übersichtsseiten, wie der Startseit oder Term-Seiten ausgegeben wird. Man könnte das aber mit einem klitzkleinen Modul umgehen.
Da ist schon wieder was im Spam gelandet. :]
k, Drupal mag die ältere, hier verwendete MySQL-Version nicht. Also erstmal nur lokales Experimentieren und bei Gelegenheit allinkl.com anschreiben.
Und Drupal verwirrt mich immer noch. Seufzer.
Ja. Drupal verwirrt mich auch immer noch. Habe heute entdeckt, dass man in die Ordner von Modulen auch Template-Dateien legen kann. Ts. Hab aber keine Ahnung, wie das funktioniert. 🙂
Was Hosting angeht: Ich kann Dir latürnich zum Testen und Spielen eine Installation auf meinem Webspace und FTP-Zugang anbieten.
Danke schön, aber ich denke, ich werde erstmal weiterhin lokal ausprobieren und dann bei Gelegenheit veranlassen, den Webspace auf mysql 4.1 umziehen zu lassen.
Die Datenmigration bereitet mir gerade Kopfschmerzen. Das wp2drupal-Modul verrichtet zwar seinen Dienst, importiert aber soweit ich das sehe nicht die Metadaten (außerdem müsste dann ohnehin der lokale Umweg begangen werden, weil ich hier auf dem shared webspace nur eine Datenbank pro Domain/Unterverzeichnis laufen lassen kann). „WordPress Import“ wiederum erstickt schon an dem ~3 MB großen Export-XML von WordPress und wird bewusstlos. Wenn das lokal schon so läuft…
Durch das Theming steige ich momentan noch nicht wirklich durch. Die grundlegenden Sachen (Blöcke, Menüs usw.) sind klar, aber die Modifizierung des Outputs (wie z.B. das Markup von spezifischen Blöcken – Hauptlinks, eigene Blöcke ect. – ändern?) erschließen sich mir noch nicht wirklich. Mal schauen. (Und weil ich letztens erst hier die Grundlinie eingebaut habe, bringt mich Drupal gerade an den Rand der Verzweiflung, weil es Zeilenumbrüche an den unmöglichsten Stellen einfügt und dadurch grundliniges zerschiesst. Ist mir irgendeine Einstellung entgangen, die festlegt, dass Drupal _nichts_ an meinem Markup ändert?)
Ach und ben_: Wäre es möglich, mir das SemanticWeblog-Modul zukommen zu lassen? Hinsichtlich des Imports der Metadaten wäre es nämlich nicht schlecht, zu sehen, wie das Ganze bei Drupal gehandhabt wird.
zum theming: ich habe dasselbe bedürfnis beim themen. daher greife ich einfach „hart“ auf das node-objekt zu, in dem alle daten zu dem node liegen, und forme dann selbst die ausgabe. es gibt bestimmt einen besseren weg (ben_?), den ich aber noch nicht kenne.
ich geb mal ein beispiel.
ziel: tags ausgeben als liste, die man evtl. anders formatieren will.
gegeben: drupal gibt als standard-output die variablen $taxonomy und $terms zur verfügung. mit $taxonomy überprüfst du, ob es tags gibt, in der variable $terms ist eine liste aller terms, verlinkt, als html gespeichert.
die ausagbe sieht in etwa so aus:
if (count($taxonomy)) {
print '';
print $terms;
print '';
}
wenn man nun die liste anders formatiert haben möchte (z.b. komma-separiert), kann man das folgendermaßen machen:
if (count($taxonomy)) {
print '';
$max = count($node->taxonomy);
$counter = 0;
foreach ($node->taxonomy as $term) {
$counter ++;
$comma = '';
if ($counter != $max) {
$comma = ', ';
}
print '<a>tid . '">' . $term->name . '</a>' . $comma;
}
print '';
}
für meine zwecke habe ich noch spezielle funktionen eingebaut, die die url und das aussehen verändern, je nachdem, ob ein tag auch eine textliche definition hat.
diese methode hat bestimmt innerhalb von drupal enorme nachteile – ich hab nur noch nicht rausgekriegt, welche 🙂
oops, jetzt ist auch von mir ein kommentar wohl vom spam-filter geschluckt worden. ich hab da wahrscheinlich zu viel code, insb. pre-tags reingebaut…
@Theming: Also es gibt grundsätzlich drei legitime Wege in Drupal, den Ouptput den eigenen Bedürfnissen anzupassen.
1. Themable Funktions. EIGENTLICH sollte aller Output, der HTML enthätl und vom System oder von Module kommt durch eine Funktion, die mit „theme_“ beginnt. Damit hat man dann die Möglichkeit diese Funktion in der template.php zu überschreiben.
http://api.drupal.org/api/group/themeable
In der Tat sind ziiiiiemlich viele Dinge themeable.
2. tpl.php Dateien. Man kann durch bloßes Anlegen von tpl.php Dateien, die Ausgabe bestimmter Elemente der Seite als Templates „umschalten“. Man kann also bspw. eine Tpl-Datei
block-modul.tpl.php anlegen und laufen alle Blöcke aus dem Modul durch dieses Template statt durch die block.tpl.
Mehr dazu hier: http://drupal.org/node/341628
Und insbesondere hier: http://drupal.org/node/190815
3. Rohe Daten. Ganz viele Dinge, die Drupal fertig gerendert ausliefert, sind in den Templates auch als Rohe Daten vorhanden und können statt der fertig-gerenderten Variablen genutzt werden. Das hat allerdings den Nachteil, dass man alle „Funktionen“, die Module in die fertig gerenderten Sachen mit reinstecken nicht direkt angezeigt werden sondern immer eine Anpassung des Themes erfordern.
Hilfreich dazu (wenn auch für D5):
Infos zur node.tpl.php: http://drupal.org/node/11816
Infos zur page.tpl.php: http://drupal.org/node/11812
Infos zur block.tpl.php: http://drupal.org/node/11813
Infos zur comments.tpl.php: http://drupal.org/node/11815
@Import-SW-Plugin: Ich hab ja damals beim Import die Keys weggeworfen und alle „values“ in ein eigenes Vokabular „Lexikon“ importiert. Traurig aber wahr.
ben_: Im Prinzip ist also das Theming bei Drupal größtenteils genau das, was ich an WordPress so schrecklich fand? Ich muss, wenn ich das Markup bestimmter Ausgaben ändern will (und diese nicht als extra Variable schon bereitgestellt werden wie z.B. bei den Kommentaren $author) extra mittels Überschreiben von theme_yadayada anpassen? Hmm.
Und nur damit ich eine ungefähre Vorstellung davon bekomme: Wenn ich Drupal dazu bringen möchte, das Markup vom – sagen wir mal -Primary Links Block zu ändern, welche Funktion ist dann die richtige? theme_blocks? Sorry, aber in der Hinsicht stehe ich momentan im tiefsten Wald.
>Im Prinzip ist also das Theming bei Drupal größtenteils genau das, was ich an WordPress so schrecklich fand?
Äh … hähä … also … öhm … ja. Nur anders. Also das „Überschreiben“ passiert ja in der template.php, die wiederum zum Theme gehört. „Überschreiben“ hat bei Drupal die Bedeutung, die es in der Objektorientierung hat. Die Methode einer abgeleiteten Klasse „überschreibt“ die Method der Elternklasse. Während man bei WordPress „überschreiben“ im wörtlichen Sinne machen muss, als im Kern die dortigen Bytes durch eigene über-schreiben.
Aber ich gebe zu, das macht es nicht wirklich einfacher. Um zu Deinem konkreten Problem zu kommen. Wenn Du im Ordner Deines Themes die Datei block-menu-primary-lins.tpl.php einebaust, kannst Du da drin rumfusseln. Aber leider stehen dem Block nicht die eigentlichen Rohdaten zur Verfügung. Einfach mal ausprobieren und folgendes reinschreiben:
$vars = get_defined_vars();
print_r($vars);
Theoretisch kann man in der tpl.php dann auch Funktionen aus dem Kern-Aufrufen, die einem die Rohdatenliefern und die dann rendern.
In der Tat wäre in diesem Fall das „Richtigste“ aber die entsprechende Themeable Functions zu bemühen:
http://api.drupal.org/api/search/6/theme_menu
Leeeider hast Du Dir auch gleich einen etwas komplizierten Fall ausgesucht, weil das Überschreiben der theme_menu_tree() oder theme_menu_item() oder theme_menu_link() prompt alle Menüs themed und ich nicht weiß, wie man die im Zweifel unterscheiden kann.
Auch wenn ich mich inzwischen mit dieser Komplexität abgefunden habe: Dein Einwurf ist nicht ohne Substanz. Genau das wollte ich ja auch in Heimweh anders machen.
Ich bin inzwischen schon ein wenig tiefer gestiegen und– man verzeihe es mir, ein heute Morgen geschriebener, kurzer Rant muss jetzt sein:
Ich bin Markup-Diktator, zugegeben. Ich will mein Stylesheet nicht dem Markup anpassen (müssen), sondern es hat in einem Templatesystem verdammt nochmal genau andersrum zu sein.
Die Benennungskonvention von tpl.php-Dateien habe ich inzwischen gelesen (von vollständig begriffen kann ja keine Rede sein). Und nach meinen Versuchen stelle ich mir wirklich die Frage, ob ich unter „Template“ etwas völlig Abwegiges verstehe. Darf sich sowas überhaupt Templateengine schimpfen, wenn ich alles drumherum einfachst bekritzeln darf (eben z.B. die block-, node-, page.tpl.php ect. Dateien), aber zugleich nicht den Inhalt ansich, das worauf es letztlich ebenso ankommt? Überall nur $[…-]content als bereitgestellte und mit Markup versehene Variable – W.T.F. Es kann doch nicht der Weisheit letzter Schluß sein, dass man, will man solche vermeintlich grundlegenden Dinge anpassen, zig Funktionen „überschreiben“ muss. Ich verstehe, dass Komplexität und Flexibilität ihren Preis hat, aber das ist im Endeffekt und im Vergleich schlicht unglaublich flexible Starre.
ben_: Ich sehe schon. Will ich also alles so haben, wie ich es will, stehen mir vergnügliche Stunden des Überschreibens bevor. Offene vs. spezialisierte Struktur, schon klar. Aber im Moment ist das nur ein einziger Krampf.
(btw: Sehe ich das also richtig? Es wäre für „meinen“ Import günstiger, für jeden Key ein (Unter-)Vokabular zu erstellen und mit den entsprechenden Werten zu befüllen (zB. Werte der keys „sw_Serie“ gehen ins Vokabular „Serie“ ect). Wie auch immer ich das dann bewerkstelligen sollte…)
Ja, hm. Also zuerst zum Theming und Ranting. Das ist ja völlig legitim, damit unzufrieden zu sein. Ich würde es ja auch ander machen, wenn ich könnte. Ich hab sogar schon überlegt in Drupal oder WordPress einfach die kompletten Frontend-Layer auszutauschen und durch einen eigenen zu ersetzen. Die AAAWP war ja schon ein erster Schritt in die Richtung und im Drupal-Dashboard hab ich schon was ähnliches gemacht.
Das Dillema bleibt dann aber das selbe: Plugin- und Modulentwickler bekommen ihre Daten/Features nicht ins HTML, oder sie müssen sich doppelte Arbeit machen. Aber in der Tat hab ich mich ja – gerade durch die Diskussion hier – in den letzten Tagen auch tiefer in die Drupal-Themeing-Mechanik begeben als je zuvor und muss sagen, dass da Tiefen auftauchen, die für normale Menschen kaum noch nachvollziehbar sind. Kein Wunder dass es nur zum Theming ein eigenes Buch gibt.
http://www.amazon.de/Drupal-6-Themes-Ric-Shreves/dp/1847195660/
Und jetzt wo wir hier so darüber plaudern, fällt mir die Session von letzter Woche wieder ein.
http://anmutunddemut.de/2009/04/21/three-tier-four-tier-two-tier-zoo-architecture
Wenn der gute Mann recht hat, dann bekommen wir eh bald bessere
APIs, auf die wir unser Rendering draufsetzen können.
Ach und was den Import angeht: Ja hm. Also wie gesagt. Ich hab alle Informationen, die in den Keys stehen weggeworfen und wirklich alle Values in ein einziges Vokabular gesteckt, weil die Idee des Semantic Weblog ja eiiiigentlich ist, diese Semantik über Relationen zwischen den Nodes/Topics abzubilden. Die Idee war dann, sobald die Topics da sind, auch ein Topic „Serie“ anzulegen und zwischen „Lost“ und „Serie“ die Assoziation „is a“ anzulegen.
Diese Relation könnte man halt theoretisch aus den Keys extrahieren. Das wäre das allerrichtigste Importweg. Also für jedes Metadatum auch gleiche eine Assoziation „key“ – „is a“ „value“ anlegen…
Ich überlege momentan wirklich, alles händisch in die Themedateien zu schreiben, was nicht unbedingt zwingend von Drupal organisiert sein muss (eg. Navi-Links händisch, kein Block usw.). Das wäre zwar mehr als dreckig, aber sieht ja außer mir keiner und würde mir den einen oder anderen Krampf ersparen. Andererseits: Was lerne ich dadurch schon? Hm.
Wobei ich desweiteren gerne erleuchtet werden würde: Wie bekommst du die Metadaten als Block bei dir angezeigt? Überhaupt: Wie lagere ich Daten, die einen Node betreffen, so aus, dass ich sie auch außerhalb der node.tpl.php verwenden kann (eben beispielsweise dynamisch in einem Block)? Da dreht mein WP-geeichter Geist gerade Knoten nach Knoten. Seufzer.
@Import: Ah, Groschen gefallen. Merci.
Übrigens hat’s mir gerade nach der Aktivierung des SW-Moduls (danke dafür) liebliche Zeilen ausgespuckt:
Fatal error: Call to undefined function user_access() in […]drupal610includesmenu.inc on line 449
Wie läuft das denn bei Drupal, wenn ein Modul Probleme macht? Bei WP reicht es ja, das betreffende Plugin schlicht zu löschen/aus dem Ordner zu entfernen. Das quittiert mein lokales Drupal allerdings damit, mir zwar wieder das Frontend zu zeigen, mich aber nicht mehr ins Admin-CP zu lassen.
Aaalso: Zum einen kannst Du mit dem Kern Drupal ja auch eigene Blöcke anlegen und da nacktes HTML reinstopfen. Das ist ein durchaus üblicher Weg. Machen wir bei Zeit Online auch reichlich.
Für solche Blöck kannst Du dann ja zudem auch noch eigene tpl.php Dateien anlegen und haufenweise PHP machen, wie Du magst.
Der Metadatenblock wird vom Semantic-Weblog-Modul geliefert. 🙂
Ist ein Trick. Mit der funktion arg($int) kommt überall in Drupal an an die einzelen Teile des Query-Strings dran.
if (arg(0) == 'node') {
if (is_numeric(arg(1))) {
$node = node_load(arg(1));
dprint_r($node);
}
}
So kommt man überall an die aktuelle Node, wenn man denn auf einer Node-Seite ist. Sollte ich mal in eine gekapselte Funktion refaktorisieren. Gesagt getan:
function tools_get_current_node(){
if (arg(0) == 'node') {
if (is_numeric(arg(1))) {
$node = node_load(arg(1));
//dprint_r($node);
return $node;
}
}
return false;
}
Ich hoffe das funzt. Hab noch nie direkt in einem Kommentar-Feld programmiert. 😉
Urgs. Das mit dem user_access() ist nicht so schön. Spontan würde ich sagen, Drupal hat dich ausgeloggt. Genau kann ich das aber nicht sagen…
Hehe, schaut doch gut aus. Wundert mich allerdings, dass du damit zur Abwechslung nicht im Spamordner gelandet bist 😉
Zur Fehlermeldung: Das Komisch daran ist ja, dass es – wenn ich wiederholt ein frisch installiertes Drupal benutze – für mich nicht reproduzierbar auftaucht. Wenn, dann aber allen Anschein nach erst beim Versuch, das Association-Submodul zu aktivieren (kann es am Installationsort liegen? sites/all/module oder /modules/).
Aber irgendwas läuft da überhaupt nicht so, wie es soll. Das Pathauto-Modul z.B. spinnt ebenso unregelmäßig herum. Manches Mal nach der Aktivierung erscheinen die Einstellungsoptionen für automatischen Alias-URLs, wie das sein soll– häufiger jedoch tauchen sie im Menü erst gar nicht auf.
Also. Wichtig: Alle eigenen und third party Themes und Module immer in sites/ installieren.
Alles, was in sites/all liegt ist für alle Sites dieser Installation verfügbar.
Alles, was in sites/defalt liegt nur für die Default-Site, in Deinem Fall der beste Ort.
Zwei Dinge sind an der Fehlermeldung erstauntlich.
1. Dass keine / zwischen Ordner stehen.
drupal610includesmenu.inc on line 449
drupal610/includes/menu.inc on line 449
2. Dass der Fehler in der menu.inc auftritt. user_access ist nämlich eine Kern-Funktion uns solle daher auch in der zum Kern-gehörigen menu.inc problemlos funktionieren… sehr merkwürdig.
Noch ein Versuch und nun (alles in sites/default/modules abgelegt) hat es zumindest ohne Fehlermeldungen geklappt. Allerdings ist das Einstellungsmenü für Pathauto wieder verschwunden, nachdem es zuvor noch aufgelistet war.
Aktivierte Module momentan:
Das kann aber nichts mit der von mir vergebenen Administrator-Rolle und ihren Berechtigungen zutun haben? Testeshalber allen Rollen alle path-/pathauto-Berechtigungen gegeben und trotzdem bleibt das Konfigurationsmenü verschwunden. Hmpf.
Was meinst Du denn mit „pathauto-konfigurations-menü“?
Die Ergänzung von pathauto zum Node-Creation-Form?
Oder admin/build/path/pathauto ?
Und: Auch wenn man das nicht soll: Ich bin auch immer als user 1 auf a&d unterwegs. Für’s Bloggen ist das die handlicheste Einstellung.
Sorry, meine admin/build/path/pathauto. Eigentlich sollte bei aktiviertem pathauto da ja ein Karteireiter „Automatische URL-Aliases“ (so in etwa) stehen. Der fehlt einfach (während sich lustigerweise zugleich der entsprechende Punkt im Node-Creation-Form befindet). Und versuche ich es per manueller Eingabe des Pfades, werde ich nur auf die normale URL-Alias Seite geworfen, auf der einzig „pathauto“ im Eingabefeld zum Filtern eingetragen ist. Damn.
Als welcher User bist Du denn unterwegs?
User 1, sollte also doch eigentlich zu sehen sein(?)
Ah, Übeltäter scheint das Association-Submodule zu sein, warum auch immer. Wenn ich das deaktiviere, habe ich den „Automated alias settings“-Reiter wieder dastehen.
Uuund: bei deaktiviertem Asscociation-Module taucht der Node-Type „Topic“ zugleich auf.
Uuups. Na da muss ich wohl nochmal ran. Sorry.
Wobei ich eh überlege das ganze Module neuzuschreiben. Das ist irgendwie nicht das, was ich mir vorgestellt habe … Aber die Datenbank würde ziemlich sicher so bleiben.
Oha, dabei wollte ich mit dem salzigen Finger [sic! & hehe] nicht noch stärker in der Wunde umherwühlen. Aber gut so, bohrender, entmaterialisierender fym-Antrieb, ha! Voran, voran, voran :]
Und endlich, endlich, endlich! erblicke ich in der Sidebar gewohntes Markup. Ich musst nebst block-[blockid].tpl.php einzig ein Block-Modul dafür schreiben… Lustig, dass das wohl noch die unkomplizierteste Vorgehensweise sein dürfte. Drupal ist knuffig.
Voran! Also wenn drum ging, nur handgeschriebenes Markup in einen Block zu bekommen, dann kannste ja auch einen Block über die GUI anlegen und dann über block-blockid.tpl.php themen:
admin/build/block/add
„Fymantrieb“ klingt überigens voll nach Warpantrieb 2.0 und fügt sich daher nahtlos in meine Prestartrekbegeisterung ein.
Weitere Links zum Thema „Themeing in Drupal besser machen“:
1. Rohdaten in Template-Dateien bekommen:
http://drupal.org/node/223430
2. Themeable Functions in Template-Dateien verwandeln
http://drupal.org/node/173880#convert-type
P.S.: Bin gespannt, wielange dein Wordpres/Hoster das noch mitmachen, dass wir hier Kommentar unter Kommentar zu posten.
Aua! Das hab ich davon, mein eigenes Theme aktiviert zu haben. Da fehlt dann natürlich in /build/blocks der (z.B. bei Garland vorhandene) Karteireiter „Block hinzufügen“. Danke für’s Hinweisen auf den Wald. Naja, auch gut. So weiß ich jetzt wenigstens schon in etwa, wie das mit dem Schreiben (einfacher) Module so funktioniert. Wieder was gelernt .]
Merci für die Links.
PS: Vorhin noch überlegt, wie witzig der Rattenschwanz hier ist, wenn man ihn von oben bis zu dieser Stelle verfolgt… Gut so, hat die comments.php auch mal ein bisschen was zu tun.
Und es wird nicht leichter, Drupal mein eigenes Markup aufzudrücken. Aktuell kämpfe ich mit dem Kommentarformular– und verliere. Verdammte divs, verdammte Doppelpunkte.
Mit dem Kommentarformular hast Du Dir aber auch gleich den weißen Wal unter den Drupal-Theming-Möglichkeiten rausgesucht.
Alle Formulare werden bei Drupal zentral durch die Forms-API gejagt.
http://api.drupal.org/api/group/forms/6
http://api.drupal.org/api/group/form_api/6
http://api.drupal.org/api/file/developer/topics/forms_api_reference.html/6
Das hat gleich mehrere Vorteile.
1. Man kann global das Markup bestimmteter HTML-Formular-elemente ändern.
2. Da die Formulare vor dem rendern als Array-Repräsentation durch das System geschleust werden, können sich andere Module über Hooks an die Formulare dranhängen, erweitern, reduzieren, umstrukturieren etc.
3. Die zentrale Verwaltung der Forms bietet Drupal Sicherheitsmöglichkeiten, die anderen System bei weitem fehlen.
Der „einfachste“ Weg ist – wiedereinmal – ein eigenes Modul zu schreiben und den hook_form_alter zu implementieren.
http://api.drupal.org/api/function/hook_form_alter/6
Darin kannst Du dann das Comment-Form-Array manipulieren „wie Du willst“. Insbesondere die Möglichkeit zu jedem Form-element einen beliebiges prefix und postfix zu deklarieren, bringt viel. So habe ich bswp. die „you may want to login“ Funktion integriert.
Grundsätzlich gilt: Ich hab mir ein Modul angelegt, das nur dazu da ist, mein Theme zu unterstützen. Das ist ganz praktisch. Würde ich eigentlich jedem Drupal-Betreiber raten.
Modul ist per Mail auf dem Weg zu Dir.
Hm, das Ganze hier hat mich doch sehr nachdenklich gestimmt … vielleicht sollte ich „Heimweh“ doch noch mal eine Chance geben.
*grübel’n’seufz*
Tja, ich hatte es zuvor schon über das Bäumchen-Array in $form versucht, allerdings sehe ich da u.a. nur Angaben zu den Beschriftungen/Namen der Inputfelder (Mail, Homepage, Name ect.), jedoch nichts, was die darauffolgenden Doppelpunkte festlegt bzw. womit man diese entfernen könnte. Ein Krrraaaammpppff.
Danke fürs Modul 🙂 Und ja, das ist wohl die bessere Vorgehensweise. Aber man könnte doch im Prinzip, abgesehen von den eigenen Blöcken, die restlichen dort stehenden Sachen auch ebenso in die template.php packen, wenn ich das bisher richtig verstanden habe(?)
Und wie oben geschrieben: Drupal bedeutet für mich im Moment erstarrte Flexibilität. Das ist in meinen Augen, selbst für ein Allroundsystem, schlicht Overkill und könnte so, so, soooo viel einfacher & vor allem intuitiver sein. Nja… was weiß ich schon.
Also (und da bin ich mir auch nicht so sicher) eigentlich kann man die Funktionen aus dem Modul „Ludig“ eben nicht in die templat.php packen. Das ist weil die hooks, die in dem Modul implementiert werden eben nur für Module gelten und nicht für themes. Da musste ich das erste mal auch tief schwer schlucken, als ich das eingesehen habe. Die template.php hingegen ist dazu da, themabale functions zu überschreiben. Hooks sind hooks und themeable function sind themeable functions.
Zur erstarrten Flexibilität: Die Erfahrung der Erstarrung kenne ich. Das läßt aber nach sobald man ein erfahrener Modul-Entwickler wird. Grundsätzlich ist in Deiner Kritik aber ein Kern Wahrheit. Drupal hat sich vorgenommen das „Linux für das Netz“ zu werden und der Vergleich ist im Guten wie im Schlechten richtig. Drupal zieht v.a. Leute an, die es aus Entwickler-Perspektive richig richtig machen wollen. Daher nimmt man in Drupal einen Abstraktionslayer mehr als weniger. Auch auf die Gefahr hin, dem System seine Leichtigkeit und Intuitivität zu nehmen. Es ist eine Wette auf die Zukunft: Wer den besten Kern hat, hat auf lange Sicht auch die besseren Module und das bessere Backend.
Also … die Diskussion verläuft hier ja auch ein bisschen einseitig, deswegen will ich mal auch noch ein paar gute Sachen von Drupal aufzählen, die es in vielen Teilen weit angenehmer machen als WordPress.
1. Die Blockverwaltung erlaubt eine sehr einfach und angenehme Gestaltung der Seite.
2. Modul-Entwicklung ist ziemlich einfach und v.a. sauber.
3. Neue Teil-URLs (was ja in der Regel ein wichtiger BEstandteil von neuen Modulen ist) lassen sich sehr einfach und schön registrieren.
4. RSS-Aggregator schon integriert
5. Cron-Job-Hooks für regelmäßig Tasks
6. Richtige Suchmaschine mit eigenem konfigurierbaren Index.
7. Beliebig viele Content-Typen.
Das macht schonmal vieles deutlich einfacher.
Mein „Gemeckere“ ist ja letztlich auch nur in erster Linie das: Momentaufnahme. Auch wenn ich mir bisweilen die Haare raufe, ob dieser verkomplizierten Modulierung, merke ich zugleich schon seit den ersten Gehversuchen: das System ist mächtiger, viiiel mächtiger. (Und die von dir aufgezählten Sachen gehören zweifellos dazu. Würde ich das nicht merken, würde ich mich schließlich nicht mit der Lernkurve quälen ;)) Und das ist auch gut so, bedingt aber wohl zwangsläufig, dass alles, was das offene Inhaltssystem betrifft, eben damit einhergehend starrer, modularer vom Kern kommt und eine Lernkurve nach sich zieht, welche mit „steil“ noch höflich umschrieben wäre. Aber kommt Zeit, kommt (hoffentlich) Wissen…
Und ja, das alles ist vielleicht nötig, aber es gäbe bestimmt Mittel und Wege, das Ganze ein wenig zu entzerren, ein wenig zugänglicher zu gestalten. Vielleicht ist in der Hinsicht die 7’er Version ja besser, nach allem was ich von dir dazu gelesen habe. Sicher, ich erwarte von einem System wie Drupal bestimmt keine Hau-drauf-hau-rein-Attitüde, kein krudes und ungenormtes Reinknüppeln von (z.B. Theming-)Code, wie das beispielsweise bei WP der Fall ist. Aber wäre es nicht viel praktischer (für den Anfänger, für denjenigen, der kein völlig unbeschriebenes Blatt ist, der weiß was er will), da einen Abstraktionslayer zu haben, welcher zuerst und einzig ausreichend ist, all die „simplen“ Dinge (Anpassungen, Individualisierungen ect.) als primäre Anlaufstelle zu verrichten? Sollte nicht das auch eine Stärke eines flexiblen Systems sein – abgestuft nach Erfahrung des Nutzers eine unkomplizierte Anlaufstelle zur Verfügung zu stellen? Hm.
„Sollte nicht das auch eine Stärke eines flexiblen Systems sein – abgestuft nach Erfahrung des Nutzers eine unkomplizierte Anlaufstelle zur Verfügung zu stellen?“ … das werde ich mal in meinem Hirn bewegen.
Bis dahin gibt es auch noch spannende Entwicklung auf der Seite des Gartens auf dem Du noch meine einem Bein stehst: http://justintadlock.com/archives/2009/04/30/tag-descriptions-in-wordpress-28
Gar keine üble Entwicklung. Mit ein bisschen Gefummel könnte man die Beschreibungen wohl durchaus gut für die semantischen Relationen der Tags untereinander benutzen. Hm. Damit spiele ich bei Gelegenheit vielleicht auch nochmal rum.
Achso, apropos nachgestellte Doppelpunkte im Kommentarformular (bei den label-Inhalten): http://drupal.org/node/293908
Da trifft genau das Gleiche zu, was mich bei WordPress letztens genervt hat. Wieso, wieso, wieso ist sowas hardcoded? Bzw. wenn man schon die Formulare durch ein Array jagt (was ich inzwischen und mit ein bisschen Gewöhnung gar nicht mal sooo schlecht finde, zugegeben)- warum hardcoded man sowas? Warum derlei Dinge nicht schlicht ebenso ins Array packen? Stattdessen muss man noch eine lange Funktion in die template.php packen. Tsts.
Nunja, jetzt jedenfalls keine Doppelpunkte mehr. Fehlt nur noch das gesamte restliche Markup des Kommentarformulars 😉
Für die Relationen würde ich die Beschreibungen nicht nutzen. Aber jetzt brauch man dann kein Post/Pages mehr, die Repräsentaten der Tags/Metadaten sind. Man kann die sw_defines Relation wegwerfen …
Schon wieder was im spam gelandet? Da war nichtmal ein Link drin …
Hab’s wieder rausgeholt (warum auch immer es drin gelandet ist).
[WP-Umfunktionierer]Man könnte aber doch– in die Beschreibung ein Format a la „xy … is a … xy“ und ein bisschen am Template geschraubt… Hach…[/WP-Umfunktionierer] :]
Ich hab gerade – um mal zu schauen, ob ich nicht vielleicht zuunrecht so an Drupal festhalte – mal WP 2.7.1 runtergeladen und mich mal im Code umgeschaut. Das geht es allerings immer noch so skuril zu wie eh und je.
Nun, nachdem ich es nach unzähligen Versuchen gerade geschafft habe, Drupal mein Markup für das Kommentarformular beizubringen und dafür nur drei Funktionen schreiben musste (leerraum_theme, leertraum_form_alter und phptemplate_form_element) würde ich selbst das wordpres/sche (gnihi) Code-Chaos nicht mehr wirklich als sooooo „skurril“ bezeichnen. In dem kruden Mischmasch aus Code und Eingeweiden hätte ich wenigstens nur einen Bruchbruchbruchteil an Zeit dafür benötigt 😉
Dazu auch gleich grundlinig, har! Immerhin:
Achso, um die Balance zu halten: Erstaunlich, wie es Drupal schafft, validen Code zu liefern, selbst wenn man mehr oder weniger stark am Anpassen ist. Bei WP war’s üblich, dass ich entsprechend den dortigen Codingrichtlinien etwas angepasst habe und anschließend trotzdem mit (X)HTML-Validator bewaffnet auf die Jagd in den Templatedateien gehen musste. Pustekuchen, bei Drupal bisher vollkommen unnötig. Wenn falsches Markup auftaucht, dann höchstens durch die Nutzereingaben in den Inhalten. Sehr schön.
Allerdings merke ich jetzt auch, dass mich WordPress mit seiner wpautop-Funktion hat ziemlich faul werden lassen, was das eigene Markup von Einträgen angeht. Übertrage ich jetzt händisch WP-Posts in Drupal, baut mir dieses (je nach verwendetem Eingabeformat) entweder überall Zeilenumbrüche rein, die da nicht hingehören oder belässt den ungemarkupten (heisa…) Inhalt so, wie er (ohne wpautop-function) ist. Beides keine ideale Grundlage für eine Datenmigration.
Hm. Ob man die WP-Inhalte vor einem Export durch die wpautop-function laufen lassen und erst dann exportieren kann? Überhaupt Datenmigration. Kopfschmerzen. Jetzt schon.
Hm. Die ersten Erfolge sehen ja schon schön aus. Wenn ich noch was helfen kann … ich lese ja hier mit. 😉
Was Auto-P angeht: Das ist lustig. Über der Drupal Funktion _filter_autop() steht Folgendes.
/**
* Convert line breaks into and in an intelligent fashion.
* Based on: http://photomatt.net/scripts/autop
*/
Ich hatte damit eigentlich nicht viel Ärger. Und falls Du den WPXML-Export als Grundlage für den Import nimmst … (Ich stell Dir auch Gerne mein Modul zur Verfügung) … der wendet alle Filter einschl autop vorher an.
Nja, der Import allgemein wäre halt so eine Sache. Das Modul wäre da schon eine Hilfe, denke ich. Zumal ich momentan noch keinen blaßen Schimmer habe, wie ich z.B. die Metadaten sauber importieren kann. Und das Export-XML von WordPress wäre auch meine Wahl, nur hat sich da letztens das „WordPress Import“-Modul schon an den ~3MB verschluckt und den Dienst verweigert. Hm. Hmm.
Ach ja: Weil ich da noch nicht ganz durchsteige, ne Chance, dass du mal kurz skizzierst, wie du Terms, Topics und Associations benutzt? Also wie das alles zusammenläuft? („Public Identifier“ in der Topic-Erstellung z.B. ect)
Ach, und ich mag noch gar nicht daran denken, was da noch alles auf mich zukommt. delicious-Importer, Bildwand, FavPosts (aka Eintragsliebe) und und und… muss ja auch alles noch irgendwie übertragen werden. ‚Dammt! Das hat man von der DIY-Einstellung 😉
Das einfachste zuerst: Delicious Importer ist schon fertig. Alle Lesezeichen bei Konnexus kommen über den Weg. Mail mit dem Modul ist unterwegs.
Jetzt das etwas aufwändigere. Ich hab ja glück, dass mein Webspace sehr ordentlich ausgestattet ist und konnte so den ganzen Import online machen. Ich würde spontan empfehlen, über mein Modul zu gehen, weil das Meta-Daten so importiert, wie Du das am haben möchtest. Das gute an meinem Modul ist, dass es immer nur eine Node importiert. Und dann im HTML-Output ein Javascript-Schnipse ausliefert mit einem window.location= auf die Import-URL des Nächsten Artikels. Wenn Dein Webspace das XML also zumindest als SimpleXML einlesen kann, dann sollte das machbar sein.
Die SW-Architektur bei Konnexus und mir sieht wie folgt aus.
Als erstes Taggen wir mal unsere „normalen“ Nodes mit Tags, die alle in einem Vokabular liegen. Meines heißt „Lexikon“. Ich hab beim Import alle meta_values in ein und dasselbe Vokabular geworfen, ungeachtet der meta_keys.
Dann gibt es Nodes vom Typ Topic. Diese definieren die Terms im Tags-Vokabular. Das Semantic-Weblog Plugin rendert dieses Nodes dann auf die Term-Seiten rein.
Dann gibt es einen Node-Type der Association-Type heißt, mit dem sich für die Installation die nötigen Relationstypen anlegen lassen. Ich hab leider noch nicht angefangen, Relationstypen anzulegen. Grunsätzlich kämen da aber wohl die üblichen Verdächtigen.
http://anmutunddemut.de/2007/12/20/semantic-weblog-semantische-relationen
Wie die Relationen angelegt werden, wird gerade von mir umgebaut. Ursprünglich, konnte man nur an Topic Nodes Relationen zu anderen Topic Nodes anlegen. Jetzt soll es so werden, dass man im Node-Creation-Form aller Node-Typen Relationen zwischen Topics anlegen kann.
Die Relationen werden dann wiederum bei den einzelnen Nodes mitgeladen.
Mail mit dem Import Modul ist ebenfalls unterwegs. Ich weiß aber nicht ob es tadellos funktioniert. Schick mir Doch mal deine WPXML-Export, dann schau ich schon mal und passe das ggf. an.
Gut, SimpleXML sollte ich hier zur Verfügung haben, wenn mich phpinfo() nicht anschwindelt.
Mail ist abgeschickt.
@Topic Nodes- Vorhin hatte ich es zuerst folgendermaßen versucht: Ich habe einen Term (Gesellschaft), habe einen Topic-Node erstellt (Titel auch „Gesellschaft“. Hm.), blah-Text als Inhalt geschrieben und eben die Termid „Gesellschaft“ im Creationform ausgewählt. Wenn ich jetzt den Term-Node aufrufe, erscheint oben lediglich der Hinweis, dass Node „[Link auf die Topic-Node]“ diesen Term definiert, nicht aber die Beschreibung ansich. Wenn ich mir als Beispiel dein „On my way to Heimweh“ anschaue: auf der Term-Seite sollte dann doch eigentlich der Inhalt des entsprechenden Topic-Nodes erscheinen, oder nicht?
Habe ich da was „falsch“ gedacht oder muss für die Ausgabe z.B. das taxonomy-Template modifiziert werden?
Ne. Ist super richtig gedacht. Ich hab auf a&d derzeit noch kein einzige Topic. Deswegen verwende ich noch für ein halbes Dutzend Terms die Term-Description. Die ist im Drupal-Kern mit drin, wird aber standardmäßig nicht ausgegeben. Frag mich nicht warum. Und Indeed … derzeit steht da nur „… is defined by …“. Vorhanden ist an der Stelle aber schon die ganze Topic-Node. Das müsse ich mal alles umbauen, auf Templates und Preprocess-Funktionen.
Ich bin derzeit aber mit der ganzen Usability des Semantic Weblog unzufrieden und hab schon ein paar Chats mit Konnexus deswegen gehabt. Ich bin mir da unsicher, was der geschickteste Weg des Vorgehens ist … für Anregungen und Hinweise bin ich dankbar.
Durch das Import-Modul blicke ich übrigens momentan noch nicht so wirklich durch. Und ich weiß erst recht nicht, warum es momentan nicht funktioniert.
Was Usability angeht, kann ich vorerst nicht viel zu sagen (habe es ja schließlich noch nicht wirklich benutzt). Allerdings ist das Ganze bei Drupal dem ersten Eindruck nach im Gegensatz zu WP angenehmer zu nutzen. Allein schon, weil Drupal beim Freetagging diese liebliche durch Kommata getrennte Liste anbietet mit Vervollständigungsfunktion. Wenn ich da an das ganze Dropdown-Gedöns in WP denke…
Im Allgemeinen wäre es schon praktischer, könnte man sofort im „normalen“ node creation form sozusagen on-the-fly Topics erstellen, e.g. Eintrag schreiben, Verschlagworten und dabei gleich für ein oder mehrere Terms entsprechende Definitionen tippen, welche dann beim Speichern der normalen Node zugleich erstellt werden. Umgekehrt könnten die Topic-Node-Inhalte (herje) im edit form eines Nodes angezeigt (+ editierbar) werden.
Hinsichtlich Usability würde ich das Ganze eben versuchen so zu gestalten, dass „alles unter einem Dach“ ist, d.h. der Nutzer also im Idealfall und im normalen „Arbeitsablauf“ niemals separat (und damit ja im Prinzip vom Schreib-, Erstellungs-, Gedankenablauf abgekapselt) node/add/topic aufrufen muss.
Hast du Zugriff auf admin/settings/feedimporter? Das ist normalerweise von /admin aus verlinkt. Dort kannst Du URLs, UIDs und das Vocabulary angeben, in das die Tags importiert werden soll. Der Importer läuft dann mit jedem Cronjob. Einfach /cron.php aufrufen, losgehts.
Erfolgreichen Cron-Läufe und Feedimports werden unter admin/reports/dblog geloggt.
Was die Semantic-Weblog Funktionen angeht: Yep. Genau dahin will ich auch schon. Zum einen sollen Topics automatisch erstellt werden wenn neue Terms erstellt werden. Zum anderen werden Assoziationen über eine dreistufiges Type-Ahead-Feld erstellt, so ähnlich, wie das Tagging jetzt. Nur das beim ersten „Tag“ halt nur Topics vorgeschlagen werden, beim zweiten nur Assoziations-Typen und beim dritten wieder Topics. Funz auch schon lokal.
Das Bearbeiten von Topics aus anderen Nodes heraus könnte allerdings etwas aufwändiger werden. Mal schaun.
Ne, ich meinte den Import der Postings aus der WPXML. Mit dem Feedimporter hab ich ganz andere Problemchen (der Import der Linkitems läuft über irgendeine Mailfunction(?), die Links sind bisweilen zerschossen ect.). Den Feedimport habe ich erstmal nach hinten gestellt, bis der WP-Import läuft und ich meine Blogdaten lokal habe.
Soweit ich das nachvollziehen kann, wird das XML nicht richtig geparst bzw. sind dann in $allposts bei weitem nicht alle Daten enthalten (zwar alle Posts, soweit ich das sehe, aber eben nicht alle dazugehörigen Post-Daten). Bsp:
[576]=>
object(SimpleXMLElement)#583 (6) {
["title"]=>
string(48) "Wie die kleinen mit[...]"
["link"]=>
string(81) "http://blog.fymmie.de/13[...]"
["pubDate"]=>
string(31) "Sun, 13 Jan 2008 16:11:38 +0000"
["category"]=>
array(6) {
[0]=>
string(11) "Außendinge"
[1]=>
string(11) "Außendinge"
[2]=>
string(6) "Medien"
[3]=>
string(6) "Medien"
[4]=>
string(12) "Politdingsda"
[5]=>
string(12) "Politdingsda"
}
["guid"]=>
string(94) "http://blog.fymmie.de/13/[...]"
["description"]=>
object(SimpleXMLElement)#1624 (0) {
}
}
Da ist nichts vom (z.B.) Tag „wp:status“ im Array zu sehen (vom post content ganz abgesehen), weshalb wohl auch wordpressimport_import_post() nichts tut bzw. die Import-Schleife endlos durchläuft, ohne Nodes zu erstellen.
Hell, I remeber. Das liegt glaube ich daran, dass der ganze Spaß in CDATA-Section drin ist und obendrein alles voll ist mit Namespaces. Bäh, bäh. Ich glaube ich hatte den WPXML deutlich „gesäubert“. Ich setz mich jetzt mal dran…
nachdem ich mein konnexus.net etwas umgebaut hab, kann ich jez auch erklären, wie ich es mit den topics/terms geregelt hab. ihr habt ja beide zugänge zu meinem system, dann kann ich darauf verweisen.
ich hab ganz dreist das modul von ben modifiziert (im modul selbst). natürlich macht man sowas nicht, und den ärger hab ich jetzt, nachdem ben_ ne neue version des modul gemacht hat.
trotzdem hat es mir bis jetzt gute dienste geleistet, und zwar so:
jeder term ist erstmal nur ein term, ohne dazugehörigen topic. die meisten terms kommen bei mir durch den import aus delicious, und für die meisten ist eine topic-definition uninteressant, weil zu viel arbeit.
ein topic wird für der term angelegt, sobald man auf den term klickt, also zur liste aller nodes zu dem term gelangt. der topic kriegt automatisch den title des terms.
an dieser stelle (am title des terms) ist für den admin ein button platziert, um den topic zu editieren. obwohl man sich auf der term-page befindet, kommt man dann zur topic-edit-seite und kann dort den title ändern, definitions-text oder assoziationen anlegen. speichern führt aber wiederum zur term-page.
das heißt: die topic-einzelseite wird bei mir überhaupt nicht „im ansichts-modus“ angezeigt. der zugang ist ausschließlich durch die terms. dafür werden aber die daten des topics dauernd genutzt:
– die definition auf der term-page
– die definition beim lexikon (http://konnexus.net/lexicon)
– die definition bei einer artikel-einzelansicht unter den kommentaren (dort werden alle topics angezeigt, mit denen der artikel vertagged ist)
– die assoziationen bei der term-page
– die assoziationen bei den topics unter der artikel-seite
– der title überall, wo auch die definition auftaucht.
– der title überall statt des term-namens (beispiel: auch wenn eine seite mit dem term ‚konstantinweiss‘ vertaggt wurde, erscheint in der ansicht der topic-name ‚Konstantin Weiss‘.
beispielseite term-page: http://konnexus.net/fym
beispielseite artikel-einzelseite mit topics: http://konnexus.net/notes/fym-drupalisiert-sich
Bevor ich zum Konnexus SWlog Ausführungen kommen, erst erste Einsichten aus dem WP-Import. VOR dem einspielen folgende Suchen-Ersetzen durch führen
„<wp:“ ersetzen durch „<“
„</wp“ ersetzen durch „<“
„:encoded>“ ersetzen durch „>“
„& “ ersetzen durch „&“
Danach muss man dann auch noch das WP-Import Modul anpassen. Nichtzuletzt weil sich die XML-Struktur seit meinem Import verändert hat. Diese beiden Zeilen:
$node[‚body‘] = „“.ereg_replace(„„, „“, ereg_replace(„„, „“, $xml->encoded));
$node[‚teaser‘] = “;
zu diesen machen
$node[‚body‘] = „“.ereg_replace(„„, „“, ereg_replace(„„, „“, $xml->content));
$node[‚teaser‘] = “.$xml->excerpt;
Nachtrag: Hmm … das funktioniert nur so bedingt, hier XML-Kram reinzuschreiben. hähä… ich schicke Dir nachher mal die funktionierende Datei.
Wichtig auch dabei: Path-auto ausschalten…
Mail unterwegs. Den WP-Export schick ich jetzt auch noch hinterher. CDATA kannst drinnlassen scheinbar.
Die Teile, die ggf noch einer Anpassung bedürfen habe ich mit !!! gekennzeichnet. Außerdem habe ich die alten DB Funktionen rausgeworfen. Ist etwas übersichtlicher.
admin/wordpressimport/import/1
sollte die erste Datei importieren. Wenn das alles so funzt, wie Du magst, einfach die Zeile nach
// !!! Activate this line only, if the import works!
einkommentieren … 😉
der wp-import steht mir ja auch noch (bald) bevor …
eine ganz andere frage: wie kann ich drupal beibringen, dass nodes, denen ein bestimmter term zugeordnet ist, nur von bestimmten rollen gesehen werden?
@Konnexus: Klitzekleines Modul. Über die den hook_nodeapi, ist das kein großer Akt.
Da saß ich doch gerade wie gebannt vor den an mir vorbeirauschenden Texten. Den eigenen Texten. Unbeweglich saß ich da, starrte gebannt auf den Textfluß und zugleich an ihm vorbei. Das an einem vorbeiziehende Leben in Bildern.
Irgendwann war der Fluß im nun ruhigen, offenen Meer angekommen. Und ich weiß nicht wie lange es noch gedauert hat, bis ich das realisierte.
Erstaunlich. Die Dinge, die uns gefangennehmen…
[Had to. Mit dem nächsten Kommentar gibt es wieder nervige Fragen meinerseits, keine Sorge.]
Erstmal: Vielen Dank für die Mühe, ben_ 🙂
Ich bin auch aktuell dabei, mir das Ganze meinen Anforderungen entsprechend anzupassen. Ein paar Fragen hätte ich:
1. Was hat es bei Drupal mit dem Anrisstext auf sich? Es gibt doch schon in der DB neben einem body- ein teaser-Feld. Setze ich im node creation form einen Anrisstext, steht dieser im teaser-Feld der DB, während sich im body-Feld zugleich der gesamte Text einschließlich teaser-Inhalt und an entsprechender Stelle ein <!–break–>-Tag befindet.
Was hat es damit auf sich? WP kennt ja nur die mittels Tags „definierten“ Teaser. Welche der beiden Varianten sollte man bevorzugen (einfacher Teaser vom body getrennt oder mittels break-Tag)? Dadurch entscheidet sich ja, was ich mit den <!–more–>-Tags der WordPress-Posts machen muss.
2. Die Teaserbild-Information. Wohin gehen die? Was ist da das drupal’sche Äquivalent zu den postmeta Daten? Wie speichere ich diese/frage sie ab? Benutze ich dafür das CCK oder kriegt das Drupal von Haus aus irgendwie hin?
Hss… also das mit dem Anrisstext funktioniert bei Drupal in der Tat so, wie es aussieht. Drupal verwaltet „eigentlich“ keinen eigenen Anrisstext. Wenn Du das „break“ nicht von Hand setzt wird BEIM SPEICHERN der Node eine Anzahl von Zeichen vorne vom Body abgetrennt (natürlich möglichst nach Ab/Sätze), die Du hier festlegen kannst: admin/content/node-settings.
Wenn Du das von Hand setzt wird eben dieser Teil genommen. In der Vollansicht sieht man dann den ganzen Text.
Einen unabhängigen Anrisstext, der nur in der Teaseransicht und nicht in der Vollansicht des Artikels zu sehen ist, kennt der Drupalkern nicht. In der Tat würde sich dafür entweder ein eigenes kleines Modul oder CCK anbieten.
Wenn Du mein Teaserimage-Modul vorher aktivierst. Dann werden die Teaserimages auch gleich richtig gespeichert. Das übernimmt der die Kernfunktion node_save, wenn man ihr eine korrekte Node übergibt, dadruch, dass sie intern dann die entsprechenden Hooks in den Modulen aufruft.
Grundsätzlich gibt es in Drupal kein generisches Meta-Datensystem wie in WordPress. The Drupal Way to do it, wäre CCK, das ja in der Version 7 auch in den Kern wandert. Ich habe aber auch schon ein paar mal überlegt da vielleicht mal ein bisschen ein verbessertes Modul zu zuschreiben …
… aaaallerdings hab ich am Wochenende rausgefunden, dass in D7 der ganzen DB-Layer neugemacht wird und ich alle Module anpacken darf, die SQL-Queries enthalten. Das bremst meine Begeisterung, neue Module zu schreiben doch arg.
Ach und: Darf ich den vorherigen Kommentar mit den vorbeirauschenden Texten so deuten, dass der Import zumindest schonmal rudimentär läuft?
Schon wieder ein Kommentar gefressen …
Momentan ist eingestellt, dass die gekürzte Fassung unbegrenzt viele Zeichen haben darf. Urgs. Bedeutet im Endeffekt ja, dass Posts doppelt gespeichert werden. Wenn ich jetzt ein Verhalten wie bei WP haben will (die Postings werden auf der Frontseite vollständig angezeigt, und nur bei vorhandenem more-Tag geteasert) und Drupal grundsätzlich einen Teaser speichert… Hm. Hm. Mal basteln und schauen.
Das Teaserimage-Modul würde ich aktivieren, wenn ich es hätte 😉
Hehe, da habe ich mir ja genau den richtigen Moment ausgesucht, auf Drupal umzusteigen, was? Wenigstens habe ich durch die 6.11’er schon mal einen Upgrade-Vorgang mitmachen dürfen.
Und jap, der Import funktioniert so, wie er soll. Dankeschön. Neben den üblichen Anpassungen (was da teilweise in postmeta von irgendwelchen Plugins reingeschrieben worden ist, nene) musste ich einzig noch hinzufügen, dass die importieren Posts auf der Startseite erscheinen und welches Eingabeformat sie besitzen.
Also naja … ich würde das ja eh über das Template steuern. Also mach ich ja auch. Das ist nämlich ganz schön. Auch für das Rendering der Startseite und der Term-Übersichtseiten und bspw. der Archiv-Seiten wird die Node.tpl.php verwendet. Da geht echt einiges. Was ich machen:
1. Ein Template für die Vollansicht und eines für die Teaseransicht.
2. Eine eigene Funktion für das erstellen der Teasertexte basteln. Die basiert bei mir schon auf dem Drupal eigenen Mechanismus, greifen mitunter aber ein.
3. Ggf. noch nach Node-Typ differenzieren.
Vorschau, was in D7 kommte im Bereich Theming:
http://drupal.org/community-initiatives/drupal-core/theming
hier gefunden:
http://www.lullabot.com/drupal-voices/drupal-voices-25-john-albin-theming-improvements-drupal-7
Wie ich das aber in der node.tpl.php hinbekommen soll, blicke ich momentan noch nicht wirklich. Wenn ich zB. das teaser-Feld leer lasse (Ich dachte für die eigene Funktion der Teasererstellung – wie ich das hinbekomme weiß ich noch nicht – daran „teaser“-Feld standardmäßig leerzulassen und nur bei Verwendung eines breaks entsprechend zu füllen): Ich habe dann $content, den Status $teaser und sehe so keine Möglichkeit Drupal zu sagen, dass eben nicht standardmäßig Teaser angezeigt werden. Selbst wenn ich ganz brachial über $node versuche auf den body-Text zuzugreifen, bringt das auch nichts, weil jener dort nicht enthalten zu sein scheint.
Ah. Ups. Hähä. Da läuft bei mir schon wieder Theme-Entwicklung und Modul-Entwicklung durcheinander. Das kann man latürnich wieder nur über einen Modul-Hook lösen. Bei mir sieht das im Modul „Ludwig“ so aus:
function ludwig_nodeapi($node, $op, $arg = 0){
switch ($op) {
case „view“:
//dprint_r($node);
if($node->content[„body“][„#value“]==““){
$node->content[„body“][„#value“] = substr(nl2br(strip_tags($node->body, „“)), 0, variable_get(‚teaser_length‘, 600));
return $node;
}
break;
case „rss item“:
$node->body = ereg_replace(„<!–break–>“, “ „, $node->body);
break;
}
}
Ach, dankeschön für den Richtungsweiser.
Wow. „Wenn $node->content[‚body‘][‚#value‘] leer ist, dann belege es mit $node->body“ und schwups, werden sofort die vollen Texte angezeigt. Während es sonst im Template selbst kein $node->body gibt bzw. jenes nicht belegt ist. Soso. Auf die Vorgehensweise kann man ja von selbst kommen…
Ich glaube, mein Hirn krampft gerade 😉
Und weil mein Verstand es im Moment noch nicht wirklich begreifen mag (die conditional tags von WP sind wohl mehrheitlich geistig noch vorhanden):
Wo setze ich am besten zur Unterscheidung der einzelnen Bereiche an? Beispielsweise will ich eine andere Node-Ausgabe auf Taxonomy-Seiten haben (vgl. die Entitätsseiten hier). Eine page-taxonomy.tpl.php habe ich erstellt, um dort das umschließende Markup zu setzen (div Bereich mit eigener ID ect.). Die Nodes auf dieser Taxonomy-Seite selbst, wie modifiziert man da am besten?
Derzeit würde ich es im node.tpl.php über arg() lösen (also je nachdem, ob „/taxonomy/…“ gegeben ist, innerhalb der node.tpl mittels arg() und switch ein anderes Markup benutzen). Wäre das bei Drupal ok oder gäbe es da ein „besseres“ Vorgehen?
Für das Problem der unterschiedlichen Teaser auf unterschiedlichen Seitentypen kenn ich in der Tat auch keine bessere Lösung als in node.tpl.php mit arg() zu switchen.
Man kann in Modulen auch eigene Template-Vorschläge machen. Aber ich hab keine Ahnung, wie das geht und ich halte das auch nicht für gut.
arg() ist Dein Freund!
Ich hab in meinem letzten Theme sogar mit arg() haufenweise CSS-Klassen ins Haupt-Div-Tag gestopft:
<div id=“arena“ class=“grid-widthfull arg0-<?=arg(0)?> arg1-<?=arg(1)?> arg2-<?=arg(2)?> arg01-<?=arg(0)?>-<?=arg(1)?>“>
Damit läßt sich verblüffend viel machen.
Nur damit ich mich nicht an der komplett falschen Stelle bemühe: Welchen Hook verwendest du für die eigene Funktion zur Teasererstellung? Ich versuche es momentan über _nodeapi und „insert“, doch trotz „$node->teaser = „“;“ speichert Drupal einen automatisch generierten Teaser ab.
Oh. Ne. Insert ist ja nur beim Speichern. „nodeapi“ ist schon der richtig Hook. Ich geh da stumpf über $op = „view“. Alternativ ginge auch $op = „load“. Ich hatte ja vergessen beim Import die Teaser zu setzen. Jetzt sind sie alle leer, hähä. Deswegen muss ich über view oder load.
(Oha, ich meinte mit „insert“ schon den $op-Wert in hook_nodeapi(). Erst jetzt gesehen, dass es ja auch ein hook_insert() gibt. Die Funktion meinte ich nicht)
Im Import-Modul selbst habe ich das schon so modifiziert. Also dass nur bei vorhandenem „more“-Tag das teaser-Feld in der DB befüllt wird und ansonsten leer bleibt.
Unter $op = „view“ habe ich angegeben (siehe einer meiner letzten Kommentare), dass bei Ansicht der Startseite & leerem Teaser der volle text body angezeigt wird.
Jetzt geht es mir eben um die Node-Erstellung, da ist „insert“ doch der richtige Einstieg, oder nicht?
Nur wenn ich ein break verwende, soll das teaser-Feld in der DB befüllt werden. Ansonsten soll es leer bleiben, d.h. kein automatischer Teaser (mit dem in den Optionen anzugebenden Zeichenlimit) erstellt werden. (Damit das eben mit den per „view“ modifizierten Sachen im Einklang ist)
Doch trotz $node->teaser = „“; wird einer erstellt. Hm.
Ah, das $op-Zauberwort lautet „presave“:
„[…] you can’t modify the content of the node during insert and update operations […]„
Also ja. Zu dem Zweck ist der Insert-Operator eigentlich das Mittel der Wahl. Ich bin mir jetzt aber nicht sicher, ob das eine kluge Idee ist, den Teaser einfach leer zu speichern. Wie gesagt, ich würde da eher nach „When you in Rome …“ handeln und das Speichern so machen, wie es Drupal per Default macht und dann beim Auslesen lieber filtern. Einfach schauen, ob beim „load“ das break mit im Body steht.
@presave: Schau an! Da weißt Du schon mehr über Drupal als ich.
Hm. Hm. Mir erscheint das nur sehr redundant. Die paar Zeichen (mindestens ja 200) sind für sich genommen nicht viel, aber da läppert sich bei ~1000 Posts schon was zusammen. Und da das hier nur shared webspace ist, würde ich (prinzipiell unnötigen) Zusatzballast gerne aus dem Weg gehen, zumal Drupal im Vgl. zu WordPress schon ein wenig „gewichtiger“ scheint.
Ist der Teaser denn soooo wichtig für einen Großteil der Drupalfunktionen?
Klar. Das kann ich nachvollziehen. Und ich glaub, der Teaser ist auch nicht sooo wichtig, zumal Du dich ja eh schon eingehängt hast. Aaaber auf der anderen Seite. Meine 7093 Nodes machen mal mit 6.4 MB mal gerade 10% des Speicherumfangs meiner DrupalDB aus. Was Deinem Andruck vom größeren Gewicht bestärkt. Ich habe derzeit 70 Tabellen in meiner Installation. Das ist der „Preis“ der größeren Mächtigkeit und der saubereren Implementierung. Datenbank-Normalisierung, halt.
Heisa, eine ~64 MB große Datenbank? Hehe, und schon erscheint die damalige Kritik am eingeführten Revision-System in WordPress („zuviel Datenballast, zu speicherhungrig“ ect.) in neuem Licht.
Aber das ist ok so. Ich hatte ohnehin vor, den Umzug für ein „Verschlichter dich“ zu benutzen und ein paar Sachen rauszuwerfen. Lustig, dass das aufgrund eines vergleichsweisen schwereren Systems passiert.
Übrigens @Import-Modul: Eine Sache ist mir erst jetzt aufgefallen. Die Reihenfolge der Kommentare ist bei einigen durcheinander geraten (bei der Drupaleinstellung „Chronologische Liste – vollständig“ und „Ältere Kommentare zuerst“, wie es hier eben auch der Fall ist). Soweit ich das sehe, stimmen die Zeitangaben im WPXML, daran sollte es also nicht liegen. Eine weitere Vermutung war das in WP eingeführte (in der 2.5 oder 2.7’er, keine Ahnung) threaded commenting. Aber auch das scheint es nicht zu sein. Momentan bin ich ratlos.
Der Kommentarbug ist in der Tat merkwürdig. Welche Datumse haben die Kommentare denn nach dem Import in der Drupal-DB?
Die sich in der DB befindlichen Timestamps sind identisch. Stimmen also. Auch wenn ich in phpmyadmin nach timestamp aufsteigend sortiere, sind sie in der richtigen Reihenfolge. In der Kommentarausgabe unter dem Post sortiert sie Drupal (obwohl Drupal selbst die richtigen Datumsangaben ausgibt) munter durcheinander.
Hm. Scheint an den cid’s zu liegen. Die sind, sofern sie aufsteigend sein sollen, falsch vergeben. Und ich nehme an, Drupal sortiert bei der Ausgabe der Kommentare allein danach.
Hm. Shit. Dann mach doch mal im wordpressimportmodul, aus dieser Zeile
$coms[„comments“][] = $new;
jene Zeile
$coms[„comments“][$new[„timestamp“]] = $new;
Vielleicht klappt das.
Hm, ne. Das war’s nicht.
Ist es denn so, dass die Reihenfolge der CIDs nicht der der Timestamps entspricht?
Vielleicht noch ein asort($coms); zwischen die beiden foreachschleifen in der wordpressimport_import_post() ?
Jap. Ich hab mal nen Screenshot gemacht. Die Kommentare dieses Eintrags, cid aufsteigend sortiert: drupal_cidsort.gif
Du siehst, dein erster Kommentar steht beispielsweise erst an fünfter Stelle.
Hm. Ja, irgendwie muss da noch sortiert werden. Gerade nachgeschaut und im WPXML stehen die Kommentare in genau der gleichen Reihenfolge (warum auch immer, liebes WordPress). Mein Rumprobieren war bisher allerdings noch nicht von Erfolg gekrönt.
Dashier zwischen die beiden Foreaches zeitigt glaube ich das gewünschte Ergebnis.
ksort($coms[„comments“]);
Memo an mich: Erstens schauen, ob man auch die richtig Sort-funktion benutzt. Danach schauen, ob man auch das richtige Array sortiert.
Und dabei ist mir eine Zeile ins Augegefallen, die Du vielleicht anpassen solltest:
if($new[„name“]==“ben_“){
$new[„uid“] = ‚1‘;
}
*hähä*
Nope @ ksort. Aaaaaber ich hab es inzwischen sortiert bekommen:
uasort($coms["comments"], 'wordpressimport_sortperid');
Einfach vorher
$new["comment_id"] = $comment->comment_id;
hinzugefügt und dann mittels Callback Function den comment_id Wert sortieren. Wenigstens vergibt da WordPress fortlaufende IDs, wenn es schon nicht in der WPXML sortiert.
Der zusätzliche „comment_id“-Wert wird hoffentlich durchs anschließende node_save verworfen(?). Braucht man dann ja nicht mehr.
Ach und @ Namensanpassung: ist schon längst passiert, ben_. Ich mag PHP-Invalide sein, aber sowas fällt selbst mir auf 😉
Hmpf, wie ich es zuvor befürchtet hatte: Bei manchen Postings in der WPXML fehlen Paragraphen ect., was Drupal auch genau so importiert. Gäbe es da irgendeine Funktion, die man vor dem Import über den body Text drüberlaufen lassen könnte, oder läuft es auf ein manuelles Bearbeiten der WPXML hinaus?
Also es gibt in Drupal die Funktion _filter_autop($text); die kannst Du überall verwenden und macht Dir p und br sogar ziemlich schlau in deinen Text. Ich würde die aber nicht hart in den Body reinschreiben, sondern per default auf alle importierten Nodes ein Format anwenden, dass den autop-Filter enthält. (Full HMTL z.B.)
Nachtrag: Ach so. Manuelles bearbeiten des WPXML ist allerdings ein Weg den ich selber immer gerne gehe. Da man das ganze Korpus in einer Datei hat, kann man auch prima mit Regexen oder Xslts drüber arbeiten. Das hab ich immer auch genutzt um noch einen Haufen anderer Aufräumarbeiten zu machen. :]
Hm, autop wird ja auch beim Filtered HTML-Format benutzt, wenn ich mich nicht irre. Da hatte ich es rausgenommen, weil es mir an den unmöglichsten Stellen ein </p> reingehauen hat. Ich versuch’s mal. Aber ich fürchte, das wird wohl doch darauf hinauslaufen, es selbst zu editieren (ob nun im XML oder später mittels Drupal). Hmpf.
Edit: Mit RegExpen stoße ich schon an die Grenze, des für mich machbaren. Die letzten XLST-Versuche liegen bei mir schon Jahre zurück.
Hm. Ich habe als Format der zu importierenden Posts schon Full HTML eingestellt. Bei dem Eingabeformat ist wiederum einzig der Zeilenumbruchkonverter aktiviert (das sollte doch autop sein, wenn mich nicht alles täuscht). Ergebnis des Ganzen siehe oben: keine Paragraphen. Hm.
XSLT ist eigentlich nur wichtig, wenn Du das XML fundaemental umbauen willst. Das war ja für Heimweh-Wichtig. Regexe hingegen sind kein Hexenwerk. Was ist denn der Editor Deiner Wahl? Mit Textmate (Mac) und Ultraedit (Windows) bekommt man mit den Suchen/Ersetzen mit weniger Regexen echt viel hin.
Das wichtigste was man braucht ist n für Zeilenumbrüche.
Davon ab: Das finde ich schon erstaunlich, dass das Autop komisches Markup erstellt. Ich bin da bisher tadellos mit zufrieden. Haste mal ein Beispiel?
Wenn Du das Markup mit in der DB haben magst, kannste autop ja auch im wordpressimport-modul mal hier reinbasteln?
$node[‚body‘] = „“._filter_autop($xml->content);
Wie? Gar keine Absätze? Das ist skuril!
Ist der body völlig gleich bei load und render?
node/1234/devel/load
node/1234/devel/render
Beispiel für unschönes Verhalten von Autop, mein Markup für Bilder in Einträgen (wie hier zB.)
<div class="picarea negint pafloat"><img class="m655" alt="" src="url" /> <p class="pcap capright"><a href="blah">Name</a> (<a href="url">cc</a>)</p> </div>
Wenn sich nur ein Leerzeichen oder gar ein einfacher Zeilenumbruch zwischen dem img- und dem darauffolgendem p-Tag befindet, fügt Autop ein </p> ein. Das ist hier wie in Drupal gleich. Bei Drupal allerdings, ich weiß nicht wieso, zerschiesst es sofort das Layout (kurioserweise muss ich bei Drupal, um die Grundlinie beizubehalten, das Stylesheet anpassen, selbst wenn das Markup der Einträge identisch ist).
Und ja, autop fügt keine Absätze hinzu, wenn im XML lediglich Zeilenumbrüche stehen. Bei WordPress war das kein Problem (deshalb habe ich da wohl auch keine Paragraphen manuell gesetzt, damn), weil Autop bei der Ausgabe welche hinzugefügt hat. Drupal macht das nicht. Selbst, wenn ich testeshalber den Node nochmals (mit entsprechendem Format) speichere.
Hm. Bei load und render sind sie identisch. Hm. Ah, duh!
Meine Modifikation (wenn keine Vollansicht & der Teaser leer ist, dann zeige den body-Text an) ist wohl Schuld an der Verwirrung. Bei der Startseite (und den paged Unterseiten) scheint autop so nicht durchgeführt zu werden. Hab ich jetzt mal hinzugefügt und schwups, sehen die Einträge wieder „normal“ aus.
Grmpf.
(Ändert aber nichts daran, dass ich immernoch nicht weiß, warum ich bei gleichem Markup mein stylesheet anpassen muss, damit alles grundlinig bleibt. Hm.)
Jetzt hast Du mich aber verloren. Zur Not einfach autop selber anstoßen im Rendering. Sachich mal so.
Hehe, sorry. Ich hatte nicht gesehen und beachtet, dass die Einträge nur auf der Startseitenübersicht (und allen folgenden Seiten) zerschossen, in der Einzelansicht aber richtig dargestellt wurden. Und das lag daran, dass aufgrund meiner Modifikation (siehe dein Eintrag hier und mein folgender) für den Text kein autop durchgeführt worden ist.
Und jetzt ist alles gut mit Absätzen und so?
Schaut zumindest so aus. Bleibt nur das Mysterium der Grundlinie übrig, aber da passe ich das Stylesheet lieber ganz faul an, als nach Ursachen zu forschen. Denn über weitere Baustellen kann ich mich ja wahrlich nicht beklagen.
Ist es übrigens so gewollt, dass der Autor bei importierten Einträgen „Gast“ ist? Hm.
Der Autor der Node? Oder Kommentatoren? Grundsätzlich wir die ID des Autors ja im Worpressimport-Modul auf 1 gesetzt und sollte dann auch den Namen von USer 1 tragen.
Der Autor der Node. Ich habe extra nochmal im Plugin selbst nachgeschaut und nach dem Import in der DB: Dort ist die uid auch auf 1 gesetzt. Trotzdem zeigt Drupal unter /content/node den Autor als „Gast“ an. Ich hatte zwischenzeitlich den Benutzernamen verändert, aber das liegt schon zig Import-Durchläufe zurück. Hm.
Unter admin/content/node ?
P.S.: In der Tat. Steht bei mir auch. Ts.
P.P.S.: Beim mir steht in der tabelle „node“ aber auch 0 als uid. In der Tabelle „node_revisions“ hingegen steht richtigerweise 1.
P.P.P.S.: Habs. Füg mal in der Funktion
_wordpressimport_makemynode($node)
diese Zeile ein:
$node->uid = „1“;
Jau, so läuft’s. Merci.
Und weil ich mich gerade mit dem Pager umherschlage: Wie unflexibel ist das Mistding bitte schön? Position selbst festlegen? Optionen (wieviele Seiten werden maximal gelistet ect.) daran verändern? Bisher nichts wirklich Brauchbares gefunden. Und wenn ich mir die Suchergebnisse auf drupal.org dazu so anschaue, scheint das im Vergleich z.B. zur Pagebar bei WordPress eine große drupalsche Baustelle zu sein.
Mann, Mann, Mann, Fym, Du findest aber auch mit erschreckender Präzisoin die offenen Wunden … soo schlimm sieht das aber gar nicht aus, wie ich finden muss.
http://api.drupal.org/api/function/theme_pager/6
http://api.drupal.org/api/search/6/pager
Da hat man schon mal ein bisschen was in der Hand. Position selber festlegen … grübel.
Naja, sieht in meinen Augen schon schlimm aus.
Modifziere ich theme_pager(), zerschiesst es mir die einzelnen Pager-Links (davon abgesehen, dass HTML-Entities von z.B. theme(‚pager-first‘) ect. nicht dargestellt werden. Überhaupt scheint der Pager bei Drupal zu sehr mit den eigentlichen SQL-Queries verquickt zu sein.
Und was die Position angeht: Zur Not und wenn alle Stricke reissen, würde ich halt mit CSS drangehen. Aber auf den Entitätsseiten habe ich das nette Problem, dass die Teaserbilder in einer unsortierten Liste aufgelistet werden, diese Liste aber nicht geschlossen wird, weil sich der Pager umgehend nach dem (auf dieser Seite) letzten li-Element reinsetzt. Da ist auch mit CSS nicht mehr viel zu machen (vom chaotischen Markup mal abgesehen).
Eine einfache Variable zur Region-Bestimmung würde ja eigentlich schon ausreichen, aber naja.
Testeshalber in der template.php die theme_pager()-Funktion (aus der pager.inc kopiert) reingesetzt und am Ende bei arg(0) == „taxonomy“ eine Variable mit der ansonsten einfach zurückgegebenen „theme(‚item_list‘, yadayada)“-Funktion belegt. Diese Variable in page-taxonomy.tpl.php global gesetzt (schlimm, schlimm, ich weiß) und zumindest taucht der (zwar zerschossene, siehe oben) Pager an der Stelle auf, wie ich es möchte.
Hm. Hm.
Drupal trennt Tags per Kommata und sieht demnach einen WP-Term, welcher solche enthält, als zwei separate Terms an und importiert dementsprechend. Unschön. Mal versuchsweise basteln.
Aber schön zu erleben: Lernkurve und so. Drupal hört inzwischen zumindest häufiger auf das, was ich von ihm möchte.
Dann einfach, beim Import alle Tags in “ “ setzen. Verausgesetzt in Import-Korpus sind nun nicht auch noch tags mit Anfühunrgszeichen.
Ui, dachte schon, ich hätte dich mit meinem drupalschen Kommentierenthusiasmus vergrault. Ich würd’s ja niemandem verdenken :]
@Import. Will try, will do.
Und weil ich das – Salz in die Wunde und so – ja gerne mache: Die Limits der anzuzeigenden Nodes sind böse bei Drupal. Bisher noch keinen praktischen Weg gefunden, für spezifische Bereiche/Seiten (aktuell z.B. für das Archiv) ein höheres Limit der anzuzeigenden Nodes festzulegen. variable_set(‚default_nodes_main‘, 50); sah erst gut aus, legt aber leider trotz if-Bedingung ect. den Wert global fest. Überhaupt, alles viiiiel zu global bei Drupal. Gut auf der einen Seite, aber eben auch ein Nachteil auf der anderen. Scheint sich aber in dieser Hinsicht bei D7 was zu bewegen: http://drupal.org/node/33809
(und hmm… vielleicht sollte ich mir dieses Views-Module doch mal anschauen, wenn es denn mit Version 7 in den Core wandert.)
@Vergraulung: Ne, ne. Gestern musste ich nur tatsächlich mal richtig arbeiten und dann Heimweg nach Bielefeld und hier wartet ja auch wer auf Aufmerksamkeit. Der heutige morgen war dann von einer prophezeihbaren Entspannungs-Migräne bestimmt. 🙁
Über das Problem mit den unterschiedlichen Anzahl von Nodes pro paginierbarer Seite hatte ich schon mal mit Stefan von Erdfisch.de gesprochen. Da gibt’s ne Lösung für. Die hab ich aber vergessen. War aber nicht unaufwändig, wenn ich mich nicht irre.
Entspannungsmigräne? (Wikipedia bemüht) Oha, in der Poststress-Entspannungsphase wie böse ist das denn bitte.
Ich habe mich jetzt jedenfalls schon durch zig Seiten bei drupal.org gequält und kann die Standardantwort („Ist ganz einfach… mit Views.“) nicht mehr lesen. Hmpf. Und irgendwie gestaltet es sich schwerer als gedacht, Drupal beizubringen, den Nodesterms-Block nur als Liste, ohne umschließendes Div, auszugeben. Weiterschrauben. Gestrichen, einfach die theme_item_list rausgeworfen und die auszugebende Liste direkt in $output gesteckt.
Kuhl! Wie wirft man denn was direkt in die $output?
Ach und ja, ich kam mir gehörig verarscht vor, als ich zum ersten Mal erfahren habe, dass so ein Gehirn auf plötzlich ausbleibenden Stress mit noch fieserem Stress reagiert. Frechheit.
Hm? Ich meinte nur: In theme_semanticweblog_nodesterms_block() steckst du die SW-Terms ja in $items[] und übergibst die wiederum an theme_item_list(), welche daraus letztlich eine (un-/)sortierte Liste macht (und einen dieser netten drupalschen div-Container redundant drumlegt).
Den theme_item_list()-Aufruf hab ich schlicht rausgenommen und stattdessen reingekritzelt:
$output = "<ul>"; foreach ($items as $item) : $output .= "<li class="metaitem">" . $item["data"] . "</li>"; endforeach; $output .= "</ul>";
theme_item_list() macht ja (im Prinzip) nichts anderes, als die $items in <li>-Tags zu setzen und das war’s dann auch. Kann imo also raus, besonders, wenn ich wirklich nur die reine Liste möchte, ohne nervigen div-Container. Einwände, Vorschläge?
@Import: Hm, nein. Mit Anführungszeichen sollte ich keine Tags haben (hoffe ich). Die Empfehlung mit den „“ funktioniert so, danke schön. Und da merke ich jetzt, dass ich da noch ein bisschen mehr anpassen muss. Hatte die Metadaten ja doch für das ein oder andere hier eingesetzt und entsprechend modifiziert (die IMDb-Links zB., mal schauen, wie ich die handhaben soll).
Hinsichtlich der IMDb-Links weiß ich noch nicht, was besser wäre: Entweder die Filmtitel und Links wie gehabt separat als Terms importieren und entsprechend das SW-Modul für die Ausgabe modifizieren– oder gleich ein eigenes Modul schreiben, in das die Links ansich kommen (wobei ich mich an deinem teaserimage-Modul orientieren würde, ben_).
Ersteres wäre wieder so ein elendiges Rumgefummel. Bei Letzterem würde es wiederum den Zusammenhang der Metadaten irgendwie doch arg zerklüften. Hm.
Ähnlich gestaltet sich das auch für die Übernahme der Metadaten zu den hier verwendeten Bildern (flickr-Zeugs, Name, Link ect.). Aber da wäre die Modul-Variante wohl das günstigste.
Also für die IMDB-Kiste und Deine Anderen Sachen würden sich imho zwei Dinge anbieten.
1. CCK. Kein Witz. Da CCK bald zum Kern gehört überlege ich auch schon mein Teaserimage Modul nach CCK zu portieren. Ist quasie wie gemacht dafür.
2. Wir schreiben ein Meta-Daten-Modul, das im Grunde so funktioniert wie die WordPress-Metadaten. Es hat den Vorteil gegenüber CCK, dass man es deutlich leichter auch in anderen Modulen verwenden könnte, bzw. für neue Funktionen überhaupt keine Module braucht. Gleichzeitig ist es schlanker als CCK.
Im Grunde schrecke ich aber davor zurück, weil es defaktor eine Konkurrenz zu CCK wäre und man sich damit von den Funktionen, die D7 bringen wird noch weiter abtrennt, als ich das mit allen meinen Modulen eh schon gemacht habe.
Hm. Mit dem CCK habe ich mich bisher nicht auseinandergesetzt, aber wenn ich das gerade richtig überflogen habe, bietet das CCK selbst ja auch nur „rudimentäre“ Optionen an (die sicherlich für die meisten meiner eigenen Metadaten ausreichen würden), welche von anderen Modulen erweitert werden? Das scheint ja vollends „Modulmodule“-Wahn zu sein? Hülfe. Dann ist es ja kein Wunder, dass das Ding in den Kern wandert/wandern muss.
Um die Teaserbilder über das CCK laufen zu lassen, müsste man – wenn man ganz bequem ist und neben der Angabe zur Teaser-URL auch noch eine Uploadfunktion im selben Eingabeformular haben möchte – auch noch eines dieser zusätzlichen Module für’s CCK installieren, wenn ich das recht verstehe. Die drupaleigene Uploadfunktion hängt doch letztlich nur hochgeladene Dateien an den Node an bzw. verknüpft sie gleich damit, auch nicht so das Wahre… zumindest ein bisschen unschön, in meinen Augen.
Ich würde ja (stilecht mit meinen idealistischen Augenklappen) fragen: Konkurrenz? Nein, und selbst wenn, was soll’s? Ich habe lieber *ein* schlankes Modul. Der eigene Weg, der ja trotzdem auf Drupal aufbaut, kann doch weder ein schlechter noch ein „abgetrennter“ sein. Nie. Wenn Drupal für sich in Anspruch nimmt, modular und damit flexibel zu sein, dann muss es sowas abkönnen ;]
Aber ich probiere mal mit dem CCK rum, was ich damit von Haus aus machen kann und was nicht.
Also CCK ist v.a. dazu da, Nodes um weitere Content-Felder zu ergänzen. Dazu gibt es einen schicken Klickibunti-Editor, mit dem man die Felder je nach Bedarf zusammenbasteln und benamsen kann. Standardmäßig werden die meisten Felder einfach so im Frontendrausgerendert. Aber das kann man – wie fast immer – überschreiben und so hinbiegen, wie man das gerne hätte. Und obschon CCK auch eine API hat, und es viele Module gibt, die darauf aufbauen, würde ich schon sagen, dass man nur mit CCK und Theming schon ziemlich weit kommt.
Für Dateiuploads gibt es in der Tat ein CCK-Ergäzungsmodul, das ich aber nicht benutzen würde. Mir reicht der „normale“ Upload. Ich markiere dann immer die BildURL per Doppelklick und füge sie im Teaserimage Feld wieder ein. Würde ich auch beim Einsatz von CCK nicht anders machen.
Eigenes Meta-Datenmodul hatte ich v.a. der Blogevolution und meiner Lehren aus Heimweh wegen in Betracht gezogen. Meta-Daten sind auch nur kleine Assets. Und mit einem guten Assestsystem wäre die Blogevolution auch nicht mehr so weit weg … ach. Wenn ich mich nur aufraffen könnte das Zend Studio aufzumachen. Urlaub ist viel anstrengender als ich dachte. 😉
@ Upload: Ah, ok. Die absolute URL nach dem Upload hatte ich übersehen. Und ich weiß nicht wieso, aber jetzt zeigt er mir angehangene Dateien auch nicht mehr direkt in der Ausgabe des Postings. Gut, die Variante ist somit gekauft.
@ CCK: Das mag ich daran eben nicht. Diese Starre. Und das wäre eben das feine an einem eigenen Meta-Datenmodul. Eben so, wie es hier in WP der Fall ist. Einfach on-the-fly ein Feld mit neuem Metakey benutzen und aus, fertig. Wenn ich so darüber nachdenke, wäre das CCK eigentlich ganz toll, um die Key->Value-Relationen meiner Metadaten zu behalten, anstatt sie alle in ein Vokabular zu schmeissen. Aber was bringt das schon, wenn eben die Flexibilität fehlt; ich erst vor der Verwendung eines neuen Keys in die Einstellungen der Inhaltstypen gehen muss, um ihn benutzen zu können. Und überhaupt wäre das node creation Formular dann überladen (es zeigt ja alle für den Inhaltstypen definierten Felder an, wenn ich das richtig sehe– komme, was wolle). Hmja.
Anhang zum letzten Punkt: Uuuuund überhaupt wären das bei Verwendung des CCK hinsichtlich der Usability gleich mehrere rückwärtsgerichtete Schritte. Hmpf.
Und @ CCK-Anzeige: Kannst du mich mal in die richtige Richtung stubsen? Welche Funktion muss ich überschreiben, damit die CCK-Werte nicht automatisch ausgegeben werden?
Die beiden fundamentalen Unterschiede zwischen CCK und WP-Meta sind ja, dass zum einen das was in WP „Keys“ sind in CCK quasie die Namen der Felder sind. Zum anderen macht CCK für jedes neue Feld eine neue Tabelle. Überdies kann man mit CCK Daten typisieren und gruppieren. Das macht CCK zum mächtigeren der beiden.
Würde ich ein Meta-Asset-Modul in Drupal-Programmieren wäre das grundlegende Model des Assets deutlich mächtiger als das eine Meta-Datums.
Neben dem Key gäbe es wohl noch wenigstens Title, Body, Author, Source-URL und Date. Wirklich durchdacht hab ich das aber noch nicht. Es würde damit mehr dem ähneln, was WP mit seinem Kommentar-Tabelle veranstaltet, wo ja neben den Kommentaren auch noch die Trackbacks drin landen. …
CCK Theming … nicht, dass ich es schon gemacht hätte: http://drupal.org/node/62462
http://drupal.org/node/206980
Hm, das wäre dann für mich persönlich schon fast wieder Overkill (und ich muss ja ein bisschen auf die Ressourcen schauen ;)). Mir würde es reichen, wenn ich Terms angeben, sie selbst ggf. definieren und zudem (optional) mit semantischen Relationen anreichern kann (d.h. viel eher eine Mischung aus explizit angegebenen und – sowohl auf den explizit angegebenen aufbauend und darüber hinausgehend – „automatisch“ hergeleiteten Relationen).
@IMDb-Zeugs: Merke gerade, wie sehr die WP-Keys bei den Terms fehlen, wenn ich die Ausgabe von Links zur IMDb (0, 1, n Links) umsetzen möchte. Wenn ich alles über das CCK laufen lasse, wird es schwieriger mit der Integration in die Terms (eben so umgesetzt, wie hier). Wenn ich zur drupalschen Umsetzung CCK und SW-Terms mische, muss ich einiges umbauen. Wenn ich nur die SW-Terms benutze, muss ich wahrscheinlich noch mehr umbauen. Hach, wie man es macht…
Hm… ja indeed. Wenn du mehr als einen Wert pro Key hast … ist CCK soweit ich das beurteilen kann auch nicht so richtig richtig. Damn. Der naheliegendste Drupalweg wäre dann, sie alle in ein eigenes Vokabular zu stecken.
Hach ich hab auch immer mehr das Gefühl, dass SW unter Drupal irgendwie nicht richtig gemacht zu haben, obschon Konnexus ja gut zufrieden ist damit. Ich muss da mal mehr drüber nachdenken.
Nja, damit ich z.B. bei mehreren IMDb-Links überhaupt Links zu den richtigen Metadaten zuordnen kann, gebe ich ja schon jetzt den Filmtitel zusätzlich zur IMDb-ID an (a la „Filmtitel->IMDb-ID“). Das ist zwar nicht besonders schön, erfüllt aber wenigstens seinen Zweck. (Müsste ich nebenbei bei Verwendung eines Vokabulars genauso handhaben)
Bei Drupal habe ich es jetzt ähnlich umgesetzt. Wie alle SW-Terms vor der Ausgabe in einen Array gesteckt werden, stecke ich jetzt zusäzlich bei vorhandenen Werten im CCK-Feld „imdblink“ (in der Form „Filmtitel//IMDb-ID“) diese in einen Array ([Filmtitel] -> Markup des Links)und hänge (wiederum nur bei vorhandenen CCK-Werten) diesen an die passenden Terms an. Wie geschrieben: Nicht besonders schön, nicht sauber – aber so funktioniert es jetzt zumindest auch in Drupal.
Nicht, dass ich es jetzt verstanden hätte … nur soviel: Sehe ich das richtig, dass Du das über ein Zeichenketten-Konvention (in diesem Fall „//“) machst?
Japs, einfaches explode() halt. Ich sag ja: nicht besonders schön, gar schon dreckig, aber es tut.
Mir gefällt die Umsetzung in Drupal trotzdem besser. Per CCK ist es von den mir eigentlich wichtigen Metadaten, dem gewünschten semantischen Netz eben, räumlich getrennt. Mag sehr eigen sein, aber Links sind so vergänglich, die gehören für mich einfach nicht in den selben semantischen Topf.
Ich beschreib’s mal genauer, auch wenn du das wahrscheinlich gar nicht wissen willst 😉 Also, im Prinzip läuft’s jetzt so:
Die Terms kommen in ein Array ($terms), wie gehabt. Zusätzlich wird noch der Term selbst als reiner Text hinzugefügt (zur späteren Zusammenführung). Wenn sich Inhalte im CCK-Feld „imdblinks“ befinden, diese in ein zweites Array ($imdblinks) packen: Key ist hierbei der mit dem SW-Term identische Filmtitel, Wert ist der schon fertig gemarkupte Link zur IMDb-Seite.
Das Terms-Array wird anschließend wie gehabt mit foreach abgearbeitet. Jetzt wird allerdings, wenn CCK-Inhalte für diesen Node vorhanden sind, eine Variable mit dem Inhalt von $imdblinks[$terms[„Term“]] belegt und mit ausgegeben.
Ergo: Gibt es einen entsprechenden CCK-Eintrag zum Term (Filmtitel) wird automatisch der CCK-Link an die Termausgabe angefügt. Wenn nicht, dann ist folglich nur der Term zu sehen.
Funktioniert.
Jetzt muss ich nur noch schauen, wie ich aus dem Import-Modul heraus die CCK-Felder bestücken kann.
So. CCK-Felder (zusätzlich zu der imdb-Geschichte lasse ich wohl auch die Quellangaben zu den in den Einträgen verwendeten Bildmaterial darüber laufen) werden im Import-Modul schon gefüllt. Und ich überlege gerade, ob es tatsächlich nicht besser wäre, dann auch gleich die Teaserbilder darüber laufen zu lassen. Wie du ja schreibst: CCK wandert eh demnächst in den Core. Und allein schon deshalb, um Redundanz zu vermeiden. Ein Modul weniger. Hm.
Yep. Kann man in CCK einzelne Konfigurationen nicht auch exportieren?
Hach, wenn ich nicht gerade in so einer unglaublich tiefen Unentschlossenheit feststecken würde … ich bin wirklich völlig unfähig zu entscheiden, was das richtige ist für das Semantic Weblog … geschweige denn, dass ich auch nur eine Zeile Code hinbekomme.
Man kann den kompleten Inhaltstyp exportieren und damit eben auch die für ihn festgelegten CCK-Felder.
Ha, und gerade leuchtet mir in lieblichem Rot wieder eine Aufforderung zum Update entgegen… zweites Mal upgraden. Sitze ich wirklich schon so lange an meiner lokalen Drupalinstallation? ;]
Nein, die letzten beiden Updates kamen in ziemlich schneller Folge. Die Sicherheitslücke, die beide Updates nötig machte ist aber ziiiiemlich obskur und kann eigentlich nur ausgenutzt werden, wenn man zusätzlich noch ziemlich fahrlässige Themes/Module an hat:
„Certain byte sequences that are valid in the UTF-8
specification are potentially dangerous when interpreted as UTF-7. Internet Explorer 6 and 7 may decode these characters as UTF-7 if they appear before the tag that specifies the page content as UTF-8, despite the fact that Drupal also sends a real HTTP header specifying the content as UTF-8.“
Nebenbei: Im Kommentarfeld das blockquote Element zu erlauben aber kein weiteres Blockelemente … ergibt das dann validen Code?
Ja, hatte ich schon gelesen. Aber fahrlässige Themes/Module? Betrifft mich ja bestimmt. Wenn nicht jetzt, dann doch sehr bald. Zumal ich schon überlege, wie ich den anderen hier zu findenden Kram in Drupal umsetzen könnte. Die Lesart-Seite beispielsweise.
Hier in WordPress ist das ein eigenes Plugin, mit eigener DB-Tabelle usw. Aber ob in Drupal ein eigenes Modul dafür nötig wäre? Momentan denke ich, dass man das dort mit einem eigenen Inhaltstyp, CCK und ein bisschen Theming hinbekommen könnte. Und eigentlich wäre es auch besser so, schließlich gehören die Daten ebenso zu den restlichen Einträgen ect., sind hier momentan aber von jenen getrennt. Hmjahmm.
@valider Code: Sollte eigentlich (tut es aber trotzdem nicht, wie mir der Validator gerade verrät, hmhm), weil die HTML-Tags da nebenan sowieso nicht stimmen 😉 p-Tags sollte man z.B. selbst setzen können, wenn man denn will. Überhaupt schon vor einigen Tagen aufgefallen, dass ich blockquote für den Kommentarbereich gar nicht gecss’t habe. Funny. Aber da die Migration eh passieren wird, hab ich auch keine Lust, hier jetzt noch für Validierung und CSS zu sorgen.
@“Wenn nicht jetzt, dann doch sehr bald“: Wohl kaum. Denn erstens müsstes Du ja Deine eigene Seite mit Schadcode wider den IE6 und 7 versehen wollen, und das könntest Du leichter haben. Und zweitens müsstest Du schon dafür sorgen, dass Kommentar-Texte VOR dem HTTP-Header ausgegeben werden. Ich sag mal so: Beides würdest Du wohl ziemlich zeitnah rausfinden. 😉
@Lesart: Was ist die Lesart-Seite? Ah! Gefunden. Sweet! 1 A Premium eigener Node-Typ + CCK würde ich auch sagen. Wobei sich da latürnich überlegen läßt, ein gemeinsame Tagging-Vokabular zu haben, um Autoren und Titel auch für andere Nodes nutzbar zu machen.
@Validität: Valider Code ist Spießbürgerei für Geeks. Echten Freidenker genügt die Wohlgeformtheit. 😉
@Lesart: Meinte ich auch. Das CCK würde ich eben nur für die Coverbilder/Teaserbilder benutzen, für die eigentlichen Metadaten würde ich das gleiche Vokabular der sonstigen Einträge wählen. So miteinander verdrahtet hatte ich es ursprünglich für WP ja auch angedacht, aber… hmja, WordPress halt.
Hach, Drupal. Alles unter einem Dach. Dann lohnt es sich auch, endlich die blogoffs zu betermen. (btw „gecsst“, „betermt“ – gotta love it).
Natürlich ist das alles nur halbfertig, bis ich einen (hoffentlich einfachen) Weg finde, an der Anzahl der angezeigten Nodes seitenabhängig zu drehen. Ich weiß ja nicht, wie du das siehst, aber für mich sollte z.B. ein Archiv durchaus mehr als 8-10 Nodes auf einmal anzeigen. Überblick gewähren – sonst ist es irgendwie kein Archiv.
Die Lesart-Seite macht nach meinen Vorstellungen auch dann nur Sinn, wenn ich alle (zumindest pro Jahr) Nodes (=Bücher) auf einer Seite beisammen habe.
Übrigens: Für solche Sachen (Lesart, Teaserbilder ect) wäre es ganz wunderbar, wenn man dem Upload auf dem node creation form je nach Nodetype ein anderes Uploadverzeichnis aufs Auge drücken könnte. Also zwar alles in /files, aber eben z.B. files/bookcover oder files/teaserpics ect.
@Num-of-Nodes-per-Page: Ja das sehe ich genauso. Grundsätzlich finde ich eine Zahl für Termseiten und Archiv und so ok. Aber gerade die Startseite ist ja wirklich was ganz anderes. Zwei Möglichkeiten sehe ich da aber noch.
1. Die Zahl auf einen Wert setzen, der Dir für die „normalen“ Übersichtsseiten reicht, und die letzten Nodes auf der Startseite dann über einen neuen Block fahren. Damit würde ich auch das „in der Zukunft publizieren“ Problem umgehen.
2. Mit hook_boot oder hook_init die Variable neu setzen, jenachdem wie $q aussieht. Dafür könnte man sogar eine Konfigurationsseite bauen. Und hinterher, mit hook_exit wieder zurücksetzen.
Dritte Möglichkeit von Stefan:
In der settings.php
$path = $_GET[‚q‘];
if ($path == “) {
$conf = array(
‚default_nodes_main‘ => 1,
);
}
else if ($path == ’node‘) {
$conf = array(
‚default_nodes_main‘ => 2,
);
}
else if($path == ‚taxonomy/term/75‘) {
$conf = array(
‚default_nodes_main‘ => 3,
);
}
@Lesart-Seite: Views!
Oder sobuz ein eigene Page bzw. einen eigenen Block geschrieben. Ist ja nur ein Query.
@Upload: Ja, das hab ich mir auch schon gewünscht. Aber mehr so aus einer Vision der Ordnung heraus. Denn andererseits: Nicht, dass ich in den letzten Jahren wirklich mal in irdenwelchen Ordnern rumgeturnt wäre. Das höchste der Gefühle ist, ein Bild via FTP durch eine neue Version von sich selbst austauschen. Und dafür ist es sogar praktischer, wenn alle in einem Ordner liegen.
Die dritte Möglichkeit habe ich gewählt und ein wenig modifiziert. Welches „in der Zukunft publizieren“-Problem meinst du denn?
@Views: Nö! Ich bin ja schon beim CCK idealistisch eingeknickt, das wird mir bei Views nicht auch noch passieren ;] Aber ich denke, dass obige Modifizierung von default_nodes_main in Kombination mit ein, zwei CCK-Feldern für die Lesart-Seite ausreichen wird. Außerdem muss es ja auch keine wirkliche 1:1 Umsetzung werden. Mal schauen.
Wenn Du in WP einen Post mit 1.1.2010 datierst, geht der automatisch dann online.
In Drupal geht der sofort online und es steht halt 1.1.2010 als Datum dran … vor-veröffetnlichen geht nicht in Drupal. Zumindest nicht ohne Zusatzmodul.
Ah. Witzig, ich wäre nicht auf die Idee gekommen das zu testen, obwohl ich die „Funktion“ hier bei WP häufiger mal verwende. Andererseits ist das wohl eines der Features, auf die ich dann auch verzichten könnte.
btw Das Verhalten hätte ich an deiner Stelle in der „Der große Krieg“-Reihe mit nem Augenzwinkern benutzt. Zumindest für den ersten Eintrag, zwei Wochen das Datum auf dem 7.7.2014 gestellt lassen 😉
@Upload: Nja, alles in einen Ordner zu stopfen, ist mir dann doch einen Tick zu unübersichtlich, zu überladen. Wenigstens die Trennung per Unterordner sollte schon sein, so ein Zeugs wie Jahres- oder Monatsordner brauche ich dann auch nicht. Zudem lade ich ohnehin Eintragsbilder per FTP hoch, von daher…
Jedenfalls ist „Upload path“ genau das, was ich gesucht habe. Damit kann man allgemein oder nach Node type definiert Muster für die hochgeladenen Dateien angeben und diese so in Unterordner stecken.
Hm. Wer hat sich das Verhalten der Node-Titel ausgedacht? Titel werden wohl als plain text behandelt, weshalb HTML-Entitäten nicht als solche ausgegeben werden und stattdessen as is erscheinen. Wenn ich also im Titel z.B. HTML-Entitäten für die Guillemets verwende, erscheinen diese anschließend nicht, sondern nur plain als „»“ bzw. „«“. Wenn ich die Anführungszeichen direkt ins Titelfeld kopiere, also keine HTML-Entitäten benutze, dann werden sie angezeigt. Hmhmpf.
Darüber hinaus müsste ich pathauto noch irgendwie beibringen, eben diese Guillemets aus dem Pfad-Alias zu streichen. Unnötig. Unschön.
Gerade eben geschafft:
– Guillemets aus dem Pfad-Alias gestrichen
– Lesart-Seite zusammengebastelt (per Block)
– Kleines Importmodul für jene Lesart-Daten geschrieben (praktisch, dass ich für das Plugin-Gegenstück hier gleich zu Beginn schon einen XML-Export geschrieben hatte)
Jetzt steht noch an:
Modul für den Import der blogoffs
Seite für die letzten x Kommentare
Die Bildwand irgendwie portieren
Irgendwie die Feeds so hinbiegen, wie mir das passt.
(+ all die Dinge, die ich gerade noch übersehe)
So it goes . . .
Gratz! Das mit den Guillemets interessiert mich auch. Wie hast Du’s gemacht?
Ansonsten: Das sind ja überschaubare Hindernisse, die da noch kommen. Mostly Fleißarbeit würde ich sagen.
Zwei Varianten, um die Guillemets aus dem Pathauto-Alias zu entfernen:
Die (imo bessere) Variante ist, sie der i18n-ascii.txt hinzuzufügen und in normale Anführungszeichen umwandeln zu lassen, welche Pathauto dann wie gehabt entfernt. Die Variante hat bei mir natürlich nicht funktioniert. Ob’s an der Zeichenkodierung lag, falscher Zeichenverwendung von mir oder woran sonst, keine Ahnung.
Variante #2 ist dreckiger, hat bei mir aber wenigstens funktioniert: In pathauto.inc bei der function pathauto_punctuation_chars() die Guillemets im $punctuation-Array hinzufügen. Dann in den pathauto Optionen, wenn nicht schon geschehen, entsprechend als Aktion „Entfernen“ einstellen. Et voilà.
@Hindernisse: Jap, schaut so aus. Gerade deshalb: Igitt. Fleißarbeit. Und es wird wohl trotzdem darauf hinauslaufen, dass ich irgendwas Entscheidendes übersehen/vergessen werde. Muss einfach. Murphy und so.
Dass die blogoffs keine Titel haben, machte zumindest diese Sache zu mehr als zur reinen Fleißarbeit.
Wenigstens steige ich inzwischen bei Drupal so weit durch, dass den Blogoffs jetzt ein Titel nach Format „Blogoff #x“ (x = Anzahl aller Blogoffs einschließlich des gerade erstellten) gegeben wird. Und Drupal meckert inzwischen auch nicht mehr über das leergelassene Titel-Feld im blogoff node creation form. Ha! Kleine Schritte…
Wieder ein Grund mehr, warum ich autop bisweilen überhaupt nicht leiden kann: http://drupal.org/node/212236
Und warum so ein relativ lang bekanntes „Problem“ immernoch mittels Patch behoben werden muss und nicht gleich in die aktuelle Version integriert wird, ist mir ein Rätsel.
Am Theming der /search-Seite hänge ich momentan auch ein bisschen. Das mag noch nicht so, wie ich will. Und ich spiele schon mit dem Gedanken, die Suche gleich komplett zu deaktivieren.
Nicht, dass ich je den Wunsch gehabt hätte, die Suchseite und deren Node-Ansicht zu verändern, aber … was ist denn mit hook nodeapi, $op = „search result“
http://api.drupal.org/api/function/hook_nodeapi/6
und zusammen mit der search-result.tpl.php sollte doch eigentlich so eiiiiniges machbar sein, oder?
Hm. Mein Kommentar mit Linksen zur Hilfe ist wieder im Orkus gelandet. Ich hoffe, der läßt sich Montag noch rausfischen. So oder so aber: Damit das hier nicht nur zu einem besseren „nichts“ führt sondern andere auch was davon haben, lass uns doch die Tage mal zusammenschreiben, was alles so schiefläuft im Drupal-Theming.
Schönes langes Wochenende!
Nach meinem letzten Kommentar habe ich es dann noch hinbekommen. Die Sache bei diesen Dingen ist weniger das Markup der einzelnen Nodes, sondern überhaupt die genauere Platzierung von Inhalten auf der gesamten Seite. Diese Zersplitterung vom Großen zum Kleinen ist beispielsweise einer der „Schiefläufer“, die ich beim Drupal-Theming als solche empfinde. Man muss bisweilen an zig Stellen zugleich ansetzen, um das Verhalten zu bekommen, dass man sich von Drupal wünscht.
Das Theming ist einerseits wunderbar unkompliziert und flexibel – Seitenbereiche definieren, somit eine flexible Schablone haben, das ist im Vgl. zu WP, wenn sie erst einmal steht, Zucker. Sauberer, besser.
Zugleich fühle ich mich als Nutzer/Themer bisweilen von Drupal entmündigt. Warum kann ich nicht unkompliziert entscheiden, wo (durchaus wichtige) Bereiche hingehören? Kommentarbereich? Pager-Navi? Nix. Nada. Man hat für die einzelnen Seitenbereiche wunderhübsche Variablen ($content ect), warum obige Bereiche nicht ebenso ansteuern? Und und und…
Ich hatte ohnehin vor, das alles nach der (dann hoffentlich erfolgreichen) Migration des nichts mal zusammenzuschreiben, zu dokumentieren, Erfahrungsbericht eines WP-Umsteigers, sozusagen. Nicht ganz so fahrig und zerklüftet eben.
*demütigdashauptinascheneigend*
Ja, völlig richtig. Diese entmündigenden Aspekte sehe ich jetzt auch deutlicher. Was sie so ärgerlich macht, ist v.a. die Tatsache, dass sie so unnötig entmündigend sind. Das hätte man mit wenigen Handgriffen oder nur einfachen Entscheidungen nochmal deutlich eleganter lösen können.
Wenn ich noch was helfen kann: At your command!
Jap, sie sind eigentlich unnötig. Das ist das bisweilen Frustrierende daran. Und das zieht sich durch alle kleinen, wie großen Themingbereiche. Wenn ich z.B. eine komplette Funktion überschreiben muss, indem ich diese nahezu 1:1 aus dem Standard übernehme, nur um letztlich ein umschließendes, unnötiges div streichen zu können… (da gab es vor kurzem auf codecandies ja diesen netten Eintrag und die bezeichnende Erwähnung von Drupal in den Kommentaren) Dem Suchformular wird beispielsweise einfach ein solcher div-Bereich hinzugefügt, ohne, dass dieser wirklich Sinn macht. Es wird für ihn keine ID oder Klasse vergeben, so dass sich nicht einmal ein Nutzen für potentielles Styling ergibt. Das und einige andere Dinge sind einfach unnötig.
Und nebenbei: Lustig, irgendwas habe ich vor dem Wochenende wohl geschrieben, dass Drupal nun dazu veranlasst, die Admin-Seiten mit dem leerraum-Theme anzuzeigen und das eingestellte Verwaltungstheme dabei völlig zu ignorieren. Ach, ach.
Also das mit den ganzen funktionen kopieren ist so eine Sache. Da hab ich mir auch schon drölfschrilljausen Mal das Hirn drüber zermartert. Denn die einzige Alterntive dazu ist, den ganzen Spaß auf mehr Funktionen zu verteilen, was wiederum auch nicht gerade transparent ist. Scheinbar geht man bei Drupal aber zusehendst den Weg weg von themable Function hin zu Templates und preprocess Funktionen … was ich eigentlich eleganter finde.
Wenn wir beide das mal besser verstanden haben, alles, könnte man mal ein Modul schreiben, dass EINIGE unschönheiten im Themeing behebt. Sollte nicht unmöglich sein.
Aber macht man bei den preprocess-Funktionen nicht im Prinzip das Gleiche? Da werden die Standardfunktionen doch ebenso schlicht überschrieben und es endet potentiell ebenso damit, dass man ganze Funktionen nahezu 1:1 übernimmt/übernehmen muss, nur um ein, zwei kleine Sachen zu modifizieren.
Der Weg hin zur Verwendung von Templates ist hingegen wirklich nett bei Drupal. Kein Vergleich zu WordPress. Dort habe ich die festgelegten möglichen Templatedateien und aus. Das drupalsche Themesystem macht das Ganze flexibler, auch wenn die Namensgebung mir schon das ein oder andere Haareraufen beschert hat– kann mir keiner erzählen, dass er da komplett durchsteigt ;] Da hat mich zum Glück das Devel-Modul schon vor dem ein oder anderen Amoklauf bewahrt.
Mehrheitlich werden wohl aber immernoch bei der Wahl die Templatedateien links liegen gelassen, habe ich den Eindruck. Vielleicht, weil die Verwendung von Funktionen relativ gesehen schneller, als zig individuelle Templatedateien ist(?)
Bei Drupal merke ich vor allem die unscharfe Abtrennung des Ganzen. Wie du weiter oben ja schon geschrieben hast: Theming und Module gehen bisweilen fließend ineinander über. Das ist, was die Ordnung der Dinge angeht, auch nicht immer soooo optimal geregelt. Und da wären mir, ebenfalls weiter oben schon geschrieben, zwei vereinheitlichte, für sich allein stehende Ansatzpunkte lieber. Einer für das Markup – per Template eben komplett zu ändern. Und einer für die datenmäßige Aufarbeitung. Das wäre Zucker.
Und übrigens: Das Verwaltungstheme mag wieder. Einmal drupal_add_feed(); an der falschen(?) Stelle im leertraum-Modul hat es wohl durcheinander gebracht. Zumal ich jetzt auch gar nicht mehr weiß, warum ich die Funktion überhaupt aufrufen wollte- hm.
Footnotes-Modul und meine Anpassungen der Teaserdarstellung wollen bei teaserlosen Nodes nicht so recht miteinander. Hmpf.
Desweiteren habe ich das Rätsel, wie man denn eigene Feeds mittels drupal_add_feed() den bestehenden hinzufügt, ohne dass das Verwaltungstheme ignoriert wird. Menno.
Mann-o-mann, langsam verstehe ich gar nicht mehr, mit was Du Dich da eigentlich rumschlägst. Meinst Du das Footnotemodul: http://drupal.org/project/footnotes ?
Bei solche Pseudomarkupsprachen bekomme ich ja immer Schmerzen. Was ist denn das Problem mit den beiden Modulen?
Und was meinste mit „ohne dass das Verwaltungstheme ignoriert wird“? Uijuijuijui … da bist Du ganz schööön abgetaucht was?
Ich schlage mich mit Kleinigkeiten (sollte man meinen) herum – wenn ich ein System einsetze, dann soll es eben meinen Vorstellungen entsprechend funktionieren, keine Kompromisse. Jaja, ich ekel mich ja selbst an ;]
@Fußnoten: Jap, dieses Modul. Ein paar 100 Kommentare weiter oben, hab ich ja schon geschrieben, wie ich Nodes, die keinen Teaser besitzen, auf der Startseite vollständig anzeigen lasse: In meinem leertraum-Modul per nodeapi und „view“ wird geprüft, ob ein Teaser vorhanden ist, wenn nicht, dann wird der komplette Eintragsinhalt als Teaser genommen (e.g. $node->content[„body“][„#value“] = _filter_autop($node->body);). Nun ist es aber so, dass der Footnotes-Filter dann entsprechend nicht mehr greift. Eine Möglichkeit, aus meinem Modul auf diesen Filter zuzugreifen (also ähnlich wie _filter_autop()) sehe ich nicht. Hm.
(Und ja, ich mag das vom Prinzip auch nicht wirklich, aber wie sollte man sonst Fußnoten besser auszeichnen/erstellen können?)
@Verwaltungstheme: Ich hab für den Adminbereich & Bearbeitung der Posts/Seiten Garland eingestellt. Als ich mich daran gemacht habe, eigene rss-Feeds anzubieten (neben dem normalen Feed also z.B. einer nur für die Blogoffs bzw. auch Einträge+Blogoffs usw), wollte ich diese mit drupal_add_feed() zu den schon vorhandenen hinzufügen. Wenn ich die Funktion aber nun im leertraum-Modul aufrufe, dann erscheinen die Feed-Links (link-Tags im Header) zwar zusammen mit den anderen, aber plötzlich wird für Admin-Seiten und Co. nur das lerrraum-Theme benutzt. Egal, was als Verwaltungstheme gewählt wird.
Okay, die Verwirrung um drupal_add_feed() konnte ich gerade ad acta legen. hook_init() ist ab sofort mein Freund. Versprochen. Wie konnte ich den auch nur vergessen, tsts.
Weil’s mir gerade wieder beim Portieren des Bildwand-Plugins auffällt: Hach, eigene Alias-Pfade Drupal hinzuzufügen. Hach! Das ist Zucker für einen PHP-Dilettant wie mich.
Wenn ich da an das WP-Gegenstück für Plugins (rewrite_rules(), anyone?) denke…
Ds freut mich aber außerordentlich, hie auch mal was gutes zu hören. Sehr schön. Hoffnung.
Ach, das hier eher Sachen stehen, die negativ wirken, liegt ja größtenteils daran, dass das hier auch als Ventil für Frust dienen muss. Folglich steht hier im Prinzip mehr Schlechtes über die eigene Unfähigkeit, als über das System Drupal ansich ;]
Die Bildwand ist übrigens fertig. Und nicht nur ist die Integration eigener Pfade/dedizierter Seiten bei Drupal Zucker, auch die Integration von Stylesheets und JS ist sehr fein, wie ich bei der Gelegenheit gemerkt habe. Bei WP muss man mit zig Iterationen von wp_register_script() und Co. handieren, sowie die abhängigen Skripte definieren – bei Drupal kommt einmal ein drupal_add_css/js ins Modul und aus die Maus. Sehr schön.
Die Eintragsliebe ist nun ebenso fertig. Jetzt heißt es, noch ein Auge auf etwaige Baustellen zu richten, die mir bisher vielleicht entgangen sind. Und dann steht der Migration (hoffentlich) nichts mehr im Wege.
Hmpf, der Feedimporter mag nicht so recht. Mal schauen, ob ich da etwas dran ändern kann.
Was mag er denn nicht?
Lokales Problem, weil der Mailserver nicht konfiguriert ist (brauche ich offline ja nicht). Aber ich verstehe nicht ganz, warum das Modul überhaupt für die Erstellung der Bookmark-Nodes Mails versendet/benutzt. Hm.
Ja, haste recht. Nötig ist das eigentlich nicht. Ich hab das nur gerne, wenn ich über Sachen, die in meinem CMS passieren über Email benachrichtigt werden. Das ist sozusagen ein Poormans-Backup. 🙂
Na toll. Kommentar schon wieder verschlungen.
Den Aufruf von feedimporter_sendmail_bookmar() habe ich auskommentiert. Trotzdem: „warning: Invalid argument supplied for foreach() in […]feedimporter.module on line 156.“ Schreibt’s und „importiert“ nur den Node-Titel ohne URL. Zugleich zeigt das Archiv jene Bookmarks doppelt an. Hm. Hm.
Klingt ganz so als hätte Delicious seinen RSS-Output verändert. Männo. schau ich mir am Wochenende an. Ok?
Sonst kannste aber auch selber mal Hand anlegen:
In der Delicious Funktion
feedimporter_delicious_sxml2items()
einfach mal am Anfang des ersten foreach
print_r($item);
machen und schauen, wie das XML aussieht
und dann entsprechen die Zuordnungen in den Zeilen darunter anpassen.
Ist nicht soo schwer.
Bin ich schon dabei 😉 Der RSS-Output scheint noch so zu sein, wie ihn das Modul erwartet.
Kann es sein, dass er beim foreach von $item->topics->Bag->li (die beanstandete Zeile, siehe oben) meckert, weil ich – faul wie ich bin – die wenigsten Bookmarks getaggt habe? Keine $item->topics->Bag->li ergo „invalid argument“?
Oh. Ja. Dass kann sein. Dann mach doch mal sobuz ein
if(is_array($item->topics->Bag)) um das zweite Foreach. 🙂
Japs, keine Fehlermeldungen mehr. Aber auch keine Tags. Bag => li => […] scheint leer zu sein(?). Hm.
Da hat es sich jetzt gerächt, dass ich damals mit dem Format „Entität || Titel“ bei delicious angefangen habe. Nja, wird jetzt eben wieder rückgängig gemacht.
Und weil ich sowieso gerade das Feedimport-Plugin hier umgeschrieben habe (Export angepasst, damit ich die Lesezeichen wiederum unkomplizierter in Drupal reinbekomme), werde ich mir meine eigene Version des Feedimporter-Moduls zusammenschustern. Wobei „eigene“ hier als „die mir wichtigen Teile des Feedimporters rauskopieren und anpassen“ zu verstehen ist ;]
Die Sache mit den Tags nehme ich besser erst dann in Angriff, wenn die bis dato gesetzten ~600 Lesezeichen in Drupal gepackt sind.
So, Import läuft (abgesehen von den Tags, grmpf). Ich habe eigentlich nur eine Sache verändert: die URLs werden jetzt, bevor sie in der DB gespeichert werden, durch feedimporter_get_redirect() gejagt. Ist zwar leistungsintensiver, aber irgendwie mag ich nicht z.B. Feedburner-URLs in der DB haben, deren redirect-Abfrage vielleicht in sechs Monaten nichts bringt (wenn mich nicht alles täuscht, löscht Feedburner doch die Redirects nach ein paar Wochen, sofern der Account gelöscht wird?). Klar, Links sind ohnehin mehrheitlich nicht für die Ewigkeit, aber trotzdem… Hm.
… und wieder rückgängig gemacht, nachdem ich nun schon zum dritten Mal den drupalschen Cron-Lauf abgeschossen habe 😉
Nebenbei hab ich jetzt auch eine nette Navi für die Posts (in der Einzelansicht von Nodes Links zum vorherigen und zum nächsten Node, wie es hier eben ist) zusammengewürfelt.
So, Tags werden nun ebenso importiert und gespeichert. Bei der zuvor verwendeten URL („http://feeds.delicious.com/rss/username“) werden die Schlagworte im Attribut eines selbstschließenden Tags ausgegeben und das nur als delicious-Link. Urgs. Unter „feeds.delicious.com/v2/rss/username“ ist das zum Glück nicht so. Ein bisschen umgestellt und nun mag auch die Verschlagwortung importiert werden. Fein.
Nebenbei: Ist es so gewollt, dass in der feedimporter_nodeapi() nicht geprüft wird, ob tatsächlich der jeweilige Bookmark-Node in der Einzeldarstellung gezeigt wird? Denn wenn der Node das nicht wird, sind einige der dortigen Anweisungen unnötig. So wird beispielsweise beim Aufruf des Archivs für jedes Bookmark feedimporter_get_redirect() durchgezogen, was das Laden der Seite merklich verzögert. Ich hab da einfach mal eine if-Anweisung anhand von arg() reingeklöppelt.
So. Sorry, für den langen Ausfall. Die Migräne hat wieder ihren Tribut gefordert am Wochenende.
1. Dass feedimporter_get_redirect() zu inperformat ist, wundert mich eigentlich. Das lief bei mir eigentlich ziemlich ordentlich. Aber das ist ja auch schon ne Weile her.
2. Für „Links zum vorherigen und zum nächsten Node“ hätte ich Dir auch mein „back and forth“ Modul zukommen lassen können. Vielleicht können wir das die Tage mal zusammenführen.
3. Was war denn eigentlich das Problem mit den delicious Tags? Das hab ich immer noch nicht verstanden.
4. feedimporter_nodeapi(): Schick mir wenn’de Zeit hast, mal die Anpassung. Dann ergänze ich das bei mir auch.
Sollten wir für all die Drupal-Modul vielleicht mal nen Git-Hub-Repository einrichten? Ich drück mich da ja schon seit langem vor …
1. Das wiegt auch sicherlich bei ein, zwei, drei geladenen Bookmark-Nodes nicht so schwer, meine ich. Kann auch gut sein, dass das einzig hier bei mir lokal lahmt. Ich tendiere jedoch grundsätzlich erstmal dazu, dass alles, was lokal nicht besonders fix passiert, auf dem shared webspace hier ebenso nicht besonders flott laufen wird.
2. Ich hatte überlegt anzufragen, aber dann habe ich es lieber selbst probiert. Ist auch ok, Drupal-Modul Training und so 😉
3. Unter „delicious.com/rss/username“ sehen die Tags so aus:
<taxo:topics>
<rdf:Bag>
<rdf:li rdf:resource="http://delicious.com/fymmie/Denken"/>
[usw.]
Mit wegge-ereg_replace’ten (gnihi) Namespaces gab SimpleXML mir hier für topics->Bag->li jeweils nur ein leeres SimpleXML-Objekt zurück. Überhaupt etwas unschön, dass die eigentlich wichtigen Informationen nur in ein Attribut gepackt werden. Unter „delicious.com/v2/rss/username“ sehen die Tags hingegen so aus:
<category domain="http://delicious.com/fymmie/">Denken</category>
Weniger Namespaces, nicht dermaßen verschachtelt und Tags, die mit Daten gefüllt sind und wo man diese nicht einzig nur aus dem Attribut extrahieren kann/muss. Zumal die v2/rss-Variante inzwischen auch der Standardfeed von delicious zu sein scheint.
4. Ich hab da in der Titelanzeige der Nodes die Domain rausgeschmissen – stattdessen erscheint da jetzt nur „Lesezeichen: $node->title“. Und deshalb reicht es bei mir, die zwei Zeilen
$url = feedimporter_get_redirect($url);
$domain = t("Bookmark");
mit einem „if (arg(0) != „archive“)“ zu umschließen, da es unnötig ist, bei der Ausgabe der Titel bei allen Bookmarks die redirect-URL abzufragen. Läuft damit auf der Archiv-Seite nun spürbar schneller. That’s it 🙂
Gute Idee, mit dem Git-Hub-Repository. Zumal ich da hoffnungsvoll vorbeigeschaut hatte, bevor ich mich selbst an einer „back and forth“-Funktionalität versucht hatte 😉 (ist bei mir nur ein zusätzlicher Block im leertraum-Modul)
HTH
Schreibe einen Kommentar