Beiträge von b3317133

    Ein kurzer Blick in den Code von wp_get_update_data() ergibt, dass dort via current_user_can(..) bestimmte Rechte (bei WordPress "Capabilites" genannt) des aktuellen Benutzers geprüft werden.

    Da Dein Plugin via Cron nicht im Kontext eines Benutzers mit solchen Rechten im Backend läuft, lässt sich diese 0 ganz gut erklären.

    Als Workaround könntest Du den Code von wp_get_update_data() in eine eigene Funktion Deines Plugins kopieren und die entspr. Checks weglassen.

    Irgendwas probieren hilft hier nicht, überlege Dir auf welcher Domain/Pfad die Installation laufen soll und richte Sie dementsprechend ein, Google / Forumsuche "WordPress Umzug", "Better Search Replace" usw., oder installiere die Installation frisch genau dort mit einem vorher erstellten Paket Deiner Entwicklungsumgebung mit dem Duplicator-Plugin.

    Wenn dann zusätzlich eine dritte Domain darauf weiterleiten soll, verwende eine externe http 301 Weiterleitung.

    Wenn der Kunde die Installation erst unter seite-b.de/unterverzeichnis/ und dann später unter seite-b.de/ sehen will, ist später ein weiterer Umzugsvorgang mit z.B. "Better Search Replace" nötig.

    Ja, weil Du WordPress so eingerichtet hast, dass es denkt, es würde unter seite-b.de/unterverzeichnis/ laufen, siehe siteurl & home & .htaccess. Stelle WordPress auf seite-b.de/ oder seite-b.org/ um oder verwende die o.g. Alternative.

    WordPress kann nicht gleichzeitig für verschiedene Domains/Subdomains/Unterordner eingerichtet sein.

    Wenn die Domain-Weiterleitung für seite-b.de auf das Unterverzeichnis zeigt, ist die WordPress Installation da drin von aussen unter seite-b.de/ erreichbar, nicht unter seite-b.de/unterverzeichnis/

    Man legt in der Regel eine Subdomain an, z.B. test.restlos-gluecklich.berlin und arbeitet dann dort mit einer komplett neuen WordPress Installation mit eigener Datenbank und einem Plugin wie Password Protected. Am Ende macht man einen Domainumzug von WordPress, dazu nutzt man z.B. das Plugin "Better Search Replace". Mehr dazu über die Forumsuche mit "Domainumzug" o.ä. bzw. dem Plugin Namen.

    Vermutlich zeigt die Domain seite-b.de direkt auf das Unterverzeichnis anstelle auf das übergeordnete Verzeichnis.

    Eine mögliche Alternative wäre, den Umzug komplett neu mit einem Plugin wie Duplicator o.ä. zu machen, dann werden viele Schritte automatisch erledigt, d.h. viele Fehlerquellen scheiden aus.

    Bei den meisten Plugins üblicherweise [FONT=Courier New]/sitemap.xml[/FONT]

    Darin enthalten ist dann oft ein sog. Sitemap-Index der auf weitere Sitemap-Dateien verweist.

    Manche Plugins wie z.B. Yoast SEO leiten den Aufruf auch auf eine eigene URL weiter, aber mit [FONT=Courier New]/sitemap.xml[/FONT] macht man auch da nichts falsch.[FONT=Courier New][/FONT]

    Zitat von "Marcus[IS

    "] und für zwei WP die selbe Datenbank nutzen würde ich persönlich nicht machen, da bei einem Hack direkt zwei Blogs betroffen wären.


    Am Rande bemerkt, viele aktuelle Hacks die wir sehen, scannen einfach durch alle verfügbaren Ordner und Unterordner und übergeordnete Ordner usw. und suchen / infizieren da alle möglichen index.php und / oder wp-config.php Dateien die sie finden, also auch andere Installationen im gleichen Webspace, die Datenbank an sich bleibt dabei meist völlig unbeachtet.

    Zum o.g. Vorgehen:

    Wenn der Installationspfad nicht gefunden wurde, stimmt das Domainmapping nicht bzw. im o.g. Fall fehlt wohl einfach das passende SSL-Zertifikat für die zweite Domain - versuche es mit [plain]http://[/plain] statt [plain]https://[/plain], oder WordPress wurde nicht komplett / korrekt entpackt und hochgeladen.

    Das manuelle Erstellen einer wp-config.php mit dem eigenem Prefix sollte nicht nötig sein, das Prefix gibt man in der Regel bei der Installation ein und diese erstellt die wp-config.php dann selbst. Oder wurde ein "AppWizard" Installer o.ä. von Strato verwendet?

    Siehe auch oben...

    Die "Fatal error" Meldung bedeutet: Die nächsten 32768 zusätzlich benötigen Bytes (und alle weiteren danach ggf. zusätzlich benötigten Bytes) sind nicht mehr möglich, bei bereits 73400320 genutzten Bytes für die Bearbeitung der aktuellen Seite bzw. für den PHP-Code "dahinter".

    Alle Plugins rauswerfen, die man nicht unbedingt und zwingend braucht, um den Speicherverbrauch zu verkleinern.

    Oder ein entspr. grösseres Paket mit mehr Arbeitsspeicher (RAM) buchen.

    Leere Deinen Browser-Cache, dan ist das Problem wieder da, der Browser merkt sich auch die Redirects.

    WP Rocket ist mMn. die Ursache für Dein Problem, zumindest so wie es bei Dir eingerichtet ist.