
Kreativer gehts nicht. Bei Smip2Smile gestaltest Du Dein persönliches Geschenk & kleine Aufmerksamkeiten ganz persönlich, ganz einfach und mit Spaß.
Bleibe am laufenden Ball und abonniere mein RSS Feed
Kreativer gehts nicht. Bei Smip2Smile gestaltest Du Dein persönliches Geschenk & kleine Aufmerksamkeiten ganz persönlich, ganz einfach und mit Spaß.
Bleibe am laufenden Ball und abonniere mein RSS Feed
Überblick der Drupal API Änderung von 6.x nach 7.x
Übersetzung von http://drupal.org/node/224333
Liste wird erweitert, sobald es neue Änderungen gibt.
(issue) und (issue) Bei der Implementierung von hook_perm(), muss der zurückgegebene Wert geändert werden:
Drupal 6 unterstützte dieses Format:
Drupal 7 Code muss folgendes Format verwenden:
Vorher waren die Werte die Berechtigung; jetzt ist Berechtigung der Schlüssel und der entsprechende Wert ist ein Array mit dem Titel und Beschreibung der Berechtigung. Sollte es sein, dass die Berechtigungen zusammengesetzte dynamische Werte enthält, wie die Namen der Inhaltstypen. Lohnt sich ein Blick auf das generierte Array-format von node_list_permissions(), welches von node_permission() und hook_perm()-Implementierungen von anderen Kern Node-Module wiederverwendet wird.
(issue) Berechtigungen werden nicht mehr alphabetisch sortiert, jedoch werden sie in der Reihenfolge angezeigt, wie diese in deiner hook_perm() definiert ist.
Die empfohlende Reihenfolge der Berechtigungen ist:
(issue) _comment_load() wurde umbenannt nach comment_load(), da diese Funktion auch extern Anwendung findet.
Zusätzlich zum Funktionsname selbst muss jeder Menüpunkt, der die %_comment Wildcard anwendet, nach %comment geändert werden.
(issue) Drupal unterstützt jetzt eine dynamisch-ladende Code-Registrierung. Alle Module müssen daher ihre Codedateien in der info.-Datei angeben. Wie im folgenden Beispiel:
Wenn ein Modul aktiviert wird, wird Drupal alle angebenden Dateien untersuchen und gefundenen Funktionen und Klassen indexieren. Das bedeutet jede Klasse oder Funktion, welches indirekt aufgerufen werden (z.B. wie ein hook), kann außerhalb einer .module Datei untergebracht sein und wird On-demand eingebunden.
Klassen werden automatisch geladen durch PHP, wenn auf sie das erste Mal zugegriffen wird. Bei Funktionen, ersetze alle Aufrufe von function_exists() mit drupal_function_exists(), welches die notwendige Datei lädt und TRUE oder FALSE zurückgibt abhängig, ob die Funktion jetzt existiert.
Im Falle von hooks oder irgendein anderen aufgerufenen Code durch module_invoke*(), node_invoke(), etc. wird dies dann automatisch durchgeführt.
In Drupal 6 konnten Menüpunkte eine inc-Datei angeben, welche dann beim Seitenaufruf geladen wurde. In Drupal 7 ist das nicht mehr länger nötig, da diese Dateien automatisch durch registry geladen werden. Die file und der file path-Einträge sollten innerhalb von hook_menu() und hook_theme() entfernt werden.
(Issue) Die {permission} Tabelle ist weg, stattdessen gibt es eine {role_permission}, welches die (role ID, permission string) Paare speichert. Demnach ist jede bewilligte Berechtigung für eine gegebene Rollen-ID in eine separate Zeile in der Tabelle.
Dieses Update ist in der system.install, so dass es bereits abgeschlossen ist, wenn ein Update eines anderen Kern oder bereitgestellte Modul läuft. Dies soll die Veränderung der vorhandenen Berechtigungen viel leichter machen.
(Issue) Der Standardtyp für Elemente in Formulare oder andere strukturierte Array Daten (z.B. node content), welche an drupal_render() übergeben wird, ist '#type' => 'markup'. In Drupal 6 und früher wurde der HTML Inhalt zum Array mit dem #value Attribut hinzugefügt.
In Drupal 7 muss es auf #markup geändert werden. Diese Änderung gilt auch für diese Formularelemente von '#type' => 'Element'. Diese Änderung verringert die Verwirrung zwischen Formularwerte und Markup und ermöglicht, dass der Code in drupal_render() vereinfacht wird.
Beispiel 1, aus system.admin.inc
In Drupal 6:
In Drupal 7:
Beispiel 2, aus contact.pages.inc
In Drupal 6:
In Drupal 7:
Diese kleine Tabelle zeigt den Status eines Nodes oder Kommentars und dessen numerischer Wert:
| Version | Type | Veröffentlicht | Nicht-Veröffentlicht |
|---|---|---|---|
| 6.x und davor | Nodes | 1 | 0 |
| 6.x und davor | Comments | 0 | 1 |
| 7.x | Nodes | 1 | 0 |
| 7.x | Comments | 1 | 0 |
Die Hauptänderung liegt in den SQL-Abfragen und Code, welche mit den Kommentaren interargiert.
Wenn man in Drupal 6.x und davor Code hatte, der wie folgt aussieht:
Muss das dann in Drupal 7.x so aussehen:
Man kann auch die Konstanten verwenden, die im Comment-Modul für eine erhöhte Code-Klarheit und künftigen Korrekturhilfen definiert sind:
6.x:
7.x:
(Issue) Um eine bessere Leistung zu erzielen, wird es dringend empfohlen alle Aufrufe von time() mit einer definierten Konstante REQUEST_TIME zu ersetzen, welche immer den UNIX Zeitstempel zurückgibt von dem Startzeit der aktuellen Anfrage. Wenn es nicht vermeidbar ist kann time() weiterhin verwenden, um die aktuelle Uhrzeit zu erhalten, welches jedoch nicht empfohlen wird.
(Issue) referer_uri() ist entfernt worden und wurde mit der von PHP zur Verfügung gestellte globale Variable $_SERVER['HTTP_REFERER'] ersetzt. Wenn es kein Referrer gibt, wird Drupal $_SERVER['HTTP_REFERER'] automatisch auf ein leeren String setzen.
(Issue) Einige Funktionen, die zur Verarbeitung von Formularelementen (definiert durch ein #form Item in der Forms API) verwendet wurden, sind umbenannt worden, um Ihre allgemeinen Benennung zu vereinheitlichen. Dies betrifft folgende Funktionen:
| Alter Name | Neuer Name |
|---|---|
| expand_password_confirm | form_process_password_confirm |
| expand_date | form_process_date |
| expand_radios | form_process_radios |
| form_expand_ahah | form_process_ahah |
| expand_checkboxes | form_process_checkboxes |
| process_weight | form_process_weight |
Wenn das Modul ein neues Element mit der hook_elements() definiert, müssen die #process-Callbacks aktualisiert werden.
(Issue) Mit Drupal 7 wird eine komplett neue Datenbank-API eingeführt, die sich eine Reihe an dynamischen Query-Builder und bestehende Statements zu nutze macht. Der folgende Konvertierungs-Führer sollte grundlegendste Fälle abdecken, aber das Lesen der vollständigen Dokumentation wird empfohlen.
Normale SELECT-Anweisung
Iterieren mit dem Ergebnis von db_query().
INSERT Anweisung
UPDATE Anweisung
DELETE Anweisung
Weitere Beispiele siehe (Units Tests).
(issue) In 6.x umgeht die Funktion bei der Überprüfung von Dateierweiterungen die uid=1. Dies wurde in 7.x entfernt. Wenn dein Modul auf dieses Verhalten abhängig ist, musst du die uid des Benutzers überprüfen, da dies so in file_validate_extensions()- Validator vorgegeben ist.
(issue) Die file_scan_directory() und drupal_system_listing() Funktionen verwenden jetzt preg_match() anstatt ereg(), welches einen Groß-und Kleinschreibung Abgleich ermöglicht und zudem die Geschwindigkeit verbessert. Folglich ergibt sich durch die Formate der Regulären-Ausdrücke dieser Funktionen, dass die Parameter geändert wurden.
Bei den meisten Modulen braucht man nur einfach ein führendes und abschließendes / (Schrägstrich) hinzufügen.
Drupal 6.x:
Drupal 7.x:
Bei etwas komplexeren Regulären-Ausdrücken sollte man sich die PHP-Dokumentation für die ereg() und preg_match() Funktionen nochmals anschauen.
Module, die das Node-Formular ändern wollen können nun die Überprüfung mit !empty($form['#node_edit_form']) durchführen anstatt mit der ausführlichen Variante
Siehe #161301.
Der Doxygen-Style Kommentar ist für Administratoren auf update.php einsehbar. Hintergrund-Info - #286035.
(issue) In Drupal 6 wurde das Eingabeformat ein Textbereich zugewiesen, indem ein übergeordnetes Element den Textbereich umschloss und ein Filterformat-Auswahl wurde dem untergeordneten Element hinzugefügt, wie z.B.:
Es gab kein Standard für die Benennung, Zuweisung der Format-Auswahl zum übergeordneten Element, deshalb war es unmöglich, Textbereiche und deren zugeordneten Eingabeformate zu identifizieren (im Vergleich zu Nur-Text-Eingabe-Widgets). Zudem war es Allgemein üblich für dieses Konstrukt eine Baumstruktur zu verwenden. So würde man ['comment_filter']['comment'] und ['comment_filter']['filter'] Werte erhalten oder eine Nicht-Baumstruktur, so das man ['comment'] und ['filter'] bekommt.
Dies ist in Drupal 7 alles streng definiert und automatisiert mit der Einführung von der #input_format FAPI-Eigenschaft. Man muss einfach nur das zu verwendende Standard-Eingabeformat angeben und Drupal wird automatisch das Element mit ein 'value' und 'format' Element erweitern, aus dem o.g. Code wird:
Die Weg ist einfacher und Drupal 7 kümmert sich um den Rest. #input_format sollte den Wert des Standard-Eingabeformats haben, die mit der Auswahl verwendet wird. Durch die Formular-Verarbeitung, wandeln Drupal diese Struktur innerhalb form_process_input_format() in 'value' und 'format' Kinder um.
Obwohl die Struktur ['comment']['value'] und ['comment']['format'] ergeben, enthält $form_values Array die abgesendeten Formular-Daten den Kommentar-Wert in ['comment'] und das Format in ['comment_format']. Mit diesem kann man zwischen formatierte und nicht-formatierte Eingabe einfach umschalten ohne aufwendiges Programmieren. Dieses neue Format lässt es auch zu, dass WYSIWYG-Editoren ihre unterstützten Eingabeformate an die Steuerelemente zuordnen können.
(issue) Da Drupal 7 mind. PHP 5 voraussetzt, ist es möglich die Funktion drupal_clone zu entfernen und clone direkt aufzurufen.
Drupal 6.x:
Drupal 7.x: