2.8 RC1 Abwärtskompatibilität - Modulentwickler

[WebBird]

Das Modul bekommt eine precheck.php welche prüft ob die Version 2.7 ist.

Wo finde ich die Dokumentation zu dieser Datei?

[doc]

Hi,

Tja, wenn Du das tun willst, feel free.

Habe die Admin-Module beim Upgrade von 2.6 auf 2.7 upgedated, denke für WB 2.8 sind andere dran

Oder halt Quick und Dirty. Meine Erfahrung von Quick und Dirty Lösungen ist nur, dass diese aus Bequemlichkeit meist länger bleiben als angenommen und es auch keinen wirklichen Anreiz gibt, Module auf WB 2.8 upzudaten, was sich dann spätestens beim nächsten WB Update rächt. Nun, wir werden sehen.

Gruss Doc

[WebBird]

Beim nächsten Mal kann man dann aber zu Recht sagen, "Das war lange angekündigt, wer seine Module jetzt noch nicht umgestellt hat, ist selber Schuld." Das kann man jetzt noch nicht mit Fug und Recht behaupten.

[WebBird]

Übrigens... ich hab jetzt schon von der einen oder anderen Seite gehört "Ach, WB 2.8, das macht doch nur Probleme und bringt nix wirklich Neues, also bleib ich doch lieber bei 2.7."

Schade eigentlich.

[Hans>NULL]

bringt nix wirklich Neues,

Wenn das von ECHTEN Weltverschwörern kommt, ist's Werbung  
Übrigens: Dieser Sommer würde auch angekündigt, aber er bringt nix neues.
Gruß, Hans>NUL

[ruebenwurzel]

Hallo,

==offtopic==

Übrigens... ich hab jetzt schon von der einen oder anderen Seite gehört "Ach, WB 2.8, das macht doch nur Probleme und bringt nix wirklich Neues, also bleib ich doch lieber bei 2.7."

-über 10 neue features
-über 50 fixes
-5 third party scripts aktualisiert

und die Probleme, dazu ist ja die RC Testphase da um das zu lokaliesieren. Das meiste was bisher hier im Forum an Problemen aufgetaucht ist ist ja bereits gefixt oder wird gefixt.

Ok, aber wer nicht will, der muss ja nicht. Bleibt jedem selbst überlassen.

==offtopic ende==

Matthias

[ruebenwurzel]

Hallo,

so ein Teil der admin/images hat wieder Einzug in WB 2.8 gehalten. Damit wäre der Part erledigt, jetzt sind die Moduldevelopper dran 

http://project.websitebaker2.org/changeset/1086

Matthias

[doc]

Hi,

Damit wäre der Part erledigt, jetzt sind die Moduldevelopper dran

Fertig. Speichere CSS, Icons und Bilder von Modulen im Normalfall im Modulordner selbst

Doc

[chio]

Speichere CSS, Icons und Bilder von Modulen im Normalfall im Modulordner selbst

Dann sind die Bilder ein Fremdkörper und passen nicht zum Admin-Template.
Ich muss Webbird recht geben, das Problem völlig richtig erkannt.
Und die Lösung, die alten Admin-Bilder wieder reinzugeben ist wohl die einzig sinnvolle. Viele Module fallen ohne sie völlig auseinander.

[WebBird]

Fertig. Speichere CSS, Icons und Bilder von Modulen im Normalfall im Modulordner selbst

Wie ich schon sagte, dann haben wir hinterher dieselben Bilder in x Modulordnern - was für eine Platzverschwendung.

Von dem von chio bereits erwähnten Darstellungsproblem mal ganz abgesehen.

[WebBird]

Danke, Matthias, für Deine sehr pragmatische Herangehensweise.

[doc]

Hi,

Dann sind die Bilder ein Fremdkörper und passen nicht zum Admin-Template.

Ich spreche von Modul-Icons die nicht im Admin Ordner enthalten sind, wie z.B. die Symbol-Icons im Addon File Editor.

Wenn sich zukünftige Module wirklich nahtlos in das gerade aktive Backend Theme integrieren wollen, dürften ein paar mehr Klimmzüge nötig sein (z.B.):

- /modules/my_mod/icons/common/bild.gif   (unabhängig Bilder oder Bilder wenn gewählte Theme nicht unterstützt)
 - /modules/my_mod/icons/theme_x/bild2.gif (Bilder wenn theme_x verwendet wird)
 - /modules/my_mod/icons/theme_y/bild2.gif (Bilder wenn theme_y verwendet wird)

Ähnliches Konstrukt dann für die Modul CSS. Alternativ könnten man auch im jeweiligen Admin Backend Theme eindeutige CSS Selektoren für Addons einführen: Überschriften, Paragraphs, Form Elemente ..., welche an das jeweilige Admin Theme angepasst sind. Wäre dann eine Latte von "Konventionen" für Backend Theme Entwickler.

Ohne solche "Vorgaben" könnte man bei den Modul CSS ähnlich wie mit Modulbildern verfahren, also /modules/my_mod/css/theme_x.css ...

So oder so, es wird noch eine Weile Dauern bis vernünftige Standards ausgearbeitet wurden. Wenn man sich dann auf einen Standard geeinigt hat, wäre das ein guter Topic für den "Modul-Leitfaden".

Gruss Doc

[Stefek]

auch im jeweiligen Admin Backend Theme eindeutige CSS Selektoren für Addons einführen: Überschriften, Paragraphs, Form Elemente ..., welche an das jeweilige Admin Theme angepasst sind. Wäre dann eine Latte von "Konventionen" für Backend Theme Entwickler.

Genau so wäre es richtig.
Es wäre zunächst wichtig, einen vernünftigen Backend Theme Prototypen zu erstellen, der Klassen bereithält, die widerum von den Modul-Designern/Entwicklern eingesetzt werden können. Also solche, auf die die Designer zurückgreifen können.

Ein Topic für den Modul Primer in diesem Zusammenhang wäre sehr sinnvoll.

Stefek

[WebBird]

Mein Beitrag #25 wurde wohl übersehen. Wo finde ich die Doku zur precheck.php? Wo gibt es ein Beispiel?

[ruebenwurzel]

Hallo,

hoffe, dass wir bis zum Final eine muster precheck.php (gibt es schon) + dazugehörige Doku liefern können.

Matthias

[WebBird]

Kann ich das Muster haben? Würd das gern schon in EM einbauen.

[doc]

Hi,

Mein Beitrag #25 wurde wohl übersehen. Wo finde ich die Doku zur precheck.php? Wo gibt es ein Beispiel?

Ein Beispiel für "Precheck-Basics", sprich Abfrage der Modul-Mindestanforderung für WB- und PHP Version findest  Du im Addon File Editor ab Version 0.70. Hatte mal ne "precheck.php" die alle Möglichkeiten aufzeigt, ist aber beim letzten Platten-Putz über den Jordan gegangen.

Ein paar Infos über mögliche Schlüsselwörter findet man in der Datei /framework/addon.precheck.inc.php. Wer Zeit hat, sollte wohl lieber warten, bis Matthias die vorhanden Infos  lokalisiert und gepostet hat und dann loslegen  

Doc

[ruebenwurzel]

Hallo,

so, nach einem Tip von doc bin ich fündig geworden  .

Im Anhang ein dummy-modul und ein dummy-template in dem eine precheck.php drin ist. Denke innerhalb der Datei ist alles so gut dokumentiert, dass zumindest modul/template developper damit zurecht kommen. Dennoch wäre eine zusätzliche Dokumentation (mehrsprachig!!) nicht schlecht.

Viel Spaß beim testen.

Matthias

[WebBird]

Hm. Vorschlag für Doku in Deutsch:

---

Mit Hilfe der precheck.php ist es möglich, vor der Installation eines Moduls auf dem Server zu überprüfen, ob alle Voraussetzungen erfüllt sind. (Beispielsweise bezüglich der WB- oder PHP-Version.)

Hierzu wird in der precheck.php ein Array $PRECHECK belegt. Folgende Schlüssel können verwendet werden:

WB_VERSION
Die websitebaker-Version, die installiert sein muß.

Beispiel:

Code:

$PRECHECK['WB_VERSION'] = array('VERSION' => '2.7', 'OPERATOR' => '>=');

Das Attribut OPERATOR kann auch weggelassen werden; Default ist '>=', also "größer/gleich" oder auch "mindestens".

WB_ADDONS
Vorausgesetzte (andere) Addon-Module.

Beispiel:

Code:

$PRECHECK['WB_ADDONS'] = array(
    'anynews'    => array('VERSION' => '0.3.4', 'OPERATOR' => '='),
    'backup',
);

Es muß mindestens ein Verzeichnisname angegeben werden. Sofern eine bestimmte Version vorausgesetzt wird, kann diese zusätzlich angegeben werden. Siehe Beispiel.

PHP_VERSION
Vorausgesetzte PHP-Version.

Beispiel:

Code:

$PRECHECK['PHP_VERSION'] = array('VERSION' => '5.2.6', 'OPERATOR' => '>=');

Das Attribut OPERATOR kann auch weggelassen werden; Default ist '>='.

PHP_EXTENSIONS
Vorausgesetzte PHP Extensions. Diese werden als einfaches Array angegeben.

Beispiel:

Code:

$PRECHECK['PHP_EXTENSIONS'] = array('gd', 'libxml');

Die Extensions werden einfach namentlich angegeben.

PHP_SETTINGS
Einstellungen der php.ini, die vorhanden sein müssen. Die Angabe besteht in einem Array; Schlüssel sind die Attribute der php.ini, Werte die erwarteten Werte.

Beispiel:

Code:

$PRECHECK['PHP_SETTINGS'] = array('display_errors' => '1', 'safe_mode' => '0');

CUSTOM_CHECKS

Über die o. g. Standardprüfungen hinaus können eigene Checks definiert werden. Hierzu wird der Schlüssel CUSTOM_CHECKS verwendet.

Code:

$status = file_exists(WB_PATH . '/include/yui');
$required = $TEXT['INSTALLED'];
$actual = ($status) ? $TEXT['INSTALLED'] : $TEXT['NOT_INSTALLED'];

$PRECHECK['CUSTOM_CHECKS'] = array(
    'yui library'    => array('REQUIRED' => $required, 'ACTUAL' => $actual, 'STATUS'    => $status)
);

---

So weit erstmal.

[WebBird]

Entschuldigung, vor lauter Begeisterung hab ich glatt vergessen, mich zu bedanken.

[ruebenwurzel]

Hallo,

cooles teil,l gelle 

Danke für die deutsche howto, sollte in modul-primer mit aufgenommen werden (oder hello-world, oder auf auf hilfeseite oder ...)

Matthias

[WebBird]

cooles teil,l gelle 

Very cool.

[JayKay89]

Könnte mal jemand das Form X Modul unter WB2.8 testen? Verursacht bei mir Probleme, sobald ich die Einstellungen verändere, was nämlich dazu führt, dass im Frontend nur noch die Doppelpunkte, aber keine Felder & Labels mehr angezeigt werden...

[erpe]

Hallo
das Form X Modul wird soweit ich weiss nicht weiter gepflegt (seit Herbst letzten Jahres).

Daher hat sich jemand des Moduls angenommen, es etwas "gereinigt", neue Funktionalitäten hinzugefügt und es als mp Form zur Verfügung gestellt.
Weiss nicht, ob es jetzt Sinn macht, das Form X nochmal aufzugreifen.

Das MP Form ist hier zu finden:
http://www.websitebakers.com/pages/modules/interaction/mpform.php

Gruss

erpe

PS: Auch wenn es aus Gründen der Abwärtskompatibilität eventuell Sinn macht

[Stefek]

Bin der gleichen Meinung.
MP Form leistet alles was mit X Form beabsichtigt wurde und noch viel mehr.
Der X Form Entwickler entwickelt das Modul nicht mehr.

Ich empfehle einen Umstieg auf (und eine Förderung des) MPForm Moduls.

Gruß,
Stefek