Hallo Martin,
es gab da ein Problem mit der neuen CSP , die für das Backend eingeführt wurde. Die hat bei Objekten wohl auch im Frontend eingegriffen. Laut BugBase soll es in der Nightly behoben sein, siehe https://qa.webedition.org/view.php?id=14355
VG Adrian
Hi Thomas,
da du ja geschrieben hast, dass du nur ungerne eine Lösung über Metafelder haben möchtest hier noch ein Ansatz über Dokumente.
Du könntest z. B. in einem Dokument mit dem we:block die einzelnen Slides von den Redakteur:innen einstellen lassen. Dann könntest du entweder mit we:link direkt arbeiten oder mit we:img + we:href, we:link oder einfach nur we:input, je nachdem was noch pflegbar sein soll, z. B. target, title, etc...
Ich denke die beste Lösung für dich ist am Ende abhängig davon, wie du den Slider (oder vielleicht auch mehrere?) baust und die Redakteur:innen die Inhalte pflegen sollen.
Metafelder, Objekte oder Dokumente haben alle Vor- und Nachteile aber machbar ist es auf jeden Fall. Ich hoff du findest eine für dich passende Lösung.
VG Adrian
Ja theoretisch schon, bei sehr vielen Empfängern entsteht hier aber ein hohes Zeitintervall, deswegen sollte der Versand Client-Unabhängig über einen Cronjob erfolgen.
Versteh ich nicht. Was hat denn die Möglichkeit eines Cronjobs mit der Einstellung der Anzahl zu tun? Das ist doch eher eine zusätzliche Anforderung.
Ich hatte die aber direkt mit beim Punkt "Geplanter Versand per Scheduler" gesehen. Hier muss der Cronjob natürlich in Intervallen die Mails pro Sendungsvorgang abarbeiten und nicht direkt alle Mails raushauen. Und dabei würde ich halt die Werte sehen, die aktuell bei "Anzahl der E-Mails pro Sendevorgang" und "Wartezeit bis zum nächsten Sendevorgang (in ms)" hinterlegt werden.
Vom Anwendungsfall geht es uns doch darum, ich starte den Versand (egal ob manuell oder per Scheduler/Cronjobs), webEdition arbeitet das ganze im Hintergrund ab und hält sich an die Vorgaben wir viele Mails gleichzeitig rausgehen dürfen.
Oder verstehe ich hier was falsch?
Beim Thema An-/Abmeldung und Adressverwaltung sollte webEdition direkt nach der Installation DSGVO-konformer sein. Es gibt bereits die Möglichkeiten für Double Opt-in bei der Newsletter-Anmeldung. Hierbei sollte sollte jedoch direkt noch protokolliert werden wann die Zustimmung erfolgt ist. Dazu könnte in der Kundenverwaltung der Tab Newsletter z. B. ein gesperrtes Feld "Opt-In" integriert werden, in das der Zeitpunkt der Zustimmung mit dem Klick auf den Double Opt-in Link gespeichert wird. Hierfür müssten wahrscheinlich nur kleine Anpassungen erfolgen.
Die Angabe "Mitglied seit" in der Kundenverwaltung reicht hier meiner Meinung nach nicht aus, da es ggf. Kunden geben kann, die keinen Newsletter haben oder sich erst später, nach dem es das Kundenkonto schon gab für den Newsletter angemeldet haben. Daher fände ich die Überlegung die gesamte Newsletter-Adressverwaltung aus der Kundenverwaltung zu lösen und in das Newsletter-Modul zu verlagern auch nicht verkehrt.
Zusätzlich würde ich mir wünschen die E-Mail Adressen aus der URL beim Double Opt-in nur noch als hash-Wert zu übertragen, sowohl bei der Registrierung als auch bei der Abmeldung. Auch hierfür müssten wahrscheinlich nur kleine Anpassungen erfolgen.
Natürlich gibt es hierzu diverse Einschätzungen und Meinungen, was, wann, wie, etc. gemacht werden muss. Daher wird man sicherlich nicht alles von Haus aus abbilden können, was sich jeder individuell wünscht.
"Maximale Anzahl Newsletter pro Zeiteinheit (für einige Provider nötig)."
Das ist über die Einstellungen "Anzahl der E-Mails pro Sendevorgang" und "Wartezeit bis zum nächsten Sendevorgang (in ms)" doch eigentlich schon möglich, oder nicht?
Oder geht es dabei eher um die Anwendungsfreundlichkeit nach dem Motto: Ich hinterlege sende max. 500 Mails pro Stunde und webEdition kümmert sich dann selbst drum wie viele Mails in welchen Intervallen in einer Stunde versendet werden?
"DNS-Prüfung vorab? (z.B. SPF-Eintrag für Mailserver oder Webserver vorhanden?)"
Das wäre für mich eine Funktino, wo ich keine große Prio bzw. we-Entwicklerzeit für sehen würde. Ich denke das sollte man von den Personen die webEdition für den Newsletetrversand einrichtet erwarten können, dass sie entweder wissen was hier auf Seiten es Mailsevers wichg ist oder einen Provider haben, der sie da unterstützt. Wenn die we-Entwickler sagen, das sowas kein großer Aufwand ist, kann es gern eingebuat werden.
Ergänzend noch:
Kopier-Funktion per Button, wie bei Dokumenten damit es einheitlich ist.
Hallo Heiko,
das klingt ja nach nem echten Kampf mit dem Projekt, so lange wie sich der Post schon zieht.
Steht in der DB in der Tabelle tblErrorLog irgend was drin, was einen Anhaltspunkt geben kann?
Ist dein Benutzer richtig in der Datenbank?
Kannst du auf dem System generell eine 9er Version installieren und dich anmelden?
VG Adrian
Wir können das gerne bei der we:conf mal genauer besprechen. So wie das ganze redirect Thema inkl. automatische 301-Weiterleitgen etc. und andere Feature Requests.
Hi, dazu gibt es schon einen FR in der Bugbase. Dort findest du auch eine möglichen Lösungsansatz.
webEdition CMS - Quality Assurance
VG Adrian
Hallo Heiko, das Thema Login & Sessions hattest du auch schon versucht, oder: https://forum.webedition.org/viewtopic.php?…sparent#p105330
Hi, ja kenne ich auch und kann deinen Feature-Request nur unterstützen. 
Je nach Aufwand könnte das auch gut Schrittweise in we integriert werden, erst a später b/c.
Ich glaube Variante a würde schon schnell für mehr Ordnung sorgen.
Stimmt Finn, hatten wir auch mal bei ner Neu-Installation bei nem neuen Provider der OpenSSL 3.x einsetzt. Wenn man die Session-Verschlüsselung über die Config aus macht, konnte man jedoch wieder auf's Backend zugreifen und dann dort webEdition auf eine Version 9.1.5 oder höher updaten.
Hallo Steff11,
ich tippe auf eines meiner Lieblingsprobleme beim Login, dass hier bereits einige hatten. Geh mal in die we_conf_global.inc.php und stell in der folgenden Zeile die Session-Verschlüsselung aus, in dem du folgendes setzt:
Code
//crypt we session before save
define('SYSTEM_WE_SESSION_CRYPT', 0);0 = keine Verschlüsselung
1 = Transparent
2 = Cookie
Wenn danach der Login wieder geht, hängt es damit zusammen.
Gab es einen Server-Wechsel oder ein we-Update?
VG Adrian
Also laut der Doku ab webEdition 9.2. Die we 9.2 braucht mindestens PHP 8.1.
https://www.webedition.org/de/dokumentation-community/systemvoraussetzungen.php
Ist jetzt nur ne doofe Frage, aber du hast auch in der Klasse eingestellt, welches Feld Titel, Description und Keywords liefern soll, oder? Siehe Screenshot.
Hallo Markus,
ich bin grade nicht 100 % sicher, aber ich meine die Meldung kam versehentlich auch wenn andere Systemvoraussetzungen nicht passten. Hast du schon die WE-Sessionverwaltung aktiv? Und welche Datenbank Version setzt du ein?
Da du auf die 9.1.5.1 gehen willst, schau dir mal die Systemvoraussetzungen an:
https://www.webedition.org/de/dokumentation-community/versionshistorie/version-9.1.3
https://www.webedition.org/de/dokumentation-community/systemvoraussetzungen.php
VG Adrian
Für diese zusätzlichen Funktionen musst du den Editor mit den commands konfigurieren. Das geht Global in den Einstellungen (dein Screenshot IMG_3416) oder individuell im jeweiligen Template, in dem du we:textarea einsetzt. In der weTag-Refrenz findest du alle Befehle: https://tags.webedition.org/textarea-wysiwyg-true
Kann ich für die 9.2.1 auch bestätigen.
Hallo Martin,
geh mal in die we_conf_global.inc.php und stell in der folgenden Zeile die Session-Verschlüsselung aus, in dem du folgendes setzt:
Code
//crypt we session before save
define('SYSTEM_WE_SESSION_CRYPT', 0);0 = keine Verschlüsselung
1 = Transparent
2 = Cookie
Wenn danach der Login wieder geht, hängt es damit zusammen.
Gab es einen Server-Wechsel?
VG Adrian
Hi, hast du noch die Session-Verschlüsselung aktiv? Dann stelle die als erstes mal aus.
Du kannst das in der der ./webEdition/custom/conf/we_conf_global.inc.php in der folgenden Zeile setzen:
//crypt we session before save
define('SYSTEM_WE_SESSION_CRYPT', 0);0 = keine Verschlüsselung
1 = Transparent
2 = Cookie
Wenn der Login im Backend danach wieder klappt, versuch mal herauszufinden, welche OpenSSL Version die neue Plesk-Version nutzt. Erst seit der 9.1.4 werden OpenSSL > 3.0 von webEdiiton unterstützt. Dazu wurden der Verschlüsselungsalgorithmus von Blowfish auf AES geändert, siehe auch den Eintrag in der Bugbase. https://qa.webedition.org/view.php?id=13884
Wir hatten das Problem mal direkt nach einer Neuinstallation bei einem Hoster, bei dem auch eine neuere Plesk-Version mit OpenSSL 3.0.x eingesetzt wurde.
Falls es läuft mach ein Update auf die 9.1.5 oder 9.2.1, danach kannst du die Session-Verschlüsselung wieder aktivieren.
Hoffe die Info hilft dir bei der Fehlersuch.
VG Adrian