Beiträge von b3317133

Das "Sticky Editor" Plugin ist für das Backend und macht was komplett anderes, zudem:

Zitat

Dieses Plugin wurde seit mehr als 2 Jahren nicht akualisiert! Es könnte daher nicht mehr unterstützt werden und ebenso Kompatibilitätsprobleme bereiten, wenn es mit aktuellen WordPress-Versionen eingesetzt wird.
...
Kompatibel bis: 3.9.15
Zuletzt aktualisiert: vor 3 Jahren

"Dateifilter aktivieren" = "Enable File Filters"

Darüber kannst Du dann Deine Riesendatenmenge begrenzen, so dass ein Duplicator-Paket in vernünftiger Grösse erzeugt werden kann.

Das Nonce-System von WordPress dient hauptsächlich zur Abwehr von CSRF-Angriffen. Wenn man das System (wie oder warum auch immer) absichtlich aushebelt, sollte man genau wissen was man tut. Viel Erfolg mit dem Projekt.

Dein Duplicator-Paket wäre lt. Screenshot 1.39 GB gross, das ist sehr viel und wird wohl fast jeden Server in die Knie zwingen.

Würde beim Erzeugen des Duplicator-Pakets mal unter "Archive" den Dateifilter aktivieren und entspr. Verzeichnisse oder Dateien per Datei-Erweiterung (zip o.ä.) ausschliessen.

Warum wird das mehrfach ausgegeben?

Jedes Formular bekommt normalerweise seine eigene Nonce. Beispiele im Codex, dort wird jeweils die entspr. ID angehängt.

Ein Error oder eine Warnung von PHP wird im laufenden Live-Betrieb bei entspr. Konfiguration von WP_DEBUG nicht ausgegeben.

Welches "invalide HTML" genau wird denn erzeugt bzw. von welchem HTML-Validator als solches bezeichnet? Ein Link zum Formular wäre hilfreich.

In dem Fall z.B. ganz zu Beginn von header.php eine entspr. Zeile PHP einfügen, Beispiel hier.

Der "Codeschnippsel" wird nur i.v.m. dem restlichen Code des verlinkten Beispiels funktionieren und wird als Plugin oder in die functions.php des verwendeten Themes eingebunden.

Keine Ahnung was hier die Ursache sein kann, nur eine Anmerkung am Rande:

Bei einem Strato-Account hier im Umfeld hatte sich im letzten Jahr irgendwann "spontan" der interne absolute Pfad geändert, was dazu geführt hat, dass z.B. BackWPUp keine Backups mehr gespeichert hat, weil es den absoluten Pfad nutzen wollte.

Zwischen Plugin löschen und neu installieren könnte man also mal in die DB in die Tabelle wp_options schauen, ob dort ein ggf. veralteter absoluter Pfad "überlebt" weil das Plugin seine Einstellungen nicht löscht.

Alte Anleitungen zu PHP-/WordPress-Hardening bei "Shared Hosting" empfehlen wegen der beinhalteten Datenbank-Zugangsdaten das Auslagern von wp-config.php u.ä. aus dem "public_html" Ordner des Users, da dieser bzw. die Config-Datei von anderen Usern auf dem gleichen Server per PHP lesbar war.

Diese Problematik dürfte aktuelle Server-Installationen nicht (mehr) betreffen, ggf. kann ein Hosting-Anbieter da noch Details ergänzen.

Würde ein sog. Child Theme anlegen und darüber dann die entspr. Template-Datei für die Startseite mit Anpassungen versehen. Je nach Theme ist der entspr. Code in unterschiedliche Dateien hinterlegt.

Diese Möglichkeit ist abhängig vom Theme und bei Rowling (auf den ersten Blick) nicht vorgesehen.

Im Firefox about:addons in die URL-Zeile eingeben dann siehst Du alle Add-Ons und entspr. recherchieren, welches davon der Übeltäter ist.

Wahlweise mal die kostenlose Version von Malwarebytes runterladen und scannen lassen, in solchen Fällen ist erfahungsgemäss nicht nur ein Add-On ungewollt im System unterwegs.

Mit FTP hat das erstmal nichts zu tun.

Liegt (allerhöchstwahrscheinlich) an einem Firefox-Add-On und hat nichts mit WordPress zu tun.

Die Anzahl Links im Kommentar-Text lässt sich über die Diskussions-Einstellungen abfangen ("in Warteschlange schieben wenn X oder mehr Links").

Den Homepage-Link kann man z.B. via pre_comment_approved Filter prüfen und den Kommentar entspr. auf "Pending" setzen, falls nötig.

Anhand des Beispiels dort in etwa so:

...
   // inspect $commentdata to determine approval, disapproval, or spam status
    $approved = ( !empty( $commentdata['comment_author_url'] ) ) ? 0 : $approved;
    return $approved;
...

Sobald das Feld ''comment_author_url' vorhanden und befüllt ist, wird auf "Pending" gesetzt, ansonsten wird nichts verändert.

Verantwortlich für die Grösse ist die [FONT=courier new]78[/FONT] in der Datei [FONT=courier new]functions.php[/FONT] des Parent Themes "Stargazer":

// Adds custom logo support
    add_theme_support(
        'custom-logo',
        array(
            'height'     => 78,
            'flex-width' => true
        )
    );

Auf Anhieb fällt mir dafür kein WordPress Filter ein, kann aber durchaus sein, dass es da was gibt, Customizer-Freunde an die Front...

Würde in dem Fall den Theme Autor oder im Theme Support Forum fragen.

Bei entspr. PHP-Kompetenz auch selbst den Code studieren. Da es sich bei dem Theme bereits um ein Child Theme handelt, gehen Code-Anpassungen allerdings bei Updates verloren sofern man sie nicht als Plugin lösen kann.

Die verlinkte Logo-Datei ist derzeit native 185x78 Pixel gross (habe mir den Website von Mats per Google mal angesehen). Ein einfaches "Grossziehen" per CSS macht das Logo daher unscharf. Evtl. wird diese Grössenbegrenzung vom Theme vorgenommen? Denke, das ist gemeint.