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 erstellenZuerst 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.
Bei den meisten Themes hilft auch ein Blick in den HTML-Quellcode und dort in die classes im body-Tag, z.B. hier wäre es der ID 45:
<body class="archive category category-katzenbilder category-45 ..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:
Warum geht´s mit Loco Translate nicht?
Einfacher als damit kann man es eigentlich nicht haben.
Warum ein extra Plugin (das dauerhaft Resourcen verbraucht) für eine ohnehin vorhandene Funktionalität von WordPress (für die eine Datei nur einmal eingepflegt werden muss) verwenden?
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.
Deine Dateien bekommen doch davon gar nichts mit.
Ausser z.B. ein sagen wir mal in einem "unüberlegten Moment gebasteltes" PHP-Script liest/schreibt andere Dateien mit vollem Pfad im Code à la[FONT=courier new] /var/whatever/home/www/my-first-php/mein-supi-counter-data-1.txt[/FONT] o.ä.
