Martin999
Verfasste Forenbeiträge
-
Forum: Allgemeine Fragen
Als Antwort auf: Umstellung auf https/SSL, was alles tun in WordPress?Dann sollte man vielleicht besser sagen, dass und warum es wie beschrieben gemacht werden muss, weil ich manuell nie serialisierte Daten miterwische (falls das offenbar so ist). Und dann ist es beantwortet und erledigt.
Wenn eine ganz normale und durchaus nicht abwegige, extra begründete Nachfrage nach einer manuellen Alternative mit „aus irgendwelchen Gründen nicht gefallen“ kommentiert wird, klingt das schon unfreundlich gemeint. Ich habe den Grund genannt, der ist auch nachvollziehbar und wie bei GNTM mir den „schönsten“ Weg aus mehreren aussuchen tue ich schließlich auch nicht.
„Viel Erfolg“ hinterher klingt dann nicht wirklich nach ernst gemeintem Erfolgswunsch, sondern vermutlich ironisch gemeint, zumal wenn man weiß, dass es wirklich nur so geht (serialisierte Daten?). Klingt nach „probier es ruhig manuell, wirst schon sehen, was du davon hast“.
Vielleicht einfach mal versuchen, meine Brille aufzusetzen?
- Diese Antwort wurde geändert vor 4 Jahren von Martin999.
Forum: Allgemeine Fragen
Als Antwort auf: Umstellung auf https/SSL, was alles tun in WordPress?Ich hab dir ausführlich erklärt, was du aus meiner Sicht ändern musst. Wenn du meinst, dass dir das aus irgendwelchen Gründen nicht gefällt, kannst du es für dich anders machen, kein Problem. Viel Erfolg dabei.
Was soll das?
Es geht nicht um das „Was“, sondern das „Wie“.Ich habe begründet, warum ich wahrscheinlich manuell sowieso in den Code rein muss/will und dass das wegen der wenigen Seiten auch kein Problem ist. Von „aus irgendwelchen Gründen nicht gefallen“ kann also keine Rede sein.
Zum anderen, es gibt oft mehrere Wege, die nach Rom führen und wenn jemand eine andere Option anfrägt, ist das kein Grund, deswegen beleidigt zu sein.
Kann auch gute Gründe geben, warum man nicht per Plugin in der DB was ändern will, ganz abgesehen von dem Umstand bei mir, dass es nur ein paar Seiten sind.
Wenn du schlechte Laune hast oder schlicht keine Lust zu antworten, ist das o.k., dann lass es einfach.
Forum: Allgemeine Fragen
Als Antwort auf: Umstellung auf https/SSL, was alles tun in WordPress?Ein Artikel speichert die offenbar durch die General Settings bereits bei den Permalinks erzeugten https-URLs nur noch mal ab.
Ein anderer Artikel ändert es offenbar in der Datenbank (wenn ich es richtig verstanden habe).Ich verstehe nicht, was du meinst.
Siehe https://www.blogmojo.de/wordpress-auf-https-umstellen/ , die Grafik unter 3.
Da steht nach Änderung der General Settings dann überall https in den Permalink-Optionen und links unten wird ganz normal noch mal abgespeichert.…reicht es, wenn du im Plugin Better Search Replace eingibst, dass http://example mit https://example ersetzt werden soll. Es geht nur um die ersten Zeichen deiner Domain – du willst keine externen Links anpassen!
Verstehe. Nur mit der Domain vorne erwische ich alles, egal, was in der Zeichenkette danach noch kommt und gleichzeitig keine anderen Domains, die so bleiben sollen.
Es ist eine recht kleine Site mit nur wenigen pages und in den Quellcode der pages muss ich eh reingehen um etwas manuell auf https zu ändern (wegen third-party content).
Könnte ich anstelle der DB-Änderung die Bilder-URLs auch durch
– einfaches „Suchen und ersetzen“ direkt im Quellcode (HTML-Mode der Seite) oder
– durch Änderung der URLs in der Mediathek (alle Bilder dort ein mal durchgehen)
ändern?- Diese Antwort wurde geändert vor 4 Jahren von Martin999.
Forum: Allgemeine Fragen
Als Antwort auf: Umstellung auf https/SSL, was alles tun in WordPress?Wie machst du das?
Permalinks gibt eigentlich den Teil der URL an, über den die Beiträge und Seiten Permanent verlinkt sind, also bei https://example.com/ueber-uns der Teil ueber-uns, den du mit /%postname%/ abrufst. Hat mit https wenig nichts zu tun.
Ein Artikel speichert die offenbar durch die General Settings bereits bei den Permalinks erzeugten https-URLs nur noch mal ab.
Ein anderer Artikel ändert es offenbar in der Datenbank (wenn ich es richtig verstanden habe).In der wp-config eine Zeile einfügen:
define(‚FORCE_SSL_ADMIN‘, true);Damit stellst du nicht auf verschlüsselte Übertragung um, sondern erzwingst, dass die Anmeldung im Backend nur über eine verschlüsselte Verbindung erfolgen soll. Sinnvoll, weil dann keiner deine Zugangsdaten mitlesen kann, während du im Burger-Restaurant gerade deine WordPress-Updates machst.
Dann heißt das im Umkehrschluss, ich könnte mich mit http einloggen, auch wenn sonst alles auf https umgestellt ist?
Was du vergessen hast: Die Mediendateien werden in der Datenbank mit absoluten URLs eingetragen. Rufst du nun deine Webseite per https://… auf, sind das „unsichere Inhalte“, die gar nicht erst mit angezeigt werden. Du solltest also noch mit einem Plugin in allen Tabellen http://example mit https://example ersetzen (achte darauf, keine Tippfehler zu machen, das ist sonst mühsam zu korrigieren).
Hm, das wird bei einigen der Artikel wahrscheinlich in der DB-Aktion mit dabei sein, aber explizit erwähnt hat das keiner.
http://example klingt aber nicht nach Bilder-URLs. Bilder sind doch in dem uploads-Ordner und haben eine entsprechende URL?Vorher ein SSL-Zertifikat vom Webhoster einrichten zu lassen und nochmal vorsichtshalber ein Backup zu machen kann auch nicht schaden.
Schon klar. Die Frage betrifft nur die WP-Änderungen. Die 301 fehlt ebenfalls noch und die neue property in der SC, auch die functions, htaccess, robots sollte man anschauen, wo evtl. noch ein http vorkommt. Das wird häufig vergessen.
- Diese Antwort wurde geändert vor 4 Jahren von Martin999.
Forum: Allgemeine Fragen
Als Antwort auf: Aktuelles Tutorial zum Einfügen von BildernIch verstehe nicht, was du damit meinst. Das Layout einer Seite auf eine andere Seite zu übertragen ist nicht kompliziert.
Ach ja? Ich kann mich wie gesagt nur auf die Auskunft in Englisch berufen, die ich nachvollziehen kann und kenne Gutenberg zu wenig. Beim Theme läuft es so, dass ich das Layout ein Mal erstelle, unabhängig von einer Seite, einen Namen für das Layout vergebe und jeder Seite dieses Layout mit einem Klick zuordne. Das ganze Layout kann man dann auch kopieren und ändern ect.
Ich versuche rauszufinden, was für mich eher in Frage kommt für die nähere Zukunft:
– Classic Editor PluginDer empfiehlt sich da, wo Webseiten fix und fertig eingerichtet sind und die BenutzerInnen wenig flexibel sind etwas dazu zu lernen.
Das stimmt bei mir nicht. Vor schon etlichen Jahren habe ich an zwei Wochenden mir HTML-Kenntnisse selbst angeeignet und so meine erste einfache „statische“ HTML-Site erstellt, noch mit Tabellenstruktur als Layout. kannst du dich an sowas noch erinnern? Seitdem habe ich unzählige Stunden dazu gelernt. Aber ich komme beruflich aus einer ganz anderen Ecke und kann mich immer nur phasenweise intensiver mit WP, SEO oder dem Schreiben neuer Seiten beschäftigen.
Durch die ständigen Veränderungen gibt es ohnehin immer etwas dazu zu lernen. Sei es von WP, dem Theme oder von anderen Quellen her.
Wäre ich so unflexibel, hätte ich wegen Gutenberg als Themeersatz gar nicht erst gefragt und wäre nicht auf die Idee gekommen.
Wieso nur „etwas Gutenberg“?
Ja genau, mein Arbeitsflow, bei dem ich halt den fertigen Code in den HTML-Mode reinkopiere und das Layout/Design mit dem Theme mache.
Die Verwaltung von Medien läuft über die Mediathek, die sich nicht wesentlich geändert hat. Das Einfügen von Medien aus der Mediathek oder der direkte Upload von Bildern in Beiträge und Seiten hat sich geändert, sollte aber intuitiv zu bedienen sein.
O.K., also die Mediathek als solche bleibt gleich, aber speziell das Einfügen von Medien läuft anders.
Bei der „Fibel“ habe ich dazu nur das gefunden:
https://gutenberg-fibel.de/bloecke/bild/Wenn ich Zeit habe und auf Gutenberg umgestellt, werde ich mal eine Seite kopieren und versuchen mit Gutenberg nachzubauen.
Forum: Allgemeine Fragen
Als Antwort auf: Aktuelles Tutorial zum Einfügen von BildernWieso Käfig? So ein Theme ist doch flexibler als das Gutenberg-Modell. Was ist an der in Englisch gegebenen Erklärung nicht korrekt? Klar kann ich Blocks wiederverwenden, aber man muss das Layout immer wieder neu machen, auch wenn es dasselbe ist. Oder habe ich Gutenberg falsch verstanden?
Ist denn dein Problem gelöst? Oder wo benötigst du noch Hilfe?
Es geht mir um das ganze Einfügen und Bearbeiten von Medien als Teil meines Arbeitsprozesses, der so aussieht, dass ich den ganzen HTML-Code in den HTML-Mode eines Editors einfüge.
Ich versuche rauszufinden, was für mich eher in Frage kommt für die nähere Zukunft:
– Classic Editor Plugin
– „Etwas Gutenberg“ in Form des Classic Blocks, wo man ebenfalls einen HTML-Mode hat und im Grunde alles wie vorher ist. Nur eben der Umgang mit Medien teilweise nicht (Upload und Vergeben der properties). Wenn alle Möglichkeiten (nur etwas anders) gegeben sind, hätte ich die Wahl.Forum: Allgemeine Fragen
Als Antwort auf: Aktuelles Tutorial zum Einfügen von BildernDer neue Block-Editor bietet unglaublich viele Möglichkeiten, um in kurzer Zeit zu Webseiten mit ansprechendem Layout zu gelangen. Die Entwicklung in dieser Richtung hat aber erst begonnen. Es wäre schade, wenn du da den Anschluss verpasst, weil dein Theme bereits „die Möglichkeiten des Layouts“ (vermutlich mit einem mehr oder weniger proprietären Page-Builder?) bietet. Aber das ist natürlich deine Entscheidung.
Ich habe tasächlich schon daran gedacht, dass Gutenberg mein Theme eines Tages ersetzen könnte. Neben den vielen Baustellen, die Gutenberg noch immer hat (angeblich extrem viele Bug Tickets) haben die langjährigen Nutzer des Themes das als recht unwahrscheinlich bezeichnet. Weil es mehr ein Website-Builder denn ein Page-Builder ist.
Die Antwort, die ich bekam:Never. GB and page builders have totally different design philosophies to Blox. They mix content, layout and design. Blox keeps design and layout mostly separate to content. This is a much better model (IMO) and similar in principle to the popular MVC model used in development.
In GB and most page builders, a lot of the content is directly entered into the layout – making reuse of a layout near impossible.
Whereas Blox keeps it separate. You design the layout and tell it where to get the content from. Making layouts easily reusable.
So GB would have to move away from blocks you enter content directly into, to blocks that just say where to get the content from for it to replace Blox.
Forum: Allgemeine Fragen
Als Antwort auf: Aktuelles Tutorial zum Einfügen von BildernEs betrifft auch andere Seiten, z.B.
https://wordpress.org/support/article/edit-media/
https://wordpress.org/support/article/media-library-screen/
https://wordpress.org/support/article/media-add-new-screen/Mir geht’s auch gar nicht um Gutenberg, den ich noch nicht nutze, ich dachte das Hochladen und Festlegen der properties (alt, caption, alignment, size) wäre gleich geblieben und das Verschieben des Alt Textes nach oben (plus Weiteres?) wäre mit und ohne Gutenberg passiert.
„Vielleicht magst du mitmachen und einen neuen Beitrag schreiben?“
Oh, danke für das Vertrauen, aber ich bin nur User und fühle mich dazu wirklich nicht kompetent oder berufen. Wie gesagt, ich nutze noch keinen Gutenberg, kopiere eigentlich immer nur den kompletten HTML-Code einer Seite in den HTML-Mode des Editors und lade dann noch die Bilder hoch. Und frage mich dazu eben unter anderem auch, ob ich zukünftig Gutenberg mit dessen Classic Block oder noch den alten TinyMCE per Classic Editor-Plugin nehmen soll.
Die Möglichkeiten des Layouts wie Gutenberg bietet mir mein Theme.Die Gutenberg-Fibel macht tatsächlich einen guten Eindruck. Wenn es mal soweit ist, werde ich darauf zurückgreifen. Danke für den Link.
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenHallo Torsten,
Da beide überschrieben werden ist das ja gerade keine Lösung. Außer du hast das Theme selbst geschrieben und es wird keine Updates geben, die das Theme überschreiben. Oder du hast ein Child-Theme gebaut und meinst die functions.php deines Child-Themes.
„Lösung“ nicht, aber es ist auch kein sonderliches Problem, wenn header.php/functions.php bei Theme-Updates überschrieben werden. Zumindest bei der functions.php habe ich das fest auf dem Schirm, weil ich dort eh schon ein paar kleine Extracodes drin habe. Vergessen werde ich es also sicher nicht. Und ein wenig Code nach dem Update wieder reinkopieren ist keine große Sache. Oder ich lege mir ein Childtheme zu.
Deswegen wäre mir ja die functions.php lieber als die header.php. Dann konzentriert sich das alles wie bisher nur auf die functions.php.
Ja, das sind Standard-Hooks, die werden sich nicht ändern. Da bauen tausende / abertausende von Themes und Plugins darauf auf …
Sehr gut, genau das wollte ich hören. Dann gehe ich mal davon aus, dass auch das auf mich wartende Gutenberg mit einer dann schon bestehenden custom field/functions.php-Variante problemlos zu Recht kommt. Ich finde die Quelle nicht mehr, aber irgendwo habe ich mal gelesen, dass Gutenberg an den custom fields/Metaboxen und deren Nutzung nichts Relevantes ändern wird.
Wenn dem so ist, dann hätte ich mit der Option custom field/functions.php auf jeden Fall eine für mich gut funktionierende Alternative.
Ob das besser ist, als die von mir zunächst ins Auge gefasste vollmanuelle Methode, also die JSON-LD-script-tags direkt in den Editor einzugeben bzw. reinzukopieren… ist mir noch nicht wirklich klar, weil ich an dieser „Holzmethode“ halt die Unabhängigkeit von Updates jeder Art und das „Techniklose“ recht sympathisch finde.
Abgesehen von dem automatischen „in Absätze packen“ des JSON-LD-Markups durch WP (was sich auch deaktivieren ließe) scheint es zu funktionieren.Grüße,
Martin999
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenDenk daran, dass die functions.php beim nächsten Update des Themes überschrieben wird.
Da ich in der functions.php schon ein paar Kleinigkeiten drin habe, z.B. die Unterdrückung eines Emoji-JavaScriptes und der WP-Version, bin ich mir dessen bewusst. Ich hätte dann alle (bisherigen) „Besonderheiten“ eben nur an dieser einen Stelle, in der functions.php.
Dies und die Tatsache, dass auch eine header.php beim nächsten theme-Update überschrieben wird, sprechen für den hook in der functions.php.Ist so ein Hook in der functions.php mit dem erforderlichen Code in der header.php vergleichbar bezüglich Resourcen, Zukunftssicherheit, Zuverlässigkeit ect.?
Ich vermute, das sind beides recht normale WP-Standardfunktionen, die von Entwicklern beide recht häufig in ähnlicher Form angewendet werden und wohl auch in ein paar Jahren noch so funktionieren würden?
Grüße,
Martin999
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenVerstehe. Dann ist es ja gut, dass ich Admin meiner Sites bin und das wird auch so bleiben. Die von WP zusätzlich vergebenen „<p>“ werden wohl nicht weiter stören.
Grundsätzlich könntest du also wohl auch JSON in Beiträgen/Seiten einfügen. Ob das so sinnvoll und schön ist, ist dann eine andere Frage. Ich halte persönlich eine Eingabe in Custom Fields, die dann im Header oder Footer ausgegeben werden, für die sauberste Lösung.
Die vollmanuelle Editor-Variante hätte vielleicht noch den Vorteil, dass sie zukunftsicher im Hinblick auf Gutenberg ist.
Mit custom fields (und einheitlichem Schlüssel-Namen) das JSON-LD vom eigentlichen Content und auch im Handling sauber zu trennen, finde ich aber auch sympathisch. Ginge die Ausgabe im head oder body anstelle eines Codes in footer.php oder header.php eigentlich auch mit der functions.php auf ähnlich (relativ) einfache Weise? In der functions.php habe ich schon ein paar extra Kleinigkeiten drin, dann hätte ich alle „Extrasachen“ dort an einem Platz.
Google bietet noch eine weitere, nämlich dynamische Variante an, die aber gerade für mich wohl am wenigsten in Frage kommt, da eher technisch anspruchsvoll: „Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets in your content management system.“
Man könnte also nach dem Laden der Seite als Letztes noch per JavaScript den JSON-LD-Code zusätzlich laden lassen.Grüße,
Martin999
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenTags werden im Beitrags-/Seiten-Editor in Character Entities (Zeichen-Umschreibungen, z.B. „& lt;“ statt <) umgewandelt.
Ich habe es mal ausprobiert und der obige Beispiel-Code über US-Präsident Bush ließ sich ohne Umwandlung der Tag-Klammer ganz normal eingeben, speichern und wird im Browser-Code auch unverändert ausgegeben. Mit einer Ausnahme: Der ganze script-tag wird in einen Absatz-tag <p> gepackt. Sieht dann so aus:
<p><script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Person", "name": "George Bush", "disambiguatingDescription": "41st President of the United States", "children": { "@type": "Person", "name": "George W. Bush", "disambiguatingDescription": "43rd President of the United States" } } </script></p>Ist das eine neue Methode wie WP das script-Tag eliminiert, anstelle der Klammer-Umwandlung? Oder erkennt WP den eigentlich ungefährlichen (nicht ausführbaren) Code und verpasst hier WP einfach nur einen nötigen Container, ähnlich wie bei anderen Elementen, die irgendwo „drin“ sein müssen?
Wie gesagt, eigentlich ist es ja kein gefährliches, ausführbares JavaScript, nur eine Sprache zur Codierung von Meta-Informationen.Da wäre ein Plugin sicher die gescheitere Lösung. Für die Ausgabe der Custom Fields musst du schließlich auch Code einfügen.
Im Vergleich zur Option mit custom fields/header.php ist ein Plugin wohl kein großer Unterschied mehr, das stimmt. Wobei man nicht weiß, wie und was genau so ein Plugin macht.
Im Vergleich zur vollmanuellen Eingabe direkt im Editor hingegen wäre ein Plugin technisch relativ „aufwendig“.
Wenn das mit den Absatz-tags kein Problem darstellt, würde ich momentan diese Variante wählen.
Grüße,
Martin999
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenJa, Sicherheitsbedenken. Benutzer sollen im Editor kein JavaScript oder PHP ausführen. Deshalb wird dein <script … vom Editor in <script umgewandelt.
Du meinst, WP wandelt es um von einem script mit Inhalt („Punkte“) zu leeren script-tags? Soweit ich weiß, ist es kein wirklich ausführbares JavaScript, sondern nur eine auf JavaScript basierende Markup-Sprache für Meta-Informationen und der „type“ sollte das eigentlich ausdrücken. Aber ob das WP versteht… du vermutest, WP hält das für ausführbares JavaScript?
Ich habe es jetzt bei einer unwichtigen Seite einfach mal ausprobiert und den obigen Beispiel-Code von Ex-US-Präsident Bush am Ende des WP-Codes im Editor eingefügt, abgespeichert und dann im ausgegebenen Quellcode des Browsers angeschaut. Sieht alles ganz normal aus. Allerdings hat WP die script-tags in <p>-tags gepackt. Ob das für die Sumas dadurch dann wie Text behandelt wird und nicht wie JSON-LD-Code? Förderlich ist es wohl nicht.
Du kannst aber für jedes Feld deines JSON-Codes ein Eigenes Feld erstellen, was die Eingabe erleichtert.
Für jedes Feld ein eigenes Feld? Meinst du die ganz normale, oben angesprochene custom field plus „get_post_meta“-Option, bei der es so ein Problem nicht gibt? Oder meinst du eine weitere Variante, bei der ich custom fields etwas anders anwende?
Abgesehen davon … hast du mal nach Plugins geschaut, die das schon vollständig umsetzen? Vielleicht gibt es da was und du kannst dir die Arbeit sparen.
Ein Plugin, mit dem ich den JSON-LD-Code erstelle, will ich ganz bewusst nicht. Was das reine „Einfügen“ von JSON-LD-script-tags pro Seite an einer gewünschten Stelle angeht, alternativ zu den custom fields, das wäre eine Überlegung wert. Ich versuche halt immer, alles so einfach und „untechnisch“ wie möglich zu lösen, daher die Idee mit dem Editor-Code. Lieber ein Mal etwas mehr Arbeit und dafür eine langfristig sichere, leicht zu wartende und alles unter Kontrolle haltende Methode.
Grüße,
Martin999
Forum: Allgemeine Fragen
Als Antwort auf: Schema Markup mit custom fields individuell einfügenDanke für die verständlichen Ausführungen.
Also wenn ich für jede page den gleichen einheitlichen Schlüsselnamen, z.B. „schema-markup“ verwende, dann wird bei den Seitenaufrufen durch Besucher immer individuell der jeweilige „Wert“ bzw. JSON-LD-Code der betreffenden page in den Quellcode eingefügt.
Dass bei jeder page wegen des gleichen Schlüsselnamens dann sämtliche JSON-LD-Codes von allen pages in den head eingefügt werden, kann hoffentlich nicht passieren :). Ich gehe mal davon aus.Der zweite Schritt mit dem get_post_meta bewirkt dann die eigentliche Ausgabe bzw. Einfügung der jeweiligen Markups pro page. Entweder manuell in ein Template des child themes oder mit dem genannten Plugin.
Grundsätzlich kann ich mir den Ort der Ausgabe aussuchen, denn Google ist mit head und body gleichermaßen einverstanden und technisch habe ich ebenfalls die Wahl – je nach gewähltem template. Oder können es nur die von dir genannten header.php und footer.php sein? Erinnere ich mich recht, dass der get_post_meta-Befehl immer am Ende der header.php bzw. footer.php muss? Das Plugin Code Snippet macht das vermutlich automatisch richtig.
Spräche eigentlich etwas gegen die „vollmanuelle“, völlig untechnische Implementierung der pro Seite unterschiedlichen JSON-LD-Markups: Einfach das jeweilige script-tag im HTML-Modus des WP-Editors in den WP-Code der Seite einfügen?
Anders als HTML-tags wie <p> <h1> usw. wird so ein script-tag<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Person", "name": "George Bush", "disambiguatingDescription": "41st President of the United States", "children": { "@type": "Person", "name": "George W. Bush", "disambiguatingDescription": "43rd President of the United States" } } </script>doch nicht angezeigt für den Besucher, der die Seiten aufruft.
Ginge dann halt nur im body, z.B. ganz am Schluss und nicht im head, aber was spräche sonst dagegen?
Grüße,
Martin999
Forum: Installation
Als Antwort auf: Lokale Mamp-Installation mit einem Duplicator-Klon der Site?„Habe ich das soweit richtig verstanden, dass die beiden Duplicator-Dateien in dem bisher noch leeren Website-Ordner reinkopiert werden und dann wird im Grunde ganz normal per Eingabe der URL für den Installer das Ganze gestartet
Jaha … “
In deinem ersten posting hast du gesagt, die beiden Duplicator-Dateien kommen direkt in htdocs, nicht in das von mir angelegte Verzeichnis (WP-root). Da hattest du wohl einen andere Konstellation im Sinn?
Der Name des von mir angelegten Website-Ordners im htdocs-Verz entspricht meiner Lokal-Domain und lautet „frsneu“. Behält mein jetziger Website-Ordner auf der Live-Site eigentlich nach dem Hochladen der umgestellten/konvertierten Site per Duplicator seinen Namen, sagen wir mal „frs“, wenn der lokale Website-Ordner „frsneu“ heißt oder heißt der dann danach „frsneu“?
Vermutlich und hoffentlich bleibt das bei „frs“, denn diverse Pfadangaben würden dann nicht mehr stimmen, z.B. in der htaccess.