Beiträge von b3317133

    Liste alle Plugins hier auf, dann kann man Dir ggf. sagen, welche(s) davon für sowas verantwortlich sein könnte(n).

    Leider fehlen ansonsten jegliche Angaben und/oder Links zu einer Beispielseite mit so einem PNG bzw. JPG, also kann man anders kaum helfen.

    Alternativ deaktiviere der Reihe nach einzlen alle Plugins bzw. nutze temporär ein anderes Theme und teste jeweils dazwischen, ob das Verhalten weiterhin auftritt, dann kannst Du das selbst eingrenzen.

    Wenn die falschen Einbindungen im Child Theme entfernt werden, sind die zugehörigen Preloads überflüssig. Sie sind generell auch überflüssig bzw. in Deinem Fall sogar kontraproduktiv, denn der Browser holt sich normalerweise anhand Angaben in [FONT=Courier New]@font-face[/FONT] nur das für ihn passende Format, mit den aktuellen Preloads lädt er extra unnötige Formate.

    Wenn Du unbedingt eigenes Font Awesome verwenden willst, wende Dich an den Autor des Child Themes und zeige dem den o.g. Link in #4 bzgl. korrekter Einbindung. Der Autor wird dann auch im Code des Parent Themes sehen können, wie man die 4.7 Version per [FONT=Courier New]wp_dequeue_script()[/FONT] entfernen kann, falls sie im sonstigen Parent Theme nirgends verwendet werden sollte.

    Die saubere Lösung wäre hier, Font Awesome 4.7 aus dem Parent Theme wie dort vorgesehen zu verwenden und den HTML-Code Deines Floatmenüs darauf anzupassen,siehe HTML-Code in #7.

    Das Parent Theme lädt jetzt die Font Awesome Version 4.7:

    Code
    <link rel='stylesheet' id='font-awesome-css'  href='.../wp-content/themes/langwitch/design/css/libs/font-awesome.css' type='text/css' media='all' />


    Der HTML-Code im Plugin Icon passt nicht dazu:

    Code
    derzeit: <i class="fas fa-envelope-open"></i>
    für 4.7: <i class="fa fa-envelope-open"></i>


    Weiterhin wird die [FONT=Courier New]font-family[/FONT] für alles per CSS vom Child Theme mit [FONT=Courier New]!important[/FONT] überlagert:

    CSS
    html, body, div, span, ... mmary, time, mark, audio, video {
        font-family: 'Raleway' !important;
    }


    Das [FONT=Courier New]!important[/FONT] da müsste weg oder alternativ im Child Theme CSS wiederum überlagert werden:

    CSS
    .fa {
        font-family: FontAwesome !important;
    }


    Alternativ beim Theme Hersteller nachfragen, ob es auch eine Theme Version mit Font Awesome 5 gibt.

    Ausserdem werden derzeit noch alte unnötige Preloads im [FONT=Courier New]<head>[/FONT] vom Child Theme ausgegeben:

    Code
    <!--  Fontawesome  -->
        <link rel="preload" as="font" type="font/woff2" href=".../wp-content/themes/webasmedia-child/fontawesome/webfonts/fa-brands-400.woff2" crossorigin="anonymous" />
       usw.

    Wie man Font Awesome lokal hostet, ist z.B. hier beschrieben, man bindet dafür genau eine Datei ein, die lädt dann den Rest, schau Dir den Inhalt der Datei mal an, vor allem das Ende.

    Code
    <link href="/your-path-to-fontawesome/css/all.css" rel="stylesheet">


    Das Child Theme auf der genannten Seite bindet alles doppelt und vierfach ein.


    Der Autor des Child Themes ist da offenbar irgendeiner falschen oder sehr unklaren Anleitung gefolgt.

    Funktioniert das Plugin, wenn Du alle Dinge bzgl. Font Awesome im Child Theme abschaltest und zudem auch (falls vorhanden) irgendwelche Optimierungsplugins die Einfluss auf Font Awesome nehmen?

    Die aktuelle Einbindung von Font Awesome Dateien über das Child Theme ist ein ziemliches Chaos, gleichzeitig minified und nicht minified Dateien usw., zig verschiedene Subsets usw., das sollte man wohl mal gründlich überarbeiten.

    Deaktiviere das Einbinden im Child Theme und schau dann, ob das Plugin selbst Font Awesome korrekt lädt.

    Stelle die PHP Version 8.0.1 auf die vorher verwendete zurück.

    Offenbar ist die bei Dir verwendete WordPress Version 5.0.11 oder Deine veraltete Impreza Theme Version 7.8 oder eines der verwendeten Plugins nicht damit kompatibel.

    Erst ab WordPress 5.3 gab es entspr. Support für das Problem, für dann allerdings auch nur bis PHP 7.4.x, mehr dazu hier.

    Hat teilweise geholfen.


    Wo/wie genau hat es nicht geholfen?

    Das Jetpack Plugin hat z.B. alle Deine Grafiken auf Server in die USA wie i0.wp.com, i1.wp.com, i2.wp.com, .. hochgeladen und von dort eingebunden, weiterhin wurden auch Teile des WordPress Core von dort eingebunden, z.B. c0.wp.com, weiter auch Teile des Jetpack Plugins, widgets.wp.com, usw., das führt dann bei Routingaussetzern oder Überlastung der entspr. Server dort zu solchen Fehlern und Problemen, ganz abgesehen davon, dass dadurch die IP-Adressen aller Besucher ohne Zustimmung an Dritte weitergeleitet werden.

    Falls manuell HTML-Code mit Links zu diesen externen Bildern u.ä. kopiert und anderweitig eingefügt wurde, sollte das noch entspr. bereinigt werden, so dass die Links nur auf die eigene Mediathek zeigen, Beispiel:

    Code
    vorher: https://i0.wp.com/tvv-neuwulmstorf.de/wp-content/uploads/2020/11/stellen-1.jpg?ssl=1
    nachher: https://tvv-neuwulmstorf.de/wp-content/uploads/2020/11/stellen-1.jpg

    Nahezu alle Funktionen von Jetpack sind nicht DSGVO konform einsetzbar, würde es daher ganz weglassen.

    Es spricht nichts dagegen, die Seite erst unter einer Subdomain aufzubauen, am besten mit einem Passwort Schutz oder einem sonstigen Maintenance Plugin versehen.

    Wenn die Seite dann fertig ist, zieht man sie entweder selbst mit einem Migrationsplugin auf die Haupdomain um oder lässt sich gerade als Anfänger für einen kleinen Betrag z.B. über die Jobbörse direkt helfen, am besten dann von jemandem, der mit dem genutzten Hostinganbieter etwas Erfahrung hat, dann ist dabei wie in diesem Fall auch ein sauberer Umzug der Inhalte zwischen zwei vorinstallierten "Strato Apps" möglich, so dass danach im Backend von Strato auch noch alles weiter funktioniert was bzgl. der App angeboten wird.

    Änderungen an den "Strato App" Installationen oder auch an ähnlichen Mechanismen bei anderen Hostinganbietern sollte man ansonsten ausschliesslich über das vorhandene Menü der App im Backend des Hostings machen und nicht anderweitig in die meist entspr. markierte Datenbank oder Weiterleitung eingreifen.

    @thhoen Dieser notwendige Schritt bezieht sich auf jede Art WordPress Umzug wenn auf dem Server Pfade verändert werden.

    Die meisten Migrationsplugins berücksichtigen das automatisch, daher der entspr. Hinweis, und die meisten Leute die WordPress Seiten betreuen, wissen das auch.

    Wenn Du direkte Unterstützung benötigst, poste bei Bedarf ein Gesuch in die Jobbörse des Forums, dann bekommst Du vermutlich zeitnah Angebote für kompetente Hilfe.

    wp.heimat123.de -> /wordpress/
    heimat123.de -> /html/

    Dann würde man einfach die Hauptdomain heimat123.de auf /wordpress/ umstellen, Datenbankeinträge ändern, fertig.


    Oder auch nicht fertig, denn dann stellt sich bei genauerer Betrachtung heraus, dass diverse Dinge nicht mehr funktionieren, da sie den vollen Document-Root Pfad auf dem Server nutzen und damit nicht mehr finden, angefangen von weit verbreiteten Cache-Plugins mit entspr. Einträgen in .htaccess über div. Themes mit internen js/css Caches bis hin zu Backup-Plugins, die lokale Backups nicht mehr anlegen oder später mal nicht wiederfinden, wenn man sie irgendwann dringend einspielen möchte.

    Daher empfiehlt sich gerade für unbedarfte Anfänger in der Regel die Nutzung von entspr. Migrationsplugins, die solche Dinge berücksichtigen.

    Ok, bedenke dabei, dass falls Du dann das offenbar nur eine verfügbare Zertifikat von .de auf .com umstellst, alle mit https erfassten aktuellen Links zu .de sofort nicht mehr erreichbar sein bzw. einen Zertifikatsfehler im Browser anzeigen werden, genau so wie beispielsweise jetzt hier:

    Code
    https://www.kurt-singer.com/?test123

    Stelle den Kunden für alltägliche Arbeiten einen Account mit z.B. der "Redakteur" Rolle zur Verfügung, ggf. mit je nachdem etwas angepassten Capabilities, dann wird der grösste Teil dieser Hinweise nicht angezeigt werden.

    Eine generelle Lösung zum Entfernen von solchen Boxen gibt es nicht, WordPress hat keine einheitliche Schnittstelle für solche Hinweise und Plugins und auch Themes kochen daher ihr eigenes Süppchen für diese Hinweise bzw. Werbung...

    Möglichkeiten damit umzugehen:

    a) Das Problem weiter eingrenzen, um die eigentliche Ursache herauszufinden. Das wäre evtl. möglich über das Zurücksetzen bzw. sog. Rollback von WordPress auf die ältere Version mit der das Bearbeiten der Seite noch funktioniert hat und dann ein Abgleich, was seitdem an WordPress verändert wurde. Das könnte ggf. auch allgemeine Fehler bzw. Unzulänglichkeiten im Editor aufdecken. Je nach Ergebnis könnte man bei dieser WordPress Version bleiben, bzw. zumindest innerhalb des sog. Zweiges, also z.B. WordPress 5.5.x und nur innerhalb des Zweiges das .x aktualisieren, nicht in den nächsten Zweig z.B. WordPress 5.6.x hinein. Die älteren Zweige erhalten bis weit (derzeit bis 3.7.x) zurück sicherheitsrelevante Updates.

    b) Als Workaround noch das Plugin Classic Editor versuchen, das verwendet dann den älteren, sehr viel einfacheren Editor von WordPress und stellt die Bilder dann aber wohl auch etwas anders dar und das Einfügen usw. unterscheidet sich ebenfalls.

    c) Keine weitere Massnahmen, die fragliche Seite bleibt wie sie ist, mit dem aktuellen Hosting Rahmenbedingungen nicht bearbeitbar.

    Durch die aktuell leider stetigen teils tiefgreifenden Änderungen innerhalb von WordPress ist es in der Tat leider nicht (mehr) so einfach, wie es sich an vielen Stellen im Internet (noch) darstellt.