Beiträge von b3317133

  • Wordpress Aktualisierung de_DE versehentlich verborgen

    Du könntest z.B. in die Datei [FONT=Courier New]functions.php[/FONT] Deines Themes direkt nach dem dort vorhandenen ersten [FONT=Courier New]<?php[/FONT] temporär diese Zeile ergänzen, dann z.B. das Dashboard von WordPress aufrufen und dann diese Zeile wieder entfernen. Dann sollte der Link wieder angezeigt werden.

    PHP
    <?php
delete_site_option( 'dismissed_update_core' );
// hier der Rest Deiner functions.php ...


    Alternativ gibt es noch weiteren Lösungen, z.B. mit phpMyAdmin in der Datenbank in der Tabelle [FONT=Courier New]wp_options[/FONT] (oder entspr. anderes Prefix statt [FONT=Courier New]wp_[/FONT]) die Zeile mit dem Namen [FONT=Courier New]dismissed_update_core[/FONT] entfernen...

  • keine Fontawesome Icons

    Scripts und Styles des Parent Themes entfernt man im Child Theme mit [FONT=Courier New]wp_dequeue_script()[/FONT] bzw. [FONT=Courier New]wp_dequeue_style()[/FONT].

    Falls das Parent Theme irgendwo Symbole von Font Awesome 4.7 verwendet, werden diese dann natürlich nicht mehr korrekt dargestellt.

    Empfehlung saubere Lösung siehe #9, mit dem Entfernen eines [FONT=Courier New]s[/FONT] beim Icon wärst Du mit dem aktuellen Stand der Seite ohne weitere Änderungen dann auch schon fertig:

    Code
    derzeit: class="fas
für 4.7: class="fa


  • UpdraftPlus kein Fortschritt

    Generell gilt: Viele Backup Plugins werden durch Zugriffe von Besuchern oder Suchmaschinen auf dem Website sozusagen immer wieder angestossen bis das Backup fertig ist. Wenn es kaum/keine Besucher gibt, kann das daher etwas dauern. Manche Backup Plugins arbeiten auch absichtlich langsam, um eine Serverüberlastung zu vermeiden.

  • Alle PNGs wurden von alleine iN JPGs umgewandelt

    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.

  • keine Fontawesome Icons

    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.

  • keine Fontawesome Icons

    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.

  • keine Fontawesome Icons

    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?

  • keine Fontawesome Icons

    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.

  • Fatal Error

    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.

  • Fotos werden nicht mehr geladen

    Zitat von codo*3

    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.

  • Umstieg auf WordPress

    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.

  • Umstieg auf WordPress

    @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.

  • Umstieg auf WordPress

    Zitat von JABA-Hosting

    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.