Drupal und ich

eeeem und wo ist die frage? :D

er wollte uns damit sagen, dass Drupal für ihn zu hoch ist.
Wenn Drupal für Communitys nicht geeignet ist, dann frage ich mich doch warum soviel grosse erfolgreiche Sites es verwenden und Drupal alle Preise in der Richtung abräumt.
Mein Tipp: Versuchs doch mal mit ner http://www.drupalgardens.com/ Website.
Da brauchst du Drupal nicht zu verstehen und nix selber machen.
Drupal ist das Linux unter den CMS, und nicht das Ipad.
Drupal rockt..........

wusste ich es doch. hmmm ich find drupal auch zum entwickeln genial. :D ich bin zu frieden auch wen es zeiten gibt ab denen ich fluche wie dumm dies und das ist liegt es im endefeckt zu mehr als 90% an mir weil ich nicht kapiere was geht.
ich sage nur drupal FTW. :D

@OP
Sinnlose Rumpöbelei. Schreib es das nächste mal einfach in dein Tagebuch... Und nimm wieder phpnuke

Hi,
ich glaube es kommt ihm auf die performance an.

Es kommt sehr stark auf den Anwendungsfall an wie man Drupal einsetzen sollte.

1.
Es wird oft der Fehler gemacht dass man versucht komplexe Anwendungsfälle mit
vorhandenen Modulen abzudecken.
Das ist meistens sehr schlecht.
Habe selbst erlebt wie Drupaler für eine einfache Anwendungsfälle 20-50 Module
installieren mussten für welche ich nur 1 selbstgeschriebenes Modul brauchte!

2.
Bei performanten Drupal Anwendungen sollte man kein CCK benutzen,
da CCK die Datenbankzugriffe pro Datensatz exponentiell in die Höhe treibt.
Sieh es Dir mal im PHP Debugger an.

Das mit Deiner Community geht allerdings mit Drupal ziemlich einfach und dafür brauchst ausser dem Drupal Core
eigentlich kein einziges weiteres Modul.

Lieber Gruss

@loony, nachdem es für meinen Beitrag kein eigenes Forum gibt, musste ich es halt hier her schreiben.

@Rene, wie kommst du zu der Annahme das Drupal zu hoch für mich ist? Das einzige was bei Drupal fehlt, ist eine ordentliche Logik. Meiner Meinung nach natürlich! Wenn Drupal das Linux wäre, was wäre dann wohl Typo3???

@Cyberschorsch, kein Kommentar

@Hyp1, du hast meinen Beitrag wenigstens verstanden, und du musst zugeben, dass es zwar Unmengen an Modulen geschrieben wird aber die meisten sind eben aus der Not anderer entstanden. Das bedeutet man installiert sich für jeden noch so kleinen Blödsinn zig Module. Klar könnte man das alles mit ein zwei eigenen Modulen lösen, doch dann hätte doch Drupal an sich keinen Sinn mehr. Dann kann ich gleich selber eine Seite zusammenprogrammieren die eben all das kann.
Zu 2.) für ein Script wie Drupal welches etwa 2mb groß ist, den php-Speicher auf mindestens 64ram zu erhöhen kann und darf nicht sein! Schon das zeigt wie unlogisch Drupal aufgebaut ist
Was ich dir sicher nicht glaube, dass es möglich ist eine Community mit den Core-Modulen herzustellen! Außer wir haben unterschiedliche Ansichten zu dem Wort Community.

MfG
alex01

Aber das modulare Prinzip hast du schon verstanden oder? Wo ist das Problem? Das du nicht ein "Community-Modul" hast, welches dir schon alles fertig serviert und du es dann dem Kunden nur noch verkaufen musst?

Und erklär mir mal die "Logik", von der Größe eines Scriptes über den benötigten PHP Speicher zu urteilen.

Mit Community meine ich Benutzer können sich
anmelden Beiträge erstellen, kommentieren.

Wie ich bereits gesagt habe ich würde Drupal nur
für das Benutzer Management , Interalization und
für das Ändern des Contents benutzen.
Für eine Community reicht der Drupal Core.
Willst Du Images dann noch das Image Modul
Willst Du internationalization dann noch i18n
das ist schon alles.
Willst Du WYSWYG dann halt auch noch TinyMCE o.ä.

Drupal ist ein CMS und kein Warenwirtschaftssystem
kein Informationssystem, kein Sozial Network, etc.
Solltest du einen Anwendungsfall haben der mit vorhanden Modulen
abzudecken ist hast Du Glück gehabt.

Typo3 noch viel schlechter als Drupal.
Erstens brauchst Du auch zig Module
Zweitens musst PHP und TYPO3Script können um hier etwas zu machen.
D.h der Code wird hier gleich 2 X interpretiert (PHP und Typoscript)
Typo3Script zerschmettert auch noch die Objektorientierung die man
mit PHP machen könnte.
Die Fehlersuche gestaltet sich auch viel schwieriger weil
man den PHP Code Debuggen kann, das Typoscript aber nicht.
Das Typo3 besser sein soll als Drupal kann ich nicht Nachvollziehen und ich habe auch schon einiges mit Typo3 gemacht.

Fazit:
Wenn jemand genaue Vorgaben für ein zu erstellendes System hat (UML,ERD, Use Case, Klassendiagramm)
ist es eine sehr schlechte Idee das mit vorhandenen Drupal Modulen zu versuchen.
Wenn Du kein Modul schreiben kannst bist Du sowieso auf andere Entwickler angewiesen.

Alex01, du hast keinen PHP Debugger laufen, oder?
Ich gebe Dir aber in dem Punkt recht:
Es werden oft Module benutzt wo eigentlich keine benötigt werden.
Die meisten Dinge könnte man direkt im PHP Input Filter erledigen.

@Hyp1

Wenn du Drupal als CMS verstehen möchtest, musst du auch gewisse Konzepte eines CMS nachvollziehen. Du kannst doch nicht ernsthaft vorschlagen, per PHP Input Filter Dinge zu erledigen. Das ist nicht nachhaltig und definitiv gefährlich. Wenn du Content per CMS verwaltest, hast du Redakteure die den Inhalt erstellen und verwalten. Denen dann a. zuzumuten, php zu schreiben b. und denen überhaupt so eine Macht zu geben.

Zu der Performancegeschichte möchte ich nur sagen, dass in den meisten Fällen eine schlecht konfigurierte Serverumgebung und schlechte Planung im Vorraus maßgebend für Performanceschwächen sind. Drupal bietet die Möglichkeit, die Seiten beliebig zu skalieren, sogar den Cache und weiteres mit NOSQL zubearbeiten (MongoDB).

Dein Fazit ist für mich auch nicht nachvollziehbar. Wenn ich meine Projekte modelliere dann kann ich sie zu 99% wunderbar in Drupal umsetzen. Woran soll es denn scheitern, wenn ich mit UML meine Klassen mache um bspw. Inhalte zu definieren? Es ist alles an Werkzeugen da. Ich habe das CCK, ich habe Taxonomy etcpp. M

Bitte untermauer dein Fazit noch mit beispielen bzw besseren Argumenten als einfach zu sagen, dass es eine schlechte Idee ist.

Ich arbeite nun seit Ende Dezember 2009 an Drupal und muss auch sagen, dass es teilweise nicht so einfach ist.

Manchmal kommen Augenblicke da läuft es sehr gut aber dann vergehen doch wieder Stunden in denen ich fast nichts schaffe weil ich an "Miniproblemen" hängen bleibe und sie erst spät gelöst bekomme und merke, dass ich doch noch nicht all zu viel verstanden habe. Das kann durchaus frustrierend sein.

Allerdings liegt das nicht an Drupal sondern an mir - ich spreche kein PHP, verstehe Hooks nicht usw. - daher ist es für mich im Moment schwierig das Gesamtbild zu erfassen.

Weiterhin ist es teilweise schwierig gewünschte Funktionen in "Worte" zu fassen - wonach muss man genau suchen wenn man dies oder das lösen will - ohne die richtige Bezeichnung findet man das passende Modul nicht und denkt dann "Son Scheiß" - passt man seine Suchphrasen aber an, merkt man, dass unter den knapp 4300 Modulen (für die 6er Version) eigentlich fast alles vorhanden ist was man sich nur erträumen kann. Oft in mehrfacher Ausführung.

In den 7 Monaten in denen ich mit Drupal arbeite, gab es im Endeffekt noch kein Problem, dass nicht gelöst werden konnte. Und weil Drupal und die Module so umfangreich sind, gibt es bei mir fast täglich ein AHA-Effekt und das finde ich wiederum spannend und inspirierend.

Außerdem bin ich auf der anderen Seite froh, dass Drupal nicht so einfach einzusetzen ist (für ein umfangreiches Projekt) denn das hält die Konkurrenz immer auf Abstand. Mit „schnell schnell“ ist bei Drupal nichts zu machen und viele Mitbewerber versuchen sich erst gar nicht einzuarbeiten oder aber geben nach kurzer Zeit auf.

Somit kann ich – mit genügend Elan und Arbeitseinsatz - die geilsten Projekte erstellen und Mitbewerber – mit ihren selbst zusammengeschusterten Projekten – sind meilenweit entfernt.

Das finde ich super.

Außerdem setzen verdammt große Plattformen Drupal ein – z.B. die Community von zeit.de - whitehouse.gov und - wenn sich nichts geändert hat - auch MTV – das sind doch wirklich klangvolle Namen.

Ich glaube kaum, dass solche Firmen/Institutionen Drupal einsetzen würden wenn das CMS "schrott wäre".

Ich kann für mich sagen, auch wenn es teilweise nicht so einfach ist, dass ich Drupal auf keinen Fall durch ein anderes CMS ersetzen werde – die tägliche Arbeit mit Drupal finde ich anregend und spannend und obwohl ich noch viel lernen muss, ist Drupal für mich das absolute Allroundtalent. Und bzgl. der langen Einarbeitungszeit halte ich mich einfach an das Zitat: "Nur Mühe bringt Ehre"!

Bei meinem aktuellen Projekt setze ich momentan knapp 106 contrib-Module ein - die Übersicht zu behalten ist zwar nicht so einfach - aber das Projekt läuft wunderbar und mit nem schnellen Server ist das alles überhaupt kein Problem.

Der PHP Input Filter ist nur für den Entwickler anzuzeigen und nicht
für die Benutzer!
Das Konzept ist genau gleich wie in jedem anderen Modul!
Der PHP Input Filter ist ein Modul wird durch hook_block ausgeführt

Zur Performance:
Das sind am seltensten schlecht konfigurierte Server Umgebungen
sondern schlecht geschriebene Anwendungen.
Da die meisten Hoster Ahnung haben was Sie machen.
Verwende mal XDebug und den Cachegrinder um zu sehen was wo performant ist.

Wie kannst Du ein ERD Umsetzen wenn Du CCK benutzt?
Ich rede von Objekt Relationalen Mapping auf die Datenbank!
Wenn Du mit CCK eine Entität erstellst sieht die Datenbank
vollig anders aus als als im ERD.
Beispiel:
Du sollst eine vorhandene DB Anwendung in Drupal umsetzen das Schema soll erhalten bleiben.
Entität Adresse(Name,Vorname,etc)
Machst du das mit CCK kannst Du das Schema nicht erhalten, da ein CCK in der Tabelle CCK (und Relationen) gespeichert
wird und nicht in der Tabelle Adresse (die eigentliche Entität)!

LG

Hey Leute,

alles sind Philosophiefragen und es führen ja bekanntlich verschiedene Wege nach Rom.
Ich vergleiche ein CMS mit einer Redaktion.
Z.B. bei einer Zeitung hat der Leser sowie der Autor keinen
Einfluss darauf wie oder wo Inhalte angezeigt werden.

Wann würde ich CCK einsetzen?
Nur wenn es unbedingt nötig ist, dass Redakteure eigenen Content Typen auch wirklich
erstellen müssen.
Anders gesagt, wenn sich Gegenstände ständig ändern.
Aber auch dann würde ich überlegen ob ich CCK wirklich verwenden würde.

Zur Erklärung:

Ich habe eine lokale Installation mit nur dem Drupal Core und 2 eigenen Modulen.
Firefox cache geleert Hauptseite aufgerufen (743ms):
CCK enabled cache gelehrt Hauptseite aufgerufen (1,33s)
Fast die doppelte Zeit zu laden.

Habe dann einen Content Typ CCK erstellt mit nur einem Feld CCKFeld.
Das ganze im Debugger angeguckt.

Datei: content_module.include
Methode content_storage wird aufgreufen wenn ein CCK geladen,upgedated,gelöscht wird

Hier die Erklärung:
Also beim Laden meines Content Types
(load switch)
wird erstmal 2x auf die db zugegriffen das resultset geholt und string vergleiche gemacht
um zu ermitteln welche felder mein contenttyp hat.
Dann wird nochmal auf die DB Zugegriffen um die Feldwerte zu holen.
Dann ist noch schlimmer, dass offensichtlich die Relationen in einen DB
Feld gespeichert werden und dann String geparst wird.

Der Entwickler schreibt es sogar selbst im Kommentar.
Mit einem INNER JOIN (ein einziger Zugriff auf die DB) ist der DB Server zig mal schneller (Aufgrund der
Relationalen Arithmetik)
als der PHP Interpreter mit dem parsen von Strings!
Geschätzt sind es ungefähr 6 bis 8 DB Queries im ein einziges Feld zu holen.
Noch schlimmer ist folgendes:
Bei genauerem Hinsehen ist jedes Feld meines Types ein Drupal auch gleich ein Node( muss auch upgedated werden).
In der Tabelle content_node_field
Feld db_columns sind die Felder meines Content Types in einem Textfeld serialisiert (Ist ja nur eins)
Das wiederum bedeutet, dass eine zu x:n Beziehung in einem Textfeld gepeichert wird!
Das ist eigentlich schon ein Design Fehler (Schema) und für Performance sicher nicht zu empfehlen.

Der Beitrag hätte auch gleich n Artikel werden können ;-)
Musste nochmal nachtreten, Sorry

PS:
Habe auf der Schweizer Tastatur leider kein scharfes S

Jetzt muss ich mich auch mal kurz einklinken, allerdings weniger in der "ursprünglichen" Diskussion:

@Hyp1
Der Vorteil ist, dass man CCK gut in Views integrieren kann ;) (ja, ich weiß, Views macht die Seite auch langsam, ist aber dafür ganz praktisch)

Allerdings würde ich bestimmte Inhaltstypen auch lieber mit eigenen Feldern ausstatten, anstatt CCK zu verwenden, dann muss ich mir die Daten nicht mehr in 5 verschiedenen Tabellen zusammensuchen.

Kennst du evtl. ein Tutorial, wie man eigene Felder in Inhaltstypen in Views einbinden kann? Bisher bin ich daraus noch nicht so richtig schlau geworden, bin allerdings (noch) auf Views angewiesen, denn z.B. die Calendar-View ist einfach praktisch und nicht so schnell nachgebaut ;)

@Exterior,

dass sich CCK sehr gut in Views integrieren lassen ist ein gutes Argument.
Das gilt allerdings auch für eigene Content Typen und Views verwende ich selbst
verständlich.

Wenn ich richtig verstehe möchtest Du eine Entität aus einer eigenen Tabelle laden
und in einem View anzeigen?

Deinen View kannst Du ja nach Node Typ filtern.
Da jeder Content Typ in Drupal auch ein Node ist
muss Dein Content Typ um Node erweitern. ($node enthält auch daten wie published,user,created)
Den $node->type kannst Du selbst setzen.

Nun gibt es verschiedene Möglichkeiten.
- Du speicherst die ID Deines Datensatzes mit dem Node
- Deine Tabelle enthält ein Feld mit nid (Node id)
(Damit Du immer eine Referenz von Deinem Typ auf den Node bekommst)

Einen Node Programmatisch speichern:
http://drupal.org/node/178506

Zu guter letzt solltest Du noch Deinen Node Typen vom Display trennen (w.g Theming).
benenne node.tpl.php um nach node-xxxxx.tpl.php
xxxxx=Dein_Content_Typ

Ich mache es allerdings anders:
Ich mache meist schreibe ein Block Modul weil ich möchte, dass
Drupal das Datenbank Scheme installiert und deinstalliert.
Ich möchte auch das Drupal die DB Verbindungen verwaltet
deshalb verwende ich auch Drupals db_query.
In diesem Modul implementiere ich einen Hook zur node API
hook_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL)
Diese Funktion wird aufgerufen wenn eine Node geladen,gespeichert,geändert, etc. wird
da mache ich alles (speichern,ändern,etc.) in dieser Methode.
http://api.drupal.org/api/function/hook_nodeapi/5

Fazit:
Dein Content Typ muss Node erweitern oder implementieren, dann kannst Du alles Damit machen.

Hoffe es gut erklärt zu haben

LG

Gut erklärt durchaus ;)

Allerdings zielte meine Frage eher darauf ab, wie ich meinen eigenen Inhaltstyp in Views integrieren kann.

Beispiel:
Ich benutze Calendar und Date für Termine. Bei der Calendar-View muss man als Argument und als Feld das Datums-Feld auswählen. Also fügt man ein Feld hinzu und wählt dann in der Liste das Datumsfeld.

Mich interessiert nun folgendes: Ich erstelle über ein eigenes Modul einen eigenen Inhaltstyp mit eigenen Feldern, unter Anderem einem eigenen Datumsfeld. Die Werte dieser Felder werden alle in einer extra Tabelle gespeichert (diese Tabelle enthält als Primärschlüssel auch immer die nid).

Wie bekomme ich es nun hin, dass ich in der Calendar-View unter Felder auch mein eigenes Datums-Feld auswählen kann? Denn das taucht dort ja nicht einfach mit auf.

benötigt CCK und ein paar andere Module Date API, etc.
Dieses Modul benötigt ein CCK Feld als Datumsfeld.

Such in dem Calendar Modul
warscheinlich xxxx_form_alter
oder xxxx_menu mal wo und wie die Content Typen geholt werden.
Ich kann nur vermuten dass das Calendar Views Modul auf die Felder in $node->content[''cck_xxxx_field"];
zugreift.
Das könntest Du mit den Feldern deines Objekts überschreiben.

Ich weiss leider nicht ob das Modul nur CCK Contenttypen erlaubt
oder alle (also auch page,story,etc.).
Wenn es nicht nur CCK verarbeiten kann dann solltest Du die Felder deines
Content-Typen in $node->content haben und somit sollten die auch ausgewählt werden können.

Wenn Das Calendar Modul kein $node->type unterstützt
musst du es so erweitern das auch diese untersützt werden.

Ich kenne das Modul nicht aber ich meine es sollte es eigentlich das schon machen
wenn dein eigener Content-Typ auch ein Node ist.
Evtl. musst du das Datums Feld in einer bestimmten Weise benennen.('evtl. cck_date' oder 'date' ?)

Gruss

@Exterior

Da ich das ganze gerade machen musste,
habe ich jetzt die korrekte Antwort auf Deine Frage.
Evtl. sollte ich ein Tutorial schreiben wie es genau geht
sobald ich Zeit habe.

Hier die Lösung zu Deinem Problem:
Du musst in deinem Modul den hook_views_data implementieren.
Dieser view hook ermöglicht das anzeigen der Felder eines eigenen Content-Typen.

Hier macht Du join von Deiner Tabelle zur Node Tabelle.
Und hier kannt Du die Felder angeben, die in Deiner View ausgewöhlt werden können.
(Ich verwende die Views2 API)

Dieser Code funktioniert bei mir (Tabelle xxxx_rabatt)
xxxx=modulname

Hoffe das hilft :-)
Gruss

a) Das konzept von php input filter ist einfach sowas von schlecht, da kann man keine Worte finden.
Ein Problem z.B. ist, dass der Code nicht in Versionskontrolle sein kann, aber ich bezweifle bei manchen, dass sie dieses Konzept kennen.
b) php input filter ist nicht performant. Eval ist nicht performant. Punkt.
c) Das Konzept ist anders, der PHP Code liegt in der DATEN-Bank. Man lernt schon in der Schule dass Code und Daten getrennt sein sollen.
d) Der PHP Input Filter wird durch check_markup -> php.module ausgefuehrt.

Warum sollte man CCK benutzen , spätestens in Drupal7.

The magic is called "pluggable field storage". Dank der pluggable field storage kann man die Felder anstatt in der Datenbank auch z.B. in MongoDB speichern.
Dort skaliert das ganze dann quasie unendlich. Aber das ist Drupal7.

In Drupal6 ist der riesige Vorteil, dass man sich Entwicklungsarbeit spart. Wenn man zusätzlich noch richtige Caching-Strategien fährt, dann macht CCK wenig Probleme.

Hi

ich finde diesen Thread sehr erheiternd! Hier werden Sachen in den Raum gestellt und Aussagen gemacht, die völlig am Thema vorbei gehen.

Alle Thesen aus dem ersten Post sind völlig haltlos, da Drupal viel für genau solche Seiten verwendet wird, für die es ja angeblich nicht geeignet ist. Als Beispiel kann man einfach mal in die Modul Liste von drupal.org oder http://groups.drupal.org/node/64283 whitehouse.gov schauen, um ein Beispiel zu haben, das es doch funktioniert.

Alles in allem geht es hier um Konzepte und das einzige, was man sagen kann, ist das Drupal wirklich kein einfaches Konzept ist und jedes Modul neue Bausteine mitbringt. Ich bin völlig bei euch, das es am Anfang sehr anstrengend ist und viele Sorgen macht. Aber man sollte sich auf diese Konzepte einlassen oder versuchen sein eigenes Konzept in Drupal einzubringen.

Als Beispiel: CCK ist eine Art Kontent zu unterteilen und zu verwalten. Das besteht aus viel viel mehr, als ein paar Datenbank Feldern und Abfragen. Es bringt GUIs mit und ist um beliebige eigene Felder zu erweitern. Auch kann ich mit diversen Einstellung die Darstellung der Felder manipulieren und über Preprocess und Template nach bedarf darstellen.

Wenn ein besseres Konzept als CCK da ist, dann schreib bitte ein Modul und teile es mit uns. Niemand in der Community wird etwas dagegen haben und du wirst viel Dank erhalten!

@dereine

a.
Ja Du hast recht, es ist nicht der sauberste weg und ich mach es auch lieber mit Modulen.
Aber wenn ich 106 Module installieren und konfigurieren muss wie oben angegeben,
überlege ich schon ob ich Dinge nicht lieber einfacher mache und den schnelleren Weg gehe.
Eine Versionskontrolle ist im PHP Filter Code überflüssig und die verwendeten Module
haben diese ja sowieso.

b. du hast auch hier recht eval ist nicht sehr performant.
Es ist aber um einiges performanter als mehere Zugriffe auf die Datenbank um die Metadaten und Daten der CCK Felder zu lesen.
Ich haben den Test gemacht(siehe oben) und der eval PHP Filter ist um einiges schneller als ein CCK Feld einzulesen.

c.Du kannst Dich auch im PHP Filter Code an das MVC Paradigma halten.

d. Ja der Filter wird wohl dort ausgeführt.

Zum anderen Post:
Das mit dem pluggable Field Storage ist genau das was mir
bisher bei CCK gefehlt hat.
Da CCK anscheinend sowieso in den Core integreirt wird ist das wohl das beste.

Aber solange ich noch mit Drupal 6 arbeite und Datenbank Schemen 1:1 umsetzen muss
kommt für mich CCK leider kaum in Frage :-(

Lieber Gruss und Danke für den Hinweis mit dem pluggable storage

Darum geht es doch genau. Der Code muss in die Versionskontrolle um die zeitliche Veraenderungen, schlechte Fixes usw. zurueckspielen zu koennen :)

Hi,

also irgendwie widersprichst Du dich. Zum einen schreibst Du das es manchmal sinnvoller wäre ein eigenes Modul zu schreiben, statt viele der 6000 vorhandenen Module zu verwenden (was durchaus auch ok ist) - Auf der anderen Seite empfiehlst Du den PHP Input Filter ? - Warum nicht wieder auf das von Dir angesprochene "eigene" Modul verweisen und entsprechende Hooks verwenden ? - Ein Neuling der dieses Thema hier liest könnte durchaus den Eindruck bekommen das PHP in einem Input Filter / Views Argument etc. zu verwenden ok wäre... ich halte dies für einen schlechten Weg.

Gruß Dennis

Ich habe nie behauptet dass PHP Filter der beste
und einzige Weg sei.
Ich sage man kann es verwenden um einfache abgeschlossene
Dinge zu tun bevor man riesen Dinge drum herum baut!

Folgendes:
Du möchtest Content von einer anderen Webeite parsen
und Teile bei Dir anzeigen.
Welches Modul/Module verwendest Du
oder schreibst Du lieber die paar Zeilen selbst?
Sowas muss auch ganz sicher nicht in CVS!
Vewendest Du im PHP Filter den Drupal Core
Funktionen (db_query) ist alles genauso Versioniert
wie sonst auch.

Liebe Güsse

[do:feeds Feeds]. Oder ein ähnliches Modul.
Notfalls wird ein eigenes Modul geschrieben, welches die Funktionalität komplett abbildet oder ein bestehendes Modul erweitert.

Ähm, das wage ich zu bezweifeln.
Es geht darum, dass der selbst geschriebene Code nicht unter Versionsverwaltung liegt. Oder gehst Du davon aus, dass das Erzeugen von Revisionen einer Versionsverwaltung gleichkommt? Dem ist nämlich nicht so.

 Stefan

PS: versuch mal einen Fehler, der zu einem WSOD führt, a) in einem Modul zu beheben und b) in einer Node mit PHP Input Filter zu beheben.

Das parsen einer anderen Webseite
ist Systemübergreifend da kannst Du soviel CVS haben wie Du möchtest,
wenn die die Seite ändern musst Du umschreiben.
Ausserdem glaube ich dass die Drupalentwickler Ihren
Code tatsächlich einchecken.
Du schreibst ein ganzes Modul und ich mache das mit CURL in 2 bis drei Zeilen.

WSOD:
Den findest Du in einem beiden Verionen sehr schlecht
(wenn Du ihn nicht selbst verursacht hast).

LG

Hi,

definiere ein "ganzes" Modul... nur weil Du für Deine CURL Methode nun 4-6 Zeilen brauchst anstatt 2 ? (+ info Datei). Und wer behauptet eigentlich das man eigene Module zwangsläufig in CVS von Drupal.org pflegen muss ? Kleine Helfer Module die nicht unbedingt für die Allgemeinheit zugänglich sein müssen kann man auch super selber mit GIT oder SVN in eine Versionskontrolle packen.

Es behauptet auch keiner das Du gesagt hast PHP Input Filter währe die einzigste Alternative, doch es ist nunmal einfach ein schlechter Stil damit zu arbeiten und gerade Neulingen wird hiermit suggeriert das es ein vernünftiger Weg ist. Nein ist es eben nicht!

Du sagst WSOD lassen sich in beiden fällen gleichermassen schlecht finden ? - Nöp. in einem eigenen Modul bekommst Du die Fehlermeldung so serviert das Du sofort sehen kannst in welcher Zeile Du einen Fehler gemacht hast. Im falle von PHP Input Filter bekommst Du immer die gleiche Zeile gezeigt und zwar irgendwo in drupal_eval(); viel Spaß dabei herauszufinden welcher deiner Input Filter jetzt schief läuft... Natürlich findest Du den Fehler schnell wenn Du ihn selber verursacht hast. Aber was ist im Falle eines Updates ? - Wenn dann einer Deiner Input Filter nicht mehr funktioniert ? Wenn ich mir nun vorstelle das man 20 Nodes hat und in allen zwanzig Nodes PHP Code drin steckt auha das bedeutet bereits jetzt in 20 Nodes schauen wo der Fehler sein könnte... nene das ist kein guter Stil.

Gruß Dennis

Und was genau hat das mit PHP Filter vs Modul zu tun?
Auch den Code in der Node musst Du dann anpassen.

Der Code in der Node ist nicht in einem VCS!
Egal ob CVS, git oder SVN.

Von Finden war nicht die Rede (das geht übrigens recht schnell, wenn man mal in die error-logs schaut), das Beheben ist das Problem. Jedenfalls, wenn der Code einfach in einer Node mittels PHP Input Filter geschrieben wurde.
Dann darfs Du den Code nämlich in der Datenbank suchen und anpassen.
Und das möchte man definitiv nicht tun. Auch nicht bei "2 Zeilen mit cURL".