Beiträge von b3317133

    Zwischenzeitlich erscheint jetzt eine funktionierende WordPress Einrichtungsseite statt der vorherigen 403 Forbidden Fehlermeldungen. Offenbar wird die [FONT=Courier New]wp-config.php[/FONT] der alten extra Installation im Unterordner nicht gefunden oder Daten darin, z.B. das Tabellen Präfix stimmen nicht (mehr).

    Die extra WordPress Installation im von Dir genannten Unterordner ist offenbar defekt oder Dateien bzw. Ordner darin sind ggf. serverseitig gesperrt.

    Einige Daten der extra Installation sind offenbar noch vorhanden und erreichbar, z.B. das Logo und andere Dateien und Bilder und auch zumindest Teile des WordPress Core:

    Code
    https://polyfill.at/Absamer_Naturbetten/wp-content/uploads/2016/06/Naturbetten_Logo_web.png
    https://www.google.com/search?q=inurl%3Ahttps%3A%2F%2Fpolyfill.at%2FAbsamer_Naturbetten%2Fwp-content%2F
    https://polyfill.at/Absamer_Naturbetten/wp-includes/css/admin-bar.css
    https://polyfill.at/Absamer_Naturbetten/wp-includes/js/jquery/jquery.min.js

    Deaktiviere testweise das Plugin Interactive Map of Austria for WP (austriahtmlmap), es lädt ein "nicescroll" Script, das ggf. Einfluss auf das Scollverhalten hat und verursacht lt. Browser Console hier Scriptfehler. Verwendet wird Plugin Version 2.2 bis max. WordPress 5.1.x, aktuell wäre Version 2.7 bis max. WordPress 6.8.

    @uha Es wurden nach meinem o.g. Hinweis auf den Bereich "Unterhaltung" FTP Zugangsdaten zugeschickt und ein kurzer Einblick ergab folgendes:

    Hauptproblem war das unvollständige Theme Catch Base, es fehlten darin praktisch alle PHP Dateien im Unterordner [FONT=Courier New]inc[/FONT], das führte zum Server Error. Auch mind. ein Plugin war direkt sichtbar im Frontend unvollständig, es fehlten darin u.a. Ordner mit CSS Dateien. Ursache für beides war offenbar fehlender Speicherplatz auf dem Server beim Einspielversuch der Installation. Dazu kam noch ein kleineres Folgeproblem wegen des Reparaturversuchs durch den umbenannten Theme Ordner. Nach dem Freimachen von Speicher durch Entfernen eines grossen alten ungenutzen Cache Ordners und Entfernung von tausenden Apple [FONT=Courier New].-[/FONT] Meta-Dateien und Vervollständigung der Theme Dateien mit korrekter Benennung des Theme Ordners war die Seite wieder online.

    Man kann nach kurzem Blick in den Code des Plugins die beabsichtigte Veränderung auch ohne Änderung direkt im Plugin Code über einen dort vorhandenen Filter erreichen, z.B. über ein Child Theme oder ein eigenes kleines Plugin oder ein Code Snippets Plugin, z.B. so:

    Code
    function my_wpfc_fullcalendar_args( $args ) {
        $args['post_status'] = array('publish', 'future');
        return $args;
    }
    add_filter( 'wpfc_fullcalendar_args', 'my_wpfc_fullcalendar_args' );

    Wann und wo genau erscheint diese Meldung? Screenshot? Wurden sicher alle Plugins deaktiviert? Wurde testweise ein anderes Theme verwendet? Handelt es sich sicher um eine JPG oder PNG Datei?

    Ergänzung: Es gibt ein aktuelles Ticket zum dem Thema, das ähnlich klingt, evtl. auf 6.8.1 warten.

    Wir haben noch fast nirgends 6.8 ausgerollt, die Erfahrung mit WordPress zeigt, dass man im Live Betrieb besser auf eine 6.8.1 oder auch 6.8.2 warten sollte oder zunächst nur Testinstallationen aktualisiert und ausführlich durchtestet.

    Hinweis dazu: Für einfache Endkunden klingt es oft so, als würden sie bei "Managed WordPress" Angeboten persönliche Hilfe auch für das Erstellen und Bearbeiten von WordPress Inhalten erhalten. Das ist in der Regel nicht so sondern es werden lediglich WordPress Core, Theme, Plugins aktualisiert wenn es Updates geben sollte und ggf. regelmässig Backups erstellt und im Fehlerfall wieder eingespielt. Daher sollte man sich explizit zusichern bzw. in den jeweiligen AGBs zeigen lassen, was im Detail z.B. unter "Managed WordPress" verstanden wird. Dabei nicht vergessen, wer wann wie genau individuellen Code erstellt oder anpasst bzw. ggf. nötig werdende Codeanpassungen von Plugins oder Themes oder beim Wechsel von PHP-Versionen o.ä. zuständig ist. Oft muss man sich hier nämlich dann doch wieder selbst kümmern.

    /* Füge individuelle Werte zwischen dieser Zeile und der „Schluss mit dem Bearbeiten“ Zeile ein. */


    Etwas "zwischen Zeilen einfügen" bedeutet, dass man nichts anderes löscht.

    Code
    /* Füge individuelle Werte zwischen dieser Zeile und der „Schluss mit dem Bearbeiten“ Zeile ein. */
    
    
    hier einfügen
    
    
    /* Das war’s, Schluss mit dem Bearbeiten! Viel Spaß. */

    Du hast derzeit vermutlich "unendlich" viele Revisionen der Startseite inkl. Metadaten in Deiner Datenbank. Was es bringt?

    ... auch das dürfte den Datenbank Bedarf in Deinem Fall dann stark reduzieren.


    Die Anzahl von 10 ist ein Beispiel, wieviele Revisionen Du behalten willst, bleibt Dir überlassen. Wenn Du viel an den Seiten herumbastelst, sind ein paar mehr Revisionen als 3 vermutlich kein Schaden.

    Bei der o.g. Verlinkung steht mit Unterstrichen ausschliesslich das:

    Code
    define( 'WP_POST_REVISIONS', 3 );


    Eventuell verwendest Du irgendwelche Übersetzungsfunktionen in Deinem Browser, schalte die ab, die sind untauglich, wenn sie versuchen, Code zu übersetzen.

    Würde mal im Matomo Plugin ältere Tracking Daten manuell löschen und auch automatisches Löschen nach einem gewissen Zeitraum einstellen, mehr dazu z.B. hier in der Matomo Dokumentation.

    Weiterhin die Anzahl der WordPress Revisionen begrenzen, in der Datei [FONT=Courier New]wp-config.php[/FONT] unterhalb der Zeile mit [FONT=Courier New]WP_DEBUG[/FONT] z.B. folgende Zeile einfügen:

    Code
    define( 'WP_POST_REVISIONS', 10 );


    Nach dem Einfügen dieser Zeile einmal die Startseite speichern, auch das dürfte den Datenbank Bedarf in Deinem Fall dann stark reduzieren.

    @DummyGirl Da das Problem des Bearbeitens und Speicherns nur eine einzige Seite betrifft, ist es wohl kein generelles Problem von Elementor:

    Beim Speicherversuch kommt die Meldung: Serverfehler (500 Internal Server Error) - Aber nur auf der Homeseite, andere Seiten funktioneren problemlos.


    Fass zum Überlaufen könnte sein, wenn es möglicherweise zu viele Revisionen der Startseite gibt oder zu viele Statistikdaten zu dieser Seite getrackt wurden o.ä., wenn beim Anlegen einer weiteren Revision inkl. Metadaten dann der Speicher durch die Datenbank Interaktion überlastet wird o.ä.

    Oder eben eine wie auch immer geartete andere Wechselwirkung mit diesem Consent Plugin, da angeblich "einzeln die plugins aktiviert und geprüft" wurden, der Support wollte ja helfen, nach "mehr Infos".

    Die "Allowed memory size" Meldungen zeigen einen einfachen Abbruch wegen Erreichen eines Speicherlimits, 268435456 Bytes = 256 MB.

    Ist ein direkter Bezug zum Bearbeiten der Startseite nachvollziehbar? Also Zeitpunkt Verursachung Fehler beim Bearbeiten der Startseite erzeugt direkt diese Meldungen? Die Zeiten fehlen in Deinem Zitat.

    Eine normale WordPress Installation braucht keine 256 MB zum Bearbeiten einer Seite. Entweder es liegt wie beschrieben eine Endlosschleife i.V.m einem Plugin vor, die letztlich unendlich Speicher anfordert oder es sind andere Faktoren im Spiel, z.B. eine aussergewöhnlich aufgeblähte Datenbank z.B. durch Statistiken oder hunderte alte Versionen von Seiten o.ä., das kann man von aussen aber nicht weiter beurteilen.

    Wenn man keine Cookies und keine externen Einbindungen und keine zustimmungspflichtigen Datenerhebungen zu Besuchern verwendet, ist keine Einwilligung nötig. Frage dazu am besten einen Anwalt Deines Vertrauens.