2.8 RC1 Abwärtskompatibilität - Modulentwickler

[WebBird]

Hallo,

mir ist noch was aufgefallen, wobei ich nicht weiß, ob noch andere Entwickler so schlimme Dinge treiben wie ich.

Ich hab' nämlich in meinen Modulen zum Teil Icons aus dem WB-Admin-Backend benutzt, und die liegen ja nun woanders. (Nicht mehr unter admin/images, sondern unter templates/<Template>/images) Ich finde es halt von wegen der CI etwas unglücklich, wenn jedes Modul seine eigenen Icons mitbringt - und auf der anderen Seite ist es Platzverschwendung, wenn immer dieselben Icons in den einzelnen Modulverzeichnissen liegen.

Wäre vielleicht schön, wenn es dafür eine allgemeingültige Lösung gäbe. Etwa eine Funktion, die die URL für die Grafiken des aktuell gewählten Backend-Templates liefert. Und zur Wahrung der Abwärtskompatibilität bis auf weiteres zusätzlich die alten Icons im alten Ordner.

Ginge das?

[ruebenwurzel]

Hallo,

Wäre vielleicht schön, wenn es dafür eine allgemeingültige Lösung gäbe. Etwa eine Funktion, die die URL für die Grafiken des aktuell gewählten Backend-Templates liefert. Und zur Wahrung der Abwärtskompatibilität bis auf weiteres zusätzlich die alten Icons im alten Ordner.

Ist doch alles schon gemacht beziehungseweise es wird bei der Upgrade Anleitung beschrieben:

Guckst du hier:

http://start.websitebaker2.org/de/wb-2.8.php

Vorbereitungen:
- Schritt 4 + Hinweis

Abschlussarbeiten:
-Schritt 3

Und schwuppdiwupp ziehen sich auch Module die Images immer vom aktuellen theme. 

Matthias

[doc]

Hi,

damit funktionieren dann Module für WB 2.8 aber nicht mehr für WB 2.7, da dort THEME_URL nicht definiert ist.

Wer Module für WB 2.8 entwickelt, aber sicherstellen will dass diese auch noch unter WB 2.7 laufen könnte folgendes verwenden:

Code:

$admin_theme_path = defined('THEME_URL') ? THEME_URL : ADMIN_URL;

Doc

P.S.: Und nein, precheck.php wäre hier keine Lösung, da diese Datei erst ab WB 2.8 aufwärts ausgewertet wird, in WB 2.7 aber ignoriert werden würde.

[ruebenwurzel]

Hallo doc,

das ist natürlich der Königsweg, bist wie immer genial. 

Bin gespannt ob jemand das in Modul primer mit aufnimmt. Gibt ja welche, die das weiterführen wollen.

Matthias

[aldus]

Naja - meine Begeisterung hält sich in Grenzen.
Wenn die THEME_URL nicht definiert ist dann eben gleich die ADMIN_URL nehmen.

Code:

<?php
if (!defined('THEME_URL')) define ("THEME_URL", ADMIN_URL);
?>

dann ist WebBird auch sprachlich aus dem Schneider und kann weiter 2.8 machen und für
WB2.7 nicht noch eine neue Variable anlegen u.s.w.

Und eigentlich könnte man die Zeile auch in die config.php schreiben ...
oder noch besser im #836 die gleich noch auf dem letzten drücker mit auf den Weg in die Rente dazupacken ...

Gruß
Aldus

[Luisehahne]

Ich glaube ich hatte das so verstanden und gelesen. Du entwickelst ein Modul mit THEM_URL  und da es in 2.7 die Konstante nicht gibt, siehe da, das Modul funktioniert trotzdem. Ginial

Dietmar

[Luisehahne]

Ich meinte diese Lösung

<?php
if (!defined('THEME_URL')) define ("THEME_URL", ADMIN_URL);
?>

Finde ich gut.

Dietmar

[doc]

Hi,

Und eigentlich könnte man die Zeile auch in die config.php schreiben ...

Welche config.php die von WB, wohl eher nicht. WB 2.8 kennt ja bereits THEME_URL, nur WB < 2.8 nicht. Wenn so gemeint, müsste diese Zeile in die config.php von WB 2.7, WB 2.6.x ...

Ich definiere Pfade, ULRs oder sonstige Konfigurationsvaria blen meiner Moduls meist in einer config.inc.php:

Code:

$admin_theme_url = defined('THEME_URL') ? (THEME_URL : ADMIN_URL) . '/images/';

Wers lieber mit ner Konstanten löst, nur zu. Die beste Lösung kann ja dann in den "Modul Leitfaden" einfliessen, dafür ist er ja schliesslich gedacht.

Gruss Doc

[Luisehahne]

SEhe ich auch so, Wäre ja schlimm, wenn wir alle einer Meinung wären. Es is tdoch produktiv, wenn wir unterschiedlicher Meinung sind, man denkt nach, könnte er doch recht haben. Meistens entstehen dadurch optimale Lösungen.

Dietmar

[aldus]

Hi,

Und eigentlich könnte man die Zeile auch in die config.php schreiben ...

Welche config.php die von WB, wohl eher nicht. WB 2.8 kennt ja bereits THEME_URL, nur WB < 2.8 nicht. Wenn so gemeint, müsste diese Zeile in die config.php von WB 2.7, WB 2.6.x ...

Die meinte ich auch ... dann ist sie halt "für alle da" ...

Ich definiere Pfade, ULRs oder sonstige Konfigurationsvaria blen meiner Moduls meist in einer config.inc.php:

Code:

$admin_theme_url = defined('THEME_URL') ? (THEME_URL : ADMIN_URL) . '/images/';

Wers lieber mit ner Konstanten löst, nur zu. Die beste Lösung kann ja dann in den "Modul Leitfaden" einfliessen, dafür ist er ja schliesslich gedacht.

Gruss D
oc

ups

Code:

$admin_theme_url = defined('THEME_URL') ? (THEME_URL : ADMIN_URL) . '/images/';

Auch mit der Klammersetzung? 

Code:

<?php
$admin_theme_url = (defined('THEME_URL') ? THEME_URL : ADMIN_URL) . '/images/';

Gruß
Aldus

[WebBird]

Nein nein nein, Ihr versteht mich nicht. Was ist mit den Modulen, die für 2.7 entwickelt wurden und für 2.8 nicht angepaßt werden?

[Luisehahne]

Hallo WebBird,

Vielleicht ein Modul von 27 was jetzt unter 2.8 nicht läuft. Dann könnte man eine Lösung finden. Ein praktisches Beispiel ist immer besser als die Theorie.

Dietmar

[Luisehahne]

Heisses Thema, aber berechtigt. Hier überschlagen sich die Posts

Dietmar

[WebBird]

Sorry, aber Ihr seid noch immer im falschen Film!

Neuer WB-Benutzer installiert WB 2.8. Installiert Module aus 2.7. Hat komisches Zeug im Backend, weil nix Icons da. Bezieht komisches Zeug auf Qualität von WB. Schmeißt WB weg.

Ja, es ging ursprünglich auch um mich als Modulentwickler (was tun), aber es geht auch um den Benutzer bzw. um die "tausende" Module, die es schon gibt. Wenn durch das Update eine Überarbeitung aller Module erzwungen wird, ist das nix gutt für den Ruf der neuen Version.

[WebBird]

Und jaaaa, man kann es lösen, indem man "von Hand" dies und jenes tut. Und genau das sollte nicht nötig sein. Weil ist nix gutt.

[doc]

Hi,

also zusammenfassend gibt es folgende Scenarien:
a) WB 2.7 Modul wird ohne Anpassung in 2.8 verwendet
b) WB 2.8 Modul soll sowohl unter 2.8 als auch 2.7 laufen

Lösung zu a):
Das Modul bekommt eine precheck.php welche prüft ob die Version 2.7 ist. Macht keinen Unterschied für WB 2.7, bricht aber beim Installieren des Moduls ab, wenn man versucht dieses Modul in WB 2.8 zu installieren. Ist das Modul gefixt, fliegt die precheck.php wieder raus. Müsste in jedem Modul gemacht werden (wurde so auch bei den Admin Modulen beim Update von 2.6.x auf 2.7 gemacht, Stichwort: Abschnitt Admin-Tools und Settings->Advanced Settings).

Oder: Man macht ne Abfrage in den WB 2.8 Core, der die Variable $module_platform prüft. Ist diese < WB 2.8 dann Warnmeldung, dass evtl. ein paar Ungereimtheiten (z.B. Icons ...) auftauchen können, die man fixen kann indem mann, oder ...

Lösungen zu b):
Zwei Wege. Entweder indem man das ganze im Modul Code selbst vorsieht ($admin_image_path, Konstante), oder aber in WB 2.7 eine Konstante in der config.php definiert (THEME_URL --> ADMIN_URL).

Doc

[WebBird]

Was spricht dagegen, einfach einen Icon-Satz im alten Verzeichnis zu belassen? Erspart einem einfach alles, von der Anpassung im Modul bis zur Handarbeit bei der Installation alter Module.

Ihr hattet wohl noch nie zahlende Kunden, die Euch wegen sowas an den Hals gesprungen sind, wie?

[Luisehahne]

Gebe ich dir eigentlich recht, jetzt lästere ich mal, und was spricht dagegen, wenn du deinen Kunden das alte Verzeichnis einrichtet und du den Iconsatz einspielt. Obohl ich wüsste jetzt nicht dass das alte Verzeichnis beim Upgrade gelöscht wird. Also müsste es doc hklappen. oder?

Dietmar

[ruebenwurzel]

Hallo,

Also so wie ich das verstehe:

1.) Um WB 2.7 Module, die nicht an WB 2.8 angepasst zumindest mit alten icons am laufen zu haben:
==>admin/images Folder muss in WB 2.8 drin bleiben, zumindest das was module betreffen könnte sollte wieder ins Paket aufgenommen werden.

2.) Um Module die für WB 2.8 entwickelt wurden auch unter 2.7 lauffähig zu haben:
==>zusätzlich docs/aldus script für Module oder config.inc.php in Module einbauen

Weitere Änderungen sind nicht notwendig. Damit dürften dann alle Module sowohl unter 2.8 als auch unter 2.7 lauffähig sein, ohne dass der Benutzer eingreifen muss. Bei neueren Versionen von Modulen, sollte dann sukzessive die Theme Unterstützung eingebaut werden. Der admin/images kann dann bei einer künftigen Version gelöscht zu werden.

Wäre das ok?

Matthias

[doc]

Hi,

Ihr hattet wohl noch nie zahlende Kunden, die Euch wegen sowas an den Hals gesprungen sind, wie?

Ne, weil sowas wie Upgrade, Neuinstallation etc. über meinen Support abgedeckt war und man sowas zuvor gemeinsam besprochen und auf ein gemeinsames Vorgehen geinigt hat. Bin immer super damit gefahren  

Den alten Image Ordner einfach drin lassen, ist halt die Quick & Dirty Methode.

Denke es gibt nicht allzu viele Admin Module welche auch Icons aus dem /admin Ordner verwenden. Diese sollten schnell durch eine neue Variante mit precheck.php oder define THEME_URL etc. upgedatet sein. Dann einfach das neue Admin Tool installieren und fertig - die sauberere Lösung (wie auch bei WB 2.7 praktiziert).

Doc

[ruebenwurzel]

Hallo,

Gebe ich dir eigentlich recht, jetzt lästere ich mal, und was spricht dagegen, wenn du deinen Kunden das alte Verzeichnis einrichtet und du den Iconsatz einspielt. Obohl ich wüsste jetzt nicht dass das alte Verzeichnis beim Upgrade gelöscht wird. Also müsste es doc hklappen. oder?

Dagegen spricht, User installiert sich WB 2.8, dann irgendein Modul und sieht sch.... im backend aus. Is nich gut und muss nicht sein.

Auch wenn es mir (persönlich) nicht gefällt den alten kram drinzulassen, denke aber dass ist für die Übergagszeit einfach noch die beste Lösung.

Matthias

[WebBird]

Ich hab keinen WB-Kunden gemeint. Aber im Beruf hab ich so einiges an Erfahrung, und die sagt: Wenn ich eine Sollbruchstelle kenne, und die ist einfach zu kleben, dann, um Himmels willen, klebe sie!

Mein Kunde (in beruflicher Hinsicht) hat ein Produkt meiner Firma samt Wartungsvertrag. Und er hat hunderte "Pakete", die von dem Produkt abhängig sind.

Wenn wir nun im Produkt was ändern, das dazu führt, daß der Kunde seine hunderte Pakete ändern muß, entstehen ihm Kosten. Das ist (selbstverständlich) inakzeptabel, und das würde er uns zu Recht um die Ohren hauen.

Nun muß es natürlich möglich sein, sich auch mal von Altlasten zu trennen. Das tut man, indem man dies RECHTZEITIG und LAUT ankündigt. Natürlich muß man dann damit rechnen, daß die Kunden, die allzu große Kosten befürchten, dann nicht umsteigen werden. Daher muß man sich vorher sehr genau überlegen, ob man dieses Risiko eingehen will, und ob es die Sache wert ist.

In diesem Fall bin ich der Meinung, daß es der Akzeptanz von WB 2.8 nicht gerade förderlich sein wird, wenn man solche Probleme wie diese BEWUSST provoziert. Wenn man nicht dran denkt - schlimm genug. Wenn man es aber WEISS und bewußt ignoriert, dann ist das, man entschuldige das harte Wort, grob fahrlässig. Ja, es sind KLEINIGKEITEN - und genau DESHALB sollte man eine vernünftige Lösung finden.

In diesem konkreten Fall sähe die vernünftige Lösung so aus, daß man per Default das alte Icon-Verzeichnis beläßt und darauf hinweist, daß der Benutzer es entfernen kann, wenn er sicher ist, daß er keine alten Module < 2.8 einsetzen wird. Im Zweifel soll er es lieber lassen. Wir reden hier ja nicht von Gigabytes, sondern von sage und schreibe 164 kB! (Bei mir unter Windows.)

Den Modulentwicklern legt man dann gleichzeitig SEHR eindringlich nahe, die neuen Pfade zu benutzen, da man in künftigen Versionen eben nicht mehr Rücksicht darauf nehmen wird, abwärtskompatibel zu sein.

Der professionelle Weg ist immer, mindestens eine Version lang darauf zu achten, daß man abwärtskompatibel ist. Fragt mal Microsoft.

[Luisehahne]

Wurde ja bisher auch so gehandhabt. Siehe Droplets und Outputfilter. Dafür führen ja diese Diskussionen. Ist ja sehr positiv.

Dietmar

[doc]

Hi WebBird,

was spricht dagegen, die Zeit bis zum WB 2.8 Final zu nutzen, die 10-15 Admin-Module zu fixen, die wirklich den /admin/images/... Pfad verwenden. Im WB 2.8 Upgrade Script kann man dann ein Prüfung auf alte Admin-Tools unterbringen und einen Hinweis ausgeben, diese Module mit den aktuellen Versionen auf AMASP oder der Addons Seite zu ersetzen.

Das wurde so auch beim Upgrade von WB 2.6 auf WB 2.7 praktiziert. Denke wenn gefixte Module bereit stehen, kein Problem. Dann kann man:

a) den alten Admin Pfad drin lassen
b) WB 2.7 auf 2.8 upgraden
c) die neuen Admin Tools einspielen
d) den alten Admin Pfad löschen wenn nicht mehr gebraucht.

Doc

P.S.: Vielleicht kann man ja hier eine Liste der betroffenen Admin-Module erstellen.

[WebBird]

Tja, wenn Du das tun willst, feel free.