Beiträge von b3317133

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]

Das ist keine Lösung.

Der ganze Website ist nach wie vor als kompromitiert zu betrachten, sowas online zu lassen ist im Grunde grob fahrlässig. Was wirklich zu tun ist, steht oben beschrieben...

Zitat von Smin2

Content Protect By Time Lock

Dieses (uralte) Plugin nutzt nach kurzem Einblick exakt den beschriebenen "pre_get_posts mit Custom Field und meta_query" Ansatz.

Offenbar werden Deine anderen Plugins "FB Postings und der Newsletter" aber anders getriggert, womöglich einfach dann, wenn ein Beitrag auf "publiziert" gesetzt wird, daher musst Du wohl eine andere Lösung suchen oder diese Plugins anpassen.

Man könnte eine pre_get_posts Action i.v.m. einem Custom Field (in dem das gewünschte "Veröffentlichungsdatum" steht) und einer meta_query nutzen und damit Beiträge ausblenden, die das Datum noch nicht erreicht haben. Programmierkenntnisse vorausgesetzt.

Man könnte Kategorien, Schlagworte oder ein Custom Field o.ä. und eine pre_get_posts Action mit 3-4 Zeilen Code nutzen und auf Basis dieser Einstellung je nach eingeloggt oder nicht im Frontend die entspr. Beiträge aus-/einblenden. Programmierkenntnisse vorausgesetzt.

Das allgemeine Vorgehen mit allen notwendigen Schritten bei einem Hack ist z.B. hier beschrieben.

Zitat von serwo

.. seit dieser Woche leider von Viele Freunde von mir und bekannte und auch andere geschäftsseiten in wien geändert worden wzb die umleitung.

Was bedeutet das genauer? Hier wäre herauszufinden, ob der Hack einen bestimmen Hosting-Anbieter betrifft. Falls das so ist, sollte man erst herausfinden (lassen), wo die Lücke dort war, bevor man mit dem Reparieren von WordPress anfängt.

Falls WordPress 5.3 eingesetzt wird, kann ggf. auch dieser aktuelle Fehler ein Problem in dieser Art verursachen.

Könnte man herausfinden, indem mal alle Plugins deaktiviert und ein Standard-Theme aktiviert und testet, ob dann die Veröffentlichung funktioniert.

Füge eigene Einträge in wp-config.php ausschliesslich direkt vor/oberhalb dieser Zeile ein.

/* That's all, stop editing! Happy publishing. */

Was für ein Fehler wird im Code erzeugt? Woran siehst Du, dass es ein Fehler ist? Logische Probleme oder Endlosschleifen o.ä. landen z.B. nicht im debug.log

Und wo genau in der wp-config.php sind diese Zeilen eingefügt?

Evtl. zeigt Dein PC die .webp Endung Deiner Datei nicht an, Windows blendet z.B. standardmässig Endungen aus, warum auch immer.

Versuche es mit einem Beispielbild von z.B. hier.

Dafür würde man in WordPress z.B. folgende Dinge nutzen, mehr zu den einzelnen Begriffen in einer Suchmaschine Deiner Wahl.

• Custom Post Type
• Custom Taxonomies
• Advanced Custom Fields
• FacetWP
  
• Child Theme

Für weitere Recherche, diese "Checkbox-Filteroptionen" nennt man in der Fachsprache auch Facettensuche.

Das Hochladen des Bildformat .webp ist in WordPress standardmässig nicht erlaubt.

Hintergründe dazu u.a. in diesem trac Ticket.

Kurzversion: Der Apple Safari Browser und damit iPhones/iPads usw. unterstützen .webp nicht. Würde man einen Upload standardmässig zulassen, bräuchte man umfangreiche Fallback- und Workaroundlösungen für alle Bildfunktionen im WordPress Core.

@maxe Ausser wenn der "nur Inhalt" von extern eingebunden wird, da kommen schonmal Cookies mit...

@Mbelon Link zur Seite? Dann könnte man ggf. grundsätzliche Probleme dort identifizieren. Was Du dann wie wohin schreiben musst, das kann Dir tatsächlich nur ein Anwalt sagen.

Evtl. hat Dein Umfrage Tool eine eigene .htaccess oder kollidiert anderweitig mit WordPress.

Zitat von lin

Was würdest du hier anders machen!?

Würde das Umfrage-Tool auf einer Subdomain hosten.

Evtl. hast Du bei dieser Meldung den Zwischenschritt "Live URL testen" für eine aktuelle Analyse weggelassen, aber egal, das "Neu indexieren" hat jetzt offensichtlich geklappt:

https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fsmg-wohlenbe.ch