Das eine sieht nach einer angepassten Installation von WordPress.com aus (Support gibts bei WordPress.com) und das andere nach einer eigene Installation von WordPress.org (Support gibts auf freiwilliger Basis u.a. hier), hier die Unterschiede.
Beiträge von b3317133
-
-
Sieht nach klassischem Spam-Account aus...
-
WordPress Core Funktionen kann man bis auf einige "pluggable" Ausnahmen in einem Theme oder Child-Theme nicht überschreiben.
Änderungen im Core sind sehr unüblich, daher habe ich Deine Änderung auch wg. Verweis auf ein mittlerweile angelegtes Child-Theme auf ein Theme bezogen.
Um Parameter oder Ausgaben von Core-Funktionen zu ändern, gibt es stattdessen viele sog. "Filter", in diesem Fall den get_search_form Filter, hier ein kleines Beispiel dazu mit viel erklärendem Kommentar.
-
Hast Du das nicht schon 2 mal gefragt, z.B. hier?
-
@b3317133.. was wiederum heißt, ich kann deine Methode so nicht umsetzen.
Wenn man alle Dateien in einen neuen Ordner kopiert, die Datenbank in eine neue Datenbank kopiert, dann den Plesk-WordPress-kram löscht, die Domain auf den neuen Ordner setzte und die Datei wp-config.php dort auf die neue Datenbank anpasst, wäre man diese Plesk-Probleme los und könnte Dein eigentliches Problem wie beschrieben lösen.
Wenn man denn wollen würde. Wie gesagt, viel Erfolg. Bin hier raus.
-
Um welches Theme handelt es sich denn? Das Vorgehen und die Möglichkeiten sind je nach Theme unterschiedlich.
-
Schau mal in die Dokumentation des Plugins unter FAQ bei "How do I change the output template".
Dort steht, wie man die mitgelieferte Template-Datei verwendet oder eine eigene als Parameter im Shortcode angibt. Grundlegende PHP-Kenntnisse sind dabei Voraussetzung.
-
Was genau spricht gegen Plesk?
z.B. das:Wenn Wordpress über Plesk installiert wurde kann das Basisverzeichnis nicht mehr geändert werden.
Wie gesagt, viel Erfolg.Bei Problemen wende Dich dann bitte am besten an ein Plesk-Forum.
-
PHP 7.1.x mit MySQL 5.6.x sollte inzwischen (bis auf ältere Themes & Plugins) kein Problem sein.
PHP 7.2 verursacht lt. diversem Feedback hier im Umfeld mit vielen auch aktuelleren Themes & Plugins noch Probleme, ebenso MySQL 5.7. Der WordPress Core selbst hat wie von @SirEctor bereits angemerkt, keine Probleme mit PHP 7.2.
-
WordPress hat einen eigenen integrierten "Shortener", evtl. reicht der ja schon, schau mal in den HTML-Quelltext Deiner Seiten, da sollte sich sowas wie [FONT=Courier New][plain]<link rel='shortlink' href='https://example.com/?p=12' />[/plain][/FONT] o.ä. finden, und der da angegebene Link leitet dann auf die jeweilige Seite weiter.
-
Warum hast Du dieses Häckchen gemacht? Warum benutzt Du Autoptimize? Warum WP Super Cache? Sind Dir die möglichen Wechselwirkungen bekannt? Hast Du die Dokumentation beider Plugins gelesen und v.a. verstanden? Das wäre sehr viel wichtiger, als externen Scannerdiensten irgendwas zu glauben.
Deine Seite funktioniert auch ohne diese beiden Plugins und ggf. noch weiteren, die aus welchen Gründen auch immer genutzt werden, sicherlich einwandfrei.
Abschliessend: "Gesamten CSS-Code Inline einfügen" ist die hauptsächliche Antwort auf Deine Frage, warum Du das besagte Content Code Ratio hast.
-
..erhalte ich eine Content Code Ratio von nur 3% und eine Seitengröße von 104 kb !!!
Wie kann das sein? Was verursacht bei mir soviel Non-Text-Code und wie kann ich dieses Manko beheben?Du benutzt eine Funktion in einem Cache-Plugin und/oder einen anderen Mechanismus, der sehr viel CSS-Code direkt mit in die Seite packt, anstelle es als eigene Datei zu laden.
Frage am besten den, der die Plugins "Autoptimize" und "WP Super Cache" und ggf. weitere ähnliche "Optimierung" Plugins konfiguriert hat, denn Dinge wie CSS-Code inline einfügen sind da normalerweise nicht standardmässig aktiviert.
Und schau Dir einfach den Quelltext Deiner Seite direkt an, Seite laden, rechte Maustaste -> Seitenquelltext anzeigen oder z.B. Tastenkombi Strg-U, dann siehst Du das direkt und musst nicht an Zahlen irgendwelcher externen Scannerdienste glauben..
-
Im IIS hat sich eine Einstellung geändert, vermutlich aufgrund eines Wordpress-Sicherheits-Updates von Plesk.
Zu viele Vermutungen -> Providerwechsel überlegen.
-
Bei den WordPress Custom Fields wird meta_key mit meta_value anhand meta_compare verglichen. Das betrifft die Tabelle wp_postmeta.
Wenn Du eine andere, eigene Tabelle mit in die Abfrage einbeziehen willst, gibt es dafür den o.g. posts_where Filter.
Entweder man kombiniert nun beide Ansätze, oder man setzt alle Bedingungen in den posts_where Filter.
Also Doku lesen, testen, basteln, wenn es dann zu dem von Dir entwickelten Code Fragen gibt, diese inkl. Code gern hier stellen. Falls gar keine Programmierkenntnisse vorhanden sind, gibt es noch die Jobbörse hier im Forum.
-
Mein Provider sagte mir folgendes:
Es wird vermutete das sich im IIS eine Einstellung aufgrund eines Wordpress-Sicherheits-Updates von Plesk geändert hat.Wenn er da was vermuten muss, sollte man ggf. überlegen, zu einem Provider zu wechseln, der weiss, was seine Server so machen...
-
Könnte daran liegen, dass in #20 der gesamte Code steht und in den neueren Versionen schon auf den ersten Blick mindestens der Teil [FONT=Courier New]<?php foreach (get_categories() as $cat) : ?>[/FONT] fehlt...
Dieses Forum bietet hauptsächlich Hilfe zur Selbsthilfe, etwas eigenes Mitdenken ist durchaus beabsichtigt.
-
Der Code funktioniert so. In welcher PHP-Datei steht er denn? Und was steht noch in der PHP-Date?
-
Poste doch mal Deinen Code, so wie er aussieht, wenn Du das 2. endforeach weglässt und die Fehlermeldung bekommst, und zwar den gesamten Code der PHP-Datei.
-
-
Die Lösung steht eigentlich schon in Antwort #24, post doch mal Deinen Code, wenn Du das 2. endforeach weglässt.