Was genau hast Du denn wo gelesen bzgl. header.php?
Alternativ könntest Du den Support des Themes befragen.
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenWas genau hast Du denn wo gelesen bzgl. header.php?
Alternativ könntest Du den Support des Themes befragen.
Zuerst eine dumme Fragen stellen...
Finde die Frage an sich nicht dumm, das Folgeverhalten allerdings ziemlich unglücklich.
So eine Migration kommt öfters mal vor und ist (wie kurz beschrieben) auch durchaus ohne Passwort-Wechsel für die User lösbar.
Man könnte z.B. einfach wp_check_password() mit einer eigenen Funktion ersetzen, die das Passwort einmal anhand des alten PHP-Code/Hash/whatever des SMF-Forums vergleicht (paar Zeilen Code von dort sollten genügen) und dann ggf. noch nach WordPress-Standard. Wahlweise kann man sich auch zu einem ähnlichen Zweck in den check_password Filter einklinken.
In die DB kann man die User mit diesem Ansatz mit dem alten, bestehenden Hash einpflegen.
Für den User ist es beim Login so nicht erstichtlich und auch nicht relevant, ob intern der alte oder aktuelle Password-Mechanismus verwendet wird, beides führt zum Ziel.
WordPress macht sowas ähnliches intern je nachdem ob noch (ganz) alte MD5-Hashes verwendet werden oder der aktuelle Standard.
Wenn man pro Fahrgestellnummer einen eigenen Link hat, kann man das z.B. wie folgt lösen:
1. Code-Beispiele zum Auslesen/Sortieren nach ACF-Datumsfeld gibt es z.B. in der ACF-Dokumentation zu Date Picker.
2. Eine Kachelgrösse könntest Du auch als ACF-Feld hinterlegen.
Vorgehensweise wie man sich in die Suche einklinken kann z.B. hier: Search WordPress by Custom Fields without a Plugin
Dabei in Deinem Fall ganz wichtig da "User-Input" aus dem Formular, die Variablen gegen SQL-Injection schützen...
Dank der unvollständigen "meine-seite Zensur" ergibt sich beim Nachvollziehen auf der echten Seite, dass der Sitemap-Index offenbar erzeugt wird
http://deine-seite.de/blog_dein_shop/sitemap.xml -> OK
und die Links dort zwar vermeintlich richtig angezeigt werden
http://www.deine-seite.de/blog_dein_shop/sitemap-misc.xml
aber dann tatsächlich falsch hinterlegt sind:
https://translate.wordpress.org/projects/wp-th…c-one/de/formal
-> unten "export" Link
Wahlweise diesen Blogbeitrag lesen: "Übersetzung eines WordPress Themes – Iconic One in Deutsch"
https://www.station9111.de/2016/04/18/ueb…one-in-deutsch/
Beides ungetestet...
Evtl. handelt es sich um einen Fehler im Theme?
Du könntest z.B. den Theme-Autor fragen: https://wordpress.org/support/topic/for-support-15/
Hast Du die Testversion denn überhaupt schon ausprobiert?
Alternativen gibt es u.a. hier.
Scheint u.a. ein Feature der "Pro" Version zu sein (wenn "Gallery" anhand der dürftigen Angaben das richtige Plugin sein sollte).
Ist im heruntergeladenen profile.php der entspr. php-Code?
<?php
/**
* User Profile Administration Screen.
*
* @package WordPress
* @subpackage Administration
*/
...
Dann ist die Serverkonfiguration defekt.
Ist im heruntergeladenen profile.php eine anderweitige Fehlermeldung? Dann lesen und beheben bzw. hier posten.
Zuschneiden könnte man, verkleinern ist nicht nötig. Im Code ist ein srcset angegeben so dass der jeweilige Browser sich je nach Bedarf das entspr. passende Logo holt, v.a. auch auf hochauflösenden "Retina" Geräten.
Meist fehlt (aus den unterschiedlichsten Gründen) einfach nur das [FONT=courier new]height: auto;[/FONT]
Oft hilft: Mit Firefox die entspr. Seite aufrufen, dann rechte Maustaste auf eine leere Stelle z.B. am Rand und "Seitenquelltext anzeigen" anwählen, dann erscheint der HTML Quellcode und solche Fehler sind rot markiert.
OT und gleichzeitig als Beispiel: Wenn man das bei dieser Seite hier im Forum macht, wird ein [FONT=courier new][COLOR=#FF0000]</div>[/COLOR][/FONT] in Zeile 302 unterhalb Google Analytics als "verirrtes End-Tag div" entspr. markiert.