Beiträge von b3317133

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...

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

Lt. Screenshot erfolgt der Redirect von der Autorenseite auf die Hauptseite. Das ist vermutlich in Yoast SEO so eingestellt, wende Dich a, besten an die Person, die das Yoast SEO Plugin für Dich eingerichtet hat.

Auf Deiner Starseite ist der Link zur Autorenseite unsichtbar am Beginn des Inhaltsbereichs mit "Seit nun mehr als sieben Jahren darf ich Ihnen..." hinterlegt, daher wird er wohl von diesen SEO-Tests o.ä. gefunden, dort findet sich auch eine Klasse rich-snippet-hidden. Möglicherweise kommt das auch durch Yoast SEO oder aber durch andere Optimierungsmechanismen des Themes oder anderer Plugins. Wende Dich auch hier am besten an die Person, die das Theme und entspr. Plugins eingerichtet hat, die sollte das leicht lokalisieren können.

Du könntest einen eigenen Eintrag in der .htaccess Datei vornehmen oder in WordPress ein Plugin wie Simple 301 Redirects verwenden und damit z.B. /deine-html-seite.html auf [plain]https://example.com/wp-seite/[/plain] weiterleiten.

Verwende im Script [FONT=Courier New]this.src[/FONT] statt [FONT=Courier New]src[/FONT]

Wenn die Fehlermeldung nachvollziehbar mit dem Gutenberg Editor passiert, poste das Problem am besten bei den Gutenberg Entwicklern, die lesen hier im Forum nicht mit.

Evtl. ist es dabei hilfreich, die Ausgaben der Browser-Konsole (google) beim Aufruf der defekten Seite mit anzugeben.

Ergänzend hierzu: Systeme wie Plesk oder auch Cloudflare verwenden u.a. "Blocklisten" für bekannte Sicherheitslücken, z.B. die Auflistung aller Benutzer inkl. Loginnamen über eine ältere Variante der REST-API von WordPress.

Durch die "ungeschickte" Benennung der Pfade für die REST-API, genauer gesagt durch die Beibehaltung der alten Versionsnummer [FONT=Courier New]/v2/[/FONT] beim Launch von Gutenberg werden durch diese Listen und die enthaltenen Pfade hier und da auch einige Aufrufe von Gutenberg blockiert. Die Entwickler von Gutenberg haben als "Lösung" versucht, die Listen z.B. bei Cloudflare zu beeinflussen anstatt vor dem Launch die Version zu ändern, nunja, muss man nicht verstehen...

@MB7x: Wenn ich Deinen Screenshot richtig verstehe, hast Du jetzt alle Plesk Sicherheitsmaßnahmen abgeschaltet?

Verstehst Du unter "neuer Editor" den bei Dir installierten Elementor Pagebuilder für das Astra Theme oder den WordPress Gutenberg Editor?

Was erscheint in der Browser-Konsole (google) wenn Du die Seite im ersten Screenshot aufrufst?

Versuche es mal bei Einstellungen > Permalinks statt Einfach mit Beitragsname, evtl. kommt da was durcheinander. Hinweis: Das ändert dann auch die Links im Website von z.B.[FONT=Courier New]/?page_id=29[/FONT] in "sprechende" Links wie[FONT=Courier New] /impressum-und-datenschutzerklaerung/[/FONT]