Problems with mpForm 1.3.4x

[hgs]

I have recently been updating one of these sites and have updated WB to the latest version, v2.13.1. Many of the additional modules unfortunately have not been updated for some years. I have updated a couple, e.g. MPForm and Topics, to the latest versions listed but have found that it appears that they no longer function in the same way that they did. I have been in contact with the developers to try to address some difficulties. I think some of the problems might relate to the updating of WB no longer supporting all pre-existing modules.

Which version of mpForm are you working with?Here running mpForm 1.3.40 with the latest WebsiteBaker 2.13.2 with php 8.1
The rest has crnogorac081 already explained and in a few days the next stage of php comes with version 8.2.

[mikejd]

@hgs
I am using MPForm 1.3.42 with WB 2.13.0.
The latest form I have produced looks fine but trying to submit just produces an error with Mailer. This also now happens with a previous form which used to work OK. I have been in contact with Martin Hecht, the developer, who has been trying to sort the issue but he is having to set up a complete WB installation to be able to test it.

It has been suggested to try another CMS, WBCE, which is a branch of WB. However it seems that this may have been easy to convert to from WBv2.8 but not from v2.13. I am also not sure I want to spend the necessary time to learn this.

I have just received another MPForm update from Martin which I shall be trying shortly.

[hgs]

Please attach Martin's new version here so we can test that too.
Thank you.

But it doesn't make much sense to test it with an outdated WB version.
Current version of WB is 2.13.2 r133

[Martin Hecht]

The WBMailer has been moved into another namespace and at a different location. I have added code to take this into account, but I might have misunderstood the WB developers messages - or they have changed their plans afterwards.

In addition there is a problem with the phplib template engine, which doesn't support php > 8.0 properly. I ran into these phplib problemes yesterday with php 8.1. I should give 8.0 a try, but still it's not clear to me how to call the wbmailer in WB 2.13.2. Attached is my latest approach to address this (the version that Mike has tested).

@hgs, if you have mpform 1.3.40 running with WB 2.13.2 and php 8.1, I would assume that there were either some (little) changes needed, or you just didn't stumble over the problems (yet) - frontend and backend looks ok at the first glance, but e.g. changing settings didn't work for me with php8.1, and Mike has run into the problem that the wbmailer is not working

[hgs]

ok, I have updated the test page with mpForm.
There was this success message:

Updating database for module: mpForm
Adding new fields to the settings table
Adding new fields to the fields table
Search function updated successfully
Adding new field(s) to the submissions table
Adding putting css files in place

Module mpForm updated to version: 1.3.42.1

In the backend I added a field, the error message looks like this:

Code: [Select]

"created: [Fri, 11 Nov 2022 13:05:56 +0000]
Fri, 11 Nov 2022 13:06:00 +0000 [E_DEPRECATED] /modules/mpform/save_field.php:[448]  from /modules/mpform/save_field.php:[448] str_replace "str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated""In the frontend I was able to submit the form.

Addendum:
When submitting it still comes up this ErrorLog

Code: [Select]

Fri, 11 Nov 2022 13:10:27 +0000 [E_USER_DEPRECATED] /framework/class.wb.php:[537]  from /framework/class.wb.php:[537] trigger_error "invalid method call: bin\wb::get_user_id change it to getUserId()"to fix in this file

Code: [Select]

mpform-1.3.42.1\evalform.php (2 hits)
    Line 460:         if(isset($admin) AND $admin->is_authenticated() AND $admin->get_user_id() > 0) {
    Line 461:             $submitted_by = $admin->get_user_id();


2nd addendum

For the phplip template problem this line at the beginning of the template section should help, so the module is usable in both worlds

Code: [Select]

if (!class_exists('Template')){ require(WB_PATH.'/include/phplib/template.inc');}

[crnogorac081]

Martin, use twig its much better for templates

The WBMailer has been moved into another namespace and at a different location. I have added code to take this into account, but I might have misunderstood the WB developers messages - or they have changed their plans afterwards.

In addition there is a problem with the phplib template engine, which doesn't support php > 8.0 properly. I ran into these phplib problemes yesterday with php 8.1. I should give 8.0 a try, but still it's not clear to me how to call the wbmailer in WB 2.13.2. Attached is my latest approach to address this (the version that Mike has tested).

@hgs, if you have mpform 1.3.40 running with WB 2.13.2 and php 8.1, I would assume that there were either some (little) changes needed, or you just didn't stumble over the problems (yet) - frontend and backend looks ok at the first glance, but e.g. changing settings didn't work for me with php8.1, and Mike has run into the problem that the wbmailer is not working

[Martin Hecht]

Well, the module was written for wb 2.7 and I was taking care about it since 2014. One could rewrite it for twig. Maybe this would solve a few problems,  but other things would still be broken. All the security features don't work in WB anymore. The template engine is broken noe, the mailer is not usable anymore. In an attempt to update a very simple test environment from 2.13.1 to 2.13.2 the installation got skrewed up and the upgade skript bailed out. I've thrown it away and reinstalled it, but still I can't make even simple adjustments. Sorry, but I must agree with mike that WB is not usable anymore. Sorry.

[ruebenwurzel]

Hello,

Martin,didn't you read this from hgs?

... Here running mpForm 1.3.40 with the latest WebsiteBaker 2.13.2 with php 8.1 ...

As far as i see, it is possible to have a version of MPForm wich works with WB and the forks. To get the phplib an phphmailer working it only needs to add two or three additional lines of code. How to adapt Modules is postet here in the Forum on several places.

Sorry, but I must agree with mike that WB is not usable anymore. Sorry.

This is simply not true.

[hgs]

Hi Martin
Your statement is m.E. already a little over the target.
Your profile says "beta tester" just like mine.

If problems are reported here, then solutions are sought and implemented as quickly as possible.

The current development version of WB 2.13.3 Rev. 145 is such a solution, also for mpForm.

Here the test environment, where mpForm runs in the posted version (the get_user_id problem I have already fixed privately for the test) in the FE and BE without problems.

Translated with www.DeepL.com/Translator (free version)
Originaltest in Deutsch
Hi MartinDeine Aussage ist m.E. schon ein wenig übers Ziel hinaus.
In deinem Profil steht "Beta-Tester" so wie bei mir.
Wenn hier Probleme gemeldet werden, dann wird auch so schnell wie möglich nach Lösungen gesucht und diese umgesetzt.
Die aktuelle Entwicklungs-Version von WB 2.13.3 Rev. 145 ist so eine Lösung, auch für mpForm.
Hier die Testumgebung, wo mpForm in der geposteten Version (das get_user_id Problem habe ich für den Test schon mal privat gefixt) im FE und BE ohne Probleme läuft.

[Martin Hecht]

Nun, die  WB 2.13.3 Rev. 145 steht mir nicht zur Verfügung. Bei mir, unter WB 2.13.2, funktioniert jedenfalls die phplib nicht mehr. Die Platzhalter werden nicht ersetzt. Demzufolge kann ich kein Formular anlegen, keine Settings ändern und keine Probleme nachstellen. Ich sehe gerade da hat @hgs auch was dazu geschrieben. Muss ich nochmal schauen, aber ich denke das Einbinden der Template-Klasse ist nicht das Problem. Es geht ums Ersetzen der Platzhalter unter php 8.x.

[sternchen8875]

Habe nun auf verschiedenen Servern verschiedene mpform-Versionen getestet bzw im online-Einsatz. Allesamt mit der aktuellen Stable-Version WB 2.13.2 R 133 und verschiedenen mpform-Versionen ab 1.3.39. Diese Version ist auf allen Live-Pages installiert. Die PHP-Versionen variieren je nach Anbieter zwischen PHP 8.1.3 und PHP 8.1.9. Der Versand läuft überall über PHPMail. Ich meine, hier irgendwann mal gelesen zu haben, das SMTP nicht funktioniert, nagelt mich aber bitte nicht darauf fest. Hier wäre zu beachten, das nicht jeder Anbieter aus Spam-Schutzgründen diese PHPMail unterstützt. Andere bestehen zusätzlich noch darauf, das nur server-eigene Mails verwendet werden dürfen, bedeutet: Domainename und Domainendung der EMail müssen zur Domain passen. Dies würde dann aber für das komplette WB-System und auch für andere CMS gelten.

Probleme beim mpform habe ich nur, wenn die gd-Library nicht installiert ist. Diese ist normalerweise Standard, es gab aber gerade mit Einführung von PHP 8.x Probleme bei diversen Providern mit einer fehlenden gd-Lib. Bei mir betraf das einen Server bei 1&1 mit der PHP-Version PHP-Version 8.1.3. Wählt man eine andere 8er-PHP-Version, ist die gd-Lib wieder vorhanden.
Ist die gd-Lib nicht vorhanden, bringt mpForm einen Fehler in der add.php, siehe Erklärung im mpform-Thread dazu.

Ein zweites Problem habe ich in den allgemeinen Settings von mpform und dort speziell in den Angaben zur EMail.
Wird bei den EMail-Settings keine EMail-Adresse angegeben, sondern statt dessen die anderen Optionen wie z.b. SERVER-EMAIL gewählt, funktioniert der Prüfvorgang validate_email() nicht mehr. Resultat ist diese Fehlermeldung

There was an uncatched exception
preg_match(): Argument #2 ($subject) must be of type string, bool given
in line (620) of (\framework\class.wb.php)

Die Formulare meiner Live-Seiten werden täglich benutzt, in einem Fall (Jugendherberge) sogar mehrmals täglich. Keinerlei Probleme, weder im Backend, noch im Frontend. Auch das von Martin erwähnte Platzhalterproblem sehe ich nicht

Ganz allgemein ist es wohl so, das die PHPLib nicht mehr weiterentwickelt wird und das schon seit recht langer Zeit. Als CMS-Autor steht man irgendwann vor der Frage: . Macht es noch Sinn, weiter auf diesen Baustein zu setzen oder sollte man sich umorientieren. Und dann wäre die nächste Frage: Ist es sinnvoll, zweigleisig zu fahren und wenn JA, welcher Aufwand wäre nötig.

Bekannt ist, das WB wie auch die Forks die PHPLib im kompletten Backend benutzen und einige Module, die nicht von WB selbst gepflegt werden, nutzen die PHPLib auch im Frontend, wie eben mpform, oneforall, Downloadgallery, foldergallery oder bakery etc.
Komplexe Module wie die Genannten, auf Twig umzubauen, ist m.E. noch komplexer als das Backend umzubauen. Das ließe sich durchaus abschnittsweise bewerkstelligen, pro WB-Version ein Abschnitt z.b. - das geht bei einem komplexen Modul nicht.
Ich habe für mich ein neues, auf OneforAll basierendes Modul gebaut mit all den vorhandenen Möglichkeiten, kombiniert mit dem, was die neuen WB-Versionen so bietet. Da sitz ich schon Monate dran, natürlich keine Vollzeit. Es läuft wohl auf mehreren Live-Pages, aber nur in abgespeckter Form.
Egal, was ich meinte, ist der zeitliche Aufwand. Kann ich all das abkürzen durch das Einfügen von 2,3 Zeilen Code, ist das eine Lösung, mit der doch alle leben könnten. Lt Changelog ist der Code zum Anwenden der alten PHPLib bereits seit 2018 in den 4 betreffenden Dateien. Hab nicht geschaut, ob das alle nötigen Stellen sind, da das Modul aber problemlos läuft, scheint es okay zu sein.

Für andere wie z.b. members oder kleine Galerien ist es aber eine schnelle Lösung, die auch Ungeübte fix einbauen könnten.
Natürlich kann man auch fragen, ob es nicht möglich wäre, dies über eine zentrale Abfrage zu lösen. Ist wohl eine Frage der Grundphilosophie. Irgendwann würde sich Ausnahme an Ausnahme reihen und es wird auch der Punkt kommen, das dieses alte Backend nicht mehr auf Basis der PHPLib arbeitet, sie ggf auch garnicht mehr mitgeliefert wird, dann weiß am Ende niemand mehr, wie man irgendwas noch zum Laufen bekommt.
Irgendwelche Ankündigungen für mögliche Änderungen in der zukunft kann man sich sparen, das sieht man an den Frontend-Templates. Diese kleine Definition

Code: [Select]

$template_function     = 'template';wurde schon von den Gründervätern von WB beschlossen. Sie dient der Unterscheidung von Front- und Backend-Template. Das ist über 20 Jahre her und jeder Templateautor kennt es, trotzdem findet man in aller Regelmäßigkeit Hilfeanfragen, weil sich Template "ABCD" nicht mehr installieren läßt, es läuft doch an anderer Stelle....


Deepl-Translate

Have now tested different mpform versions on different servers or in online use. All with the current stable version WB 2.13.2 R 133 and various mpform versions from 1.3.39. This version is installed on all live pages. The PHP versions vary depending on the provider between PHP 8.1.3 and PHP 8.1.9. The dispatch runs everywhere over PHPMail. I think I have read here that SMTP does not work, but please don't nail me down on that. Please note that not every provider supports PHPMail for spam protection reasons. Others also insist that only server-own mails may be used, which means: Domain name and domain extension of the EMail must fit to the domain. This would then apply to the complete WB system and also to other CMS.

Problems with the mpform I have only if the gd library is not installed. This is normally standard, but with the introduction of PHP 8.x there were problems with various providers with a missing gd-lib. In my case it was a server at 1&1 with the PHP version PHP version 8.1.3. If you choose another 8 PHP version, the gd-lib is available again.
If the gd-lib is not present, mpForm brings an error in the add.php, see explanation in the mpform thread about this.

A second problem I have is in the general settings of mpform and there specifically in the EMail details.
If no email address is specified in the email settings, but instead the other options such as SERVER-EMAIL are selected, the validate_email() process no longer works. Result is this error message

There was an uncatched exception
preg_match(): Argument #2 ($subject) must be of type string, bool given
in line (620) of (\framework\class.wb.php)

The forms of my live pages are used daily, in one case (youth hostel) even several times a day. No problems at all, neither in the backend, nor in the frontend. Also I don't see the placeholder problem mentioned by Martin

In general, it seems that the PHPLib is no longer developed and that for quite a long time. As a CMS author you are confronted with the question: . Does it still make sense to continue to rely on this module or should you reorient yourself. And then the next question would be: Does it make sense to go two-track and if YES, what effort would be necessary.

It is known that WB as well as the forks use the PHPLib in the complete backend and some modules, which are not maintained by WB itself, use the PHPLib also in the frontend, like mpform, oneforall, downloadgallery, foldergallery or bakery etc..
Converting complex modules like those mentioned to Twig is in my opinion even more complex than converting the backend. This could be done in sections, e.g. one section per WB version - this is not possible with a complex module.
I have built a new module for myself, based on OneforAll, with all the existing possibilities, combined with what the new WB versions offer. I've been working on it for months, not full time of course. I guess it runs on several live pages, but only in a stripped down form.
Anyway, what I meant is the time involved. If I can shorten all that by adding 2,3 lines of code, that's a solution everyone could live with. Lt changelog the code to apply the old PHPLib is already in the 4 files in question since 2018. Haven't looked to see if these are all the necessary places, but since the module runs smoothly, it seems to be okay.

But for others like members or small galleries it is a quick solution that even inexperienced people could install fix.
Of course you can also ask if it would not be possible to solve this via a central query. Is probably a question of basic philosophy. At some point exception after exception would line up and it will also come to the point that this old backend no longer works on the basis of the PHPLib, it may not even be supplied, then in the end no one knows how to get anything to work.
Any announcements for possible changes in the future can be saved, you can see that in the frontend templates. This little definition

Code: [Select]

$template_function = 'template';was already decided by the founding fathers of WB. It is used to distinguish between front-end and back-end templates. This is over 20 years ago and every template author knows it, nevertheless one finds in all regularity help inquiries, because template "ABCD" cannot be installed any more, it runs nevertheless in other place....

Translated with www.DeepL.com/Translator (free version)

[hgs]

@Martin
Hab dir eine pm gesendet
Danke sternchen8875 für die gute Erklärung

[Martin Hecht]

bin ein Stückchen weiter gekommen: In der Datenbank fehlt die Settings Zeile. Daher sind die zu ersetzenden Werte NULL. Die nächste Frage: Wieso fehlt die Zeile in der DB? Wird beim Anlegen einer neuen Section die add.php nicht mehr ausgeführt?

[sternchen8875]

Wird beim Anlegen einer neuen Section die add.php nicht mehr ausgeführt?

doch, sie wird ausgeführt, sie wird aber über zwei Weiterleitungen geschalten. Abhängig von den Serverseitigen Fehlerausgabeeinste llungen und den WB-eigenen, kann es sein, das nur bei einem Abbruch ein PHP- oder MySQL-Fehler ausgegeben wird.

Der Nullereintrag wird eigentlich schon beim Moduleinstall geschrieben, das war früher mal Usus bei den Modulen und hatte wohl mit den Weiterleitungen zur modify.php des jeweiligen Moduls zu tun, die dann diesen Nullereintrag gleich als ersten Datensatz benutzt hatte.

Zur Fehleranalyse gehe in die WB-Optionen, Block allgemeine Optionen, klicke rechts auf Erweiterte Optionen und trage bei WEITERLEITUNG ein = -1 (minus eins)
Dann gehe in die add.php. Letzte Zeile ist dort

Code: [Select]

$database->query($SQL);
Setze dies vor diese Zeile  -> echo $SQL;
also so

Code: [Select]

echo $SQL;
$database->query($SQL);
Speichern und eine mpform-Sektion hinzufügen
Ausgegeben wird nun der Mysql-Insert. Kopiere den kompletten INSERT (siehe Bild), gehe in die Datenbank zu dieser Installation, klicke oben auf SQL und füge den kopierten Text ein, Speichere mit OK.

Nun bekommst du entweder eine Erfolgreich-Meldung oder ein entsprechendes Fehlerfeld, das die Stelle im Insert zeigt.

[Martin Hecht]

Halllo  sternchen8875,
danke für den Tipp. Damit bin ich dem Problem auf die Spur gekommen. use_captcha wurde als Boolean gesetzt, ist aber in der Datenbank ein integer. Schön, dass du bisher nicht über das Problem gestolpert bist. Im Anhang eine Version, in der das Problem behoben ist (und hoffentlich die anderen hier berichteten Problemchen).
Viele Grüße, Martin

[hgs]

Habe gerade getestet
Im BE bei Anlegen von einem neuen Feld wird folgendes in der ErrorLogger geschrieben:

Code: [Select]

"created: [Mon, 14 Nov 2022 16:43:41 +0000]
Fri, 18 Nov 2022 08:57:47 +0000 [E_DEPRECATED] /modules/mpform/save_field.php:[480]  from /modules/mpform/save_field.php:[480] str_replace "str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated""
Beim Versenden kommt eine weiße Seite mit folgendem Fehlertext:

Code: [Select]

There was an uncatched exception
 Call to undefined function method_existes()
 in line (461) of (/modules/mpform/evalform.php):
getestet mit der offiziellen WB Version 2.13.2 r133
und der Entwicklungsversion WB 2.13.3 r145
beides unter php 8.1
Testserver ist bei allinkl.com

[hgs]

Da haben sich wohl zwei keine Typofehler eingeschlichen, hat mir ein lieber WBler erzählt.
evalform.php zn 461+462

        AND (method_existes($admin,'getUserId')?$admin->getUserId():$admin->get_user_id()) > 0) {
            $submitted_by = (method_existes($admin,'getUserId')?$admin->getUserId():$admin->get_user_id());
müsste

        AND (method_exists($admin,'getUserId')?$admin->getUserId():$admin->get_user_id()) > 0) {
            $submitted_by = (method_exists($admin,'getUserId')?$admin->getUserId():$admin->get_user_id());
werden.
Die ErrorLog Meldung beim anlegen von einem neuen Feld ist weiter vorhanden

[CodeALot]

I think this thread has derailed pretty much. The topic was WB being too difficult to use...

[Martin Hecht]

oh, I have fixed the typos and hopefully the error log entries when creating new fields

[hgs]

Fast an Ziel
Neues Feld anlegen erzeugt jetzt diesen Eintrag im Errorlog

Code: [Select]

"created: [Sat, 19 Nov 2022 04:58:20 +0000]
Sat, 19 Nov 2022 05:01:01 +0000 [E_WARNING] /modules/mpform/modify_field.php:[420]  from /modules/mpform/modify_field.php:[420] bin\Exceptions\ErrorHandler::handler "Undefined array key "separator""

[Martin Hecht]

thanks @hgs for spotting all these little mistakes. Here another prerelease

[hgs]

Danke Martin für die unermüdliche Anpassung an mpForm.

Die Aktuelle Version habe ich mit WB 2.13.2 r133

und der bald erscheinenden WB 2.13.3 r146 unter php 8.1 erfolgreich ohne Probleme getestet.

Translate DeepL
Thanks Martin for the tireless adaptation to mpForm.

The Current Version I have with WB 2.13.2 r133

and the soon to be released WB 2.13.3 r146 under php 8.1 successfully without any problems.

[hgs]

@ Martin
Machst du noch eine 1.3.43,  so wie es in der Changelog schon drin steht?

Auszug aus der Changelog.txt
        *** 1.3.43 (Martin Hecht: 19-Nov-2022)
        support wb 2.13.2 - WB has renamed get_user_id (fixed typo here)
        set use_captcha as int instead of bool - consistence with sql structure
        fix warning when separator is empty, include fix for array index

Oder soll ich diese Version ins addon laden?

[Martin Hecht]

Hi Harald,
thanks for testing. I have incremented the version number here as already announced in the changelog.
best regards, Martin