Beiträge von threadi

    Das sind 2 völlig verschiedene Baustellen.

    Bei MySQL solltest du im Bereich von WordPress so vorgehen wie WordPress es vorgibt. Siehe oben.

    Die Dateinamen (URLs) deiner Seiten könnten sowohl Bindestriche als auch Unterstriche enthalten. Der Unterschied ergibt sich hier in der Interpretation durch Suchmaschinen (Stichwort SEO): Bindestriche werden hier bevorzugt. Siehe z.B. diesen Beitrag von 2011 der auch heute noch (und viel bedeutender) Relevanz hat: https://developers.google.com/search/blog/20…destriche?hl=de

    In CSS-IDs- und -Klassen ist es dir überlassen wie du mit den Trennzeichen umgehst. Das hat für Browser keinerlei Bedeutung. Rein vom Lesen her als Entwickler finde ich Bindestriche angenehmer. Allerdings kommt es auch auf das Programm an mit dem man ggfs. den Code bearbeitet. Geschmackssache.

    Es geht hier weniger um CDN als vielmehr um jegliche von extern eingebundenen URLs. Beim Durchklicken deiner Seite sehe ich grundsätzlich erstmal keine externen Einbindungen. Aber es gibt Ausnahmen: bei der Trinkwasser- und der Preise-Seite hast du einen Kalender eingebaut der ein Script lädt um angezeigt zu werden (tidycal). Und das ganz ohne, dass ich dazu gefragt werden. Dieses Script lädt dann noch ganz viel anderes nach, u.a. auch einen Google Tag Manager von dem Service der den Kalender bereitstellt. Das müsstest du mit einem Consent Tool lösen (d.h. laden blockieren bevor Nutzer nicht zugestimmt hat) und dann auch in der Datenschutzerklärung mit auflisten. Alternativ wäre nur der Weg auf den Kalender zu verzichten.

    Auf der Kontakt-Seite lädt das Ninjaforms-Formular eine Schriftart von Google nach. Das müsstest du deaktivieren.

    Deine Matomo-Einbindung scheint übrigens auch nicht mehr zu funktionieren. Das für die Zahlung in deinen Seiten eingebaute Script lädt einen HTML-Code statt einen JavaScript-Code.

    Von irgendeinem "mixpanel" sehe ich nichts, hab aber auch nicht alles Seiten angeguckt. Möglich wäre - wie oben schon gesagt - dass du das siehst wenn du im Backend angemeldet bist. Schau dir die Seiten im privaten Modus eines Browsers oder einem völlig anderen Browser an, wo du nicht angemeldet bist. Ich würde dir weiterhin empfehlen dich hierbei nicht auf KI zu verlassen. Wenn du mal abgemahnt werden solltest, kannst du nicht sagen "aber die KI hat doch gesagt .." sondern musst Fakten liefern.

    WordPress kennt keine Produkte und auch keine Steuern, kann sich hier daher auch nicht einmischen.

    WooCommerce berechnet Versandsteuern standardmäßig auf Basis der enthaltenen Produkte. Siehe auch Dokumentation dazu: https://woocommerce.com/document/setti…pping-tax-class

    Dort findet man auch eine Anleitung zum Umgang mit höheren Steuern für Versand als für Produkte: https://woocommerce.com/document/setti…tional-tax-rate

    Natürlich kann auch German Market sich hier einmischen, weshalb deren Support für dich auch weiterhin der erste Anlaufpunkt wäre.

    Kann ich bei mir nicht nachvollziehen. Hab in einer frischen WordPress-Installation nur das Classic Editor Plugin aktiviert. Erstelle eine neue Seite, wo ich "test" als Text eintrage. Dann speichere ich die Seite. Anschließend zeigt er mir wieder den Editor an wo ich zwischen Visual und Code wechsle. Es ändert sich dabei nichts am Inhalt des Editors.

    Vermutung: vlt. mischt sich dein Browser hier ein. Teste es mal mit einem anderen.

    Übrigens deaktiviert das Plugin Classic Editor einfach nur die Gutenberg-Komponenten, wodurch wiederum die in WordPress weiterhin enthaltenen Komponenten von TinyMCE für den Editor genutzt werden. Es ist keinesfalls so, dass das Plugin den Editor mitbringt.

    Ja, genau diese Weiterleitung solltest du unbedingt einrichten. Das ist für die Wiederauffindbarkeit der Seiten, die nun umgezogen sind, essentiell.

    Soweit ich sehe wird in der originalen Website kein SEO-Plugin eingesetzt was diese Aufgabe übernehmen könnte. Stattdessen könntest du aber auch einfach dieses Plugin nutzen: https://de.wordpress.org/plugins/redirection/ - hier musst du dann pro weiterzuleitende URL einen Eintrag vornehmen, die die alte URL zur neuen umleitet. Der HTTP Status sollte 301 sein, was Suchmaschinen signalisiert, dass die URL dauerhaft umgezogen ist.

    Abgesehen davon hast du auf der Seite ganz andere Probleme, die durchaus relevanter wären und die ebenfalls beweisen, dass Yoast nicht alles sehen kann. Du hast eine falsche Reihenfolge von Überschriften die durch den Header "[size=14]wie kommst du voran?" entsteht. Dieser Text ist bei dir eine h3, was semantisch keinen Sinn macht. Ich würde empfehlen daraus einen Absatz zu machen - auch den kann man so stylen.

    Du hast auf der Seite zudem durchaus Bilder mit Alternativtexten. Diese sind auch durchaus passend benannt finde ich. Sieht Yoast offenbar auch nicht.[/SIZE]

    Also bzgl. Performance ist die aktuelle Live-Seite schon recht gut. Wenn er ab und zu hängt, ist das keine Sache die durch einen Theme-Wechsel gelöst werden kann. Viel mehr würde ich empfehlen mal zu schauen, welche Plugins genutzt werden und ob diese wirklich alle notwendig sind. Eine Analyse der Datenbankabfragen kann auch hilfreich sein (mit dem Plugin Query Monitor machbar, würde ich jedoch empfehlen nicht dauerhaft in einem Live-System laufen zu lassen). Wenn es letztlich eine unzureichende Leistung beim Hosting sein sollte, wende dich an deren Support. Es gäbe hier viele Ansätze - aber das Theme zu wechseln sehe aus dem Grund ich als allerletztes an.

    Wenn dir die Kenntnis fehlt, such dir jemanden der dich dabei (besser) unterstützen kann. Hier im Forum gibts dafür die Jobbörse: https://forum.wpde.org/forums/jobboerse.33/ - alternativ auch hier das englische Jobportal: https://jobs.wordpress.net und ebenso findet man manchmal auf regionalen Meetups Menschen die einem helfen können (in deinem Fall Dresden oder gar Leipzig).

    Ich arbeite selbst nicht mit GeneratePress, kenne aber einige in unserem lokalen WordPress-Netzwerk die darauf schwören. Was mir bei deinem Projekt auffällt: GeneratePress nutzt die GP-eigenen Blöcke und Layouts um die Ansicht abzubilden. Ich vermute, wenn man statt diesen eher die WordPress-eigenen Blöcke verwendet hätte, sähe der Quellcode schon schlanker aus. Bei GeneratePress Pro hat man nämlich inzwischen durchaus die Wahl zwischen dem GeneratePress-eigenen Layouts und den Blöcken. Es ist daher recht frei in den Möglichkeiten, auch für die Gestaltung.

    Ich sehe aber andere Baustellen bei der neuen Seite. Ich vermute das Consent Tool fehlt noch, denn bei der Live-Seite ist es vorhanden. Ohne das wird derzeit von shopvote und GoogleTagManager etwas geladen, ohne dass der Nutzer darüber informiert ist. Wenn das so bleiben sollte gehst du ein Abmahnungsrisiko ein.

    Die Art und Weise des Einsatzes von Überschriften ist auch nicht durchgehend gelungen. Es scheint ein Overlay zu geben in dem eine Telefonnummer als Überschrift deklariert ist. Macht semantisch wenig Sinn und könnte zu einer weniger positiven Bewertung führen. Auf den meisten Unterseiten existieren auch Lücken zwischen den Überschriftsgrößen.

    Die Live-Seite ist beim PageSpeed-Test besser bewertet als die neue. Bzgl. Barrierefreiheit haben beide jedoch Nachteile - da fehlt an einigen Stellen der Kontrast, vor allem bei grauen Schriften aus weißem Grund.

    Ich finde auch, dass die DOM-Größe keine so wichtige Rolle spielt. Ich würde erstmal hinterfragen was dein eigentlicher Schmerz ist, weshalb du diesen Umbau angegangen bist. Einfach nur, weil etwas aufgebläht wirkt, kann es ja nicht sein. Hast du mit der aktuellen Seiten denn spürbare Nachteile an irgendeiner Stelle?

    Grüße aus Leipzig ;)

    Auf Grund der Pfadstruktur tippe ich auf Plesk als Verwaltungssoftware für den Server. Dort gibt es mit ModSecurity auch ein Sicherheitstool, was solche Zugriffe ebenfalls blockieren könnte. Wobei das bei einfachen Bildern schon merkwürdig wäre.

    Wenn du German Market deaktivierst geht es? Dann wäre deren Support der Ansprechpartner.