Welche Funktionen kann man überschreiben?

Funktionen die mit theme_ beginnen kannst du meinst in der template.php Datei mit phptemplate_ oder themename_ überschreiben. Überschreiben einer Modulfunktion sollte meist nicht nötig sein. Ändern von Formularen geht ja z.B. mit form_alter().

gruß pebosi

Man kann sämtliche Views-Funktionen überschreiben. Warum diese und andere nicht? Muss das Modul das erlauben, und woran erkennt man das, ob es nun möglich ist oder nicht?

Mit form_alter() kann man leider nicht alles machen, habe schon einige Sachen versucht, die ich dann anders lösen musste, weil es einfach nicht ging, definitv nicht..

hook_user() werden wohl auch sehr viele überschreiben, jedenfalls ergänzen. Das geht doch auch, warum dann nicht alle Funktionen? Welche? Welche nicht?

Bei "gmap_location_user_html()" habe ich lange gesucht, schließlich ging es keinesfalls über form_alter sondern eben über "phptemplate_gmap_location_user_html()". Aber woran erkennt man das nun, wie man es machen muss?

Vielen dank.

Vielleicht hat noch jemand eine Idee oder gibt es eine Doku?

Ja, gibt es: http://api.drupal.org/api/group/hooks/5

Danke.

Was dort steht, wusste ich schon.
Die Hook-Funktionen dort sind für den Core oder mitgelieferte Module.

Mir geht es um selbst installierte Module.
Wann kann man bei weiteren Modulen mit der Hook-Methode erweitern und wann nicht?

Muss man da nur herumprobieren oder gibt es da eine Regel?

Zunächst: Hooks werden nicht überschrieben, sondern implementiert. Meistens werden alle Implementierungen eines Hooks nacheinander aufgerufen. Wenn dem nicht so ist, dann weil es einfach nicht angebracht ist.

Beispiel:

Es wird nur die Implementierung von hook_form aufgerufen, die von dem Modul bereitgestellt wird, das auch den Inhaltstyp (Knotentyp? Nodetype? Was ist hier die bevorzugte Terminologie?) bereitstellt. Andere Module können dieses Formular durch Implementierung von hook_form_alter modifizieren, alle Implementierung von hook_form_alter werden ausgeführt.

Bei Theme-Funktionen kann man eher davon reden, das etwas überschrieben wird, da pro Seitenaufruf nur ein einziges Theme aktiv ist.

Sie werden vom Core und von mitgelieferten Modulen bereitgestellt; zur Implementierung in eigenen Modulen.

Beispiel:

Du möchtest wissen ob es sich bei der Überarbeitung einer Seite um eine sprachliche Änderungen, eine inhaltliche Anpassung oder eine komplette Überarbeitung handelt. Dazu schreibst du ein Modul foo, das

1. hook_form_alter implementiert (foo_form_alter), so das die notwendigen Formulare um ein entsprechendes Eingabefeld erweitert werden,
2. hook_nodeapi implementiert (foo_nodeapi), so das Einträge in das bereitgestellte Eingabefeld zu entsprechenden Zeitpunkten validiert, gespeichert, geladen, angezeigt werden.

Grundsätzlich kann man immer mit der Hook-Methode erweitern.

Beispiel:

Organic Groups erlaubt es, Inhalte nur einer bestimmten Gruppe zugänglich zu machen. Dazu fügt Organic Groups in der Funktion og_form_alter (eine Implementierung von hook_form_alter) dem Formular ein Feld hinzu, in dem Gruppen ausgewählt werden können. Wenn du diese Funktionalität nicht haben willst, dann kannst du ein Modul nog schreiben, das in der Funktion nog_form_alter (deiner eigenen Implementierung von hook_form_alter) dieses Feld wieder entfernt. Du musst nur sicherstellen, das dein Modul schwerer ist als Organic Groups, damit deine Implenmentierung nach der von Organic Groups ausgeführt wird.

Einige selbst installierte Module bieten auch selbst Hooks an.

Beispiel:

Das Workflow-Modul bietet hook_workflow an. Implementierungen von hook_workflow können Zustandsübergänge verhindern und nach Zustandsübergängen Aktionen auslösen. Man kann also das Verhalten des Workflow-Moduls auf bestimmte Art und Weise beeinflussen.

Zu den am häufigsten verwendeten Module existiert Dokumentation direkt auf drupal.org, z.B. das Content Construction Kit Handbook oder Views Documentation. Dort ist dann auch erwähnt, welche Hooks das entsprechende Modul anbietet. Ansonsten hilft ein Blick in den Quelltext des Moduls.

Danke für die ausführliche Info.

Aber das scheint einfach zu kompliziert zu sein.
Ich schau natürlich in den Quelltext und sehe dann dort eine Funktion, die zwar was macht, aber nicht ganz das, was ich will.

Die Frage ist dann immer, wie kann ich diese Funktion nun ändern oder erweitern, ohne den Quelltext des Moduls selbst zu verändern. Manchmal geht es mit hook_form_alter, aber nur selten und was ist in all den anderen Fällen? Warum lassen sich manche Funktionen mit neu implementieren hook()s erweitern und manche nicht? Die Frage bleibt also, denn klar ist das noch lange nicht ...

Vielen Dank.

Hooks werden aufgerufen durch module_invoke oder module_invoke_all. Wenn du also siehst, das eine Funktion eine dieser Funktionen aufruft, dann weißt du, das du sie mit einem Hook beeinflussen kannst.

Manchmal werden Hooks auch durch call_user_func_array aufgerufen; dann ist das aber im Quelltext dokumentiert.

--

module_invoke heißt doch, dass ein anderes Modul aufgerufen wird.

Ich verstehe das nicht ganz:
Nur weil eine Funktion ein anderes Moduls aufruft, ist diese Funktion über hook() beeinflußbar??? Wo ist der logische Zusammenhang?

Es wird ein Hook in einem anderen Modul aufgerufen. Die Implementierung dieses Hooks in dem entsprechenden Modul beinflusst, wie sich Drupal verhällt. Aber du hast schon recht, meistens wird module_invoke_all verwendet.

--

Drupal setzt einige Konzepte der Objektorientierung um, ohne dabei neuere OO-Features von PHP zu nutzen. Über die Hooks ist es so möglich vorhandene Funktionalitäten zu erweitern / überschreiben, so wie es aber auch weiterhin möglich ist Methoden davor zu bewahren (Sichtbarkeit). Für welche Funktionen nun was zutrifft liegt ist der Entscheidung des Modul-Entwicklers überlassen. Es entspricht in der OOP privaten und öffentlichen Methoden (zumindest in den OO-Sprachen, die dieses Konzept umsetzen, da fällt Smalltalk also raus), wobei öffentliche Methoden diejenigen sind, die das Arbeiten mit dem Objekt (Modul) überhaupt erst ermöglichen und private Methoden sind diejenigen, die lediglich für interne Zwecke benötigt werden und wo ein öffentlicher Zugang sogar schädlich sein kann, weil zu tief in die Eingewweide eingegriffen werden kann.

Du hast vermutlich auch kein Problem damit jemandem zu sagen, was du beruflich machst, wirst aber nicht jedem der fragt auch freimütig deine Verdienstbescheinigung unter die Nase reiben...

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Ja, objektorientierte Programmierung und Sichtbarkeit und öffentliche und private Funktionen, das ist alles klar.

Aber wie erkennt man, wenn man den Quelltext eines Moduls ansieht, ob nun eine Funktion mittels hook() zusätzlichen Code implementieren erlaubt oder dies bei einer Funktion nicht möglich ist und wie weiß man, welche Methode man wann anwenden muss?