Woo-poly-integration: Probleme mit variablen Produkten

Ich habe das gleiche Problem, wenn ich aus Primärsprachen kopiere, zeige ich nur einfache Produkte, ohne die Möglichkeit, Variationen zu kopieren. Wie kann ich das lösen?

Hallo,

Haben Sie versucht, das Plugin "jQuery Migrate Helper" zu installieren?

Können Sie bitte den Code aus dem Repository verwenden, zip direkt aus dem Download-Code herunterladen und installieren, ich denke, es könnte gelöst werden, ich werde das nächste Woche viel testen, aber jedes Feedback ist willkommen.

Können Sie bitte den Code aus dem Repository verwenden, zip direkt aus dem Download-Code herunterladen und installieren, ich denke, es könnte gelöst werden, ich werde das nächste Woche viel testen, aber jedes Feedback ist willkommen.

Nach dem Download von Zip und der Installation von GitHub habe ich 2 Probleme:
1) Wenn ich ein Produkt aus der Primärsprache in die Sekundärsprache kopiere, entstehen viele Variationen (Beispiel: Wenn ich ein Produkt mit 2 Farben habe, erzeugt die zweite Sprache 10 Variationen der Farbe)
2) Nach einer Kundenbestellung ist das Produkt vergriffen, auch wenn noch Lagerbestände vorhanden sind.

1. If I copy a product from the primary language into the secondary it creates many variations, (example if I have a product with 2 colors, the second language creates 10 variations from the color)

Ich habe das gleiche Problem mit der GitHub-Version des Plugins

Es scheint, dass die neueste PR #518 etwas im Zusammenhang mit variablen Produkten vermasselt hat.

Ok, ich habe das Thema gelesen, jetzt ist das Problem ein Schreibfehler in einem Meta-Attribut. Können wir mit einer Update-Abfrage lösen und den Namen in src/Hyyan/WPI/Plugin.php korrigieren?
@mrleemon Ich habe gesehen, dass Sie an diesem Projekt mitarbeiten. Wenn Sie mir einige Richtlinien zu diesem Fehler geben, kann ich eine Lösung ausprobieren und sie der Community zur Verfügung stellen.

Entschuldigung, ich habe vor langer Zeit nur einige Korrekturen für Tippfehler vorgenommen. Mein Wissen über das Innenleben dieses Plugins ist nahe Null.
Ich weiß nicht, was getan werden muss, um diesen Variationsfehler zu beheben.

Im Moment denke ich, dass der einzige, der weiß, wie dieses Plugin funktioniert, @Jon007 ist

Ich habe gesehen, dass Nr. 518 diese Tippfehlerkorrektur enthält, die ich bereits bei Nr. 450 abgelehnt habe, da dies wahrscheinlich bestehende Websites beschädigen würde, aber

Ich habe vorerst #518 zurückgesetzt. Und ich werde später genauer hinschauen

Danke!

Vielleicht sollte das Plugin den offiziellen Polylang pll_copy_taxonomies Filter verwenden, um WooCommerce-Taxonomien (product_type, product_visibility und andere) zu synchronisieren, anstatt den aktuellen benutzerdefinierten Weg, der für die ständigen WooCommerce-Versionen anfällig zu sein scheint. Das Plugin verwendet bereits den Polylang pll_copy_post_metas Filter, um Produkt-Meta zu kopieren, daher scheint es vernünftig, pll_copy_taxonomies zu verwenden, um Produkttaxonomien zu synchronisieren.

Mit diesem Filter kann man die Taxonomien angeben, die synchronisiert oder kopiert werden sollen, und Polylang kümmert sich um die Synchronisierung/Kopie dieser Taxonomien und der zugehörigen Begriffe, wenn eine neue Übersetzung erstellt wird.

Nur eine Idee.

Ich habe mir das angesehen, aber all dies wird gefährlich veraltet, da Woocommerce sich mehr auf seine eigene API und seine eigenen Tabellen zubewegt, können Sie sich nicht darauf verlassen, Produkte als Post zu behandeln und generische postbasierte APIs zu verwenden. Bestenfalls gibt es Fehler mit dem Woocommerce-Caching-Mechanismus.

Ja, ich weiß, dass. Ich habe es als vorübergehende Lösung gedacht, während wir auf WC-API-Änderungen warten.
In der Zwischenzeit denke ich, dass wir die falsche Auswahl von "Einfaches Produkt" beheben können, wenn das Produkt variabel ist und den JS-Code in Meta.php ändert in:

Von:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .removeAttr("selected");%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '    .attr("selected", "selected");%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

Zu:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .prop("selected", false);%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '     .prop("selected", true);%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

Anscheinend ist die Verwendung von attr() und removeAttr() zum Auswählen/Abwählen von Optionen mit den jüngsten Änderungen von jQuery in WP veraltet.

Von https://jquery.com/upgrade-guide/3.0/ :

Breaking change: .removeAttr() no longer sets properties to false

Prior to jQuery 3.0, using .removeAttr() on a boolean attribute such as checked, selected, or readonly would also set the corresponding named property to false. This behavior was required for ancient versions of Internet Explorer but is not correct for modern browsers because the attribute represents the initial value and the property represents the current (dynamic) value.

It is almost always a mistake to use .removeAttr( "checked" ) on a DOM element. The only time it might be useful is if the DOM is later going to be serialized back to an HTML string. In all other cases, .prop( "checked", false ) should be used instead.

Wenn der Benutzer derzeit auf den Link WC-Duplikatprodukt klickt, wird der Produkttyp nicht über das Replikat kopiert.

Ich habe es "behoben", indem ich dies der Funktion unlinkOrginalProductTranslations() in Duplicator.php hinzugefügt habe:

$type = $product->get_type();
update_post_meta($duplicate->get_id(), '_translation_porduct_type', $type);

Ich weiß nicht, ob daran etwas nicht stimmt.

Ich würde '_translation_porduct_type' gerne komplett loswerden, es sollte nicht wirklich notwendig sein, es ist nur dazu da, um mit den Macken der Benutzeroberfläche fertig zu werden, aber das einfachste ist es im Moment, es beizubehalten und zu tun, was Sie vorschlagen

Ich wollte dich danach fragen. Warum wird der übersetzte Produkttyp in _translation_porduct_type gespeichert? Kann es bei Bedarf nicht direkt vom Originalprodukt abgerufen werden?

Ich denke, es ist kompliziert, weil beim Übersetzen von Polylang versucht wird, Ihnen die übersetzten Produktdetails zu geben, wenn Sie nach dem alten Produkt fragen, zumindest ist es einfacher, es in die Metadaten zu kopieren

Ich denke, um das _translation_porduct_type Meta loszuwerden, sollte das Plugin die WC-API-Funktion WC_Product:save() verwenden, um Übersetzungen zu speichern, anstatt sich auf eine benutzerdefinierte Lösung mit wp_insert_post Aktion direkt, aber dies bedeutet, dass ein Großteil des Codes in Meta.php umgestaltet wird, und ich weiß nicht, wo ich anfangen soll.

Hallo. Haben Sie dieses Problem gelöst?

Hallo, ich habe einige Lösungen für die Probleme mit den Variablenprodukten festgelegt, einschließlich einiger Erläuterungen zu # 430 - es wäre großartig, wenn jemand den neuesten Code testen und bestätigen könnte, welche Probleme verbleiben - idealerweise bei einem neuen sauberen Github-Problem, da es viele teilweise gab oder vollständig duplizierte Tickets und es wird schwer, ihnen zu folgen.

Danke für deine Arbeit! Ich werde den neuesten Code bei Gelegenheit testen und Sie informieren, wenn Probleme auftreten.

Ich habe ein Problem geöffnet, nachdem ich Ihren neuesten Code getestet habe:
https://github.com/hyyan/woo-poly-integration/issues/526

@hyyan @mrleemon Ich habe letzte Woche einige wichtige Änderungen überprüft und als 5.1 bezeichnet

Insbesondere habe ich den Workaround-Fix von @mrleemon auf #408 entfernt, indem ich den meta.php-Aufruf auskommentiert:
$this->syncSelectedproductType( $ID );

Bisher hatten wir dieses Problem, weil die Speicherreihenfolge zumindest in 5.0 nicht korrekt war:

1. WordPress speichert Beitrag
2. woopoly synchronisiert Post (aber WooCommerce ist noch nicht gespeichert, daher wird der Produkttyp nicht korrekt gespeichert und synchronisiert)
3. WooCommerce spart Produkt
4. [für variable Produkte speichert WooCommerce Variationen und woopoly synchronisiert diese]
5. Beim Anzeigen der Produktübersetzung hat der Workaround-Fix das Formular zurückgesetzt, um den Produkttyp im _translation_porduct_type anzuzeigen, damit die Übersetzung beim Speichern dann korrekt ist

Die Code-Revisionen greifen jetzt direkt nach dem Speichern von WooCommerce auf und wurden angepasst, um auch bei der Schnellbearbeitung (#549) und der Massenbearbeitung zu arbeiten, sodass die Produkttyp-Workarounds nicht mehr benötigt werden.

Natürlich ist dies noch nicht das Ende - das Ganze sollte noch einmal überprüft werden, um nur die woo-API zu verwenden und die wp-API zu vermeiden -, sondern sollte einige der seltsamen Verhaltensweisen entfernen.

Toll! Dieser Workaround-Fix war wirklich schrecklich.
Ist das falsch geschriebene _translation_porduct_type Meta also auch nicht mehr notwendig?
Ich werde diese aktualisierte Version testen, wenn ich eine Minute Zeit habe.

Danke!

Ich habe die falsch geschriebene _translation_porduct_type-Metazuweisung vorerst drin gelassen, aber sie wird nicht verwendet. Wenn diese Version in Ordnung ist, könnte eine nachfolgende Version diesen und anderen redundanten Code entfernen

Ich habe diese neue Version getestet und ein Problem gefunden:

1. Ich habe eine Website mit drei Sprachen (Spanisch, Englisch und Französisch). Spanisch ist die Standardeinstellung. Die Synchronisierungsoption "Produkttyp" in woopoly ist aktiviert.
2. Ich füge ein neues Produkt auf Spanisch hinzu
3. Ich wähle "Gruppiertes Produkt" (oder einen anderen Produkttyp als "Einfaches Produkt") und speichere.
4. Das Dropdown-Menü Produkttyp zeigt den ausgewählten Produkttyp an.
5. Ich klicke auf einen "+"-Link in der Metabox "Sprachen", um eine Übersetzung hinzuzufügen.
6. Das Dropdown-Menü für den Produkttyp in der neuen Übersetzung ist deaktiviert (die Synchronisierungsoption "Produkttyp" ist aktiviert), zeigt jedoch "Einfaches Produkt" anstelle des ausgewählten Produkttyps im Standardsprachprodukt an.

Ok ja ich schau mal.
Das Ändern von Produkttypen (und anderer Eigenschaften) für vorhandene Produkte sollte in Ordnung sein.

@mrleemon hat eingecheckt: bei neuen Übersetzungen, die benötigt werden, um den WordPress-Hook

OK danke!
Ich teste es später, wenn ich einen Moment Zeit habe, und melde mich so schnell wie möglich zurück.

Ich habe diese neue Version getestet und mein Problem mit neuen Übersetzungen ist behoben.
Danke!