Speichern fehlgeschlagen

Hallo liebe Joomla User!

Vor kurzem habe ich das Webdesign für eine Seite übernommen, die bereits mit diesem

Fehler behaftet war. Der bisherige Admin hatte schon etliche Wochen nichts mehr geändert,

der Fehler ist erst vor kurzer Zeit aufgetreten, als eine Seite aktualisiert werden sollte.

Die genaue Fehlermeldung lautet:

Speichern fehlgeschlagen. Fehler: ( hier sind keine weiteren Details aufgeführt )

Das Problem ist wohl nicht neu und tritt in mehreren Variationen auf.

Es lassen sich keine Inhalte, also Beiträge, Kategorien, und keine Menüs speichern.

Änderungen im System sind möglich.

Im Forum habe ich noch keine passende Lösung gefunden.

Bereits probiert:

- DB Reparatur

- Wiederherstellen Kategorien

- Cache leeren

Auch in dem dicken Wälzer "Praxiswissen" bin ich nicht fündig geworden.

Als Newbe bei Joomla bin ich für jede Hilfe / Anregung dankbar.

Zitat von Elwood

Sind alle Erweiterungen/Template/Framework auf dem aktuellsten Stand?

Versuche mal im KA die PHP-Version auf 8.0/8.1 umzustellen.

Moin Elwood, die Erweiterungen sind auf dem neuesten Stand. PHP 8.0 und 8.1.23 probiert - keine Veränderung.

Gruß

Ralf

Zitat von Benno

Hi,

siehe: Fehler finden durch detailliertere Fehlermeldung. Debug-Modus. Call stack.

Freundliche Grüße,

Benno

Hallo Benno, keine Änderung in der Fehlermeldung. Den Artikel muss ich mir aber noch in Ruhe durchsehen.

LG Ralf

Zitat von Indigo66

Prüfe, ob im Kundencenter von Strato unter Sicherheit Gästebuch-Spam Einstellungen, der Filter deaktiviert ist. Geht es dann?

Hallo Tom,

der Filter ist deaktiviert, war leider auch nicht die Fehlerursache.

Besten Dank,

Gruß Ralf

Zitat von Sieger66

Bist du als Super-Benutzer(Super Users) angemeldet wenn der Fehler auftritt ?

- JA

Lassen sich den Beiträge nach der Anmeldung(Sign In) im Frontend der Website bearbeiten oder erstellen ?

- Änderungen kann man zwar bearbeiten und auch Einträge in der Maske "neu" erstellen, es lässt sich aber nichts speichern.

Schon mal mit deaktiviertem SEO probiert?

- JA

help.joomla.org/proxy?keyref=Help43:Site_Global_Configuration&lang=de#SEO

Sind bei der Fehlersuche nach jeder Veränderung auch alle Cache ( z.B. der Browsercache und der Joomlacache )

gelöscht worden?

- Wenn damit System / Wartung / Cache leeren gemeint ist, JA

Gib uns mal den Inhalt der .htaccess im Joomla-root-Dateiordner, also aus dem Dateiordner in dem auch die configuration.php ist.

- siehe Anhang

Gibt es in einem der nachfolgenden Dateiordner eine Datei die mit einem Punkt beginnt ?

htdocs/STRATO-apps/joomla_01/

- JA,

.htaccess

.HTpireq1.appconfig.php

Gib uns mal die Systeminformationen aus:

System -> Systeminforamtionen -> Als Text herunterladen

- siehe Anhang

---

Schon mal mit Subdomain www probiert?

https://www.fmcmorse.org/administrator/index.php

- JA

Alles anzeigen

Hallo Sieger66, jetzt geht es aber so richtig ins Eingemachte.

Kann nicht sagen, ob ich noch lange den Durchblick behalte

Gruß Ralf

Zitat von JoomlaWunder

Schaut soweit ganz gut aus.

Hast du den Inhalt der htaccess.txt oder den der .htaccess gepostet?

Die htaccess.txt ist nur eine reine Textdatei ohne jegliche Auswirkung. Interessant wäre die .htaccess, sofern sie existieren sollte. Da du bei SEO alles deaktiviert hast, wird sie allerdings nicht benötigt. Manchmal macht man in dieser Datei aber auch serverspezifische Einstellungen. Dann wäre deren Inhalt interessant. Schau noch mal nach zur Sicherheit!

Ansonsten: Teste mal einen anderen Browser!

Und kannst du da wirklich keine weiteren Fehlerangaben ermitteln? Verwende auch mal die Fehleranalyse mitltels F12 im Browser!

Sind nur bestehende Beiträge usw. betroffen oder auch neue Beiträge?

Alles anzeigen

Anbei noch die Datei .htaccess. Aber die ist schon vom Dez. 22, bis vor ca. 2 Wochen lief alles fehlerfrei.

Mit einem anderem Browser, Edge, und auch am Tablet mit Chrome keine Veränderung.

Keine neuen Erkenntnisse mit F12.

In bestehenden Beiträgen kann man keine Änderungen speichern und neue Beiträge, Kat., Menüs lassen sich nicht anlegen.

Immer das gleiche: Speichern fehlgeschlagen. Fehler: - ohne weitere Angaben -

Gruß Ralf

.htaccess

##
# @package    Joomla
# @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license    GNU General Public License version 2 or later; see LICENSE.txt
##


##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of Apache mod_rewrite, but it may have already been set by
# your server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##


## MISSING CSS OR JAVASCRIPT ERRORS
#
# If your site looks strange after enabling this file, then your server is probably already
# gzipping css and js files and you should comment out the GZIP section of this file.
##


## OPENLITESPEED
#
# If you are using an OpenLiteSpeed web server then any changes made to this file will
# not take effect until you have restarted the web server.
##


## Can be commented out if causes errors, see notes above.
#Options +FollowSymlinks
#Options -Indexes


## No directory listings
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>


## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>


## Protect against certain cross-origin requests. More information can be found here:
## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
## https://web.dev/why-coop-coep/
#<IfModule mod_headers.c>
#	Header always set Cross-Origin-Resource-Policy "same-origin"
#	Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>


## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
<IfModule mod_headers.c>
Header always set Content-Security-Policy "script-src 'none'"
</IfModule>
</FilesMatch>


## These directives are only enabled if the Apache mod_rewrite module is enabled
<IfModule mod_rewrite.c>
RewriteEngine On


## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site then comment out the operations listed
# below by adding a # to the beginning of the line.
# This attempts to block the most common type of exploit `attempts` on Joomla!
#
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.


## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects


##
# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##


RewriteBase /


## Begin - Joomla! core SEF Section.
#
# PHP FastCGI fix for HTTP Authorization, required for the API application
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# -- SEF URLs for the API application
# If the requested path starts with /api, the file is not /api/index.php
# and the request has not already been internally rewritten to the
# api/index.php script
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the /api/index.php script
RewriteRule .* api/index.php [L]
# -- SEF URLs for the public frontend application
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
</IfModule>


## These directives are only enabled if the Apache mod_rewrite module is disabled
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When Apache mod_rewrite is not available, we instruct a temporary redirect
# of the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>


## GZIP
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
##     directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this file, and you see
##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,
##     then your server is already gzipping css and js files and you don't need this
##     block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]


# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]


# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]


<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip


# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

Zitat von Sieger66

Seltsam ist das ich manchmal wenn ich den nachfolgenden Link aufrufe:

https://fmcmorse.org/index.php…w=form&layout=edit&a_id=0

erscheint die Seite zum erstellen neuer Beiträge im Frontend obwohl ich ja keine Login-Daten habe.

Siehe auch nachfolgend beigefügtes Bild.

Manchmal kommt aber eine Fehlerseite inclusive Call Stack.

Kannst auch mal obigen und alternativ nachfolgenden Link versuchen um einen neuen Beitrag zu erstellen wenn du angemeldet bist im Frontend:

https://fmcmorse.org/index.php…_id=0&template=cassiopeia

Also zuerst dort im Frontend anmelden:

https://fmcmorse.org/index.php…ers&view=login&Itemid=126

Und erst dann obige Links mal testen zur Beitragserstellung und Fehlersuche.

Geht dann das speichern eines neuen Beitrages oder kommt eine erweiterte Fehlermeldung?

Alles anzeigen

Hmm, das wird ja immer kurioser. Bei mir das gleiche Ergebnis, einmal die Seite mit Eingabefeld - dort auch wieder "Speichern fehlgeschlagen" - oder

die CallsStack-Seite. Kann man über CallStack Fehler erkennen? Bin da völlig ahnungslos.

Gruß und schönes Wochenende

Ralf

Die Kopfzeile der Startseite, die manchmal über den o.g. link erscheint, stammt übrigens von einer viel früheren Version, die gar nicht mehr vorhanden sein dürfte. Vielleicht liegt da der Hund begraben, daß irgendwo noch Reste der alten DB vorhanden sind und jetzt das Durcheinander verursachen.

Zitat von Elwood

Kann man.

Schau mal hier:

Thema

Fehler finden durch detailliertere Fehlermeldung. Debug-Modus. Call stack.

Gelegentlich sind Fehlermeldungen auf "toten Seiten", die Joomla anzeigt, nicht ausreichend, um die Fehlerquelle zu identifizieren, also die Erweiterung, die einen Fehler verursacht.

Um mit etwas Glück die Fehlerstelle zu finden, tue Folgendes:

Gehe in die Joomla-Konfiguration.
- Im Reiter "Server" findest du die Einstellung "Fehler berichten". Setze sie auf "Maximum".
- Im Reiter "System" findest du die Einstellung "System debuggen". Setze sie auf "JA".
- Speichere die Joomla-Konfiguration.

Solltest…

Re:Later

10. Oktober 2018

ok, danke Elwood - Auf zum nächsten Versuch!!

Gruß Ralf

Zitat von Elwood

Siehe Link in #7.

Wenn man aber keine Antwort darauf bekommt, und die Lösungsvorschläge nicht abgearbeitet werden ..................

Hallo Elwwood, den Beitrag hatte ich schon durchgearbeitet und die relevanten Vorschläge probiert.

Schreibschutz stand bereits auf deaktiviert. Gruß Ralf

Zitat von Sieger66

Hast du dich jetzt dort:

fmcmorse.org/index.php?option=com_users&view=login&Itemid=126

angemeldet und anschließend mal die Links in #11 zum erstellen neuer Beiträge im Frontend benutzt ?

Welche Fehlermeldungen kamen dann?

Bitte nicht wundern das bei dem Link mit cassiopeia am Linkende die Website im Cassiopeia-Template-Stil erscheint.

Dies ist völlig normal und nur zum testen ob der selbe Fehler bzw. die selbe Fehlerseite auch bei Nutzung des Cassiopeia-Templates erscheint.

Du kannst aber gerne auch einfach im Backend auf das Cassiopeia Template umschalten und dann nochmal die selben Links aus #11 zum erstellen neuer Beiträge im Frontend benutzten bzw. zur Fehlersuche nutzen.

Alles anzeigen

Ja, habe ich, auch hier lässt sich kein Beitrag speichern. Fehlermeldung rechts unten im rosa Feld: Speichern fehlgeschlagen.

Wenn ich den gleichen link nochmal anklicke, kommt eine Seite mit CallStack-Meldungen.