Posts by splendid-text-u-webdesign

Das Missverständnis scheint wohl einfach fortzubestehen und die gesuchte Lösung zu erschweren – ein „Tag“ (also in der WordPress-Terminologie post_tag genannt) kann keiner category angehören, da es zwei eigenständige, voneinander getrennte Taxonomien sind. Möglicherweise gibt es aber Kategorien, die Ancestor-Kategorien angehören und in der (gleichlautenden) Bezeichnung genauso wie ein anderer post_tag heißen (aber in der Datenbank trotzdem eine andere Entität mit eigener ID bilden).

Genau, da hat DummyGirl absolut recht – sonst lässt sich nur spekulieren. In den DevTools Deines Browsers kannst Du möglicherweise herausfinden, ob für die ungewollt großgeschriebenen Buchstaben ein Ersatzfont geschaltet wird, der dann in der gewollten Darstellung abweicht (Im Inspektor relevantes HTML-Element heraussuchen und schauen, welcher Font für die Anzeige verwendet wird).

Ist das entsprechende Zeichen womöglich nicht im Font enthalten bzw. wird für den einzelnen Buchstaben vielleicht ein Fallback-Font verwendet?

Man könnte für den jeweiligen Post-Type eine oder mehrere Sidebars via React anlegen (also mit PluginSidebar, der Gutenberg-Entsprechung zu den Meta-Boxes); diese Sidebars ließen sich dann mit den benötigten Eingabefeldern ausstatten, die dann optional – je nach Post – mit Informationen „gefüttert“ werden. Diese ließen sich dann bspw. als post_meta speichern und im Theme ausgeben. Dies würde das Ladezeit-Problem im Backend vermutlich lösen – bedeutet aber natürlich die Programmierung einer entsprechenden Infrastruktur.

Tags und Kategorien sind separate Taxonomien (die eine hierarchisch, die andere nicht hierarchisch), das heißt ein Tag kann nicht in einer Kategorie vorkommen. Lediglich ein Term könnte einer Taxonomy angehören.

Quote from Kurt Singer

Finde ich jetzt garnicht. Wenn ich die Site aufrufe benötige ich trotz sehr schneller Leitung relativ lange, bis sich alles öffnet. Das Foto auf der 1. Seite lädt zum Urlaub ein, nicht zum Webdesign. Ich würde überlegen, ob meine von Dir erstellte Site dann auch so lange braucht und nicht zielführende Fotos enthält. Sorry, für mich die Chance des ersten Eindrucks verpasst.

Da gebe ich Dir sogar völlig recht – Bildauswahl, Texte etc. zähle ich jedoch zum Inhalt, nicht zum Aufbau. Ich meinte lediglich, dass die Elemente einer sinnvollen Struktur prinzipiell da sind (nur sicherlich anders befüllt werden könnten; also dass es prinzipiell ein Bild der Expertin gibt). Aber, wie Du sagst, wäre ein anderes Bild zweifellos besser.

Wenn es sich um identische Bezeichnungen handelt, ließe sich vielleicht die category_exists() nutzen (Codex)

Ansonsten könnte man alle existierenden Categories abfragen und mit PHP-String-Funktionen überprüfen, ob deren Bezeichnungen jeweils den relevanten Post_tag-name enthalten.

Ah, okay – nur um sicherzugehen: Wenn die Post_tag-Bezeichnung in der Category-Bezeichnung enthalten ist (es geht also um den Text, wenn die eine Bezeichnung in einer anderen Bezeichnung vorkommt)?

Also zum Beispiel:
Sportwagen (Tag) -> Alte Sportwagen (Category) -> <button class="category-alte-sportwagen">Sportwagen</button>

Da ist Shadow nur zuzustimmen: Die größte Herausforderung besteht vermutlich, Interessierte (indirekt über anderen Content) anzusprechen, da – höchstwahrscheinlich – kaum jemand direkt nach so etwas sucht.

Dann wäre es für „Conversion Rate“ vermutlich sinnvoll, das Upload-Formular gleich unterhalb von Title/Tagline anzuzeigen, statt es erst extra aufrufen zu müssen.

Der Aufbau (Hero-Section, Problemlösung, Projekte und Social Proof) ist schon sehr gut.

Mir fällt spontan auf, dass die Überschriftenhierarchie nicht stringent ist und es bspw. drei miteinander konkurrierende <h1>-Überschriften gibt (also ein SEO-Problem). Außerdem gibt es relativ viele Rechtschreib- und Grammatikfehler, die nicht nur allgemein den professionellen Eindruck schmälern, sondern auch Zweifel an einer Deiner Kernkompetenzen, Marketing-Texte, wecken.

Du könntest außerdem stärker Benefits und Outcome Deines Angebots betonen (weniger im Design als in den Texten).

Die Kund:innen-Stimmen würde ich weiter oben platzieren, vielleicht sogar schon unter der Hero section.

Kategorien und Tags sind ja zwei separate Ordnungsgruppen – meinst Du vielleicht, welcher Taxonomie ein Term angehört? Dann könntest bräuchtest Du den jeweiligen Term als Object, bspw. via $term = get_queried_object(); $tax = $term->taxonomy;

Relevant wäre noch, herauszufinden, ob der externe Datenbankserver eine Verbindung zulässt, da die Sicherheitsrichtlinien mancher Webhoster dies untersagen.

SEO-Plugins tragen, paradoxerweise, relativ wenig zur Suchmaschinenoptimierung bei. Zumeist bieten Sie Eingabemasken für Titel und Kurzbeschreibung an, die im Quelltext als unverbindliches Angebot für Suchmaschinen und Social-Media-Plattformen hinterlegt werden (etwa zur Darstellung auf einer Suchergebnisseite); dies ist bei Google jedoch lediglich ein indirekter Rankingfaktor, da die damit gefütterten Rich Snippets die Klickrate, einen direkten Rankingfaktor, beeinflussen.

Allenfalls die Erzeugung strukturierter Daten gemäß schema.org ist eine relevante Leistung mancher SEO-Plugins, da diese ebenfalls im Quellcode hinterlegten Angaben Suchmaschinen erleichtern, den Content zu verstehen.

Die eigentliche SEO spielt sich hingegen auf Text-, also auf Content-Ebene ab; das heißt, der primäre Inhalt eines Posts kann auf über Suchmaschinen vermittelte Search Intents hin optimiert werden – also wie r23 bereits geschrieben hat:

Quote

Man optimiert eigentlich nicht wirklich auf Keywords. Sondern welche Fragen hat meine Zielgruppe und wie beantwortet ich diese.

Das liegt daran, dass Post-IDs vom Datentyp integer sind (so auch der entsprechende Datenbanktyp, genau genommen bigint). String-Parameter sind in der is_page-Funktion für den Post-slug oder den Post-title als Angabe vorgesehen. Als (nicht-redundanter) Primärschlüssel ist die ID die präziseste Angabe, um in der Datenbank effizient einen Post zu finden.

Dies würde bei der Eingabe via JavaScript/React erfolgen können. Über wp.data.dispatch('core/editor').editPost() lässt sich auch der title kontrollieren/modifizieren.

Es müsste gehen, wenn die Bedingung innerhalb der function gestellt wird [ID-Parameter in is_single() entsprechend anpassen]:

function js_file() {
if ( is_single(ID) ) wp_enqueue_script('custom-js', get_stylesheet_directory_uri().'/js/example.js',array('jquery'),false,false);
}
add_action('wp_enqueue_scripts','js_file');

Quote from b3317133

Oft werden bewußt Dinge eingestellt, ohne sich über sonstige Auswirkungen darüber im Klaren zu sein.

Richtig – und deswegen müsste man vermutlich eine neue Lösung erarbeiten.

Das stimmt natürlich: Mit einer Reduktion des Wertes von left ließe sich das Problem sicherlich teilweise lösen. Der Wert von left ist jedoch vermutlich bewusst so eingestellt, damit sich die Menüs nicht überlagern; insofern wäre wohl eine robustere Lösung für das Einblenden anzustreben.

Vermutlich bewirkt das einer der eventListener, die für den Listeneintrag (<li>) geschaltet sind, mutmaßlich mouseOut. Man müsste hier CSS so schalten und einstellen, dass das Menü offen bleibt, solange man sich in den nach rechts öffnenden Untermenüs befindet.

Lässt sich dies mit einer Abfrage über is_page() / is_single() und der dazugehörigen ID lösen (also eine if-Abfrage, in welche die add_action-Direktive eingebunden ist)?