Beiträge von b3317133

Zitat von meisterleise

..., so ist dieser auch bereits sichtbar und noch schlimmer: die Seite lässt sich auch trotzdem aufrufen.

Link zu dieser trotzdem aufrufbaren Seite?

Eine mit WordPress geplante Seite erzeugt vor dem Termin einen Fehler 404, ausser evtl. man nutzt planlos irgendwelche ggf. auch fehlerhafte Caching-Plugins.

Weiterhin lässt sich eine mit WordPress geplante Seite nicht einem Standard WordPress Menü zuordnen.

Vermutlich funkt hier irgendein Plugin oder ein sonstiger, nicht zuende gedachter manueller Eingriff dazwischen..

Zitat von aufdraht

@b3317133 Da hast du recht!

Mit was genau?

Die genannte Demo-Seite und jetzt auch Deine Seite ist im Gegensatz zur urspünglich vorhandenen Einstellung auf Deinem Website klar zentriert. Für weitere Fragen oder Anregungen für Änderungen im Plugin am besten den Plugin Support kontaktieren.

Zitat von meisterleise

Ich erstelle auf all meinen Kundenseiten folgende Konfiguration:
1. xmlrpc per htaccess unterbinden (im Gegensatz zu @b3317133 kann ich auf keiner Seite Probleme feststellen)

Wo/welche Probleme genau stelle ich dabei fest?

Zitat von meisterleise

Natürlich gilt als 1. Regel das von @b3317133 angemerkte sichere Passwort, diese Regel hilft aber wenig, wenn man nie sicher sein kann, dass Kunden, Mitarbeiter und Redakteure sich daran halten, ...

Da Kunden, Mitarbeiter und Redakteure sicherlich keinen Account mit Administrator Rolle in WordPress nutzen, ist deren Passwortsicherheit zwar auch wichtig, aber nicht so relevant.

Zitat von RTW

Vielleicht sollte man an dieser Stelle auch nochmal anmerken, dass ein Backup eigentlich ein guter Garant ist, dass man seine Seite im Falle einer feindlichen Übernahme auch wiederherstellen kann.

Ein solches Backup wieder einzuspielen ist ein sicherer Garant, dass der Website erneut übernommen wird, weil die genutze Sicherheitslücke wieder mit eingespielt wird.

Zitat von meisterleise

..wenn der Hacker deinen Webauftritt kopiert hat und als Fakeseiten online stellt.

Die Inhalte eines Websites kann jeder jederzeit mit einem einfachen Scraping-Tool völlig an WordPress vorbei oder falls zugänglich auch komfortabel über die WordPress REST API kopieren und irgendwo verwenden, dagegen kann man rein gar nichts machen.

Wenn ihr eine totale Sicherheit bzgl. WordPress Login haben wollt, erzeugt aus einer lokalen Installation komplett statisches HTML und stellt nur das auf euere Server.

Deaktiviere testweise alle Optimierungs-, Minify-, CDN- und Cache-Plugins wie WP-Optimize, Cloudflare, Lazy Load usw., und leere dann auch Deinen Browser Cache. Ändert das etwas am Verhalten?

Zitat von NetOldie

Ich habe einen 4 Jahre alten Thread bei cf-7 gefunden, da schien es mal zu funktionieren.

Vor 4 Jahren wurde noch nicht [FONT=Courier New]FormData(..)[/FONT] beim Versand verwendet, schau Dir den Quellcode z.B. der Version 4.4 des Plugins mal an.

Zitat von NetOldie

.. und ohne Java-Script bleibe ich Browserunabhängiger.

Ohne JavaScript im Browser wird Dein Feld [FONT=Courier New]eintragen[/FONT] auf Deiner Testseite in [FONT=Courier New]$_POST[/FONT] mit an den Server übertragen:

_wpcf7=170
_wpcf7_version=5.1.9
_wpcf7_locale=de_DE
_wpcf7_unit_tag=wpcf7-f170-o1
_wpcf7_container_post=0
your-message
eintragen=Ich habe es mir anders überlegt

Erst mit JavaScript im Browser entsteht durch [FONT=Courier New]FormData(..)[/FONT] der von Dir beschriebene Effekt.

Allerdings ist in der aktuellen Version von Contact Form 7 ein [FONT=Courier New]name[/FONT] Feld bei Submit-Buttons gar nicht dokumentiert.

Contact Form 7 versendet die Formulare per Javascript in [FONT=Courier New]includes/js/scripts.js[/FONT] und nutzt dort u.a. [FONT=Courier New]new FormData(..)[/FONT] um die Formulardaten zu ermitteln. In diesen Daten ist der Submit Button nicht enthalten.

Eine Lösungsmöglichkeit wäre ein [FONT=Courier New]hidden[/FONT] Feld im Formular und ein kleines Script mit dem Du auf dem Server in [FONT=Courier New]$_POST['your-button'][/FONT] bzw. falls gewünscht auch in der E-Mail selbst den ID des Buttons bekommst.

[submit id:button-1 "Senden 1"]
[submit id:button-2 "Senden 2"]
[hidden your-button]

jQuery(document).ready(function($) {
    $('.wpcf7-submit').on('click', function(e) {
        $(this).closest('.wpcf7-form').find('[name="your-button"]').val($(this).attr('id'));
    });
});

Habe durchaus gelesen, dass für Dich ein Script keine Alternative ist, für Mitleser mag das anders sein, daher hier mal so ein Lösungansatz.

Du hast die Datei ISO-8859-1 encoded gespeichert und Dein einzelner Aufruf kunden.php gibt sie als ISO-8859-1 aus, siehe auch HTTP Header in der Browser Console > Netzwerkanalyse.

Content-Type text/html; charset=ISO-8859-1

WordPress benutzt aber UTF-8, daher gehe vor wie oben beschrieben.

Lt. PHP-Quellcode ist ein entspr. Parameter in der Free Version vorhanden, Du kannst den ja mal testweise auf [FONT=Courier New]'on'[/FONT] stellen und bei Funktion und Gefallen dann das Pro Plugin erwerben.

smart-grid-gallery/includes/functions/parameters.php


       'origincode_gallery_video_ht_view2_content_in_center_lightbox'              => 'off',

Änderungen in Plugin Code natürlich nur mit entspr. Backups und Updates des Plugins überschreiben wieder alles...

Deaktiviere diesen Mechanismus in Rank Math, eine Weiterleitung statt 404 ist nur für einzelne ganz gezielte Links gedacht die irgendwo extern falsch zu Dir verlinkt sind o.ä., alternativ wende Dich an die Person, die dieses Plugin eingerichtet hat, die sollte das wissen und entspr. einstellen können.

Und schau Dir einfach den HTML-Quelltext Deiner Seite in Deinem Browser an, dann siehst Du den Link zur CSS-Datei, dafür brauchst Du kein Pagespeed... Was sagt der Programmierer des CSS dazu?

Im HTML-Quelltext sieht man auch, dass weiterhin offenbar Optimierungs-, Minify- oder Cache-Plugins laufen, warum auch immer, offenbar gibt es kein echtes Interesse an Hilfe, bin raus, ist mir zu mühsam. Viel Erfolg.

Diese Datei existiert nicht auf Deinem Server und irgendein völlig unsinniger Mechanismus leitet bei Dir "404 nicht gefunden" Links auf die Startseite weiter, was dann eine neue Instanz von WordPress startet und das Ergebnis runterlädt und was der Browser dann natürlich nicht als CSS interpretieren kann und dann geht es erst weiter... Was sagt der Programmierer des CSS dazu?

Ergänzend: Für Hilfe bei der Suche nach Ladeproblemen deaktiviere alle Optimierungs-, Minify- und Cache-Plugins, aber das weisst Du ja bereits schon.

Die Quelldatei für Kunden ist nach wie vor ISO-8859-1 encoded, daher werden die Sonderzeichen so gezeigt.

Stelle das Encoding vor dem Upload der Datei im Texteditor auf UTF-8 (ohne BOM) um oder wandle die Daten per PHP Code vor der Ausgabe in UTF-8 um.

Nach wie vor ist völlig unklar, welches CSS Du meinen könntest... keine Antworten = keine Hilfe möglich. :rolleyes:

Welches CSS? Welche extra Datei? Was sagt der Programmierer des CSS dazu? Screenshot der entspr. Meldung?

Die Ladezeit der leutaschklamm Seite wird nach kurzem Einblick vor allem durch eine Vielzahl von externen Einbindungen ([plain]fonts.googleapis.com, fonts.gstatic.com, m.media-amazon.com, http://www.komoot.de, maps.google.com, api.mapbox.com, account.komoot.com, tiles-api.maps.komoot.net, events.mapbox.com, maps.googleapis.com, zig subdomains von tiles-api.maps.komoot.net[/plain] und viele, viele weitere externe Dateien von verschiedenen Trackern) beeinflusst.

Für Hilfe bei der Suche nach Ladeproblemen deaktiviere alle Optimierungs-, Minify- und Cache-Plugins, derzeit mind. aktiv: Autoptimize, weiterhin alle Tracking-, Statistik- und Werbung-Plugins (Google Analytics, Adsense o.ä., WP-Statistics, VG Wort, Amazon, ...), dann kann man ggf. zuordnen, was wo wie woher kommt bzw. für die genannte "enorme Ladezeitverzögerung" verantwortlich sein könnte.

Bei Kunden ist der [FONT=Courier New]<html>[/FONT] und [FONT=Courier New]<head>[/FONT] Tag mit Inhalt zu viel und die Quelldatei ist ISO-8851-1 encoded statt UTF-8.

Bei Social ist ein [FONT=Courier New]<body>[/FONT] Tag zu viel und die Bilder sind wegen [FONT=Courier New]<td width="1%"></td>[/FONT] in der ersten Zeile der Tabelle unsichtbar.

Die Position wird vom verwendeten Script berechnet, das betrifft auch andere Breakpoints bzw. Bildschirmbreiten wenn nur zwei Bilder nebeneinander stehen usw.. Vermutlich gibt es eine Einstellung im entspr. Plugin, zumindest der Code [FONT=Courier New]data-show-center="on"[/FONT] in einem der Beispiele des Plugins mit zentrierter Anzeige lässt darauf schliessen.

Zitat von angalo

Wo kann ich da mit der Fehlersuche ansetzen?

Beispielsweise in der Dokumentation von Contact Form 7. Dort ist auch was zum genannten Tag zu finden:

Zitat

reCAPTCHA v3 doesn’t need a CAPTCHA widget ... to work, so [recaptcha] form-tags are no longer necessary.

Weiterhin in den Forenregeln, ein Link zur Seite fehlt...

#site-navigation button:active,
#site-navigation button:focus {
   outline: none;
}

Evtl. zusätzlich noch [FONT=Courier New]border: none;[/FONT] wobei ich hier den grauen Rand nicht reproduzieren konnte...

Deaktiviere testweise alle Optimierungs-, Minify- und Cache-Plugins. Weiterhin deaktiviere testweise alle "Sicherheits"-Plugins. Und leere dann Deinen Browser Cache. Ändert das etwas am Verhalten? Link zur Seite?

Evtl. steht in der [FONT=Courier New]wp-config.php[/FONT] irgendwo noch [FONT=Courier New]define('RELOCATE',true);[/FONT] oder es läuft ggf. noch irgendein SSL/https Plugin...[FONT=Courier New][/FONT]

Ein Theme aktualisiert man immer im gleichen Ordner, nicht wie hier offenbar in einem neuen Ordner, sonst kann und wird da sehr viel schiefgehen. Eine vorherige Version kann man vorher z.B. per FTP sichern und bei Bedarf dann den ganzen Ordner durch die alte Version ersetzen.

Generell ist natürlich ein vollständiges Backup des ganzen Websites inkl. Datenbank vor dem Einspielen von Updates ratsam.

Weitere Hinweise bei "leeren Seiten" ergeben sich aus dem PHP Error Log beim Hosting, vermutlich ein Fehler 500 durch was auch immer, von alter PHP Version bis hin zu sonstigen Inkompatibilitäten mit dem Child Theme oder Plugins o.ä. ist alles möglich.

Am besten wendet man sich an die Person, die den Website ursprünglich eingerichtet hat, die sollte den nötigen Sachverstand mitbringen, die Probleme zu identifizieren und zu beheben.

Und ergänzend ein technischer Tipp am Rande: Aus irgendwelchen Gründen wird neben der jQuery Version von WordPress parallel eine weitere jQuery Version 3.2.1 von einem externen CDN eingebunden, das sollte man beheben. Diese Einbindung und auch die Einbindung externer Google Webfonts fehlen zudem in der Datenschutzerklärung.