Moin Christoph,
hast du mal probiert die Dokumenten Id statt self zu nutzen?
Verhält es sich dann korrekt? Dann ist es eventuell ein Bug der neuen Version.
LG
Finn
Posts by Finn
-
-
Der Hoster sollte wohl (hoffentlich) Backups der DB haben von vor dem Update.
-
Habt ihr eine Lösung gefunden? Gerade das gleiche Problem, kann kein Update oder Backup mehr machen, bei Datenbank aktualisieren bleibt er hängen. HostEurope macht nur noch php 8.1 oder 8.2 ...
In der Bugbase habe ich gefunden: "Datenbank updates schlagen fehl, wenn der DB Benutzer keine Rechte RELOAD oder FLUSH_TABLES besaß"
Wie stelle ich das denn an?!
Wenn du auf dem Server nicht weiter kommst, zur Not die Datenbank und das Dateiverzeichnis kopieren, lokal unter PHP 8.0 das Update machen und die aktualisierte DB + Files wieder hochschieben.
(Datenbank jeweils in der Config entsprechend anpassen) -
Mit relativ hoher Wahrscheinlichkeit wird es das sein:
OpenSSL 1.1.1n 3.0.14-1 Siehe Hinweis in der Versionshistorie:
https://www.webedition.org/de/dokumentation-community/versionshistorie/
Achtung: wichtiger Hinweis bis Version 9.1.3Sollte der Provider auf OpenSSL >3.0 wechseln, so ist ein Login in webEdition nicht mehr möglich. Man kann dann in der config_global von Hand die Sessionverschlüsselung deaktivieren, um einen Zugang wieder zu ermöglichen. Wir empfehlen bald möglichst die aktuelle Version ab 9.1.4 einzuspielen.
-
Weitere Ursache könnte ein Update der SSL Version sein, welche WE Version ist aktiv und welche SSL Version?
-
Hey Mo,
vielen Dank für deine Unterstützung. Bei Aussagen wie „das macht grundsätzlich keinen Sinn“ wäre ich jedoch vorsichtig – es könnte einfach außerhalb des eigenen Horizonts liegen. Ich habe für mein Problem inzwischen eine andere Lösung gefunden.
Moin Kay,
Marc hat schon Recht, Formulare im Backend führen oft zu Fehlern, da diese unter Umständen beim Speichern, Veröffentlichen etc. abgesendet werden und Systemfunktionen so stören können. -
Moin Moin,
ich versuche mal ein paar Fragen raus zu lesen und zu beantworten:Vieles habe ich auch mit XAMPP gemacht. Die Fehlermeldung "Dear customer, our service is currently not available. Please try again later. Thank you. Sehr geehrter Kunde, aus Sicherheitsgründen ist ein Login derzeit nicht möglich! Bitte probieren Sie es später noch ein mal. Vielen Dank" kommt vom Provider oder von WebEdition?
> Ja webEdition merkt sich fehlgeschlagene Logins und sperrt die entsprechende IP Adresse für eine festgelegte Zeit, wenn ein Limit pro Zeiteinheit ereicht ist, dieses lässt sich in den Einstellungen festlegen.
Die Anzahl der Fehlversuche war immer 0/4 in 1h in der Kundenverwaltung angezeigt.
> hm du kannst mal in der Datenbank schauen, in der Tabelle tblFailedLogins stehen alle Fehlgeschlagenen Logins drin.Super dass Sicherheit eingebaut ist - aber ich wüsste gerne wo und wer. 4 Fehlversuche und danach 1h Wartezeit?
> Du kannst dir mit einem Listview diverse Infos für ein Admindashboard ausgeben lassen, ich glaube fehlgeschlagene Logins gehen aber nicht, weil es sich um einen Dynamsichen Wert aus der tblFailedLogins handelt und nicht ein Feld des "Kunden" ist.
So kann so ein ListView aussehen, der die Daten in ein Array schreibt um sie z.B. als JSON auszugeben.
<?php
$data = array();
$i = 0;
?><we:listview type="customer" order="Surname" >
<we:repeat>
<we:field name="we_id" to="global" nameto="data[$i][ID]" />
<we:field name="Forename" to="global" nameto="data[$i][Forename]" />
<we:field name="Surname" to="global" nameto="data[$i][Surname]" />
<we:field name="Username" to="global" nameto="data[$i][Email]" />
<we:field name="Berechtigungen_Rolle" to="global" nameto="data[$i][Rolle]" />
<we:field name="Berechtigungen_Sonderrechte" to="global" nameto="data[$i][Sonderrechte]" />
<we:field name="Berechtigungen_OhneZuweisung" to="global" nameto="data[$i][StandortVisibility]" />
<we:field name="Berechtigungen_Standorte" to="global" nameto="data[$i][Standorte]" />
<we:field name="Berechtigungen_Kategorien" to="global" nameto="data[$i][Kategorien]" />
<we:field name="Berechtigungen_Reiter" to="global" nameto="data[$i][Reiter]" />
<we:field name="LastLogin_Date" to="global" nameto="data[$i][LastAccess_Date]" />
<we:field name="Signatur_Praefix" to="global" nameto="data[$i][Signatur_Praefix]" />
<we:field name="Signatur_Standort" to="global" nameto="data[$i][Signatur_Standort]" />
<we:field name="Signatur_Position" to="global" nameto="data[$i][Signatur_Position]" />
<we:field name="Signatur_Telefon" to="global" nameto="data[$i][Signatur_Telefon]" />
<we:field name="Signatur_Mobil" to="global" nameto="data[$i][Signatur_Mobil]" />
<we:field name="Signatur_Fax" to="global" nameto="data[$i][Signatur_Fax]" />
<we:field name="LoginDenied" to="global" nameto="data[$i][LoginDenied]" /><?php
$data[$i]['ID'] = (int)$data[$i]['ID'];
$data[$i]['Sonderrechte'] = (int)$data[$i]['Sonderrechte'];
$data[$i]['StandortVisibility'] = (int)$data[$i]['StandortVisibility'];
$data[$i]['Signatur_Position'] = htmlspecialchars_decode($data[$i]['Signatur_Position']);
$i++;
?>
</we:repeat>
</we:listview>Anstatt selbst zu programmieren bieten die WE-Tags oder Providerfunktionen automatisch den "State-of-the-Art".
-
Ich habe jetzt auch nochmal mit <we:listview> und <we:listview type="languagelink"> herumgetüftelt, bin damit aber auf keinen grünen Zweig gekommen.
Der Vorschlag mit dem language Attribut bei <we:a> gefällt mir persönlich nicht so gut. Wenn hier eine ID angegeben ist, dann erwarte ich mir ja auch, dass das Dokument bzw. Objekt ausgegeben wir und nicht ein anderes.
Wenn, würde ich vorschlagen <we:listview type="languagelink"> um ein optionales id bzw. docid Attribut zu erweitern. Damit könnte man die Sprachvarianten eines beliebigen Dokument (bzw. Objekts) ausgeben lassen.
Just my 2 cents,
SaschaHalte ich auch für eine gute Idee, dafür unter https://qa.webedition.org einen Feature Request machen und auf diesen Thread verweisen.
-
Cookies können auch von anderen Tags gesetzt werden, wenn notwendig.
-
Ab der 7er Version wirds einfacher mit den Updates, aber von der 6er auf die 7er wird vermutlich viel Handarbeit erfordern.
-
Du kannst es danach direkt in WE bearbeiten und muß nichts hochladen - aber sei dir bewußt, das ein Schreibfehler in der ini Datei dafür sorgen kann, das die ganze Seite nicht erreichbar ist, und ggf. auch WE nicht funktioniert.
Der Hinweis ist wichtig, deswegen bearbeiten wir htaccess und php configs immer per FTP und nicht in WE selbst.
-
Kannst du dann dafür nicht auch eine Navigation nutzen oder ein Config-Array mit den IDs? Oder wie dynamisch muss das ganze sein?
-
Hallo zusammen,
ich hänge mich mal an die Frage zum Thema SMTP-Eintrag an.
Ein Kunde hat mir mitgeteilt, dass bei ihm der E-Mailversand auf Microsoft 365 umgestellt wird.
Gibt es da Probleme beim Versand über SMTP-Server. Oder anders gefragt: muss ich bei den Einstellungen unter "Benutze SMTP-Server" etwas beachten?
Freue mich über eine Info.LG
Silvia
Meistens kommt es zu irgendwelchen Problemen, aber sie sind lösbar.
Was bei uns mit office365 funktioniert:
SMTP Server: outlook.office365.com
Port: 587
Verschlüsselung: TLS
Das Konto über welches versendet wird, braucht eine Lizenz und bei office365 muss explizit der SMTP Versand von extern erlaubt werden. -
Okay, dann hab ich nicht richtig verstanden, was du möchtest, hast du ein Beispiel dafür?
-
Moin Moin,
wenn die Dokumente über die Sprachen hinweg verknüpft sind, kannst du einen Listview nutzen um ein Sprachmenü zu erstellen.
<we:listview type="languagelink" order="de_DE,en_GB" hidedirindex="true" showself="true"><we:repeat>
<we:field name="we_path" />
<we:field name="WE_TARGETLANGUAGE" />
</we:repeat>
</we:listview>
Wir schreiben uns die beiden Felder in der Regel in ein Array und bauen das Menü dann mit PHP um ggf. Sonderfälle etc. besser behandeln zu können.
Hier ein Beispiel aus dem echten Leben: https://www.primebremen.de/ -
Okay und das Formular wird asynchron abgeschickt? Weil sonst würde doch das jQuery bei Load die Werte wieder setzten?
Falls es anynchron gesendet wird, braucht es nach dem Send-Response einfach ne kleine Funktion, die die Defaults wieder setzt (mit javaScript)
Hast du sonst nen Link wo du das schon gebaut hast? -
Bei diesem Code:
$price = $pn;
<we:comment>
$price = $pn * 1.05;
</we:comment>
wo genau fängt der php Bereich an und wo hört er auf? wenn du so ein Konstrukt hast:
<?php
$price = $pn;
<we:comment>
$price = $pn * 1.05;
</we:comment>
?>
kann ich mir vorstellen das sich die Tags nicht korrekt verhalten.
Meiner Meinung nach sollte es so aussehen:
<?php
$price = $pn;?>
<we:comment>
<?php
$price = $pn * 1.05;
?>
</we:comment>
Oder noch besser:
$price = $pn;
/*
$price = $pn * 1.05;
*/
Aber diesen Mix wie im Beispiel würde ich nicht tun ohne PHP Tags zu schließen vor den we:tags -
Moin Moin,
damit ich das richtig verstehe, du brauchst den Range Slider in einem Formular und nach dem Senden soll das Formular weiterhin angezeigt werden, mit den eingegebenen Werten? -
Moin Moin,
ich glaube ohne mehr Template wird das schwer. -
Moin Christoph,
du schreibst die Variablen to global und ließt sie aber in local aus.
Du musst sie in GLOBAL auslesen, hat in der 8er fälschlicherweise noch funktioniert.
<p>Anmeldung</p>
<p>
Vorname: <?php echo $GLOBALS['recipientVorname'] ?><br />
Nachname: <?php echo $GLOBALS['recipientNachname'] ?><br />
</p>