Beiträge von b3317133

Der Link steht in der CSS-Datei wp-content/themes/di-blogger/style.css und muss dort geändert werden.

PHP funktioniert, daran liegt es nicht. Kann man anhand anderer Dateien nachvollziehen...

Könnte z.B. ein fehlgeschlagener Hack sein der sich in Systemdateien einnisten wollte, hier in die Datei wp-includes/http.php

In so einem Fall zuerst alle Dateien sichern, z.B. in einen neuen Ordner per FTP runterladen, damit man sonstige Änderungen später nachvollziehen kann.

Dann aus dem .zip Archiv der verwendeten WordPress Version via FTP die Ordner /wp-admin/ und /wp-includes/ und die WordPress-Dateien im Hauptordner (hier nur die Dateien, die auch im .zip sind), wo die wp-config.php liegt (diese Datei erstmal in Ruhe lassen), auf dem Server löschen oder umbenennen und aus dem .zip Archiv neu hochladen. Dann sollte die Seite wieder laufen.

Dann gilt es die Ursache zu finden und zu beheben, hier ist grob beschrieben, wie es weitergeht.

Die Meldung an sich kommt daher, dass die Änderung des "Code wegen der DSVGO" wohl nicht korrekt war.

Am Rande bemerkt, die allermeisten Funktionen von JetPack entsprechen wohl nicht der DSGVO, viele werfen dieses Plugin daher raus oder verwenden es erst gar nicht.

Zitat von gustavmega

Reicht das für DSGVO?

Das kann Dir anhand der Ergebnisse von Möglichkeit 1 und Möglichkeit 2 nur ein Anwalt beantworten.

Hier ist die Plugin-Support Seite (das Plugin scheint schon recht alt zu sein), der passende Begriff bei englischen Anfragen wäre "GDPR", das ist in etwa die Übersetzung von "DSGVO".

Änderungen an Theme-Dateien sollte man generell ausschliesslich über FTP bzw. SFTP vornehmen, dann kann sowas nicht passieren.

Weiterhin sollte man solche Meldungen (die nicht "ein weiteres Problem" sondern die eigentliche Hauptursache sind) bereits in das erste Posting mit reinschreiben, das vereinfacht eine Hilfe von aussen sehr.

Für Mitleser: Durch Updates von Plugins oder von WordPress selbst wird eine Datei header.php im Theme nicht überschrieben. Offenbar lief also noch was anderes schief..

Möglichkeit 1: Befrage den jeweiligen Plugin-Autor bzw. -Support.
Möglichkeit 2: Mache einen Code-Review jedes Plugins.

Seit WordPress 4.9.6 gibt es für Plugins theoretisch eine Schnittstelle, wo sie Vorschläge für eine Datenschutzerklärung zur Verfügung stellen können, dazu den Abruf der gespeicherten Daten und das Löschen oder Anonymisieren der gespeicherten Daten. Da es WordPress 4.9.6 aber erst seit ein paar Tagen gibt, dürfte das von die allermeisten Plugins noch nicht genutzt werden.

Zitat von Raphael

Daher habe ich im Header der Seite eine Weiterleitung per php eingerichtet. Könnte die PHP-Weiterleitung das Problem bei Facebook erzeugen?

Höchstwahrscheinlich ja, da so eine Lösung, wie auch immer die aussehen mag, wohl direkte externe Links zu Bilddateien nicht betreffen wird.

Würde eher eine Lösung des Problems bzgl. .htaccess empfehlen, und die Redirects dort machen. Viele Hoster bieten eine für ihre Server passende Lösung auf ihren Support Seiten an, da kann z.B. die RewriteCond schonmal durchaus unterschiedlich sein. Nicht einfach Code-Schnipsel aus dem Netz verwenden...

Auf den ersten Blick könnte im Theme Ordner die Datei header.php fehlen oder defekt sein.

Ändert sich etwas, wenn Du das Plugin JetPack deaktiverst? Das schiebt nämlich derzeit einen Teil der Daten auf externe Server in eine Cloud.

Was erscheint, wenn Du WP_DEBUG aktivierst? Was steht im Server Error-Log?

Ein vollständiges Backup besteht übrigens aus Datenbank und Dateien, nur einen Teil zurückzuspielen, kann unvorhersehbare Effekte haben.

Mit dem Plugin "Better Search Replace" kann man in der Datenbank alte Bildpfade suchen und durch neue Bildpfade ersetzen.

Am besten macht man vorher aber ein Backup der Datenbank.

Am Rande, in der Datenbank irgendwas wie "Bildpfade" einfach zu löschen, ist eher nicht ratsam.

Mit Link zur entspr. Seite könnte man ggf. genauer sagen, wo Du suchen musst, ob in Datenbank oder z.B. in einer CSS- oder PHP-Datei o.ä.

Falls Du die Bereiche ganz unten auf der Seite meinst, die Inhalte dort ändert man über das Menü "Design > Customizer > Allgemeine Einstellungen > Footer" und man kann dort als Absatztrenner ein [FONT=Courier New]<br />[/FONT] einfügen.

Hier erscheint sie, evtl. bist Du in WordPress angemeldet o.ä., melde dich mal ab oder lade die Seite in einem "privaten Fenster" im Browser.

Dein Theme bastelt das Kommentarformular zum Grossteil selbst, anstelle die dafür vorgesehenen WordPress Funktionen sauber zu nutzen. Daher können sich diese Plugins dort nicht "reinhängen".

Die Startseite kommt aus WP Super Cache, alle restlichen Seiten geben nur ein UTF-8 BOM aus, die Login-Seite weisst auf Cookie-Sperre wg. bereits erfolgter Ausgaben hin. Das lässt darauf schliessen, dass höchstwahrscheinlich die Datei wp-config.php mit einem unpassenden Editor bearbeitet wurde. Mit dem Hosting dürfte es weniger zu tun haben.

Mögliche Lösung: Notepad++ herunterladen, wp-config.php herunterladen, mit Notepad++ öffnen, im Menü Encoding auf OHNE den Zusatz BOM ändern, speichern, hochladen.

Weitere mögliche Lösung, denn offenbar bastelt gerade jemand an der Seite, eines der jetzt aufgetauchten 4 'w' in [plain]https://wwww.finanzen-mit-pl..[/plain] weglassen.

Zitat von Evalo

Das mit dem Entfernen des "weiterlesen..." (also das weiterlesen mit den 3 Punkten dahinter) in den 3 featured-pages auf der Startseite kann doch eigentlich gar nicht funktionieren, da, wie wir gesehen haben, auch jedesmal das weiterlesen... von den Excerpts auf den Kategorieseiten entfernt wird (vor Maxes letztem Post auch samt Texten).

Wenn Du die Voraussetzungen klarer definierst, kann man besser helfen. Von Kategorieseiten war bisher keine Rede.

Und zum Punkt, versuchen, Code-Schnipsel zu verstehen, versuche mal zu verstehen was in dem von Dir gefundenen Code dieser Teil ausgibt:

<?php the_excerpt(); ?>

und was dieser Teil ausgibt:

<a class="more-link" title="<?php the_title_attribute(); ?>" href="<?php the_permalink(); ?>"><?php _e( 'Read more','radiate' ); ?></a>

Lasse testweise mal einen der beiden Teile weg und prüfe das Ergebnis.

Poste mal die Datei comments.php aus Deinem Theme.

Die wp-config.php ist die einzige Core-Datei, die bei einem Update garantiert nie überschrieben wird.

Richtig, das Durchreichen hat noch gefehlt, hatte nicht drauf geachtet, dass hier warum auch immer $text als Eingangsparameter benutzt wird und nicht gleich $excerpt, wie man es sonst machen würde...

Die schliessende geschweifte Klammer hat vor der return... Zeile gefehlt

Off Topic: Ein paar Grundkenntnisse zu WordPress & PHP sollte man haben, wenn man Code-Schnipsel verwenden will. Hat man keine, kann man sich auch ganz schnell böse Sicherheitslücken einhandeln, nicht in diesem Fall, aber alles schon erlebt, blindes Copy & Paste einer Login-Funktion führte zu unerwarteten Ergebnissen...

Es wäre wie beschrieben wohl besser, das Session anlegen vor jeglichen Ausgaben von WordPress bzw. des Themes zu machen, z.B. über die init Action, mehr dazu siehe z.B. Suchmaschinen. Das auslesen usw. kann man dann wohl auch in den Template-Dateien machen.

Oft ist die Fehlermeldung hilfreich. Hier würde ich sagen, es fehlt eine schliessende geschweifte Klammer.