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 erstellenWenn es im Ordner der Hauptdomain eine [FONT=Courier New].htaccess[/FONT] gibt, muss man diese ggf. noch anpassen, ..
Gibt es eine und falls ja, was steht drin?
Vor der ganzen Aktion alle Cache-/Optimier-/Minfy-/Sicherheits-/Login-Verstecken und ähnliche Plugins in der Installation der Subdomain abschalten.
Wurde das gemacht?
Leider schleichen sich durch Angaben von Platzhaltern statt echten Domainnamen oft Fehler ein, also kann man hier nur vermuten.
Liegt an allgemeinem CSS für alle Hx Überschriften, die eigentlich immer einen Abstand nach oben haben, nur dann nicht, wenn sie das erste Element im Container sind. In Deiner ersten Spalte fügt Elementor offenbar einen [FONT=Courier New]<style>[/FONT] Tag als erstes Element ein, daher ist diese [FONT=Courier New]<h4>[/FONT] nicht mehr das erste Element und der obere Abstand wird gezeigt.
Verwende einen einfachen Absatz statt der H4.
Das verwendete Theme ist nicht mit der aktuell installierten WordPress Version 6.1.1 kompatibel.
In der Datei [FONT=Courier New]wp-content/themes/luisa-wp/assets/js/main.js[/FONT] wird lt. Browser Console auf eine veraltete Art und Weise ein Event zugewiesen, das erzeugt dann einen Fehler [FONT=Courier New]Uncaught TypeError: $(...).live is not a function[/FONT] und die Darstellung des Portfolios bricht ab. Ändere in Zeile 603 diese Zeile:
alt:
$('.zilla-likes').live('click', ...
neu:
$('.zilla-likes').on('click', ...
Vermutlich wurde WordPress aktualisiert, ohne vorher die Kompatibilität zu prüfen. Möglicherweise sind noch weitere ähnliche Probleme im Theme, wende Dich am besten an die Person, die das Theme für Dich erstellt hat. Zudem wurde der Website wohl auf https/SSL umgestellt, das Theme versucht aber weiterhin, externe Schriftarten über http zu laden, was in vielen Browsern nicht funktionieren wird.
Hinweis: is_admin() fragt ab, ob der Adminbereich genutzt wird, nicht eine Administrator Rolle o.ä.
Mit zusätzlichem Fallback Link der irgendwo ausserhalb der Funktion definiert wird, kann man das z.B. so machen:
// irgendwo ausserhalb
global $my_privacy_link;
$my_privacy_link = 'https://meltedcloth.s1-tastewp.com/datenschutz/';
function wphdp_comment_form_field_comment($comment_field)
{
global $my_privacy_link;
return $comment_field . '<input type="checkbox" name="privacy" value="privacy-key" class="privacyBox" aria-req="true"><p class="pprivacy">Ich stimme der Speicherung und Verarbeitung meiner Daten nach der DSGVO zu und akzeptiere die <a class="privacy-policy-link" href="' . esc_url( !empty( $url = get_privacy_policy_url() ) ? $url : $my_privacy_link ) . '">Datenschutzbedingungen</a>. *</p>';
}nun habe ich versucht auf testseite/blog/wp-admin/ mich einzuloggen, ohne Erfolg.
Sobald ich das eingebe werde ich automatisch auf die Seite blog.testseite.de/wp-login.php?redirect... weitergeleitet.
Dann fehlt dieser Schritt:
.. passt in der Datenbank der Subdomain in der Tabelle [FONT=Courier New]wp_options[/FONT] die Werte [FONT=Courier New]siteurl[/FONT] und [FONT=Courier New]home [/FONT].. an:
wie bekomme ich schnellstes meine eigenständige blog.testseite.de umgezogen auf testseite.de/blog ?
"Schnellstes" wohl über die Jobbörse des Forums, dürfte keine 15 Min dauern, wenn Hosting Zugangsdaten vorhanden sind.
Ansonsten erstellt man einen Unterordner blog im Ordner der Hauptdomain, verschiebt da alles komplett aus dem Order der Subdomain hinein, passt in der Datenbank der Subdomain in der Tabelle [FONT=Courier New]wp_options[/FONT] die Werte [FONT=Courier New]siteurl[/FONT] und [FONT=Courier New]home[/FONT] (wie auch hier beschrieben) in Deinem Fall vermutlich für beide Werte auf das hier (ohne / am Ende) an:
https://www.genutzte-domain-der-testseite.de/blog
Danach meldet man sich hier an:
https://www.genutzte-domain-der-testseite.de/blog/wp-admin/
Dann klickt man einmal Einstellungen > Permalinks > Speichern ohne Änderungen und nutzt dann ein Plugin wie Better Search Replace für die Änderung aller restlichen Pfade in der Datenbank auf den neuen Pfad (ohne / am Ende).
Suchen:
http://blog.testseite.de
Ersetzen:
https://www.genutzte-domain-der-testseite.de/blog
Wenn es im Ordner der Hauptdomain eine [FONT=Courier New].htaccess[/FONT] gibt, muss man diese ggf. noch anpassen, dass Angaben darin nicht für den Unterordener gelten.
Vor der ganzen Aktion alle Cache-/Optimier-/Minfy-/Sicherheits-/Login-Verstecken und ähnliche Plugins in der Installation der Subdomain abschalten.
Dann ist der auf den Webseiten (Dein erster Screenshot und das Forum) verwendete Google Webfont Open Sans warum auch immer offenbar falsch auf Deinem lokalen Gerät installiert und wird von lokal statt der Einbindung als Webfont vom Website verwendet. Empfehlung: Verwende ein anderes Gerät, das eher dem Nutzererlebnis der Websitebesucher entspricht.
Welche Schrift auf welchem Screenshot ist richtig/falsch und welcher Screenshot stammt aus welchem Browser?
Bei Divi kannst Du in den Theme Options > Builder > Advanced > Static CSS File Generation > Clear den internen CSS Cache leeren oder auch abschalten. Das kann helfen, wenn Änderungen an Schriften gemacht wurden. Alternativ den mitgekaufen Divi Support ansprechen, wenn Du das nicht findest.
Das ist so nicht ganz richtig.
Deshalb steht da noch der im Zitat durch "..." weggelassene Teil in der Antwort #15 und verweist auf Mechanismen zur Debug Ausgabe "ausserhalb von WordPress". Andere Realitäten entstehen oft durch mangelhafte Texterfassung.
Für spätere Mitleser: Das Problem hier war nur ein (nicht standardmässig) aktiviertes [FONT=Courier New]WP_DEBUG_DISPLAY[/FONT] in WordPress (siehe Screenshot in Antwort #9). Die entspr. Konstante wurde entweder manuell in die Datei [FONT=Courier New]wp-config.php[/FONT] eingetragen (siehe Antwort #11) oder ggf. auch über irgendeine Managed WordPress Hosting oder OneClick Installer oder sonstige serverseitige Verwaltungskomponente ausserhalb von WordPress aktiviert. Mit dem Deaktivieren der Debug Ausgabe wäre das Problem erledigt gewesen.
Die [FONT=Courier New]wp-config.php[/FONT] Datei befindet sich üblicherweise im Hauptverzeichnis von WordPress. Wenn Dir das nichts sagt, wende Dich ggf. besser an die Person, die den Website ursprünglich eingerichtet hat bzw. heute technisch betreut.
Ergänzung: Mehr zu den Debug Einstellungen hier in der WordPress Dokumentation.
Möglicherweise löscht oder überschreibt irgendein Mechanismus Deine [FONT=Courier New].htaccess[/FONT] Datei. Das führt u.a. zum beschriebenen Effekt.
Wenn die Seiten wieder weg sein sollten, schau vor weiteren Änderungen nach, ob
Füge dann den Inhalt mit dem [FONT=Courier New][+][/FONT] Symbol und Code im Forum Editor ein.
hier der Screenshot:
Ist eine Zeile mit [FONT=Courier New]WP_DEBUG_DISPLAY[/FONT] in der Datei [FONT=Courier New]wp-config.php[/FONT] vorhanden? Falls ja, entferne diese Zeile oder ändere in dieser Zeile [FONT=Courier New]true[/FONT] auf [FONT=Courier New]false[/FONT]
Wenn der Linkname anders/manuell gewählt sein soll, musst Du den ganzen Link eben mit der anderen o.g. API Funktion selbst zusammensetzen, z.B. so:
return $comment_field . ' ... und akzeptiere die ' . ( ( !empty( $url = get_privacy_policy_url() ) ) ? '<a class="privacy-policy-link" href="' . esc_url( $url ) . '">Datenschutzbedingungen</a>' : 'Datenschutzbedingungen' ) . '. *</p>';Die Ausgabe des tatsächlichen Seitentitels lt. WordPress ist kein Schönheitsfehler sondern genau so gewollt. Manche nennen die Seite auf dem ganzen Website durchgängig einheitlich Datenschutzerklärung oder nur Datenschutz oder wie auch immer und bei mehrsprachigen Websites wird die korrekte Übersetzung verwendet usw.