Nodes per Code selektieren

Eigene DB-Abfragen gehen etwas über Anfänger-Fragen hinaus:
Das geht mit einem Join auf der Tabelle des Fields über die Versions-ID der Entität. Sie auch Beispiele hier:
https://api.drupal.org/api/drupal/includes%21database%21database.inc/fun...

Es gibt übrigens auch die Möglichkeit solche (JOIN-) DB-Abragen mit Views zu bauen und den View dann im custom Code zu nutzen. Oder man kann ich in Views auch die DB-Abfragen anzeigen lassen und daraus auch viel lernen.

Hallo,
bei allem was ich so im G. webmasterforum lese,
rate ich dringend davon ab zuviel an den Cores rumzuschrauben.
Es gibt da zu hauf Webdesigner die genau wegen dieser Bastelei Hintertüren geöffnet haben und dann quarken, dass dass der G.-Riese ihre Seiten gekickt hat.
ich bin zwar Anfänger, aber so wie ich das bisher erfahren habe, gibt es für fast jedes Problem ein stable Modul.

Gruß Frank

Hi,
danke für die Antworten, ich will das Modul eigentlich unabhängig von der Webseite nutzen. D.h. aktuell rufe ich es noch über einen Link auf, das will ich eigentlich noch ändern, so dass es lediglich über die Console gestartet werden kann.
Zur Erklärung:

Ich habe einen Node-Typ, welcher ein Dateiupload besitzt, diese Daten sollen über einen Cronjob verarbeitet werden. Klappt bisher über die Link-Variable auch hervorragend.
mfg
Andy

Hallo Frank,

Ich weiß nicht, was das für ein Forum ist, aber Vorsicht bei Custom Code ist in jeder Webanwendung gegeben. Allerdings kann es auch im Drupal-Core und und Contrib-Modulen Sicherheitslücken geben. Der Thread-Opener machte meiner Meinung nach keine Andeutung, daß es ihm darum geht, den Drupal-Core zu manipulieren. Seine Antwort bestätigt meinen ersten Eindruck, daß er nur ein Problem mit Custom Code lösen möchte.
Es gibt zwar für sehr viele Situationen Contrib-Module, die behilflich sind Probleme zu lösen, aber eben nicht für alles. Einige Dinge sind bei Drupal fast nur mit etwas custom code zu lösen sei es eine Formular-Anpassung mit Hook_form_alter in einem custom module oder eine Template-Funktion. Wenn man dafür konsequent und sorgsam Drupal-Standards anwendet ist das weniger problematisch als es dem Anfänger erscheinen mag. Der Thread-Opener hat allein schon mit seinem Code-Besipiel gezeigt, daß er gedenkt, die Datenbank-Abfrage mit der dafür vorgesehenen sicheren API von Drupal zu machen. Viele Sicherheitslücken auch in Modulen auf Drupal.org – die bekannt werden – haben ihre Ursache oft in selbst gestrickten Datenbank-Abfragen.
Insgesamt ermutigt die Drupal-Community seine Mitglieder sich auf den Pfad des Lernens auch bezüglich des Programmierens zu begeben und ist gerne bereit, dabei zu helfen. Denn nur so gewinnen wir neue Entwickler für Contrib-Module und letztlich auch den Drupal-Core. So gesehen führt meiner Meinung nach der Aufruf, sich auf die bestehenden Module zu stürzen und selbst keinen Code anzufassen dazu, daß wir irgendwann kaum noch Module hätten, bzw. veraltete usw.
Fazit: Der Hinweis auf die Sicherheit ist gut und wichtig, aber ein generelles Abraten vom Programmieren ist schädlich, weil vor allem die Sicherheit durch möglichst viele Entwickler verbessert wird. Das heißt nicht, daß jeder in der Community programmieren lernen muß. Aber alle die lernen wollen sind sehr willkommen.

Moin Moin,

ich denke der bessere Weg ist es zu gucken, dass man ein möglichst passendes Modul findet und versucht dieses anzupassen und dann ggf. auf drupal.org den Modulentwicklern vorschlägt die Neuerungen mit in das nächste Update aufzunehmen.
So können auch andere dieses Modul nutzen und weiterentwickeln. Dreht man mal eben so direkt an den Coreschrauben, gehen nicht nur bei jedem Update die Codeschnipsel verloren, vielmehr weis man auch irgendwann nicht mehr, wo man an welcher Schraube gedreht hat. > So geht es mir zumindest wenn ich mal im Theme was auf float oder 100% oder so stelle aber glücklicherweise kann ich das hier im Forum bei den vorzüglichen Anworten auf meine Fragen ja immer nachlesen.
Und wenn es der Community helfen soll, ist es erforderlich ein detailliertes Logbuch zu führen (wo wurde in welcher Datei was wie geändert).

Es hilft auch hier und da mal etwas zu Spenden!

Gruß Frank

MoinMoin,
also das Modul umfasst lediglich 30 Zeilen und der Code kann auch nur über bestimmte Parameter ausgeführt werden, eine Art Zugriffskontrolle.
Ansonsten denke ich dass ich nicht wirklich am Core-Schraube.
mit besten Grüßen
AndyLicht

Ja klar ist es immer gut zu schauen, ob man Probleme nicht mit bestehenden Modulen löst. Vor allem ist es meiner Meinung nach auch gut, eigene Entwicklungen (auch als neue Module für Drupal.org) nach Möglichkeit an bestehenden Module anzuhängen. So baue ich viel auf Rules auf und für Listen nutze ich fast immer Views. View hat netterweise den Weg in den D8-Core gefunden und wird dann selbst künftig auch für Core-Listen die Datenbank-Abfragen und dessen Visualisierung übernehmen.

Zurück zur Anfangsaufgabe des Thread-Openers: Gefragt ist ein Liste mit Node IDs von Node eines bestimmten Typs und mit einem bestimmten Wert in einem Feld. Da habe ich schon in meinem ersten Kommentar auf Views verwiesen zur Erstellung dieser sehr individuellen Situation. Auch die Weiterverarbeitung von Views-DB-Abfragen in individuellem Code habe ich erwähnt.
Und hier noch ein weiterer Tipp: Man kann Views in Rules als Liste laden, wenn man ein Views Bulk Operations -Field (separates Module) in den View einfügt und diese Liste dann mit Rules abarbeiten. Darüber habe ich in einem Kunden Projekt dieses Jahr eine Mail-Reminder in einem sehr individuellen Workflow realisiert. Im Alltag überlege ich immer zuerst eine Rules-Lösung und schreibe in eigenen Modulen (auch in denen auf Drupal.org) selbst Rules-Events, -Conditions oder -Actions, wenn mir bestehenden Rules-Module nicht weiter helfen.

@drruebe: Nur Du schreibst hier davon an Contrib-Modulen oder dem Core zu hacken. Das hat der Thread-Opener bisher nicht mal angedeutet und ich schon gar nicht vorgeschlagen. Im Gegenteil: Du schlägst hier vor ein Contrib-Modul "anzupassen". Dies ist genauso problematisch wie ein Hack im Core.

Ja, Geld-Spenden und Mitarbeit sind in der Drupal Association und dem deutschen Drupal e.V. gerne willkommen. Eine Mitgliedschaft dort ist übrigens ein erster guter Schritt! Aber vor allem auch Arbeitszeit-Spenden helfen der Community z.B. bei der Organisation von Community-Events, dem Betrieb einer Plattform wie dieser und vor allem bei der aktiven Arbeit am Drupal-Core und Contrib-Modulen.
Wie schon angedeutet bin ich übrigens einer dieser Modul-Entwickler auf drupal.org. Und das heißt, daß ich neben meiner unbezahlten Zeit, die auch an anderen Stellen ich die Community einbringe auch Arbeitszeit "spende" bei der Modul-Entwicklung. Außerdem ermutige ich meine Kunden dazu, individuelle Lösungen nach Möglichkeit so anzulegen, daß diese auch auf Drupal.org der Community übergeben werden können. Das heißt dann, daß meine Kunden gewissermaßen auch etwas gespendet haben, wenn sie mich dafür bezahlen, Code beizusteuern. Das betrifft auch Patches für Fehler, die mir im Alltag begegnen. Das heißt, wer irgendwelche Entwickler engagiert, um für sich oder Kundenprojekte etwas zu programmieren sollte meiner Meinung nach immer darauf achten, ob sich dabei nicht ein kleiner Mehrwert für Drupal.org ergibt, damit wie zurecht schreibst: "auch andere dieses Modul nutzen und weiterentwickeln" können. Das bringt meiner Meinung nach viel mehr als einfach nur Geld zu spenden. Und deshalb halte ich es für wichtig jede(n) zu ermutigen, sich mit dem Programmieren auseinander zu setzen und helfe wie andere Drupal-Entwickler auch gerne bei der Orientierung derjenigen, die selbst entwickeln wollen. Ich komme kaum dazu, mich mit anderen Open Source Communities zu beschäftigen, aber ich bin der Meinung, daß die Stärke der Drupal-Community eben genau darauf beruht, daß wir bemüht sind, den Menschen die Angst vor dem Code zu nehmen, aber das habe ich in meinem vorigen Kommentar ja schon beschrieben.

Hi und ein frohes neues Jahr,
vielleicht muss ich das ganze noch einmal detailierter erklären:

Ich habe ein Contenttype mit 3 Feldern: Title,Datei und Status(boolean) - mit Hilfe dieser Contenttype lade ich Dateien hoch, die verarbeitet werden. In einem bestimmten Intervall sollen diese Dateien verarbeitet werden, dabei werden alle Nodedateien berücksichtigt deren Status false ist. Bisher lade ich leider alle Nodes diesen Types und überprüfe dann den Status, daher hätte ich gerne in der Abfrage den Status mit drinnen. Ich nutze das Modul für keine Visualisierung der Nodes.
Ich habe leider noch keinen praktikablen Weg gefunden, die Dateien direkt beim Abspeichern eines Nodes auszuwerten und in eine eigene Tabelle zu speichern.
mit besten Grüßen
AndyLicht

Man kann zwar mittels Hook an eine Action/Event wie das Speichern eines Nodes operieren, aber auch das geht per Rules über das entsprechende Event. Prinzipiell könnte man mit Rules dann auch Custom-Code ansteuern, aber evtl. hilft Dir ja eine custom Entity, die Du mit Eck (https://drupal.org/project/eck) anlegst und damit auch Custom Daten-Strukturen erstellen kannst. Diese befüllst Du dann ebenfalls mit Rules und kannst somit komplett auf custom Code verzichten.
Das Views-Modul, das gerne auch mit "Ansichten" übersetzt wird dient nicht allein der Darstellung von Content bzw. Contenrt-Listen. Die Ursache des Namens liegt wahrscheinlich auch auf der Logik einer Datenbank-Ansicht (SQL-View). Und wie schon geschrieben, kann man mit Views-Bulk-Operations Views-Datenbank-Abfragen in Rules weiter benutzen und z.B. beim Event Cron-Lauf auslesen und dann auf dem Ergebnis der Datenbank-Abfrage (z.B. eine Liste von Nides, die einen bestimmten Feld-Eintrag haben) dann Operationen ausführen usw.
In Rules stecken sehr viel Möglichkeiten, die Custom Code unnötig machen oder reduzieren hilft. Allerdings muss man sich dafür intensiv in Rules einarbeiten ebenso wie viele Advanced Möglichkeiten in Views nicht so leicht erkennbar sind.