WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: masju on November 03, 2024, 01:56:34 PM
-
Ich mache hier mal einen neuen Thread auf, der nur peripher etwas mit dem "Sendeproblem" zu tun hat.
Das "Form"-Modul sendet bei meiner mehrsprachigen Seite nur, wenn ich bei der Seite die Sprache auf die "Primärsprache" der Site setze. Ist statt DE z.B. ES eingestellt, wird noch nicht einmal die E-Mail-Versandroutine aufgerufen, was ich an der fehlenden Debug-Information erkenne (ich habe bei den WB-Optionen unter E-Mail-Einstellungen das "Mail Debug:" auf "DEBUG_LOWLEVEL" gesetzt).
Also:
Spracheinstellung auf DE (=Primärsprache der Seite): Mailversand klappt, DEBUG-Infos werden angezeigt
Spracheinstellung auf ES: Kein Mailversand, keine DEBUG-Infos
Es spielt keine Rolle, an welcher Stelle die Seite im Seitenbaum eingehängt ist.
Und nun noch eine wichtige Zusatzinfo: Das Gleiche passiert auch bei einem ebenfalls auf der Seite eingebauten mpForm-Modul.
Gruß
masju
-
Noch etwas anderes ist sehr seltsam im Form-Modul:
Wenn ich eingeloggt bin und eine Seite mit Form-Modul aufrufe, dann wird im E-Mail-Adresse-Feld (es ist pro Formular nur jeweils eines zulässig) als Wert die Zieladresse des Formulars vorbelegt (nicht änderbar). Da ist doch etwas ziemlich durcheinander geraten, oder?
Verwirrte Grüße :-o
masju
-
Wenn man eingeloggt ist, erscheint da die Mailadresse aus deinen Session-Daten. Ist man nicht eingeloggt, bleibt das Feld leer - so der Plan
Das nur ein Mailfeld pro Form erlaubt ist, sollte logisch sein, das wäre dann das Absenderfeld des Schreibers. Wozu braucht es mehr?
-
Ah, okay, verstanden, sorry :roll:.
Das im Thread-Start erwähnte Sendeproblem besteht weiterhin.
Ich spiegele gerade die komplette Installation noch mal auf einen Testserver, um nachzuvollziehen, woran es liegt. Könnte das Frontend-Template einen Einfluss haben?
Gruß
masju
-
Könnte das Frontend-Template einen Einfluss haben?
nein, definitiv nicht.
Die Daten für das Frontend kommen allesamt aus der Datenbank.
Bin leider gerade mit Arztbesuchen vollgepackt und hab deswegen nur begrenzte Zeit. Mich irretiert das Sendeproblem. Ich war eigentlich der Meinung, das ich den WB-Code recht gut kenne, aber da fehlt mir gerade der Zusammenhang mit dem PHPMailer und der WBMailer-Funktion
-
Welche Form-Modul-Version verwendest du gerade?
Ich habe hier die Testversion 3.5.0 aus der kommenden WB 2.13.6 mit aktuell 4 Sprachen, DE, EN, NL und SE, Mailversand funktioniert überall, aber da fehlt halt noch das, was ich da schon gemeldet hatte, die Problematik mit der Sendeadresse
-
Ich habe die Version 3.4.4 unter WB 2.13.5 r220 und PHP 8.2.25.
Auf dem Testserver scheint alles zu funktionieren. Einziger offensichtlicher Unterschied: PHP 8.2.24
Auf der Produktivinstallati on kehrt man nach Klick auf "Absenden" auf die Formularseite zurück, keine Fehlermeldung, nix. PHP-Errorlog ist leer.
OT: Falls mal jemand danach sucht: Anbei die bislang fehlende spanische Sprachdatei ES.PHP für das captcha-control-Modul (umbenennen nach .PHP).
-
Vielleicht ein Hinweis, ich bekomme gerade eine Fehlermeldung nach dem Absenden (Error-Log):
[E_WARNING] /modules/form/printForm.php:[217] from /modules/form/view.php:[259] require "Undefined variable $sRequiredString"
Es ist zu beobachten, dass die Frontend-"view.php" vom Formmodul anscheinend gar nicht mitbekommt, dass ein "Submit" eines Formulars stattgefunden hat (bei Seitensprache <> "DE") und damit auch die Senderoutine etc. nicht aufruft.
Wenn ich die Seitensprache auf "DE" stelle, klappt das Versenden problemlos. Kann ich irgendwo eine Debug-Zeile einbauen, die mir anzeigt, was beim Submit übertragen wird?
Das eingestellte Template ist tatsächlich egal.
-
[E_WARNING] /modules/form/printForm.php:[217] from /modules/form/view.php:[259] require "Undefined variable $sRequiredString"
$sRequiredString ist die Definition für das Sternchen bei Pflichtfeldern, da gab es bei dir wohl eine Diskrepanz zwischen dem Inhalt aus der DB und den gemachten Einstellungen. Vielleicht, solang einmalig, auch ein Einlesefehler
Zum Rest... ist das die gleiche Installation, wo es auch Probleme mit der Weiterleitung zum Bearbeiten im Frontend gibt (dein früheres Problem (https://forum.WebsiteBaker.org/index.php/topic,32348.0.html))?
Eine einfache Erklärung wäre die Spracheinstellung. Ansonsten muß man das ganze Form "zerlegen". Der Submit geht durch mind. 4 Dateien, den PHP-Mailer nicht mitgerechnet. Dauert etwas, da den richtigen Punkt zu finden. Morgen bin ich den ganzen Tag unterwegs. Sollte niemand anders eine Idee haben, muß es warten bis Mittwoch
-
Ja, das ist dieselbe Installation, gehostet bei IONOS.
Ich habe sie 1 : 1 auf einen anderen Server (anderer Provider) kopiert (Dateien und Datenbank), dort läuft es.
Gruß
masju
-
Kann ich irgendwo eine Debug-Zeile einbauen, die mir anzeigt, was beim Submit übertragen wird?
Netterweise hab ich einen Kunden mit mehrsprachiger Seite bei Ionos, da funktioniert der Versand in allen sechs Sprachen. :roll:
Grundsätzlich wird das Formular an die gleiche PHP-Seite geschickt. Ein ganz einfacher Test wäre die Abfrage, ob nach dem Abschicken etwas ankommt
echo "<pre>POST in formular.php:<br>";
print_r($_POST);
echo "</pre>";
echo "<pre>GET in formular.php:<br>";
print_r($_GET);
echo "</pre>";
ganz oben in die view.php, am besten, noch vor der ersten Zeile mit dem use....
die ersten drei Zeilen zeigen die POST-Variablen, die letzten drei die GET-Variablen, also das, was ggf per Link mitgegeben wurde. GET wird hier leer bleiben.
Nach Absenden des Formulars werden nun alle Werte aus dem Formular angezeigt, schaut etwa so aus (ein ganz minimales Formular mit Name, Email, Textfeld und Captcha)
(https://i.gyazo.com/4d20f51772b4c3b797ffdb685129ab06.png)
Nach dem Absenden gehts es dann hier weiter (mit obigem Code etwa Zeile 279)
/* --------------------------------------- */
// check for errors and required fields
/* --------------------------------------- */
Ab hier gehts dann mit den Session-Werten los. Die kann man sich auch noch ausgeben lassen mit
echo "<pre>Session:<br>";
print_r($_SESSION);
echo "</pre>";
das würde dann so aussehen
(https://i.gyazo.com/e53633e6576e12b93130d6ca2149fa40.png)
Fehlen da wichtige Sessiondaten, wäre hier schon Schluß
Ist alles Nötige vorhanden, geht das Formular in die Datei checkForErrors.php. Ist die Prüfung erfolgreich, gehts in die sendMails.php und von da dann zum PHPMailer
Mach dir auf jeden Fall vor der Bearbeitung ein Backup der view.php oder des ganzen Form-Moduls. Ich würde nach dieser Zeile suchen, im Original Z 495
if (\is_readable($sAddonPath.'checkForErrors.php')){require $sAddonPath.'checkForErrors.php';}
und in der Zeile davor den Code für die Session einfügen, damit hättest du dann gleiche alle Werte inkl der nötigen Sessiondaten (siehe mein letztes Bild)
Alles, was im Formular verwendet wird, schreibt das Script in die Session, damit es im Falle einer negativen Prüfung nicht erneut getippt werden muß.
Mein Tip geht da schon in die Session, weil es auch das gleiche Problem ist wie die Pagecode-Sache. Das konnten wir aber mit deiner Anleitung auch auf anderen Servern bestätigen, da ist also schon ein Knoten irgendwo drin
-
Vielen Dank! Ich habe die Modul-Dateien nicht geändert, sondern Deinen Code einfach in eine Code-Section auf die Formularseite gepackt :-)
Ergebnis:
Spracheinstellung DE (Mailadresse geändert)
(
POST in formular.php:
Array
[section_id] => 276
[submission_id] => 8755528
[submitted_when] => 1730804222
[email] =>
[homepage] =>
[url] =>
[comment] =>
[field28] => info[at]domain[dot]tld
[field27] => Blavla
[captcha276] => 6
[submit] => Absenden
)
GET in formular.php:
Array
(
)
Spracheinstellung ES:
POST in formular.php:
Array
(
)
GET in formular.php:
Array
(
)
Es scheitert also bei Sprache <>DE schon an der Übertragung per POST.
Ich habe nun mal die Quellcodes zweier mit unterschiedlichen Sprachen erzeugten FORMS verglichen, sie sind identisch (bis auf submission_id und submitted_when). Es wird immer seltsamer :-o.
Gruß
masju
-
Nimm mal den Code für die Session statt POST oder GET
echo "<pre>Session:<br>";
print_r($_SESSION);
echo "</pre>";
ruhig rein in deine Code-Section
Wenn du nun über das Fähnchenmenü die Sprachen umschaltest, sollte sich der Language-Wert in den Session-Daten stets mit ändern
-
Alles klar, danke!
Ich habe gerade noch herausgefunden, dass das POST funktioniert, wenn Browsersprache (bei Firefox umgestellt) und Seitensprache übereinstimmen (ES=ES, oder EN=EN). Das Problem ist also nicht abhängig von der Primärsprache der WB-Installation.
Welchen Teil von $_SESSION soll ich posten? Nur den Teil ab
[PAGE_ID] => 125
[HTTP_REFERER]...
?
Der [LANGUAGE] => Wert ändert sich gemäß Seiteneinstellung.
Gruß
masju
-
Ich habe gerade noch herausgefunden, dass das POST funktioniert, wenn Browsersprache (bei Firefox umgestellt) und Seitensprache übereinstimmen (ES=ES, oder EN=EN).
What?
Das ist mit Sicherheit eine Sache, die vorher niemand von uns getestet hat :oops:
Wir haben zwar auch Tester aus dem nicht-deutschsprachigem Raum, aber da muß dann ja auch alles passen, z.b. eben eine mehrsprachige Testversion
Der [LANGUAGE] => Wert ändert sich gemäß Seiteneinstellung.
diese Info ist ausreichend, Danke
Muß jetzt leider los, bin erst am Abend wieder da
-
Ich habe gerade noch herausgefunden:
Es liegt nicht am Form-Modul, sondern an der Übermittlung von Formularen per POST im Allgemeinen. Ich habe den <form></form>-Abschnitt im Quelltext in eine eigene WYSIWYG-Section gepackt, und auch hier derselbe Effekt.
Und jetzt kommt's: Ich habe in den Einstellungen die Option "Eingangsseite" gewählt und hier eine Sprachweiche eingebaut, die beim Aufruf der index.php per header auf die jeweilige Sprachunterseite umleitet:
<?php
// Verfügbare Sprachunterseiten (z.B. 'de' für Deutsch, 'en' für Englisch)
$available_languages = ['es', 'de', 'en', 'fr'];
// Funktion zum Extrahieren der bevorzugten Sprache
function getPreferredLanguage($available_languages) {
if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) {
// Liste der Sprachen aus dem Header holen und aufsplitten
$languages = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']);
foreach ($languages as $lang) {
// Nur den Sprachcode (z.B. 'de' oder 'en') extrahieren
$lang_code = substr($lang, 0, 2);
// Prüfen, ob die Sprache verfügbar ist
if (in_array($lang_code, $available_languages)) {
return $lang_code;
}
}
}
// Standardmäßig auf Englisch setzen, falls keine passende Sprache gefunden wird
return 'en';
}
// Bevorzugte Sprache des Besuchers ermitteln
$user_language = getPreferredLanguage($available_languages);
// Weiterleitung auf die entsprechende Unterseite mit einem switch
switch ($user_language) {
case 'es':
header("Location: [...]/pg/es/inicio.php"); // Spanisch
break;
case 'de':
header("Location: [...]/pg/de/startseite.php"); // Deutsch
break;
case 'en':
header("Location: [...]/pg/en/home.php"); // Englisch
break;
case 'fr':
header("Location: [...]/pg/fr/accueil.php"); // Französisch
break;
default:
header("Location: [...]/en/home.php"); // Fallback auf Englisch
break;
}
?>
Und jetzt das Wunder von Bern: Schalte ich die Startseite (intro.php) ab, ist alles okay.
Gruß,
masju
-
Du machst mich fertig.... :-D :-D :-D
benenn mal ein paar der Variablen um, einige werden im Core schon verwendet, $lang, $user_language usw
-
(Y)
Variablen geändert in
<?php
// Verfügbare Sprachunterseiten (z.B. 'de' für Deutsch, 'en' für Englisch)
$my_available_languages = ['es', 'de', 'en', 'fr'];
// Funktion zum Extrahieren der bevorzugten Sprache
function getPreferredLanguage($my_available_languages) {
if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) {
// Liste der Sprachen aus dem Header holen und aufsplitten
$my_languages = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']);
foreach ($my_languages as $my_lang) {
// Nur den Sprachcode (z.B. 'de' oder 'en') extrahieren
$my_lang_code = substr($my_lang, 0, 2);
// Prüfen, ob die Sprache verfügbar ist
if (in_array($my_lang_code, $my_available_languages)) {
return $my_lang_code;
}
}
}
// Standardmäßig auf Englisch setzen, falls keine passende Sprache gefunden wird
return 'en';
}
// Bevorzugte Sprache des Besuchers ermitteln
$my_user_language = getPreferredLanguage($my_available_languages);
// Weiterleitung auf die entsprechende Unterseite mit einem switch-Block
switch ($my_user_language) {
case 'es':
header("Location: /pg/es/inicio.php"); // Spanisch
break;
case 'de':
header("Location: /pg/de/startseite.php"); // Deutsch
break;
case 'en':
header("Location: /pg/en/home.php"); // Englisch
break;
case 'fr':
header("Location: /pg/fr/accueil.php"); // Französisch
break;
default:
header("Location: /pg/en/home.php"); // Fallback auf Englisch
break;
}
?>
Noch kein Success.
Seltsam, dass es auf dem gespiegelten Server trotzdem lief.
-
Ging schneller als erwartet bei Doc, Donnerstag früh gehts weiter...
lass dir die Sprachen mal ausgeben mit
var_dump($_SERVER['HTTP_ACCEPT_LANGUAGE']);
vielleicht auch auf dem zweiten Server, um mögliche Unterschiede zu sehen
P.S.: noch ein Tip am Rande: ist ist empfehlenswert, bei solchen Tests immer den Browsercache zu löschen
-
var_dump($_SERVER['HTTP_ACCEPT_LANGUAG E']); ist bei beiden Installationen gleich:
string(23) "de,en-US;q=0.7,en;q=0.3"
string(23) "de,en-US;q=0.7,en;q=0.3"
(Browser-Cache ist gelöscht)
In der Sprachweiche habe ich nochmal komplett die Variablen geändert, keine Änderung.
<?php
// Verfügbare Sprachunterseiten (z.B. 'de' für Deutsch, 'en' für Englisch)
$meine_available_languages = ['es', 'de', 'en', 'fr'];
// Funktion zum Extrahieren der bevorzugten Sprache
function getPreferredLanguag e($meine_available_languages) {
if (isset($_SERVER['HTTP_ACCEPT_LANGUAG E'])) {
// Liste der Sprachen aus dem Header holen und aufsplitten
$meine_languages = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAG E']);
foreach ($meine_languages as $meine_lang) {
// Nur den Sprachcode (z.B. 'de' oder 'en') extrahieren
$meine_lang_code = substr($meine_lang, 0, 2);
// Prüfen, ob die Sprache verfügbar ist
if (in_array($meine_lang_code, $meine_available_languages)) {
return $meine_lang_code;
}
}
}
// Standardmäßig auf Englisch setzen, falls keine passende Sprache gefunden wird
return 'en';
}
// Bevorzugte Sprache des Besuchers ermitteln
$meine_user_language = getPreferredLanguag e($meine_available_languages);
// Weiterleitung auf die entsprechende Unterseite mit einem switch-Block
switch ($meine_user_language) {
case 'es':
header("Location: [...]/pg/es/inicio.php"); // Spanisch
break;
case 'de':
header("Location: [...]/pg/de/startseite.php"); // Deutsch
break;
case 'en':
header("Location: [...]/pg/en/home.php"); // Englisch
break;
case 'fr':
header("Location: [...]/pg/fr/accueil.php"); // Französisch
break;
default:
header("Location: [...]/pg/en/home.php"); // Fallback auf Englisch
break;
}
?>
PS: Wie mache ich den Cursor im Code-Modul und auch in den Droplets wieder sichtbar?
(Hinweis: code macht in diesem Forum aus dem einfachen Hochkomma immer ', deswegen habe ich quote genommen)
-
Ich habe sicherheitshalber auch noch den Funktionsnamen getPreferredLanguag e geändert. Brachte nix.
-
Ich habe nun mehrere Testläufe mit der intro.php hinter mir, denn offensichtlich ändert der Inhalt dieser Datei das Verhalten bei meinen Formularen.
Wenn ich nur die eine Zeile
header("Location: [...]/pg/es/inicio.php");in die Startseite eintrage (leitet auf eine spanische Seite weiter), funktioniert das Formularversenden auf beliebigen Seiten, wenn die Seitensprache Spanisch ist. Unabhängig von der im Browser eingestellten Sprache.
Wenn ich nur die eine Zeile
header("Location: [...]/pg/en/home.php");in die Startseite eintrage (leitet auf eine englische Seite weiter), funktioniert das Formularversenden auf beliebigen Seiten, wenn die Seitensprache Englisch ist. Wieder unabhängig von der im Browser eingestellten Sprache.
Nächster Test: Umleitung nicht mit "Header" sondern <meta http-equiv="refresh" content="0; URL=http://www.domain.de">
-
Soooo, bitte anschnallen:
Ich habe den Inhalt der Eingangsseite geändert in
<?php
// Verfügbare Sprachunterseiten (z.B. 'de' für Deutsch, 'en' für Englisch)
$meine_available_languages = ['es', 'de', 'en', 'fr'];
// Funktion zum Extrahieren der bevorzugten Sprache
function meine_getPreferredL anguage($meine_available_languages) {
if (isset($_SERVER['HTTP_ACCEPT_LANGUAG E'])) {
// Liste der Sprachen aus dem Header holen und aufsplitten
$meine_languages = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAG E']);
foreach ($meine_languages as $meine_lang) {
// Nur den Sprachcode (z.B. 'de' oder 'en') extrahieren
$meine_lang_code = substr($meine_lang, 0, 2);
// Prüfen, ob die Sprache verfügbar ist
if (in_array($meine_lang_code, $meine_available_languages)) {
return $meine_lang_code;
}
}
}
// Standardmäßig auf Englisch setzen, falls keine passende Sprache gefunden wird
return 'en';
}
// Bevorzugte Sprache des Besuchers ermitteln
$meine_user_language = meine_getPreferredL anguage($meine_available_languages);
// Weiterleitung auf die entsprechende Unterseite mit einem switch
switch ($meine_user_language) {
case 'es':
echo '<script language="javascript" type="text/javascript"> document.location="[...]/pg/es/inicio.php"; </script>'; // Spanisch
break;
case 'de':
echo '<script language="javascript" type="text/javascript"> document.location="[...]/pg/de/startseite.php"; </script>'; // Deutsch
break;
case 'en':
echo '<script language="javascript" type="text/javascript"> document.location="[...]/pg/en/home.php"; </script>'; // Englisch
break;
case 'fr':
echo '<script language="javascript" type="text/javascript"> document.location="[...]/pg/fr/accueil.php"; </script>'; // Französisch
break;
default:
echo '<script language="javascript" type="text/javascript"> document.location="[...]/pg/en/home.php"; </script>'; // Fallback Englisch
break;
}
?>
und alles läuft. Warum der Inhalt der Eingangseite dazwischenfunkt, wenn man hier elegant per Header-Redirect verzweigt, ist mir immer noch nicht klar. Anscheinend wird die Seite intro.php nicht nur beim Aufruf der Domain durchlaufen. Aber mit einem primitiven Javascript läuft es wenigstens - zumindest bei Browsern, die das nicht deaktiviert haben.
Gruß
masju