Beiträge von meisterleise

    Hallo Kollegen, Ich habe hier eine Testseite aufgebaut mit:

    • WP5.7
    • Elementor 3.1
    • Theme: Hello Elementor
    • Child: Hello EMT child-03
    • Link zur Testseite: LINK


    Nun möchte ich die Schriftformatierungen jedoch nicht über Elementor steuern, sondern per CSS im Child Theme. Die Einträge dort werden jedoch immer wieder von anderen CSS überschrieben. Es funktioniert nur, wenn ich jeder CSS Anweisung ein !important hinzufüge, was ich natürlich vermeiden möchte!

    Beispiel:
    Die H2 habe ich mit color:red · font-size:60px · font-family:courier definiert. Funktioniert alles, da ich überall !important hinzugefügt habe. Die H3 ist genauso formatiert, jedoch ohne !important, weshalb es nicht funktioniert.

    Wie schaffe ich es, dass das CSS des Child Themes die höchste Prioriät hat also als letztes gelesen wird?

    Also ich glaube, ihr redet aneinander vorbei. @SEpp55 spricht von dem Embed-Code @BadFrog aber vom API Key. Auch mit dem Embed-Code wird die Karte nicht angzeigt, wenn kein API-Key vorhanden ist. Den Embed Code könnte @BadFrog aber sowieso nicht nutzen, da das verwendete Widget nur die Einträge Latitude und Longitude nutzt.

    @BadFrog Welches Theme nutzt du denn? Oft gibt es in den Themes ein Feld zum Eintragen des API Keys, genau wie bei DIVI, was ja im Gegensatz zu WP Bakerey ein Theme ist. Wenn dein Theme die Möglichkeit nicht bietet, suche dir ein Plugin, was dies für dich macht, bspw. "Ultimate Addons".

    Eine andere Lösung:
    Ich selbst nutze die Google Maps gar nicht mehr. Einerseits, weil die API Geschichte immer total nervlich ist, andererseits wegen des Datenschutzes. Ich nehme daher OpenStreetMaps.

    Ja, Bilder kann man nicht per FTP löschen. Sie bleiben in der DB gelistet und umgekehrt erscheint auch kein Bild in der Mediathek, welches du per FTP hinzugefügt hast. Du kannst sie aber auch jetzt noch wie gewohnt aus der Mediathek löschen.

    Bei 30K Stück ist das natürlich etwas mühselig. Am schnellsten ginge es, wenn du die Mediathek auf Listenansicht stellst und dann ganz oben im Reiter "ansicht anpassen" die Einträge von 20 auf 200 oder so erhöhst und dann per Mehrfachauswahl alle löscht. Vielleicht geht's in diesem Fall aber auch mit dem von @r23 genannten Plugin schneller...

    Also ich würde so grundsätzlich nicht vorgehen. Denn in dem Fall müsstest du jedesmal, wenn du bpsw. in der De Version etwas umbaust, es danach in En und Fr umbauen – 3-fache Arbeit.

    Ich weiß nicht, wie gut @mensmaximus Empfehlung multilingualpress da einem die Arbeit abnimmt, denn ich kenne das nicht und mit Multisites habe ich auch nicht wirklich Erfahrung. Aber ich denke, für so eine kleine Website ist die Einrichtung als Multisite überdeminsioniert und überflüssig. Zumal du dich noch überhaupt nicht auskennst, wie du schreibst.

    Meine Empfehlung wäre daher das Multilingual Plugin WPML. Ich habe gerade letzte Woche eine 2-Sprachen-Website damit umgesetzt und bin immer wieder begsitert, wie gut sich diese Software in WP integriert und einem Arbeit abnimmt. Bei WPML sind die Sprachseiten miteinander verknüpft. Wenn du also etwas in De änderst, kannst du es mit En und FR synchronisieren, statt dort ebenfalls umbauen zu müssen.

    Ich habe mal einen kleinen Performancetest gemacht. Die Ausschließung in Autoptimize wirkt sich scheinbar nicht aus, bzw. ist im Rahmen der üblichen Messschwankungen nicht wirklich messbar. Auf Bestandsseiten besteht also meiner Meinung nach kein direkter Handlungsbedarf, CF7 aufs Abstellgleis zu schicken. Auf neuen Seiten wäre das aber zu überlegen.

    Der Fehler ist ein Problem zwischen CF7 & Autopimize.
    Der Fehler rührt daher, dass CF7 sich von einigen JQuerys losgesagt hat und diese durch JS ersetzte.

    Wer weiterhin sowohl Autopimize als auch CF7 nutzen möchte, kann das Problem dadurch lösen, in den JS Optionen von Autopimize folgende Ausschließung hinzuzufügen:

    [FONT=Courier New]

    Code
    wp-includes/js/dist

    [/FONT]

    Ich verwende auch beide Plugins auf diversen Websites und werde mal prüfen, wie stark sich dies auf die Leistungsfähigkeit von Autopimize auswirkt. Prinzipiell halte ich Autopimize für 10x wertvoller als CF7. Im Zweifelsfall würde ich also auf jeden Fall CF7 durch eine Alternative ersetzen.

    Frank Goossen, Entwickler von Autopimize, hat in seinem Blog auf diesen Fehler hingewiesen und kritisiert die Änderungen von CF7: BLOG

    Welchen Browsere unter welchem Betriebssystem nutzt du?
    Fang erst einmal mit den leichtesten und schnellsten Dingen an und prüfe das Backend nochmals mit einem anderen "frischen" Browser.
    Sind die Fehler dort auch oder sind sie vll. plötzlich weg? Wenn dort auch: sind die Fehler dort identisch?

    Weiß nicht, ob ich den Fehler richtig verstehe. Was heißt:

    Meine Seiten werden im Theme Options nicht mehr angezeigt..


    In den Theme Options werden ja keine Seiten angezeigt.

    Ich kann keine Seiten mehr editieren. Dies im „Quick Editor“ und auch im „WPBakery Page Builder“.


    Auch unklar. Was passiert, wenn du das machst?

    Der Fehler rührt aller Wahrscheinlichkeit nach nicht vom the7. Ich würde mal alle Plugins deaktivieren, außer die von the7 und testen, ob dies den Fehler behebt.

    Also dass Google mit dem Bereitstellen von Inhalten ein immer größeres Ärgernis darstellt (worüber der allgemeine Nutzer sich nicht beschweren wird, weil es ja so schön praktisch ist), da gebe ich euch Recht. Dennoch funktioniert bei meinen Seiten und meinen Kundenseiten das DISALLOW zuverlässig. Mit DISALLOW schließe ich standardmäßig bspw. das Impressum/Datenschutz aus.

    1. Einfache Möglichkeit: Downloads als ZIP anbieten
    2. robots.txt: Indexierung bestimmter Objekte von der Indexierung ausschließen:

    [FONT=Courier New]User-agent: *
    Disallow: /*pdf$
    Disallow: /*doc$[/FONT]

    In beiden Fällen werden die Inhalte der Dateien nicht mehr indexiert. Falls du aber möchtest, dass die Dateien zwar indexiert werden, aber in den Suchmaschienen nicht direkt zum Download bereit stehen: Da fehlt mir die Idee. :rolleyes:

    p.s.: Da die Dateien bereits indexiert sind, kann es natürlich eine Weile dauern, bis sie aus dem Index wieder verschwinden. Möglichkeit 1 verschafft hier unmittelbar Abhilfe. Dafür bekommt der Besucher bis zur Neuindexiertung aber eine Fehlermeldung.

    Ich hole meinen eigenen alten Kommentar noch einmal hervor und verbreite hier meine Erkenntnisse. ;)
    (Die möglichen Lösungen, die ich mir bisher ausgedacht habe gelten übrigens für JEDES WordPress System und nicht nur für Elementor).


    1. Shortcode mit functions.php
    Nachfolgendes Script in die functions.php des Scripts eingestetzt ermöglicht unsichtbare Kommentierung im Backend mittles Shortcode: [note]unsichtbarer Kommentar[/note].
    Vorteil: Die Kommentare erscheinen auch nicht im Quelltext.
    Nachteil: Die Kommentare erscheinen in der Gestaltung solange man im Backend angemeldet ist. (lässt sich bei Bedarf lösen, indem man mit 2 Browsern arbeitet oder in Firefox die "Multi Account Containers" nutzt.

    <?php
    function private_notes($atts, $content = null) {
    if (current_user_can('publish_posts')) {
    return '<div class="private-note">' . $content . '</div>';
    }
    return '';
    }
    add_shortcode('note', 'private_notes');
    ?>

    2. Plugin Simple Post Notes
    Ein sehr nützliches kleines Plugin. Im Backend lässt sich zu jeder Seite, Post, etc. ein Kommentar anlegen. Die Kommentare erscheinen auch in der Seitenübersicht, sofern aktiviert.

    3. CSS display:none
    Einen Kommentar auf einer Seite mit einer CSS Klasse belegen, die auf display:none setzt.
    Nachteil: Wird in einem Pagebuilder wie Elementor, DIVI & Co. dann auch nicht mehr erscheinen, also dort nicht praktikabel.
    Achtung: Kommentare sind im Quelltext dennoch zu lesen. Lösung: Ein Optimierungstool einsetzen, welches CSS komprimiert und Kommentare vor der Ausgabe entfernt.

    @Kurt Singer
    Hmm, vielleicht reden wir aneinander vorbei oder ich habe mich unklar ausgedrückt. :rolleyes: Man kann natürlich einen der Pagebuilder Elementor oder Divi installieren und zumindest bei Elementor wird eine Seite aussehen wie vorher. Aber man kann diese "alte" Seite dann nicht in Elementor öffnen und dann erwarten, dass sich die einzelnen Elemene bearbeiten ließen, als seien sie in Elementor aufgebaut worden. Es wird auf der Seite keine Head-, Bilder-, Button- und Form-Widgets geben, sondern alles wird in einem einfachem Text-Editor-Element dargestellt. Um somit bspw. zwischen einem Text und einem Bild einen Button einzufügen bedarf es dann entweder eines Umbaus oder dem Verzicht auf den Einsatz eines Button-Widgets.

    Wie es sich bei Divi verhält, weiß ich nicht, weil noch nie getestet (muss ich unbedingt mal nachholen ;)). Aber denke, das Prinzip ist sehr vergleichbar. Vielleicht sogar noch schlimmer, da Divi ja ein Theme ist. Das heißt also, wenn ich Divi aktiviere, muss ich mein vorher genutztes Theme deaktivieren mit großen Folgen für das Design.

    Wurde auf der Website bereits ein anderer Page Builder eingesetzt, wird die Sache noch komplizierter. Ist zum Beispiel ein Theme mit eigenem Page Builder wie Avada im Einsatz oder der weit verbreitete Visual Composer (WP Bakery), dann lassen sich die Seiten mit Elementor oder Divi überhaupt nicht weiter bearbeiten.