Beiträge von Oliona

Ich bin unsicher, ob dies das richtige Unterforum ist. Ein Problem habe ich nicht, aber eine grundsätzliche Frage, die mich allgemein beschäftigt. Vielleicht mag mir jemand seine persönliche Einschätzung mitteilen.

Es geht um den Umgang mit CSS-Anpassungen. Mein Theme ist kein ausgewiesenes Block-Theme (ich nutze seit 3 Jahren Shoptimizer als Child-Theme, da ich einige wenige Dinge anbiete und die Shop-Funktionalitäten schätze. Der Kern meiner seit 2006 existierenden Webseite ist redaktionell orientiert). Ich arbeite mit Gutenberg-Blöcken, aber auch mit eigenem CSS in der style.css des Themes, sodass ich komplexere Designelemente umsetzen kann. Soweit, so gut.

Meine grundsätzliche Frage zielt nach der Best Practise: Ist es grundsätzlich besser, wordpresseigene Auszeichnungen zu nehmen (durch Klick-Klick im Backend) oder Änderungen in der style.css vorzunehmen? Oder gibt es einen ganz anderen Ansatz?

Konkretes Beispiel: Ich möchte einen Block auszeichnen, der die gesamte verfügbare Breite einnehmen soll und sich durch eine leichte Schattierung sichtbar, aber dezent vom Inhalt vorher und danach abhebt. Ich erhöhe zusätzlich das Padding für eine etwas luftigere Optik.
Das alles kann ich in einer benutzerdefinierten Klasse .infocard realisieren, die ich bei Bedarf einem Element zuweise. Ich kann das Element jedoch auch durch die wordpress-eigenen Stile gestalten, den Hintergrund weiß färben, das Padding erhöhen, die Gesamtbreite ändern. Hierzu muss ich jedoch viel mehr Klickaufwand betreiben, daher bevorzuge ich die CSS-Lösung.

Andrerseits enthält die style.css auch einige !important-Anweisungen, die bereits vorhandene Deklarationen von WordPress und Theme überschreiben – nicht gerade effizient oder elegant …

Das neueste WordPress-Theme »twentytwentyfive« hat gar keine CSS mehr, sondern arbeitet ausschließlich mit .json. Gut - bei Shoptimizer geht das wohl nicht, aber ich würde gerne lernen, ökonomischer zu arbeiten.

Was ist Ende 2024 bei einem nicht block-basierten Theme Best Practise? Wie macht ihr das? Danke für alle Impulse. :)

Ich hab's: Die fehlende Anzeige hängt direkt mit dem fehlenden Häkchen zusammen. Sobald Woocommerce Analytics aktiviert ist (mit Setzen des o. g. Häkchens), kann man unter Statistiken » Einstellungen sogenannte historische Daten importieren. Das habe ich gemacht, nun ist auch der Umsatz wieder da. :)

Zitat von threadi

Das hier klingt doch eher nach deinem Problem: https://wordpress.org/support/topic/…rmission-error/ - Lösung wäre das Setzen eines vermutlich bei dir fehlenden Häkchens.

Mein Held des Tages! Threadi, Du bist mein Retter. Das war's. Warum war das das? o_O Zuviel Rotwein? Grüner Tee zu lange gezogen? Ich weiß es nicht.

DANKE! :)

Kurze Ergänzung: Ich habe immer noch 0 Euro Umsatz, das stimmt nach wie vor nicht. Es ist aber nicht wichtig, die Buchhaltung mache ich eh extern. Aktuell werden keine Debug-Fehler angezeigt. Sollte ich etwas dazu finden, melde ich mich.

Ich bin offensichtlich nicht alleine mit diesem Problem, wie dieser Thread im Support-Bereich des Plugins Woocommerce zeigt. Eine Lösung sehe ich da noch nicht.

WP 5.9
Woocommerce 6.2.0
__________________

Meine Lieben, ich komme nicht mehr in die »Woocommerce Analytics«. Die »Berichte« sind noch zugänglich; dort erscheint dann oben der Hinweis, dass sie mit Veröffentlichung von WooCommerce 4.0 ersetzt würden. Der Klick auf »Woocommerce Analytics« führt dann zum frustrierenden Ergebnis: »Sie dürfen leider nicht auf diese Seite zugreifen«. Mir wird auch kein Netto-Umsatz angezeigt – hängt wohl zusammen.

Bisher versucht (in einer Staging-Umgebung):
Alle Plugins deaktivieren
Auf das Standard-Theme wechseln
die wp-config.php zurücksetzen
Datenbank-Diagnose-Tools nutzen (u. a. über Plesk meines Hosters)
Benutzerrechte zurücksetzen (Status / Werkzeuge)
Authentication Unique Keys and Salts neu erzeugt

Nicht zeigt Wirkung.

Schließlich habe ich Debuggen aktiviert und finde Fehler (siehe Screenshot). Erkenntnis Nr. 1: Ich hätte mir viel Zeit ersparen können. :rolleyes:

Erkenntnis Nr. 2: Ich komme trotzdem nicht weiter. Wer kann mir hier helfen? Ich wäre sehr dankbar.

Zitat von mensmaximus

Ein einheitlicher Bruttopreis, so wie das in Germanized als Standard für OSS geregelt ist, verstößt im Übrigen gegen EU Recht, weil sich dadurch der Nettopreis je nach Lieferland verändert, auf den die Anti-Diskriminierungsrichtline abstellt.

Das stimmt wohl so eben nicht – zumindest sagt das eine auf IT-recht spezialisierte Kanzlei. Dort heißt es (Zitat gekürzt):

»Was wie ein Widerspruch anmutet, ist tatsächlich allerdings keiner:
Das geltende Preisangabenrecht verlangt gerade nicht, dass der jeweilige Umsatzsteuersatz im Online-Shop angezeigt wird.
Verlangt wird nur, dass gegenüber Verbrauchern der Preis inklusive Umsatzsteuer, also der Brutto-Preis, angezeigt werden muss.
Welcher Steuersatz dahinter steckt, ist aber nicht relevant. Für den Verbraucher muss vielmehr nur ersichtlich sein, dass der Preis die Umsatzsteuer enthält.« (Quelle: Phil Salewski: EU-Umsatzsteuerreform seit dem 01.07.2021: Wie sind Preise im Online-Shop bei Verkauf ins EU-Ausland anzugeben? 06.09.2021).

Ich denke wohl richtig; gerade bin ich beim weiteren Recherchieren auf einen passenden Artikel von Dennis Nißle (Inhaber von Vendidero) gestoßen, der das Problem beim Namen nennt. Die MwSt. muss vor Abzug des Gutscheins ermittelt werden, dann ist die Rechnung richtig ausgestellt und der Gutschein wird korrekt besteuert. Da muss ich wohl YITH anschreiben, ich habe die Pro-Version gekauft.

Ich brauche gedankliche Klärungshilfe. :-)

Ich habe ein Plugin installiert, das den Kauf von Geschenkkarten ermöglicht – soweit, so gut. Die Behandlung von Gutscheinen und die Unterscheidung zwischen Einwert- und Mehrwertgutscheinen kann man online recherchieren, und mein Finanzamt bestätigte mir das, was ich dort gelesen hatte … auch gut. Da ich physikalische und digitale Produkte in D und der EU anbiete, ist meine Geschenkkarte vom Typ »Mehrwert« und wird beim Kauf nicht besteuert.

Nun habe ich testweise eine Karte über einen Warenwert von 50 Euro »gekauft«, Waren für 49,50 Euro in den Warenkorb gelegt und den Code eingelöst. Dort bleibt dann ein Restbetrag, der mit aufgeschlagenen Versandkosten einen kläglicher Rest an Steuern ergibt.

Ich habe die Bestellung nicht wirklich abgeschlossen (und habe daher die erzeugte Rechnung nicht gesehen), aber da stimmt doch etwas nicht. Von meinem logischen Verständnis müsste hier die Mehrwertsteuer für den vollen Kaufbetrag ohne Rabatt fällig (und von mir abgeführt) werden und nicht nur das kleine Steuerhäuflein der Restsumme. Versteht mich jemand? Oder habe ich einen Knoten im Hirn?

Vermutlich wäre es besser, wenn ich mein digitales Produkt ausschließe, dann könnte ich die Geschenkkarte mit 19 % besteuern und wieder gut schlafen. :-)

Ich brauche Eure Hilfe.

Ich seit längerer Zeit dieses Snippet. Ich kann seine Qualität nicht einschätzen, aber es funktioniert einwandfrei.

Das Szenario konkret:
Der Mindestbestellwert berücksichtigt aktuell alle Produkte (versandfähige wie virtuelle).

Ich biete ein E-Book mit einem Preis von X an, das Kunden separat erwerben können, ohne weitere versandfähige Produkte kaufen zu müssen. Das ist mir wichtig. Viele Kunden wollen exakt dieses E-Book und nichts anderes.
Da ich viele geringpreisige Artikel und damit verbundene Kleinstbestellungen versenden muss, die oft logistisch in keinem günstigen Verhältnis zum Gesamtbestellwert stehen, möchte ich den Mindestbestellwert anpassen. Dieser sollte jedoch höher als X liegen. Greta freut sich auch, wenn nicht jeder nur 2 Puderdosen kauft und sich zusenden lässt. :-)
Mein Problem: Setze ich den Preis nach oben, kann das E-Book nicht mehr separat gekauft werden.

Die Abfrage im Snippet dürfte aus meiner Sicht zur Ermittlung des aktuellen Bestellwerts, der gegen den Mindestbestellwert geprüft wird, ausschließlich nicht-virtuelle Produkte berücksichtigen, dann müsste sich das umsetzen lassen, was ich mir vorstelle. Nur: Meine geringen PHP-Kenntnisse sind Jahre her und waren auch nie erwähnenswert – ich schaffe das offen gestanden nicht.

if (( WC()->cart->subtotal < $minimum ) [COLOR=#ff4d4d]&& »subtotal berücksichtig nur normale Produkte (und keine virtuellen)«[/COLOR] ){
...

... irgendwie … so? (Fragt sich der Laie)

Weiß jemand, wie ich die Abfrage ergänzen bwz. einschränken kann auf nicht virtuelle Produkte?

:) FloRet, Du bist mein heutiger Held —Danke! Der Tipp mit dem Plugin war meine Rettung. Es funktioniert wieder so wie es soll, so sieht es zumindest bisher aus, auch mit aktiviertem WP HTML Mail für WooCommerce.

Man merkt, hier ist ein »Jungs-Forum«, es fehlt der Küßchen-Smiley! ;)

Aktuell ist es tatsächlich dieses Plugin, das die Fehler verursacht … oder, neutraler formuliert, im Kontext des Woocommerce-Updates scheint es Inkompatibilitäten zu geben. Schade … ich schätze dieses Plugin.

Ich komme der Sache näher … das Plugin WP HTML Mail - WooCommerce von Hannes Etzelstorferhttps://codemiq.com/macht offenbar Probleme … ich melde mich gleich.

Ich habe es mit meiner versucht, der Umlaut im Nachnamen ist mit »ae« kodiert. TLD ist .com.

Das Auffällige ist, dass ich bis vor dem Update gestern keine Probleme hatte. Heute meldete sich eine Kundin per E-Mail, weil sie den Bestellvorgang nicht abschließen konnte (eben wegen der angeblich nicht gültigen E-Mail-Adresse) und ihr Gutschein zwar angenommen wurde, aber keine Minderung des Kaufpreises erfolgte.

Seitdem sitze ich hier und teste. Der erste Schritt: Alle Plugins testweise deaktivieren und wieder aktivieren. Keine dauerhaften Erfolge. Dann habe ich die Versionshistorie von Woocommerce angeschaut und entdeckte folgende Hinweise:

• Dev – Fixed number of arguments for all occurrences of the woocommerce_valid_order_statuses_for_cancel filter. #23704
• Dev – REST API – Stop order creation if invalid data is sent. #23325
• Dev – Introduce new wc_load_cart function for dynamically loading and initializing the cart. #23794

Mir erscheint da eventuell ein Zusammenhang zu bestehen.

Eine kleine Ergänzung, da mehrere Fehler auftauchen: Mir scheint, dass Ajax Probleme macht. So finde ich, wenn ich im Browser die auf der Seite aktiven Scripte prüfe, einen Hinweis auf nicht geladene iQuery-Scripte. Interessanterweise hat das neue Woocommerce-Update einige DEV-Änderungen, die Ajax betreffen.

Hat noch jemand Auffälligkeiten bemerkt? Ajax … ich habe auch Probleme im Backend (kann nur auf Umwegen alle Bestellungen und alle Produkte sehen, sonst zeigt sich eine graue Seite …). Mir scheint, das hängt alles zusammen. Soviel Probleme kann man gar nicht haben. :)

Ihr Lieben, es hakt, und ich finde den Grund nicht. Mir scheint, als träten die Fehler seit dem Update von Woocommerce gestern auf … wie dem auch sei, einer der Fehler ist folgender:

Beim Checkout wird trotz korrekter Syntax der E-Mail-Adresse bemängelt: »Bitte geben Sie eine gültige E-Mail-Adresse an.«

Ich vermute, dass sich durch das Update (?) eine Zeichensatzdefinition »eingeschlichen« hat (wenn ja, wo?), die nicht mit der Eingabe klarkommt. Mehr fällt mir an dieser Stelle nicht ein. Meine Webseite ist im Profil angegeben. Gerne verlinke ich sie auch, bin aber nicht sicher, ob das gewünscht ist.

Die Gutscheine zicken auch, aber das kläre ich in einem eigenen Thread. ;-)

Herzlichem Dank fürs Lesen, helfen – und trösten.

Ich vermute, es hat (wie mensmaximus schon andeutet) etwas mit der Lagerverwaltung zu tun, die

zum einen über das Dialogenster PRODUKTDATEN > INVENTAR kontrolliert werden kann
(wenn Du dort »Verwaltung des Lagerbestands auf Produkt-Ebene aktivieren« aktivierst, kontrollierst Du die Verfügbarkeit des Produkts für alle Varianten)

oder in den Varianten selbst, sobald man dort die Option »Lagerbestand verwalten« aktiviert.

Ich empfehle Dir, in den

PRODUKTDATEN > INVENTAR die »Verwaltung des Lagerbestands auf Produkt-Ebene aktivieren« zu deaktivieren

und unter den Varianten die Option »Lagerbestand verwalten« zu aktivieren und dort Zahlen zu notieren.

Off topic:
kollegehenel
Schade, dass Du eine Lösung wünschst, aber offenbar keine Zeit hast, Details anzugeben noch kurz mitzuteilen, ob das Problem gelöst wurde (und wenn, wie – dann haben alle etwas davon).

Nur kurz als Info: Ich habe eine andere Lösung für mich umgesetzt – das hier genannte Problem konnte ich nicht lösen. :-)

Ich trenne die Nummernkreise durch ein Präfix und werde daher weiter Bestellungs- und Rechnungsnummern identisch halten. So ist auch ein Ausdrucken auf »schönem Papier« weiter möglich. :-)

Ihr Lieben,

ich brauche Rat: Bisher hatte ich identische Bestell- und Rechnungsnummern. Daher konnte ich WooCommerce Print Invoice & Delivery Note verwenden, um Rechnungen auf hochwertigem, im Offsetdruck hergestellten Geschäftspapier mit Logo etc. ausdrucken (nämlich nur die reinen Textinhalte, da ich kein Logo usw. hinterlegt habe), während Germanized für ansehnliche PDF-Rechnungen sorgte. Dort ist mein Geschäftspapier als PDF hinterlegt und sorgte für Konsistenz im Aussehen.

Da es sinnvoll ist, beide Nummernkreise zu trennen (denn nicht jede Bestellung führt zu einer Rechnung, wie ich mittlerweile begriffen habe), will ich 2018 genau dies umsetzen. Nur: WooCommerce Print Invoice & Delivery Note greift, wenn ich Papier-Rechnungen drucken möchte, auf die »Order-ID« zu, nicht auf die von Germanized generierte »Order-Number«. Das bedeutet: Ich kann zwar die Bestell-Nummer auf diesen Rechnungen drucken, nicht jedoch die korrekte Rechnungs-Nummer.

Was ich machen könnte: Rechnungen digital versenden, Lieferscheine ausdrucken und in die Pakete legen – als Kompromiss – da sich Lieferscheine auf eine Bestellung beziehen und hier die Angabe der Bestell-Nr. zulässig ist. Nur leider will WooCommerce Print Invoice & Delivery Note nicht die korrekte Überschrift ausdrucken, dort steht immer »Rechnung«, auch wenn ich den »Lieferschein« wähle.

Im Template (/templates/print-order/print-content.php) identifizierte ich den Titel des Dokuments (oder meine, ihn identifiziert zu haben):

<h2><?php wcdn_document_title(); ?></h2>

Aber selbst, wenn ich hier die Variable entferne und einfach »<h2>Lieferschein</h2>« angebe, wird immer »Rechnung« ausgegeben. :-(

Irgendeine Idee?

Ja, meinen. :-) Im Ernst: Die meisten kommerziellen Seiten tragen die Endung .com; es ist die häufigste TLD. »com« steht für »commercial«.

Hallo, rejoin14,

mit .com liegst Du auch international richtig. Du kannst die DE-Domain eher als Domainweiterleitung anlegen. Für eine sprachliche Untergliederung gibt es mehrere Lösungen; leider bin ich da technisch nicht fit genug, um Dir zu raten. :-)