WebsiteBaker Support (2.13.x) > General Help & Support

Problems with mpForm 1.3.4x

<< < (3/5) > >>

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


--- Quote ---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)
--- End quote ---

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: ---$template_function     = 'template';
--- End code ---
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


--- Quote ---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)
--- End quote ---

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: ---$template_function = 'template';
--- End code ---
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 (Y)

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:

--- Quote from: Martin Hecht on November 16, 2022, 09:50:59 PM ---Wird beim Anlegen einer neuen Section die add.php nicht mehr ausgeführt?

--- End quote ---

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: ---$database->query($SQL);
--- End code ---

Setze dies vor diese Zeile  -> echo $SQL;
also so

--- Code: ---echo $SQL;
$database->query($SQL);
--- End code ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page