Beiträge von b3317133

Einer auf diese Art und Weise "nachgebesserten" Installation sollte man nicht zu viel Vertrauen entgegenbringen. Evtl. sind noch andere Dinge defekt, die u.U. erst sehr viel später sichtbar werden.

Eine sonst üblichere Variante für das Herunterladen eines WordPress-Websites ist die Nutzung eines Plugins wie Duplicator auf dem Originalserver und das Einspielen des damit erstellten Paketes auf dem Zielserver. Damit werden auch alle nötigen Linkanpassungen automatisch vorgenommen. Video auf der Duplicatorseite einmal ganz anschauen, auch wenn es englisch ist, das erklärt ganz gut das gesamte Vorgehen.

Um das herauszufinden, klickt man mit der rechten Maustaste in so einen Bereich im Frontend, und schaut sich das verwendete CSS im Browser Inspector an.

Ansonsten gibt je nach Bedarf unterschiedliche Lösungen, ein Ansatzpunkt wäre z.B. in etwa so, mehr dazu siehe z.B. hier.

Hat aber alles mit WordPress eher weniger bis gar nichts zu tun, ein CSS-Forum wäre da eine bessere Anlaufstelle.

Zum warum/wieso/weshalb gehackt kann man noch anmerken, dass lt. Google Cache auf der Seite offenbar das Plugin "WP GDPR Compliance" zum Einsatz kam, mehr dazu z.B. hier im Forum oder z.B. bei heise.de

Wie genau werden Bilder bei Beiträgen hinzugefügt? Über ACF-Felder? Oder evtl. über die Galerie- oder Beitragsbild-Funktion von WordPress? Ein Screenshot wäre ggf. sehr aufschlussreich.

Und welche neue WordPress Version genau wird verwendet? Und welche lokal?

Du kannst auch für die Beiträge eine weitere sog. "Taxonomy" anlegen, eine hierarchische (wie Kategorie) oder eine nicht hierarchische (wie Tags).

Dafür gibt es einige Plugins wie z.B. Custom Post Type UI (dort der Bereich "Taxonomies"), die verschiedenen Einstellungen sind z.B. in der WordPress Dokumentation hier oder hier erklärt, alternativ gibt es über Suchmaschinen diverse Tutorials oder Videos zum Thema "Custom Taxonomy".

Die beiden extra Codeblöcke mit [FONT=Courier New]AddOutputFilterByType[/FONT] und [FONT=Courier New]ExpiresByType[/FONT] Einträgen in Deiner [FONT=Courier New].htaccess[/FONT] stammen wahrscheinlich von einem Cache Plugin, dort vom Bereich "Browsercache", und haben mit dem Problem "Login ergibt 404" nichts zu tun.

Vermutlich läuft irgendein "Sicherheits"-Plugin, das evtl. den Login "versteckt" oder sowas und Zugriffe auf [FONT=Courier New]/wp-login.php[/FONT] und [FONT=Courier New]/wp-admin/index.php[/FONT] auf eine 404 Seite weiterleitet. Andere Links im Ordner wie [FONT=Courier New]/wp-admin/upgrade.php[/FONT] funktionieren.

Um herauszufinden, ob/welches Plugin verantwortlich sein könnte: Benenne der Reihe nach per FTP die Ordnernamen innerhalb [FONT=Courier New]/wp-content/plugins/[/FONT] temporär um, das deaktiviert das entspr. Plugin, leere dann Deinen Browser Cache und versuche dann erneut [FONT=Courier New]/wp-login.php[/FONT] aufzurufen.

Evtl. existieren aber auch noch weitere [FONT=Courier New].htaccess[/FONT] in höheren Ordnern, die da evtl. Einfluss nehmen, oder das "managed" WP ist kein Original, sondern irgendwie verbastelt o.ä., das kann man von aussen aber nur vermuten.

Generell, wenn Du was an einer Datei ändern willst, erstelle einfach vorher ein Backup der bestehenden Datei.

Der Website ist definitiv gehackt, siehe z.B. auch hier.

Passieren kann das durch vielerlei Dinge, ein mögliches Einfallstor bei Dir ist die veraltete Version 1.4.2 des Plugins "WP GDPR Compliance", mehr dazu z.B. hier im Forum oder z.B. bei heise.de

Das allgemeine Vorgehen bei einem Hack ist z.B. hier beschrieben.

Für professionelle Hilfe kann man z.B. eine Anfrage in der Jobbörse hier im Forum stellen.

Die Eingabe bei "Suchen und Bieten" ist über ein einfaches Formular mit dem "Ninja Forms" Plugin gelöst, die Anzeigen selbst werden offenbar manuell über den "Visual Composer / WPBakery Page Builder" in die Seite eingefügt.

Die Funktion [FONT=Courier New]the_title()[/FONT] ist für Nutzung innerhalb der sog. WordPress "Loop" gedacht und funktioniert auch nur dort, mehr dazu siehe hier. Ausserhalb der "Loop" in Widgets usw. ist je nach Rahmenbedingungen ein anderes Vorgehen nötig.

Zitat von irulik

- Den letzten Punkt kann ich nicht beantworten, den ich weiß nicht was damit gemeint ist.

Würde wie schon andere hier ggf. die Jobbörse im Forum empfehlen, um das ganze sauber von einem Profi aufräumen zu lassen.

Die bisherigen Angaben, keine Logfiles, offenbar kaum technische Erfahrung mit WordPress, SSL usw. deuten darauf hin, dass dieses Problem im Rahmen dieses Threads sehr schwer bis kaum lösbar sein wird.

@SEpp55 War evtl. zu unklar, hier eine kleine Ergänzung:

.. was eine extra eigene zusätzliche DS Erklärung auf der Maintenance Seite erfordern könnte...

Zitat von KorneliaD

(zur Zeit Maintenance on, weil DS Erklärung noch in Arbeit)

Tipp am Rande: Dein Maintenance-Plugin bindet einen externen "Open Sans" Google Webfont ein, das sendet die Besucher IP-Adresse an Google, was eine DS Erklärung auf der Maintenance Seite erfordern könnte...

Markiere den ganzen Text im Editor und klicke dann im Editor-Toolbar in der unteren Zeile das Symbol für "Formatierung löschen", sieht aus wie ein Radiergummi, ein schräg gestelltes Rechteck, dann sollte die Formatierung verschwinden.

Das geht mit [FONT=Courier New]setTimeout(..)[/FONT], wenn man z.B. bei Google nach javascript verzögerung einbauen sucht, findet man einige Seiten, die das ausführlich besprechen, z.B. diese hier.

Mit WordPress oder dem Contact Form 7 hat das aber eher nur am Rande zu tun.

Strato teilt derzeit auf der Loginseite folgendes mit:

Zitat

Einschränkungen bei der Erreichbarkeit von Websites

Sehr geehrte STRATO Kunden,

aufgrund von DDos-Angriffen kommt es aktuell dazu, dass einige Websites per SSL kurzzeitig nur eingeschränkt erreichbar sind.
Unsere Sicherheitsmechanismen greifen und wehren solche Angriffe ab. Die Einschränkung hat keinen Einfluss auf die Unversehrtheit Ihrer Daten.

Wir bedauern eventuelle Unannehmlichkeiten.

Viele Grüße
Ihr STRATO Team

1. Normale html Seiten gehen z.B. /readme.html
2. Echte Pfade gehen, z.B. /wp-admin/upgrade.php
3. Die REST-API geht via plain Permalinks, z.B. /?rest_route=/ oder /?rest_route=/wp/v2/posts
4. Allerdings geht nicht /?rest_route=/wp/v2/pages - das ergibt einen PHP Fatal Error Uncaught ImagickException: Failed to allocate quantum_info ... in der Datei wp-content/themes/thegem/inc/image-generator/image-editor.class.php - das ist seltsam und wäre schonmal ein Rechercheansatz für den Theme Hersteller, hier ein ähnlicher Report. Der Fehler sollte auch im Server error.log sichtbar sein, ein Ansatz für den Provider.
   
5. Pretty bestehende Permalinks gehen nicht, Error 500, z.B. /referenzen/
   
6. 404-Seite mit pretty Permalinks geht nicht, Error 500, z.B. /aslödfkjalfjsldfkjksdlfj/
7. 404-Seite mit plain Permalinks geht, z.B. /?p=1

Fragen:

• Was steht in der Datei .htaccess ?
• Was ist im Backend bei Permalinks eingestellt? Plain, oder?
• Ändert sich das Verhalten bei 4., 5. und 6., wenn der Ordner [FONT=Courier New]wp-content/plugins[/FONT] temporär via FTP kurz mal auf [FONT=Courier New]wp-content/no-plugins[/FONT] umbenannt wird und im Backend pretty Permalinks eingestellt werden?

Zwischenstand: Mit "Port 443" hat das alles eher weniger zu tun. Viel Erfolg bei der Lösung.

Kann ähnliche Probleme mit einem Strato SSL Zertifikat an anderer Stelle bestätigen.

@Kati28 Daher eher kein Hack.

Siehe auch ähnliche Meldungen bei Twitter bzw. auch allestörungen.de/stoerung/strato

Evtl. wurden Änderungen direkt im Theme vorgenommen?

Änderungen in Theme-Dateien werden bei jedem Theme-Update überschrieben. In WordPress ist dafür die Verwendung eines sog. Child-Theme vorgesehen, dort bleiben die Änderungen bei Updates des "parent" Theme erhalten.

Ausnahme: Wenn ausschliesslich nur CSS-Ergänzungen vorgenommen werden, trägt man diese im Menü "Design > Customizer > Zusätzliches CSS" ein, dort bleiben CSS-Ergänzungen auch bei einem Theme-Update erhalten, so dass in diesem Fall kein Child-Theme nötig ist.

Spiele ein Backup der alten Theme-Version ein, oder notiere die Änderungen aus einem Backup und übertrage diese dann in ein Child-Theme.

Seltsam, es sind gar keine Scriptschnipsel nötig.

Wenn alles orange weg ist und alleine nur die ganz normale WordPress Einstellung [FONT=Courier New]define('WP_DEBUG', false);[/FONT] benutzt wird, und trotzdem Warnings auftreten, liegt es ggf. an anderen Voreinstellungen des Servers o.ä.

Alternativ kannst Du den ursächlichen, bereits oben verlinkten Fehler in WooCommerce ggf. manuell beheben, bevor ein neues Update rauskommt.

Zitat von itsmejay

Er sucht das Feld "your-name" und ließt die gesamte var $result aus.

Für Mitleser, es ist umgekehrt, das JavaScript sucht im Browser auf der Seite das Feld "your-name" und schreibt dort die dem Script mitgegebene PHP Variable $result rein.

Um eine PHP-Variable, die erst während der Ausgabe eines Seitentemplates ermittelt wird, serverseitig einem Feld eines CF7-Formulars "mitzugeben", muss der CF7-Shortcode erst nach dem Ermitteln der PHP-Variable ausgegeben werden und man muss zusätzlich das entspr. Attribut registrieren, dann geht sowas wie das hier, ungetestet [FONT=Courier New]<?php echo do_shortcode( '[contact-form-7 ... your-name="' . $result . '"]' ); ?>[/FONT]

Die Voraussetzungen sind aber in diesem Fall nicht gegeben, es wurde z.B. gesagt, das CF7 Formular wäre in einem Widget o.ä., daher ist das hinfällig.