Beiträge von b3317133

    Beispiele für so etwas findet man ...


    .. oder auch umfassend beschrieben in der WordPress Dokumentation zur Ausgabe von Datum und Uhrzeit, verlinkt in der Antwort #2 hier im Thread.

    Etwas eigenes Mitdenken sollte man schon wenigstens versuchen, dafür ist dieses Forum da.

    In diesem Fall hätte einfach auch schon nur das Lesen des Links geholfen, dort steht sehr klar:

    Zitat

    The [FONT=Courier New]date_i18n()[/FONT] function basically behaves like the PHP [FONT=Courier New]date()[/FONT] function, except that it also translates things like month names and weekdays and similar into the current locale for the site. You can replace a call to [FONT=Courier New]date()[/FONT] with a call to [FONT=Courier New]date_i18n()[/FONT], using the same arguments.


    Das ist exakt die Antwort auf die ursprüngliche Frage.

    Der Test bzgl. der Fehlermeldung beim Speichern mit dem temporär aktiven Classic Editor Plugin hat nichts mit dem Neuerstellen bzw. Nachbauen der Startseite zu tun. Bitte genauer lesen.

    Macht es Sinn, die einzelnen Seiten mit dem AVADA-Editor, (wenn ich bei dem Team [Theme] bleiben sollte), also Visual, nicht mit Text im Nachhinein zu nachzubearbeiten?


    Es macht hier am meisten Sinn, in der bestehenden Installation eine neue Seite mit Avada anzulegen, mit den Elementen des zugehörigen Editors, und die Inhalte der bisherigen Startseite darin möglichst ganz ohne eigenes HTML neu nachzubauen und dann später diese Seite als Startseite einzustellen.

    Ähnliches Vorgehen gilt für weitere Seiten, falls diese manuell mit viel eigenem HTML erstellt wurden und/oder ähnliche Fehlermeldungen verursachen.

    die Plugins habe ich alle deaktiviert, um zu sehen, ob die 633 MB geringer wurden, leider nein, es bleibt bei 633 MB.


    Ok, das bedeutet, dass diese Speicheranforderung vom Theme bzw. vom eingefügten Inhalt verursacht wird. Installiere und aktiviere testweise das Classic Editor Plugin, ändert das etwas am Verhalten beim Speichern?

    Kann ich jemanden von Euch vielleicht die Zugangsdaten geben, ich weiß das soll nicht sein, aber ich komme so nicht weiter.


    Hilfe im Direktkontakt gibt es über die Jobbörse hier im Forum.

    Also, wenn ich nicht auf Eure Fragen antworten kann., liegt das nicht daran, es nicht tun zu wollen, ich kann es nicht.


    Deaktiviere alle Plugins. Aktualisiere die fragliche Seite. Wird eine andere Zahl als ca. 633 MB bei allocated in der Fehlermeldung gezeigt? Welche?

    Kontaktiere den mitgekauften Theme Support. Beschreibe dort das Problem inkl. Fehlermeldung. Folge den Rückfragen usw. dort. Poste das Ergebnis daraus hier.

    Ergänzung: Bei der fraglichen Seite wurde offenbar viel mit manueller HTML Eingabe gearbeitet, was am Sinn und Zweck von WordPress bzw. den Möglichkeiten des Themes völlig vorbeigeht. Hier ist vermutlich die Hauptursache der Probleme zu suchen. Beispielsweise Dinge, die man temporär nicht zeigen will, werden nicht mit HTML Kommentaren ausgeblendet, sondern man nutzt bei Avada den Container Publishing Status, mehr dazu hier in der Theme Anleitung.

    JABA-Hosting - im anderen Thread schreibst du - vgl: https://forum.wpde.org/threads/out-of-memory.194083/


    Sehr merkwürdig - denn hier kommt eine Tonne eine Errormeldungen raus... - so lang und umfangreich. ... hier nur ein Ausriss


    Das Problem mit dem (vermutlich endlosen) Speicherverbrauch tritt wie klar und deutlich beschrieben beim Aktualisieren einer einzigen Seite im WordPress Backend auf. Es geht hier weder um das Laden der Startseite im Browser noch um die Meldungen in einem Validator.

    Das Problem wird nicht durch "noch mehr Speicher" oder der Kauf irgendeines Servers gelöst werden. Wer in diesem Fall dazu rät, kennt sich mit WordPress offensichtlich nicht wirklich aus. Die angefrage Speichermenge ist in etwa so, wie wenn ein VW Polo plötzlich 30 Liter Benzin auf 100 km verbraucht. Sowas löst man nicht durch einen grösseren Tank.

    Zur weiteren Verfolgung der Ursache wichtige angefragte Angaben wie exakte Speicherverbrauchsmeldung ohne jegliche Plugins oder mit anderem Theme wurden nicht gemacht, was der Theme Support sagt, wird auch nicht weitergegeben. Daher ist ernsthafte Hilfe schwer möglich.

    Die gleiche Frage wurde hier schon gestellt:

    https://forum.wpde.org/threads/out-of-memory.194083/

    Beantworte alle dort noch offenen Fragen in den Beiträgen bzw. folge den Hinweisen dort.

    Ergänzung: Die Lösung hier ist nicht das blinde Erhöhen des memory limit, das bei Dir offenbar bereits über 633 MB erlaubt, sondern das Herausfinden, warum Deine WordPress Installation beim Bearbeiten dieser einen Seite diese völlig unübliche Menge an Arbeitsspeicher zu benötigen scheint.

    Wenn Du gestellte Rückfragen beantwortest, dann kann man Dir weiterhelfen, und in der Jobbörse hier im Forum gibt es bei Bedarf auch Hilfe ohne neue Verträge oder teuere Stundensätze.

    ..also alle Tabellen markiert und das oben genannte eingegeben und er hat auch jede Menge gefunden. Nur mein Problem wurde eben nicht gelöst.


    Dann wurde offenbar der Haken bei Testlauf? bzw. Run as dry run? nicht entfernt:

    Zitat

    Beim Testlauf wird die Datenbank nicht verändert. So kannst du vorher prüfen, welche Ersetzungen vorgenommen werden.


    Beim Neueinspielen eines Duplicatorarchivs über https werden die Ersetzungen alle automatisch von Duplicator vorgenommen, Better Search Replace ist dann gar nicht nötig.

    Es sind weiterhin Einträge mit [plain]http://sealand.gmbh/...[/plain] in der Datenbank, in Yoast SEO Einträgen u.ä., irgendwas läuft bei der Ausführung der o.g. Anleitung also wohl generell falsch.

    Poste einen Screenshot Deiner Better Search Replace und Elementor Replace URL Eingabefelder, damit man sehen kann, was exakt Du alles machst oder nicht machst.

    Ansonsten wie mehrfach empfohlen, wende Dich am besten an die technisch verantwortliche Person und lasse Dir die technischen Dinge erklären, sonst geht ggf. noch mehr schief.

    Bei Better Search Replace alle Tabellen auswählen und dann das Folgende suchen/ersetzen, ebenso bei Elementor.

    Code
    Suchen:
    http://sealand.gmbh
    Ersetzen:
    https://sealand.gmbh


    Bei Elementor ist es danach sicher auch kein Schaden, den internen Cache zu leeren, siehe Anleitung Elementor bzw. Elementor > Tools > Regenerate ...

    Wie schonmal oben beschrieben, wäre generell für all diese Dinge vermutlich die Person, die den Website eingerichtet hat bzw. technisch betreut hier der beste Ansprechpartner.

    Ergänzung: Vor solchen Eingriffen sollte man natürlich immer Backups der Datenbank erstellen, was z.B. bei Better Search Replace ja auch sehr klar angezeigt wird.

    Da keine der Fragen beantwortet wurden, gehe ich davon aus, dass keiner Anleitung gefolgt wurde und nichts von den restlichen Punkten gemacht wurde. Informiere Dich etwas zum Thema SSL Umstellung WordPress bzw. Elementor und stelle die Seite dann anhand der o.g. Punkte sauber um. Danach sollten die Schriften eingebunden und angezeigt werden.

    Es ist nicht der Fehler von IONOS (oder einem anderen Hosting), wenn Deine Installation beim Aktualisieren der Startseite mehr als 633 MB PHP Speicher benötigt.

    Da die Meldung offenbar bei deaktivierten Plugins gleich bleibt, zumindest hast Du trotz Nachfrage nichts gegenteiliges beschrieben, wende Dich an den Theme Support.

    Was bei kurzer Betrachtung der Startseite auffällt, sind diverse HTML Fehler und auch diverse per HTML Kommentare auskommentierte Inhaltsteile, sowas könnte evtl. auch den Editor durcheinanderbringen und in Endlosschleifen schicken. Das sollte man im Rahmen der Problemsuche bereinigen.

    Die Meldung bleibt exakt gleich bei deaktivierten Plugins? Die Installation benötigt also ohne Plugins weiterhin mehr als 633 MB? Das wäre schon etwas ungewöhnlich.

    Was genau ist auf der entspr. Seite, bei der das Aktualisieren nicht klappt? Link?

    Und was sagt der Theme Support, den Du mitgekauft hast? Ist das Theme aktuell und passt zur verwendeten WordPress Version? Welche Theme und WordPress Version wird verwendet?

    Vermutlich wird die Telefonnummer auf dem von Dir genutzen mobilen Testgerät als Telefonnummer erkannt und klickbar dargestellt. Dadurch bekommt sie die allgemein für Links voreingestellte Standardfarbe.

    Du kannst die Farbe per CSS überschreiben, allerdings gibt es bei Deinem Link offenbar keine dafür allgemeingültige Klasse über alle Seiten hinweg, da der Footerbereich auf jeder Seite einzeln angelegt worden zu sein scheint (und dadurch jeweils unterschiedliche interne Elementor IDs hat) statt die normalen Header/Footer Funktionen zu verwenden.

    Alternativ kannst Du in den [FONT=Courier New]head[/FONT] der Seiten ein zusätzliches Meta Tag hinterlegen, das diese autom. Erkennung deaktivieren sollte:

    Code
    <meta name="format-detection" content="telephone=no">