Modules which do not work with 1.2 yet

florian · 30.12.2015 16:16:00

- Procalendar 1.3.6 (fatal error on save)
-
... (to be continued)

marmot · 30.12.2015 22:51:22

florian schrieb:

- Procalendar 1.3.6 (fatal error on save)

fixed.
Problem was, that functions.php is loaded now in core by default and must not be loaded twice.

norhei · 30.12.2015 23:25:22

If you want to keep WB compatibility just use a requitre _once , if not simply remove it :-)
Thx alot marmot.

This thread is a good idea too.

florian · 19.05.2016 16:00:43

So, after some moths of further development I've tested a bunch of modules with the current WBCE 1.2-alpha4.

The good news: many modules work out of the box or just have to be updated to the newest version.

The bad news: some modules do not work or throw notices/warnings. (I know that not all errors are caused by WBCE but also by depreciated PHP commands, I tested with PHP 5.5 / PHP 7).

So here is a small list of errors I found:

mpForm

BE: interface missing, just the following warning/error

Warning: require_once(/.../include/phplib/template.inc): failed to open stream: No such file or directory in /.../modules/mpform/modify.php on line 41
Fatal error: require_once(): Failed opening required '/.../include/phplib/template.inc' (include_path='.:/opt/php/5.5.34/share/pear') in /.../modules/mpform/modify.php on line 41

FE: No output, just a blank error

Fatal error: Call to a member function getFTAN() on a non-object in /.../modules/mpform/paintform.php on line 271

Bakery
BE: seems alright at the first glance.
When clicking on "save" at a new created item, the item is not saved, but the following error shows up:

Fatal error: Cannot redeclare rm_full_dir() (previously declared in /.../framework/functions.php:27) in .../framework/functions.php on line 64

OneForAll
exactly the same behaviour as Bakery.

Additionally, it makes throws in the Addon Monitor for many lines in the DE.php for which reasons ever the following

Notice: Undefined variable: mod_name in /.../modules/oneforall/languages/DE.php on line x

x = 37..130

CWsoft-AFE
Shows a notice in the backend.

Notice: Undefined variable: module_version in /.../modules/cwsoft-addon-file-editor/code/functions.php on line 551

Toggeling the module/template/language lists doesn't work any more, e.g. the items are not displayed, so there was no further testing possible.
This might be an issue with the renewed jquery version (1.12.0).
On other systems I had the strange phenomen that the headlines shortly showed up and than vanished slowly and also the toggling didn't work.

Accordion

Just a notice, nothing dramatically

Undefined index: SETTINGS in /.../modules/accordion/modify_settings.php on line 66

Members

FE: Shows the member items, but also

Notice: Undefined variable: reversesorting in /.../modules/members/view.php on line 361

BE - Image selection:

Deprecated: Function ereg() is deprecated in /.../modules/members/modify_member.pictures.php on line 112 [...and] 113
Notice: Undefined offset: 3 in /.../modules/members/modify_member.pictures.php on line 128

The depreciated error occurs for each found image 2 times.
The offset in the notice might be the amount of images found.

Please keep in mind that WBCE 1.2 currently is at alpha state, so it's no surprise that there are some errors. As I said before, many modules work properly (miniform, minigallery, wysiwyg, section picker, code2, Topics, Forum, event calendar, MapBaker, responsiveFG,...)

norhei · 19.05.2016 19:35:20

As i already mentioned on Github Bakery should be ok after last patch to core.
You are mixing things a bit , the Notices on members are certainly no WB issue .

please check OneForAll again , as i fixed the bakery issue which actually was a core issue ..

I cannot reproduce the MEmbers issue on the 515 server.
Can you please point me to an example ?

AFE i am on it

norhei · 19.05.2016 19:38:56

Looks like the patch for bakery fixed MPForm too tested on 515 server

florian · 19.05.2016 19:41:09

About members, see attachment.
I've tested in a fresh install (519)

florian · 19.05.2016 19:42:09

But you're right, that has nothing to do with WBCE 1.2.x

florian · 19.05.2016 19:52:16

Looks like the patch for bakery fixed MPForm too tested on 515 server

I'm sorry. I wasn't aware that the error is corrected there. But the correction seems not to be commited to the github repository?

norhei · 19.05.2016 20:17:18

https://github.com/WBCE/WebsiteBaker_Co … 72b45dc64e

Sollte es eigentlich

florian · 19.05.2016 20:27:47

Topics machte keine Probleme mehr, Bakery wie oben geschrieben. Kannst es Dir hier angucken. Zugangsdaten 519 analog 515

florian · 19.05.2016 20:58:05

Huch, jetzt sind die Posts zur DownloadGallery weg, dabei wollte ich sie doch nur ins richtige Forum verschieben. Mist.

grindbatzn · 20.05.2016 09:15:13

Wie kann man den Bug (Function ereg() is deprecated) in Members beheben? Der wird wohl auch in anderen Modulen sein.

evaki · 20.05.2016 09:56:06

Durch preg_match ersetzen.
Es existiert anscheinend noch ein weiterer Fehler.

PHP7 unter wbce1.1.6: schrieb:

Fatal error: Uncaught Error: Call to undefined function mysql_error() in \html\modules\members\modify.php:107 Stack trace: #0 \html\admin\pages\modify.php(180): require() #1 {main} thrown in \html\modules\members\modify.php on line 107

Edit: mysql_error() gibt's nun wg. MySQLi nicht mehr. Falls an der betreffenden Stelle "unwichtig" (räusper), kann man die Ausgabe natürlich dort auch schlicht deaktivieren. Ansonsten sind die MySQLi-Alternativen einzubringen. Wie das konkret aussieht, steht -glaub ich- auf der gelinkten Seite.

MfG. Evaki

Beitrag geändert von evaki (20.05.2016 13:49:46)

cwsoft · 23.05.2016 14:46:05

Wegen AFE unter WBCE 1.2.0-alpha.4.

Die Notice bekommt man durch Änderung des require Aufrufs weg.

Das keine Addons angezeigt werden, liegt wohl nur bedingt an jQuery. Zumindest nach kurzen Blick in den JS-Debugger.

Sieht wohl eher so aus, als ob in den AFE Hilfsfunktionen die globalen Variablen wie z.B. $table (code/config.php) nicht gesetzt sind und daher keine Addons aus der DB gelesen werden können. Sprich $_SESSION['addon_list'] bleibt leer. Somit gibt es dann auch nichts zum Anzeigen für den Dateimanager und jQuery blendet dann leere Tabellen ein und aus smile

Bei kurzen Tests mit dem Postits Modul (mit Simple Responsive Template) wurden mir Postits im Frontend angezeigt. Mit dem WBCE Template gab es noch sehr viele Notices über nicht gesetzte WBCE Variablen. Denke ich breche meine Recherche an dieser Stelle mal ab und teste mit einer späteren Version erneut.

Gruss cwsoft

Beitrag geändert von cwsoft (23.05.2016 16:28:55)

cwsoft · 23.05.2016 21:34:30

Nachtrag zu AFE und WBCE 1.2.0-alpha.4.

Die gute Nachricht zuerst, es liegt nicht an jQuery oder jQueryUI smile

Die schlechte Nachricht. Es scheint sich etwas im Aufruf von (Admin)Modulen geändert zu haben. Variablen auf die man früher global zugreifen konnte sind jetzt nicht mehr sichtbar.

Da AFE ein Admintool ist, dient "tool.php" als zentralen Einstieg. Hier werden Konfigurationsvariablen (code/config.php) über require geladen und im Anschluss die AFE Funktionsdatei (code/functions.php) inkludiert. In WBCE 1.x konnte man innerhalb einer in "code/functions.php" definierten Funktion über global $variable; auf in "tool.php" definierte oder geladene Variablen zugreifen. Das geht nun nicht mehr. Ein "Quickfix" wäre die in "code/functions.php" benötigten Variablen in "tool.php" über global $variable; sichtbar zu machen (quick und dirty aber nicht schön). Dann erscheint die Addon-Liste und lässt sich auch auf und zuklappen. Alternativ kann man die Variablen auch an die Funktion übergeben, anders kapseln, eine AFE Klasse bauen ...

Frage an die DEVS. Ändert sich diesbezüglich noch etwas in der finalen WBCE 1.2.0, oder bleibt das so? Evtl. sind dann noch mehrer Module betroffen, die ähnlich vorgehen.

Gruss cwsoft

Beitrag geändert von cwsoft (23.05.2016 21:42:26)

florian · 23.05.2016 23:57:08

Ich geb das mal an den Chefentwickler weiter

norhei · 24.05.2016 06:43:01

Also ...

Bisher war ja das Problem das sich keiner wirklich ans BE getraut hat , weil es ein unendlicher Wust aus historisch gewachsenem Code ist.
Leider stellt sich das jeder Form von Weiterentwicklung in den Weg und ist auch nicht wirklich eine sichere Sache , teilweise sind die Konstrukte wirklich haaresträubend , wie ein Haus das man immer wieder umgebaut und erweitert hat(50 Anbauten, weil das Dach undicht war nochmal 2 Dächer drüber gebaut wobei eins aus Zeltplane besteht und das Andere ist aus Pappe)
Eigentlich wollte ich nur einen schönen Timer mit Autosave und einige andere kleine Spielereien einbauen (vernünftige Passwort Verschlüsselung ... ), aber ich stieß immer wieder auf Wände die eigentlich gar nicht gebraucht wurden. Blauäugig wie ich war habe ich die angefangen das BE zu modularisieren, Ziel ist es das BE komplett aus Modulen zu bauen. (Damit ist Jedes Element einfach austauschbar oder einzeln upzugraden)
Infolge dessen ist die Class Tool entstanden die in der Lage ist Admintools von überall her aufzurufen und BE Seiten aus Admintools zu bauen.
Die neue Preferences Seite ist ein Beispiel oder die Settings oder Admintools listing. Sprich wenn jetzt ein besonderes Preferences für einen Shop benötigt würde könnte man einfach ein erweitertes Modul bauen und das jetzige ersetzen. Das Ganze ist noch nicht völlig fertig aber funktioniert schon recht gut.
Bei der Gelegenheit habe ich dann gleich die Kompletten Module aufgeräumt und von ihren alten Schrullen, sowie etlichen potentiellen Sicherheitsproblemen bereinigt (alle relativ unkritisch)

Dummerweise hat Florian bei ersten wirklich großen Test festgestellt , das einige Module (Ausschließlich Admintools natürlich)
Hier Probleme bereiten. Grund sind hauptsächlich 2 Probleme.

1. Die Tools benutzen Globale Variablen auf sehr ... naja sagen wir auf eine Weise wie mann sie nicht benutzen sollte(das liegt mitunter an PHP das so Etwas überhaupt erst erlaubt) . Wenn die Module jetzt innerhalb einer Klasse/Funktion aufgerufen werden werden diese Variablen nicht mehr im Globalen Namensraum erzeugt sondern innerhalb der Klasse. Lösung wäre temporär einfach die Fehlenden Variablen per global in der tools.php eben wirklich global zu machen. Bei den Meisten Modulen dürfte das ein Einzeiler sein. Besser wäre es natürlich die Module einmal wirklich zu modernisieren...

2. Die functions.php wird in der framework/initialize.php schon geladen, da die öfter schon mal vergessen wurde zu laden. Erstaunlicherweise benutzen sehr viele Module immer noch ein require statt eines require_once. Allerding habe ich mir da eine Coreseitige Lösung überlegt, die das Probem komplett behebt , nicht schön aber sollte gehen. (muss ich gleich noch ausprobieren).

Zu recht hatte Florian bemängelt , das solche Probleme nicht besonders sagen wir benutzerfreundlich sind und nicht einfach so dann im fertigen Release auftauchen sollten(Überraschung eure Module laufen nicht mehr big_smile .). Auf der anderen Seite ist es nur eine Frage der Zeit bis das Problem alle Autoren von Admintools trifft , denn auch in DV möchte in diese Richtung , sprich das wird auch in Classic kommen. Bei den Frontend Modulen gab es diesen Wechsel ja auch schon , die laufen in einer Funktion. Die Frage ist also nicht ob , sonder wie man das löst?
Einfach peng, bumm, klatsch Release und dann friss Vogel oder stirb ist keine Option.

- Florian hatte Vorgeschlagen das Release zu teilen in eine 1.2.x und eine 2.0. und diese Feature erst in der 2.0 zu verwenden, damit wäre auch genug Zeit die Module zu testen und gegebenenfalls zu patchen und auch das gesammte BE zu überarbeiten(momentan ja erst teilweise)
(rechtfertigt das eine 2.0 ?)
- Eine weitere Möglichkeit wäre das Release zu verschieben und erst die Module zu bearbeiten.
- Einfach in den Dornröschenschlaf von Classic zurück zu fallen wäre auch eine Lösung , aber keine schöne.

Bis auf die Letzte hätte ich damit keine Probleme. Und in den beiden Ersten fällen würde das Release erst kommen wenn die Module sowieso bereit sind.
Interessant wäre dabei noch ein eventueller automatischer Upgrade auch wenn der nicht auf allen Systemen funktionieren kann(Wenn Apatche als Modul läuft ist nichts zu machen)

Als weiteres fällt mir dazu noch die Frage ein was wäre ein vernünftiger Release Zyklus , zu offt ist schlecht weil die Nutzer ständig upgraden müssen.
Jedes Halbe Jahr Upgraden zu müssen ist schrecklich , dazu kommen dann noch eventuelle Sicherheitsupdates ... nicht schön. Fragt mal Chio oder Florian zu dem Thema.

Meinungen bitte !

norhei · 24.05.2016 06:52:32

Nachtrag.

Es war auch die Frage nach den Neuen Template Funktionen irgendwo aufgetaucht. Steffek hat mich da auf eine sehr schöne Idee gebracht so das die neuen Platzhalter nicht einmal von Hand ins Template eingetragen werden müssen. Sprich alte Templates müssen so sie einigermaßen brauchbares HTML enthalten überhaupt nicht von Hand bearbeitet werden. (Für üble Templates mit offenen Tags , nicht vollständigen Tags im Head , oder ohne richtigen Head , kein Body tag oder so, also richtig verhunztes HTML kann ich keine Garantie übernehmen) Prinzipiell dürften die sogar mit nicht WB templates gehen , da fehlen dann natürlich die anderen Platzhalter für Page Content und so.

cwsoft · 24.05.2016 08:56:35

@Norhei: Zuerst mal grosses Respekt vor Deiner Arbeit. Die Umbaumassnahmen und Modularisierung des Backends ist sinnvoll und überfällig. Würde das aber auch eher in einen 2.x Zweig verlegen, da dieser Umbau tiefgreifend ist und alte Zöpfe teils abgeschnitten werden (Module, Backendtemplates etc.). Hätte auch kein Problem damit AFE und Co. für 2.x lauffähig zu machen. Auch bei AFE merkt man dass er 2008 für WB 2.7 entwickelt wurde smile

Ich würde folgendes vorschlagen. Der WBCE 1.x Zweig bleibt nah an WB 2.8.3 hinsichtlich Modulkompatibilität. Paralell machen wir einen 2.x Zweig mit allen rückwärtsinkompatiblen Änderungen, API Änderungen etc. Für den Zweig können wir dann auch neue Beispielmodule mit den Möglichkeiten der 2.x Serie erstellen, bzw. die Funktionalität häufig benutzter Module für WBCE 2.x herstellen.

Gibt es eine Liste mit WB/WBCE Modulen die für 1.x bzw. 2.x laufen, bzw. nicht laufen? Welche Module sind unabdingbar und müssen laufen?

Gruss cwsoft

florian · 24.05.2016 10:04:38

Die Liste der getesteten Module ist hier weiter oben im Thread:
http://forum.wbce.org/viewtopic.php?pid=4586#p4586

Das sind so aus meiner Sicht die unabdingbaren Module. Gerade Bakery und OneForAll halte ich für sehr wichtig, um konkurrenzfähig zu bleiben und auch ambitioniertere Projekte weiterhin realisieren zu können.

Anders ausgedrückt: Für WBCE müssen m.E. folgende Funktionen verfügbar sein (das sind jetzt nicht die Modulnamen, vielleicht baut ja irgendwer neue Module)
- WYSIWYG
- Code-Einbettung (PHP/JS/HTML)
- Formular
- Bildergalerie
- Shop
- Mini-Framework, um damit z.B. Slider o.ä. zu realisieren [also das, was jetzt Members oder OfA ist]
- Newsletter (ha, ha)
- Kalender

Backend-Tools:
- Kopieren von Seiten/Seitenbäumen
- Bulk-Änderung von Metadaten
- Bearbeiten von Template- und Moduldateien im Backend
- Zugriffsstatistik

Nicht falsch verstehen: das sind m.E. die absoluten Basics. Es ist super, dass es funktionierende Module für Downloads und Forum gibt, und ich habe sicherlich einiges an Modulen vergessen, aber ohne die oben aufgeführten Möglichkeiten geht es - nochmal: das ist nur meine persönliche Meinung - überhaupt nicht, während andere Inhaltstypen _ggfs._ auch anders realisiert werden könnten.

cwsoft · 24.05.2016 13:31:18

@Florian: Danke für die Aufzählung. Diese Funktionen finde ich auch unabdingbar. Zusätzlich noch eine vernünftige und zeitgemässe Medienverwaltung.

Hast Du alle WBCE Module die im AOR gelistet sind mit WBCE 1.2.0-alpha.4 getestet? Wenn ja ist die Zahl der nicht lauffähigen Module ja wirklich überschaubar. Es sollte möglich sein, diese Module mit überschaubarem Aufwand für WBCE 1.2.0 oder 2.0.0 fit zu machen. Kann dabei gerne ab Mitte Juni mitarbeiten.

Gruss cwsoft

florian · 24.05.2016 13:36:02

Ich muss zugeben, nicht alle Module getestet zu haben, sondern eher nur so stichprobenartig meine "Lieblingsmodule" getestet zu haben.
Sollte das vielleicht noch mal etwas konsequenter und systematischer durchziehen.

evaki · 24.05.2016 15:06:07

Mitte nächsten Monats geht voraussichtlich bei mir auch (Test: Code/Sicherheit und so).
Ne Liste, wer was macht, jeweiliger Stand (wg. Freigabe für Test, auch zwischenzeitlich), und Downloadort wäre m.E. sinnvoll -oder wie auch immer "gescheit" und effizient organisiert.
MfG. Evaki

cwsoft · 24.05.2016 17:01:21

@Florian, Evaki: Würde vorschlagen für alle Module im AOR ein Github Repository anzulegen. So können Änderungen transparent nachvollzogen werden und auch leicht Zweige für WBCE 1.x, 2.x etc. angelegt werden.

Ich kann das wenn gewünscht gerne machen. Sollen die Addons einfach unter demWBCE Github Account eingetragen werden, oder soll es für WBCE-Addons einen eigenen Github Account geben? Ich bevorzuge erstere Variante. Irgendwelche Namenskonventionen (z.B. mod-anynews, tpl-super-responsive, theme-argos ... oder einfach anynews, argos ...).

Gruss cwsoft

WBCE CMS Forum

#1 30.12.2015 16:16:00

Modules which do not work with 1.2 yet

#2 30.12.2015 22:51:22

Re: Modules which do not work with 1.2 yet

#3 30.12.2015 23:25:22

Re: Modules which do not work with 1.2 yet

#4 19.05.2016 16:00:43

Re: Modules which do not work with 1.2 yet

#5 19.05.2016 19:35:20

Re: Modules which do not work with 1.2 yet

#6 19.05.2016 19:38:56

Re: Modules which do not work with 1.2 yet

#7 19.05.2016 19:41:09

Re: Modules which do not work with 1.2 yet

#8 19.05.2016 19:42:09

Re: Modules which do not work with 1.2 yet

#9 19.05.2016 19:52:16

Re: Modules which do not work with 1.2 yet

#10 19.05.2016 20:17:18

Re: Modules which do not work with 1.2 yet

#11 19.05.2016 20:27:47

Re: Modules which do not work with 1.2 yet

#12 19.05.2016 20:58:05

Re: Modules which do not work with 1.2 yet

#13 20.05.2016 09:15:13

Re: Modules which do not work with 1.2 yet

#14 20.05.2016 09:56:06

Re: Modules which do not work with 1.2 yet

#15 23.05.2016 14:46:05

Re: Modules which do not work with 1.2 yet

#16 23.05.2016 21:34:30

Re: Modules which do not work with 1.2 yet

#17 23.05.2016 23:57:08

Re: Modules which do not work with 1.2 yet

#18 24.05.2016 06:43:01

Re: Modules which do not work with 1.2 yet

#19 24.05.2016 06:52:32

Re: Modules which do not work with 1.2 yet

#20 24.05.2016 08:56:35

Re: Modules which do not work with 1.2 yet

#21 24.05.2016 10:04:38

Re: Modules which do not work with 1.2 yet

#22 24.05.2016 13:31:18

Re: Modules which do not work with 1.2 yet

#23 24.05.2016 13:36:02

Re: Modules which do not work with 1.2 yet

#24 24.05.2016 15:06:07

Re: Modules which do not work with 1.2 yet

#25 24.05.2016 17:01:21

Re: Modules which do not work with 1.2 yet

Fußzeile des Forums