Naja, Audio ist ja nicht verboten. Aber die Idee ist, dass der User selbst entscheiden können soll. Insofern mach es doch einfach mit einem Play- oder unmute-Button. Dann können die Leute, die gern Ton haben wollen, den Ton einschalten.
Beiträge von danielgoehr
-
-
1und1/ionons nutzt bei seinen OneClick Installationen u.a. eigene Plugins oder auch "Must Use" Plugins, die sowas bewirken. Habe auch schon Installationen mit gepatchten Core-Dateien gesehen.
Ja, das ist mir auch schon ein paar Mal begegnet. Nicht nur bei 1und1/ionos. Teilweise sogar in der Variante, dass sicherheitsrelevante Updates mehrere Versionen "zurückhängen", weil der Hoster noch keine angepasste Version fertig hatte.
Wir stellen stellen One-Click-Installationen auch grundsätzlich auf ein "normales" Wordpress um, wenn wir solche Seiten übernehmen.
Ich finde ionos eh lustig. Verweisen auf den Wordpress-Community-Support, um Probleme mit ihren eigenen "Bastel-Lösungen" zu supporten. Das ist in dem Fall auch nicht das erste mal, wenn ich mich richtig erinnere.
-
Die lange Antwort:
https://developers.google.com/web/updates/20…-policy-changesDie kurze:
Die Browser-Hersteller haben sie (weitestgehend) darauf geeinigt, Autoplay für Audio Elemente nicht mehr zuzulassen (und für Video auch nur dann, wenn sie stummgeschaltet sind). -
Wenn die beiden Felder ausgegraut sind, sind die URLs vermutlich in der wp-config.php per define gesetzt.
https://wordpress.org/support/article/changing-the-site-url/Lad dir Mal die wp-config.php per FTP herunter und schau da Mal nach den beiden Zeilen.
-
Das Plugin ist höchstens eine Notlösung. Lieber gleich richtig machen...
-
Ganz generell:
Solange der User explizit einwilligt und ihm bewusst ist, was mit seinen Daten genau passiert, darfst du auch nach der DSGVO (fast) alles machen, was dir so in den Sinn kommt. Wichtig ist eben nur, dass der User dieser Verarbeitung (im Detail!) zustimmt und auch versteht, für was er seine Zustimmung gegeben hat und was mit seinen Daten passiert.Wie das zu formulieren ist und in welcher Art und Weise die Zustimmung des Users einzuholen ist, kann dir aber nur ein Anwalt verlässlich sagen.
-
Das ist eigentlich wie gemacht für eine eigene Taxonomie:
https://wordpress.org/support/article/taxonomies/ -
Aktivier' mal wp-debug (am besten mit logfile) und schau nach, ob irgendwelche Fehler angezeigt werden. Da das Menü auf der Seite noch angezeigt wird, kann es ja nicht weg sein.
Ansonsten könntest du auch probieren auf PHP 7.2 oder 7.1 zu wechseln. Vielleicht ist deine Theme oder eins deiner Plugins (noch) nicht vollständig kompatibel.
-
Es gibt Hooks und Filter, ich warte noch auf eine Antwort bezgl. der Dokumentation.
Wie wäre denn die weitere Vorgehensweise? Muss ich einen kompletten Code integrieren, da das Plugin Blocksatz gar nicht kennt...oder wie?Also wirklich konkret kann ich leider nicht helfen, weil ich das Plugin nicht kenne. Das scheint ja so eine Art Produktkonfigurator zu sein. Ich habe allerdings auch noch nicht ganz durchschaut, was es genau macht und wie es funktioniert. Ich habe gestern mal einen kurzen Blick auf den Quellcode geworfen, aber sich da jetzt wirklich einzuarbeiten würde für mich leider den Rahmen sprengen.
Deshalb ist das jetzt natürlich wirklich sehr allgemein, aber die ungefähre Vorgehensweise wäre so:
1) Finde heraus, wie der Aublauf des Plugins ist. Was macht es an welcher Stelle und wo ist die Stelle, an der die Textausrichtung festgelegt wird.
2) Wie legt das Plugin an dieser Stelle die Textausrichtung fest?
3) Welchen Hook oder Filter kannst du verwenden, um an dieser Stelle "einzuhaken" und die Ausgabe oder Verarbeitung zu "manipulieren".
4) Schreibe eine Funktion, die diese "Manipulation" vornimmt.Du wirst wahrscheinlich nicht drumherum kommen, dich etwas tiefer in die Funktionalität des Plugins einzuarbeiten. Jenachdem, wie es dann funktioniert, kann es sein, dass es eine einfache Lösung (z.B. mit CSS) gibt. Es kann aber auch sein, dass es komplexer/komlizierter wird.
-
Child Plugins gibt es schon. Es gibt nur keine klare Struktur wie bei Child-Themes...
Wie definierst du denn ein "Child-Plugin"? Tatsächlich existiert so etwas eigentlich nicht (was wirklich schade ist, weil das in vielen Situationen durchaus sinnvoll wäre).
Was es gibt, sind add-ons zu anderen Plugins, die bestehende Plugins um Funktionen erweitern (in der Regel über Hooks und Filter oder z.B. indem sie das CSS überschreiben).
Auch wenn das Plugin Open Source ist, würde ich das Plugin nicht direkt ändern. Du kannst das Plugin sonst nicht mehr updaten und müsstest deinen "Fork" quasi selbstständig pflegen.
Bietet das Plugin keine Hooks oder Filter? Gerade bei sowas wie Buttons im Editor ist das ja durchaus üblich. Ich kenne jetzt dieses Plugin nicht, aber praktisch alle Editoren und Pagebuilder, die ich kenne bieten extra Schnittstellen für Erweiterungen...
-
Nein, meine Frage war eine andere: ...it is not intended for use by plugins or themes... Daher die Frage: Wo kann es denn dann genutzt werden, wenn nicht in Plugins oder Themes?
Hier meine (nicht fundierte oder belegte) Vermutung:
Das Wordpress-Entwickler-Team legt schon immer sehr viel Wert auf Abwärtskompatibilität. Das ist insofern schön, als das in aller Regel auch alte Themen und Plugins noch funktionieren. Aber es hat den Nachteil, dass wir seit Jahren an vielen Stellen alten "Ballast" mitschleppen.
Früher gab es tatsächlich auch häufig Lösungsansätze mit query_posts, heute eher mit get_posts, WP_Query oder pre_get_posts. Wahrscheinlich ist query_posts eine dieser Funktionen, die aus Gründen der Abwärtskompatibilität noch da ist, aber nicht mehr verwendet werden sollte.Ich würde sagen: Wenn die Doku sagt, man soll es nicht benutzen, sollte man es in jedem Fall lieber lassen. Zumal es ja bessere Alternativen gibt.
-
Das würde ihn ja ansich erstmal nicht davon abhalten, dem ersten Post eine andere oder zusätzliche Klasse zu geben und darüber dann anders zu stylen.
Es sei denn, es ging darum, dass der erste Post nicht Teil der gleichen ul sein soll. Dann würde ich in dem Fall auch einfach zu zwei Loops tendieren, wie @Raphael in Beitrag #4 vorgeschlagen hat.
-
In der Schleife auf den ersten post prüfen geht bei mir nicht weil ich über <li> Elemente iteriere die bekanntlich child eines <ul> ausserhalb der Schleife sind.Irgendwie ist mir nicht ganz klar, was du damit meinst.
Aber unabhängig vom Markup kannst du doch einfach mit einer "counter"-Variable arbeiten, die du einfach bei jedem Durchlauf um 1 erhöhst. Dann kannst du doch relativ einfach gegenprüfen, an welcher Stelle du dich befindest.
-
Wenn ich den Code von Maxe richtig verstehe, dürfte das nicht so sein. Die Startseite gibt dann immer den Slider aus, völlig unabhängig vom Header-Bild. Ggf. musst du aber vielleicht das CSS noch entsprechend anpassen.
-
@danielgoehr : Wie soll das mit Feldern im Customizer gehen? Ich verstehe da nicht, was du meinst.
Jetzt hat mir @b3317133 quasi die Antwort vorweg genommen. Aber so war es gemeint:
Für solche Dinge ist eigentlich die WordPress Customizer API vorgesehen.
Im Prinzip einfach ein Bild-Feld und ein Textfeld im Customizer ergänzen und dann im Theme ausgeben. Wie @b3317133 schon sagt, ist das ja genau dafür gedacht. -
Wenn du dein Theme selber schreibst kannst du ALLES mit ACF lösen.
Dann hat er aber zwangsläufig ACF als Dependency. Jenachem wofür das Theme gedacht ist und was er damit vor hat, finde ich das keine gute Lösung (vor allem nicht für so eine Kleinigkeit). Obwohl, ich sonst durchaus ACF-Fan bin ...
-
@danielgoehr: Einen ganzen Slider nur für ein bisschen Text halte ich für übertrieben. Diese Slider laden ja alles Mögliche, bevor sie mal funktionieren, weil die meisten extrem viele Funktionen mitbringen. Und das wiederum geht auf die Ladezeit.Tatsächlich hatte ich die Frage falsch verstanden. Für ein reines Bild mit Text ist das natürlich nicht sinnvoll.
@Hipster123:
Wenn du eh ein eigenes Theme schreibst, würde ich es mit zwei Feldern im Customizer machen. Finde ich persönlich etwas eleganter als die Widget-Area (auch wenn das natürlich auch funktionieren wird). Ist am Ende aber wahrscheinlich auch Geschmacksache. -
Ja gibt es.
Zum Beispiel so: https://de.wordpress.org/plugins/search/slider/
PS: Ohne weitere Angaben kann man die Frage kaum genauer beantworten (Forenregeln beachten)
-
Also die Idee ist so natürlich nicht durchführbar (aus schon genannten Gründen). Aber den Ansatz finde ich schon richtig.
Natürlich kann niemand prüfen, was ein Theme oder Plugin macht (also zumindest nicht in der breiten Masse). Aber die Plattform-Anbieter (z.B. Envato oder das "offizielle" Wordpress-Repository) könnten von den Entwicklern schon bestimmte Informationen obligatorisch abfragen, wenn sie ein Theme oder Plugin anbieten möchten. Das wäre ja ein einfaches Formular, mit dem man ein paar grundlegende Dinge abfragen könnte (z.B. werden Assets aus externen Quellen geladen, welche personenbezogenen Daten werden gespeichert, werden Daten an Dritte übermittelt, etc.). Das würde ja schon viel helfen und man würde auf einen Blick sehen, was hier passiert. Vor allem (aber nicht nur) als Laie, für den eine eigene Prüfung kaum möglich ist.
Die Plattformen machen ja auch so etliche Auflagen. Insofern sehe ich da eigentlich nicht das große Problem.Natürlich ist das dann immer noch nicht 100%ig sicher, aber man kann ja in der Regel davon ausgehen, dass solche Dinge nicht mit böser Absicht (heimlich) geschehen und die allermeißten Entwickler kein Problem mit Transparenz hätten.
-
Einfügen von CSS anhand ACF würde auch als kleines Plugin gehen.
Ok, klar, das stimmt. Dann etwas allgemeiner: Es geht nicht ohne das Schreiben von (ein bisschen) Code. :)Ich glaube, das hängt vom Theme ab. [/CODE]
[...]
Aber der Ansatz ist natürlich richtig. Nur muss man ev. die Body-Klassen pro Kategorie noch reinkriegen. Allerdings dürfte das nichtso schwer sein.Du hast Recht. Die Category-Klassen sind nur im Archive vorhanden. Die Single-Posts haben sie nicht. Man müsste das tatsächlich noch ergänzen (z.B. so: https://css-tricks.com/snippets/wordp…ame-body_class/)
Nachtrag/Edit: Jetzt auch getestet.