Beiträge von b3317133

Link zu so einer geschützten Seite?

Hast Du Dich zum Testen von WordPress abgemeldet?

Dann erzeuge den Fehler neu und poste dann die neusten Einträge aus dem Server Error-Log oder einfach mal generell die letzten Einträge.

Weiterhin deaktiviere diesen Query Monitor und alle sonstigen Monitoring- und Optimierungs- und Cache-Plugins, um Einflüsse auszuschliessen.

Schau beim Erzeugen des Fehlers mal in die Konsole des Browsers und in das Netzwerk-Tab in das Antwort-Feld beim entspr. Ajax-Aufruf wenn da was fehlschlägt oder lange dauert, was steht dort?

Weiterhin deaktiviere temporär alle sonstigen Plugins, eines nach dem anderen, und schau, ob das die Fehler beeinflusst.

Und beschreibe kurz, was genau Du seit "vor einiger Zeit" gemacht hast, bevor das Problem auftrat. PHP-Version verändert, Updates von WP, Plugins, Theme?

Welche WordPress-Version, PHP-Version, Theme & Version, Plugins & Versionen wird verwendet? Ist alles auf dem neusten Stand?

Was sagt der Support von Storefront Pro Premium zu der Fehlermeldung? Den Support hat man in der Regel mitgekauft.

Die vergleichsweise lange Dauer von 120 Sekunden dürften übrigens einfach dadurch entstehen, dass auf dem Server direkt ein Fehler passiert und das lokale Script dann bis in den Timeout auf eine sinnvolle Antwort wartet, die es nie bekommt.

PS. Wenn Du nicht mit der Installation arbeiten kannst, wende Dich am besten an die Person, die den Website eingerichtet hat, die weiss am besten, was wie verwendet wird und wie eingerichtet wurde.

Der 404-Fehler in der ersten Meldung ist lt. Autor der API normal und bedeutet, dass es keine Updates gibt.

Der PHP-Fehler deutet auf ein Problem mit dem Storefront Plugin hin. Mehr dazu findest Du ggf. im Server Error Log, wie man das bei Strato findet siehe z.B. hier.

Die Installation ist derzeit für das Unterverzeichnis /wordpress eingerichtet, Vorgehen:

1. Einstellungen > Allgemein > dort in den beiden Feldern den Teil [FONT=Courier New]/wordpress[/FONT] entfernen, so dass nur noch die Domain ohne / am Ende dortsteht > Speichern > dann wirst Du vermutlich autom. abgemeldet.
2. Strato Umleitung auf das Verzeichnis legen
3. Anmelden mit [FONT=Courier New]example.com/wp-admin/[/FONT] also ohne das Unterverzeichnis
4. Plugin "Better Search Replace" installieren und damit ersetzen [FONT=Courier New]example.com/wordpress[/FONT] durch [FONT=Courier New]example.com[/FONT] (jeweils ohne / am Ende).

Die hier verwendete Beispieldomain example.com durch Deine Domain ersetzen...

Das zweite Problem ist also auch gelöst, der Login der Installation, zu der der o.g. cuttly Link führt, funktioniert wie er soll, wenn man ihn korrekt benutzt.

Das dritte - wiederum neue - Problem ist jetzt also eine weitere Installation mit der Subdomain "devgroh" offenbar installiert in einem Unterordner der Hauptinstallation.

Die "Redirects" dort liegen daran, dass in dieser dritten Installation die Permalinks auf "Einfach" gestellt sind und die .htaccess im übergeordneten Ordner dazu nicht passt aber vom Server berücksichtigt wird (bei .htaccess geht der Server sozusagen durch die ganze Ordnerstruktur und beachtet alles).

Man könnte als Lösungsansatz die .htaccess im übergeordneten Ordner kurz umbenennen, sich dann in die "devgroh" einloggen, und die Permalinks auf "Beitragsname" o.ä. umstellen.

Das Originalthema des Threads war eine inzw. gelöste Fehlermeldung, mit dem jetzt dazugekommenen Wirrwar aus Installationen und Unterordnern hat das nichts mehr zu tun. Erstelle am besten eigene Themen für neue Probleme.

Ganz am Rande: Vielleicht wäre auch ein Posting in der Jobbörse mit exakter Beschreibung, was eigentlich das Ziel der ganzen Änderungen ist, ein denkbarer Ansatz, mit geforderter Erklärung, was genau das Problem war, um daraus zu lernen, statt von einem Problem irgendwie ins nächste zu schlittern.

Kennst Du schon die Dokumentation auf der Hersteller Seite des Plugins?

Das ACF Beitrags-Objekt gibt standardmässig ein/mehrere Post-Object(s) zurück, nicht nur Post-ID(s).

Wenn Du auch "Kind-Posts" möchtest, klicke die gewünschten mit in der Beitrags-Objekt Auswahl an oder nutze danach ein eigenes get_posts() mit post_parent oder post_parent__in Parametern und der aus den Post-Object(s) ermittelten $post->ID Werten.

Das erste Problem ist damit also gelöst, das Update via Upload war zunächst unvollständig.

Zitat von irmen

Jetzt kommt keine Fehlermeldung mehr, wenn ich ins Backend möchte - leider wird automatisch anstelle des von mir eingegebenen [plain]http://www.meineseite.de/derunterordner/wp-admin[/plain] folgender Link eingetragen..

Die verlinkte Seite nutzt lt. Quellcode keine Unterordner, die Loginabfrage erscheint da wo man sie vermuten würde unter [plain]example.com/wp-admin/[/plain]

Wo genau hast Du denn einen Unterordner eingegeben und warum?

Offenbar hast Du nicht gemacht, was in #2 beschrieben ist.

Wenn die Fehlermeldung weiterbesteht, nutzt Du weiterhin einen Mix aus verschiedenen WordPress Versionen.

Mit den Dateien aus einem frischen WordPress .zip Archiv gibt es keine Deklaration von check_password_reset_key() in wp-login.php

Neben den bereits genannten Hinweisen kannst Du auch temporär der Reihe nach alle Plugins deaktivieren und dadurch herausfinden, ob eines das Problem verursacht.

Oft sind Cache- oder Minify- oder sonstige Optimierungsplugins ein Problem, wenn sie nicht korrekt eingerichtet wurden.

Liegt es an keinem der anderen Plugins, könnte man es zudem mit dem Plugin Classic Editor versuchen, um Kollisionen des verwendeten Theme mit der aktuellen WordPress Version auszuschliessen.

Relevant wäre der Inhalt der Konsole direkt auf der "auswählen und zuschneiden" Seite während / nach dem fehlgeschlagenen Hinzufügeversuch. Auf dem zuerst geposteten Screenshot ist/war eine andere Seite zu sehen.

Ergänzend: Auf dem zuerst geposteten Screenshot war auch zu sehen, dass im Browser offenbar eine ganze Reihe von Add-Ons verwendet werden, versuche es daher auch mit einem anderen Browser bzw. mit temporär deaktivierten Browser Add-Ons.

Vermutlich wurden beim Hochladen die Dateien im Hauptverzeichnis nicht überschrieben.

Lade alle Dateien aus einem frischen WordPress .zip Archiv im Hauptverzeichnis wie /wp-login.php usw. und die Ordner /wp-admin/ und /wp-includes/ neu hoch.

Der Website verwendet derzeit kein Child Theme. Es wurde lediglich eine Menge CSS offenbar aus einem Child-Theme in den CSS Customizer des Parent Themes kopiert. Lies nochmal nach, wie das OceanWP Child Theme verwendet wird, z.B. Anleitung Hersteller.

Der Google Analytics / Tagmanager Code wurde zwischen </head> und <body> kopiert, dort hat kein HTML-Code was verloren. Entweder in den <head> .. </head> Bereich oder in den <body> Bereich, aber nicht dazwischen.

Normalerweise macht man sowas alleine mit CSS hover, ohne Script Events.

Mit WordPress hat es allerdings nichts zu tun, evtl. wäre ein HTML/CSS-Forum dafür generell besser, auch da vermutlich noch weitere, ähnliche Fragen entstehen werden.

Und passiert das bei allen Bildern so, oder nur bei manchen (z.B. sehr grossen)?

Eine Datei start.php gibt es standardmässig in der Hierarchie von WordPress nicht, es kommt also wohl auf die Umsetzung in Deinem Theme an. Wird dort eine Datei start.php z.B. als Seiten-Template für die Startseite verwendet, kannst Du die Datei theoretisch kopieren und entspr. anpassen und einer anderen WordPress Seite zum Testen zuordnen, musst dabei aber darauf achten, dass das Schreiben/Lesen der Daten für Deine Kopie nicht ggf. auch die eigentliche Startseite beeinflusst. Mehr dazu kann man nur durch tiefgehendere Analyse des Theme-Codes erfahren, viel Erfolg dabei!

Wie genau werden die Posts anderen zugeordnet bzw. verschachtelt?

Evtl. wäre das auch über ein ACF Relationship Feld lösbar.

Die Änderung bezieht sich wie beschrieben nur auf das Script in den Event Attributen, nicht auf das HTML Attribut src.

Versuche es mal mit dem Plugin Classic Editor.

Der "Profi" sollte das sehr einfach lösen können, selbst wenn die "Profikompetenz" nur aus "copy&paste" oder "Plugins installieren" besteht, wie so oft... :rolleyes:

Alternativ nutze das Code-Beispiel, das hier verlinkt ist, oder ein Plugin, das hier verlinkt ist.