Thx Lutz für den Hinweis, aber die Felder sind nicht als Pflichfelder definiert, haben also "keine Validierung" bereits eingestellt.

Moin zusammen,

auf einer Website, deren Link ich nicht benennen soll, habe ich einige Formulare von RS FORM PRO eingerichtet, die neuerdings das Problem ausweisen, dass nicht als Pflichtfelder definierte Text-Felder, das Formular am Absenden hindern, indem dort die Fehlermeldung "ungültige Eingabe" (invalid input) angezeigt wird, sie sich also wie Pflichtfelder verhalten.

Vor einigen Wochen hatte ich mit einer anderen Website dasselbe Problem. Der Support von RS FORM unterstütze mich dabei, die Ursache zufinden, es war ein Cookiehint Plugin "erivacy" das dort hineingefunkt hat und das Formular am Absenden gehindert hatte. Auf der aktuellen Website gibt es das besagte "eprivacy" Plugin nicht, weitere Plugins habe ich durchforstet und einige deaktiviert aber ohne Ergebnis. Der Support kann mir nicht helfen, weil von seinem Rechner aus die Fehlermeldungen nicht kommen, von meinem übrigens auch nicht, aber Kunden melden dies immer wieder zurück.

Hat jemand zufällig Erfahrungen bzw einen allgemeinen Ansatz, wie man dem Problem auf die Schliche kommen oder es fixen kann?

TOP, es hat alles funktioniert, besten Dank für deine Hilfe!

Hallo zusammen,

nach einem Update auf Joomla 4 habe ich Probleme mit den Benutzerrechten, die mglw. von der Joomla 3er Version, mit der die Website 2015 erstellt wurde, vererbt worden sind.

Ich habe eine neue Benutzergruppe angelegt und diese mit sämtlichen Berechtigungen ausgestattet. Ziel wäre zunächst, dass Admins, die dieser Gruppe zugewiesen sind, Beiträge erstellen und bearbeiten können. Obwohl ich alle Berechtigungen auf "erlaubt" gestellt habe, kann der Admin die Beiträge zwar öffnen, aber der Editor wird nicht angezeigt und auch die komplette Toolbar fehlt, d.h. weder das Bearbeiten noch das Speichern von Beiträgen ist möglich. Es sind wirklich ALLE Rechte 'auf grün' gesetzt, sowohl in der globalen Konfiguration der neuen Benutzergruppe, wie auch die "öffentlichen Berechtigungen" (testweise) wie auch die Berechtigungen zu den Beiträgen.

Wenn sich der Admin auf dem Dashboard das Menü als Modul erstellt, kann er zwar Beiträge des Page Builders erreichen, bearbeiten und auch löschen, sowie auch die J Events Einträge, aber nicht die Joomla Standard-Beiträge und auch keine Module.

Offenbar bestand das Problem schon unter Joomla 3, denn der ehamalige Webdesigner (nicht mehr zu erreichen), hatte diverse Benutzergruppen angelegt und diese, sowie auch alle Joomla-Standardbenutzergruppen (Administrator, Registriert, Autor, Editor) der Superadmin-Gruppe untergeordnet (s. Screenshot). Auf diese Weise werden alle Superadminrechte auf diese Gruppen vererbt und somit können sämtliche User aus den Untergruppen Beiträge speichern und bearbeiten (denn offenbar kann dies nur der Superuser), haben leider aber auch vollen Zugriff auf das gesamte System. Die Lösung, Usern aus diesen Untergruppen bestimmte Zugriffe (beispielsweise zum System) zu verweigern, funktioniert leider nicht. Zwar kann ich z.B. der Gruppe "Editor" die Berechtigungen zu sämtlichen Beiträgen oder auch einzelnen Modulen "verweigern", aber diese Einstellung wird nicht übernommen, d.h. wenn ich dort "verweigert" auswähle, bleibt die 'errechnete Einstellung' erlaubt (Super User) obwohl das "Verweigern" ja eigentlich alle vererbten Einstellungen überschreiben sollte.

Vielleicht kann mir da irgendjemand weiterhelfen? Habe bisher nicht allzuviel mit dem Rechte-System von Joomla zu tun gehabt, evtl habe ich hier eine einfache Basiseinstellung übersehen, es wundert mich nur, dass der ehemalige Entwickler offenbar auch nur diese eine Lösung gefunden hatte, nämlich unterschiedliche Benutzergruppen quasi nur oberflächlich anzulegen, tatsächlich aber allen Admins Superadminrechte zu vergeben.

Ok danke euch! Mir war bewusst, dass deutsche Sonderzeichen in Bilddateien nicht optimal sind, nur war das bei Joomla 3 auf dem selben Server noch k.P. gewesen, wusste nicht, dass das zu Server-Timeouts führen kann.

Joomla ist auf den neusten Stand gebracht. Gleiches Problem. Es liess sich allerdings lösen, indem bei einer Bilddatei auf das scharfe ß verzichtet und dieses mit Doppel s ersetzt wurde. Schwupps ließ sich der Beitrag ohne Probleme speichern. Eigentlich komisch, da die Website vor dem J4 Update unter J3 noch das ß akzeptierte und für "site" die deutschen Sprachdateien auf "Standard" gesetzt sind, für Administrator deutsch und englisch ausgewählt.

Ich lasse den Thread mal als ungelöst, bis mir da vielleicht jemand eine Erklärung geben könnte. Darf man Bilddateien generell nicht mit scharfem S benennen (in diesem Fall "Schließzeiten")?

Thx Mr Blues! ist doch recht simpel, dachte dass ich den Autor gestern nicht ändern konnte aber es funktioniert!

Hi,

ich bekomme beim Speichern eines Beitrags die Fehlermeldung:

Fatal error: Maximum execution time of 30 seconds exceeded in .../libraries/vendor/joomla/string/src/phputf8/mbstring/core.php on line 24

Der Beitrag hat keine besonderen Eigenschaften und ist auch nicht besonders umfangreich.

Wäre es nun am besten, die max execution time hochzustellen oder gibt es etvl noch andere Lösungen? Was mich wundert ist, dass dieser Fehler bei deutlich umfangreicheren Beiträgen nicht erscheint, und diese sich auch nach 5 Sekunden speichern lassen.

Hallo,

ich habe nach einem Joomla Update viele Beiträge von ehemaligen usern, die sich nicht überarbeiten lassen.

Er erscheint im Backend direkt beim Öffnen des Beitrags die Fehlermeldung:

JUSER: :_load: Fehler beim Laden des Benutzers mit der ID: 875

Ich habe dazu bereits einige Threads gefunden. Es wird dazu geraten, dies entweder 1. zu ignorieren oder 2. die beitragsautoren manuell oder über die datenbank zu aktualisieren.

Meine Frage: Wenn ein Autor einen Beitrag erstellt, kann man es dann nicht so einstellen, dass auch jeder andere Autor den Beitrag überarbeiten kann? Derzeit, kann ich diese Beiträge nicht einmal als Superuser überarbeiten, beim Speichern kommt die Felhlermeldung "Autor unbekannt". Es gibt allerdings auf dieser Website ständig wechselnde Autoren, die aber jeweils allgemeine Rechte haben sollen, ihre Beiträge auch gegenseitig zu überschreiben.

Was wäre in meinem Fall die best practice?

Top, das war, danke! Das SEF Plugin war deaktiviert.

Nein der managed server wird über einen Admin verwaltet und liegt bei alphahosting.

Hi,

nach einem Joomla 3 zu 4 Update werden auf einigen Seiten die vorhanden Bilder mehr angezeigt, die relativen Bildpfade werden teils nicht mehr richtig interpretiert.

Dies Betrifft die Inhalte zu allen Menüpunkten, die mehr als eingliedrige Pfade aufweisen.

Beispiel:

https://dev.herman-nohl.de/schulleben - Bilder werden korrekt dargestellt.

https://dev.herman-nohl.de/schulleben/schulbibliothek - Bilder werden garnicht mehr dargestellt (nur alt Text) - auch das Logo auf einmal nichtmehr (Pfad: images/logo.png)

Diesen "Effekt" hat man allerdings nur mit aktivierten Suchmaschinenfreundliche URLs + Mod Rewrite (mit standard - .htaccess), was allerdings auch so bestehen bleiben sollte.

Kann mir jemand weiterhelfen?

Ja, es lag an max_input_vars, wurde in den PHP Einstellungen von 1000 auf 2000 hochgesetzt und config speichern per Backend funktionierte darauf hin. Hatte es heute morgen schon gelöst aber noch keine Zeit für den Report, trotzdem Danke J-Wunder! Dein Engagement ist krass hilfreich für die Community :))

Hallo allerseits,

nach einem Update von Joomla 3.x zu 4.x lässt sich die Konfiguration nicht mehr speichern. Dies betrifft alle Bereiche, also Server, Site, System usw.

Ich habe die Verzeichnisrechte der configuration.php von 444 auf 644 umgestellt, dennoch (auch nach Cache Löschung) werde Speicherungen per Backend nicht angenommen. Es kommt auch keine Fehlermeldung, trotz manuellen Umstellens auf System debuggen und Maximum Fehler berichten. Andere Bereiche wie Inhalte und Menüs lassen sich problemlos speichern.

Im Netz finden sich Hinweise, dass der Besitzer der Configurationsdatei vielleicht ein anderer sein könnte, als derjenige, der der die Datenbank verwaltet (oder so ähnlich).

Per FTP wird angezeigt als Besitze der configuration.php: web917f1 und web917 wobei letzterer der eigentliche Datenbankuser ist und ersterer etwas unklar.

Hat jemand von euch dazu eine Handlungsempfehlung?

Bin euren Hinweisen nachgegangen, und habe einige Rückstände entfernt. Am Ende führte eine Anhebung des Memory Limits 32M zu 256M zum gewünschten Erfolg.

Danke euch, der Theme Expert Markdown editor war mir schon bekannt, suche aber eine Lösung für Joomla 4. Dachte mir schon, dass das schwierig wird

Kennt jemand von euch einen editor für Joomla, der Markdown unterstützt? Der JCE Pro kann einige Markdownschnipsel direkt in html umwandeln, aber die markdown syntax sollte voll unterstützt werden und auch gespeichert werden können. Den "Markdown Editor" gibt es nur für Joomla 3.

Danke euch. Leider hakt das J4 Update immer noch.

Elwood, habe alle auffälligen Tabellen gelöscht.

@ Jürgen bei "Überprüfen" werden folgende Erweiterungen angezeigt:

Authentifizierung - GMail Site Plugin 3.0.0 February 2006 Joomla!
Project authentication 10699 Authentifizierung - LDAP Site Plugin 3.0.0 November 2005 Joomla!
Project authentication 10700 beez3 Site Template 3.1.0 25 November 2009 Angie Radtke Unbekannt 10710
Beispieldaten - Blog (englisch) Site Plugin 3.8.0 July 2017 Joomla! Project sampledata 10702
Benutzer - Kontakterstellung Site Plugin 3.0.0 August 2009 Joomla! Project user 10707
Benutzer - Nutzungsbedingungen Site Plugin 3.9.0 June 2018 Joomla! Project user 10709
Benutzer - Profile Site Plugin 3.0.0 January 2008 Joomla! Project user 10708
CAPTCHA - Unsichtbares reCAPTCHA Site Plugin 3.8 November 2017 Joomla! Project captcha 10701
System - Datenschutz Zustimmung Site Plugin 3.9.0 April 2018 Joomla! Project system 10704
System - P3P-Richtlinien Site Plugin 3.0.0 September 2010 Joomla! Project system 10703
Zwei-Faktor-Authentifizierung - Google Authenticator Site Plugin 3.2.0 August 2013 Joomla! Project twofactorauth 10705
Zwei-Faktor-Authentifizierung - YubiKey Site Plugin 3.2.0 September 2013 Joomla! Project twofactorauth 10706

Die Phocagallery habe ich deinstalliert.

Dies sind die aktuellen Hinweise:

Update-Informationen nicht verfügbar

Bei den folgenden Erweiterungen sind manuelle Schritte erforderlich, da diese keine mit der gewählten Zielversion kompatible Erweiterungsversion anbieten. Dies kann daran liegen, dass diese Erweiterungen nicht das Joomla-Update-System verwenden oder der Entwickler noch keine kompatible Version zur Verfügung gestellt hat.

Die beiden "POW"s kann ich unter Erweiterungen da/aktivieren aber nicht deinstallieren. Weiss jemand, wie ich sie entfernen kann?

Phoca Download ist die neuste Version installiert (es gab dabei Meldungen, dass bestimmte Bereiche schon installiert waren).

Hat noch jemand eine Idee?

Hallo,

es hakt beim Update von Joomla 3.10.11. zu 4.x. Den Link kann ich euch leider nicht zur Verfügung stellen. Unten seht ihr das Ergebnis des Updatechecks über Joomla Next.

Ich habe die meisten 3rd party extensions bereits deinstalliert.

J-Events Phoca Docs und der JCE Editor sind auf dem neusten, J4 kompatiblen Stand.

Das "Allrounder" Template habe ich deinstalliert und auf Protostar gewechselt auch wenn dieses für Joomla 4 nicht mehr angeboten wird, ich hoffe das man später zu einem anderen Template wechseln kann.

'POWr Button und POW Banner' lassen sich nin der Verwaltung nicht deinstallieren, mit der Warnung: "Paketdeinstallation: Manifest-Datei kann nicht gefunden werden."

Die Module mod_arkpro, mod_arkstats, mod_arkupdate, mod_arkvote finde ich nicht, auch nicht per FTP, und kann sie daher nicht deinstallieren.

Das Phocagallery update wird als erforderlich angezeigt. Dieses wird aber im Backend nicht angeboten. Ich habe es neu installiert, mit der neuen J4 kompatiblen Version, dennoch wird es angezeigt.

Drittanbieter Erweiterungsprüfungen

[ Details ] Update-Informationen nicht verfügbar

Bei den folgenden Erweiterungen sind manuelle Schritte erforderlich, da diese keine mit der gewählten Zielversion kompatible Erweiterungsversion anbieten. Dies kann daran liegen, dass diese Erweiterungen nicht das Joomla-Update-System verwenden oder der Entwickler noch keine kompatible Version zur Verfügung gestellt hat.

[ Details ] Update erforderlich

Bitte die Erweiterungen aktualisieren, bevor Joomla aktualisiert wird.

[ Details ] Kein Update erforderlich

Der Entwickler der Erweiterung gibt an, dass die derzeit installierte Version kompatibel ist.

Kann mir jemand einen Hinweis geben, was die nächste sinnvollen Schritte wären?

Leute es hat geklappt, habe gestern früh die erste Joomla Update Notification erhalten Und zwar noch bevor ich Phoca Mail installiert und das Joomla Update durchgeführt hatte. Habe die Notification gerade erst im SPAM ordner entdeckt. Vorher kamen aber definitiv keine.

Woran lag es? Meine Vermutung geht stark dahin, dass es mit der Absenderadresse zu tun hatte, die unter global configuration > server einzutragen ist - unter "Mail From:" Wenn man den Erhalt einer System Mail testen will trägt, man dort die Empfängeradresse ein, also wohin die Mail geschickt werden soll, daher hatte ich dort meine Super-Admin-Mailadresse eingetragen. Das Problem bestand offenbar darin, dass diese NICHTS mit der Domain der Website zu tun hat, von der die Notification Mail ausgehen soll. Beim Test hatte es trotzdem geklappt, und auch bei Phoca Mail liess sich eine abweichende Absenderadresse eintragen. Die Notification Mail verlangt aber offenbar einen entsprechenden Eintrag, jedenfalls bei IONOS. Ich hatte ein ähnliches Problem schon einmal, daher hatte ich mich daran erinnert.

So gehts: für eine Website URL "bespieldomain.de" muss in das "Mail from" Feld der Serverconfig eine (ggf. frei erfundene) Emailadresse eingetragen werden wie info@beispieldomain.de, deren URL identisch mit der Website URL ist. Diese erscheint dann in der Update-Notification-Mail als Absender und IONOS kann sich recht sicher sein, dass kein SPAM versendet wird, bei dem die Nachvollziehbarkeit des Absenders durch einen fehlenden Zusammenhang mit der Website URL nicht gegeben ist, wie es bei Spam Emails häufig der Fall ist. Also wird die Mail nicht von IONOS blockiert und die Update Notifictions werden verschickt.

(Es kann theoretisch auch sein, dass es eine andere Ursache war, die zum Erfolf führte, wie z.B. die Umstellung von PHP Mailer auf sendmail verfahren, aber soweit ich mich erinnere, war er "Mail from" Eintrag die einzige relevante Änderung direkt vor Erhalt der Update Notification Mail. Meldet euch gerne, falls bei euch [mit IONOS] diese Lösung auch funktioniert oder auch nicht.)