Beiträge von Babelfisch

Edi: Plugins sind nicht daran Schuld. Auch ein „nackiges“ Wordpress zeigt die falsche Zeit an.

Ingo: Die php.ini wird nicht mit einer lokalen php.ini oder durch die .htaccess überschrieben. Die Ausgabe von phpinfo() habe ich auch aus einem Testscript direkt in dem DocumentRoot der Wordpress-Installtion geholt. Dort sind also exakt die gleichen Einstellungen aktiv wie in WP selbst.

Ja, auf dem Server ist in der php.ini die Zeitzone korrekt gesetzt:

date.timezone = "Europe/Berlin"

phpinfo() zeigt auch an:

[TABLE="width: 934"]

[TD="class: e, bgcolor: #CCCCFF"]date/time support [/TD]
[TD="class: v, bgcolor: #DDDDDD"]enabled [/TD]

[TD="class: e, bgcolor: #CCCCFF"]"Olson" Timezone Database Version [/TD]
[TD="class: v, bgcolor: #DDDDDD"]2017.2 [/TD]

[TD="class: e, bgcolor: #CCCCFF"]Timezone Database [/TD]
[TD="class: v, bgcolor: #DDDDDD"]internal [/TD]

[TD="class: e, bgcolor: #CCCCFF"]Default timezone [/TD]
[TD="class: v, bgcolor: #DDDDDD"]Europe/Berlin[/TD]

[/TABLE]

In meinen eigenen Scripten nutze ich es ja auch und die PHP-Datumsfunktionen funktionieren alle korrekt. date(DATE_RFC2822) zeigt mir bspw. die korrekte lokale Zeit an und wenn ich vorher ein date_default_timezone_set('UTC') mache, dann wird auch die UTC-Zeit mit -2 Stunden korrekt angezeigt.

Zitat von Edi

Verwendet wird, was als Ortszeit angezeigt wird.

Meine Frage ist ja aber nun, wie ich Wordpress beibringe, die korrekte Ortszeit zu ermitteln? Natürlich kann ich eine falsche Zeitzone einstellen aber das kann es ja nicht sein.

Ortszeit vom Server ist in meinem Beispiel (um bei der Zeit von gestern zu bleiben) der 14. September um 23:33 Uhr CEST. Laut Wordpress ist es aber 23:33 Uhr UTC und damit ist die Ortszeit von Wordpress in Berlin der 15. September um 01:23 Uhr. Wordpress nimmt also die Ortszeit ohne Rücksicht auf die echte Zeitzone und interpretiert sie als UTC.

Gleich vorweg: Das wurde schon mehrfach gefragt aber eine befriedigende Antwort habe ich bisher noch nicht zum Thema Zeitzone gefunden.

Mir ist erst jetzt aufgefallen, dass in Wordpress und meinem WooCommerce Shop eine falsche Zeit verwendet wird. Die aktuelle Uhrzeit geht zwei Stunden vor und damit werden bspw. Bestellungen im Shop in der Zukunft getätigt. Das soll natürlich auf keinen Fall sein.

Im Backend habe ich natürlich die korrekte Zeitzone Berlin gewählt aber offenbar stimmt schon die Ausgangszeit nicht:

[INDENT]Koordinierte Weltzeit (UTC) ist 14.09.2017 23:33:09. Die Ortszeit ist 15.09.2017 1:33:09.[/INDENT]

Nun ist aber zum Zeitpunkt der Lesung UTC 21:33 Uhr und die Ortszeit ist 23:33 Uhr.

Wenn ich es richtig verstanden habe, liegt der Fehler bei Wordpress, welches als Basiszeit immer UTC nicht, egal welche Zeitzone auf dem Webserver eingestellt ist. Auf meinem Webserver ist eben CEST eingestellt, was sicherlich auch nicht ungewöhnlich ist.

Auch nach einigem Googeln habe ich nichts gefunden, wie ich ohne große Verrenkungen die korrekte Zeit in Wordpress einstellen kann. Eigentlich muss WP ja nur die Zeitzone auf dem Server ermitteln und sich daraus dann UTC „basteln“ und damit dann die lokal eingestellte Zeitzone nutzen. Geht das echt nicht oder habe ich was übersehen?

Gruß

Ich hatte heute morgen ein komisches Problem mit einer PayPal-Zahlung. Die Bestellung ist – obwohl die Zahlung abgeschlossen ist (auch bei PayPal auf der Webseite) – in WooCommerce als „In Bearbeitung“ gekennzeichnet. Interessant ist, dass sie aber vorher schon fertigstellt war.

So sieht der Verlauf aus:

• Status der Bestellung von Zahlung ausstehend auf In Bearbeitung geändert.
• Status der Bestellung von Zahlung ausstehend auf Fertiggestellt geändert.
• PDT-Zahlung abgeschlossen
• IPN-Zahlung abgeschlossen

Vermutlich hängt es damit zusammen, dass hier eine IPN- und PDT-Zahlung gleichzeitig vorgenommen wurde. Wie es dazu kam, kann ich aber ebensowenig nachvollziehen.

Hat jemand eine Idee, was das schiefgegangen ist? Alle anderen PayPal-Zahlungen funktionierten bis jetzt problemlos.

• WordPress: 4.8.1
• WooCommerce: 3.1.2
• WooCommerce Germanized Pro
• PayPal: Standard von WooCommerce

Gruß

In meinem Posting habe ich nach einem passenden Hook gefragt und der war für mich nicht in 15 Minuten zu finden. Danke für die schnelle und richtige Antwort! Danach ging es um CRUD und ich war irritiert, weil du $cartItem->get_product_id() genannt hast, was es aber gar nicht gibt. Deshalb hatte ich nachgefragt und so hat sich die ganze Diskussion entwickelt.

Ich hatte sowieso vor, das auf Github zu melden und damit können wir das Thema gerne abschließen.

Mit sauberen Klassendefinitionen kenne ich mich schon gut aus und das ist eben in meinen Augen nicht ganz sauber gemacht. Du kannst nicht einfach sagen, dass post_type von WordPress kommt und deshalb nicht von CRUD erfasst werden muss. Dann sollte es get_id() nämlich genauso nicht geben, da die ID auch von WordPress kommt.

Sauber wäre es IMHO, wenn post_type gar nicht erst in den Daten landen würde. Mit get_type() gibt es ja einen Funktion für den Produkt-Typ und wer post_type tatsächlich benötigt, kann es sich anderweitig besorgen.

Hmm, die Klasse WC_Product_Variation ist aber inkl. alle Elternklassen eine reine WC-Klasse und entweder GRUD wird konsequent umgesetzt oder nicht. Außerdem ist der WordPress post_type von einem variablen Produkt in der Tabelle wp_posts = 'product' und in der Klasse wird für post_type aber 'product_variation' zurückgegeben. Das kommt also schon von WooCommerce.

Ich habe aber gerade gesehen, dass man mit get_type() zumindest den Typ ohne die „rohe“ Eigenschaft ermitteln kann.

Zitat von mensmaximus

Es geht NICHT um den Inhalt des Warenkorbs per se, sondern um die Eigenschaften der darin enthaltenen Produkte. Diese - die Eigenschaften der Produkte - müssen über die CRUD Klassen abgefragt werden.

Hast du eine Idee, warum man die ID oder Parent-ID mit get_id() oder get_parent_id() abfragen kann, jedoch nicht den post_type? Die Methode get_post_type() gibt es nicht und ich muss da dann wieder auf die Eigenschaft zurückgreifen.

Das scheint mir alles noch sehr schwammig implementiert zu sein.

Ok, aber nur bei einem einfachen Produkt. Bei einem variablen Produkt wäre es [COLOR=#333333]$cartItem['data']->[/COLOR]get_parent_id(), da in ['data'] ein WC_Product_Variation-Objekt ist. Ist nicht wirklich gut durchdacht.

Da momentan bei $cartItem['product_id'] noch keine Deprecation-Warnung kommt, gehe ich mal davon aus, dass es noch eine Weile erhalten bleibt und lasse es erst mal so. Ich hab’s aber zumindest auf dem Schirm.

Ok, aber wie würde das in meinem Beispiel aussehen? Deine Variante $cartItem->get_product_id() geht so erst mal nicht, da $cartItem eben ein Array und kein Objekt ist.

Zitat von mensmaximus

Schau mal in Dein error.log. Ich würde annehmen wollen, dass Du bei WooCommerce 3.0 "Deprecated" Meldungen erhältst. Mit den neuen CRUD Klassen scheibt man $cartItem->get_product_id()

Bin gerade bei der Umstellung auf WC 3 und auch da wird noch ein Array geliefert. Auch in der Doku steht dazu:

Zitat

get_cart( )
Returns the contents of the cart in an array.

Da hat man also CRUD noch nicht implementiert.

Danke für den Hinweis! Ich bin noch bei 2.7, da die 3er bisher noch zu viele Baustellen hat. Werde frühestens bei 3.1 umsteigen.

Ich habe jetzt woocommerce_after_checkout_billing_form genommen, da das wohl der letzte Hook davor ist. Falls andere ein ähnliches Problem haben, hier mal meine Lösung:

function action_woocommerce_after_checkout_billing_form()
{
    global $woocommerce;
    
    $cart = $woocommerce->cart->get_cart();




    foreach($cart as $item => $cartItem)
    {
        if ($cartItem['product_id'] == MEINE_PRODUKT_ID)
        {
            $woocommerce->checkout()->enable_guest_checkout = false;
            return;
        }
    }




}; 
add_action( 'woocommerce_after_checkout_billing_form', 'action_woocommerce_after_checkout_billing_form', 10, 2 );

Gruß

Mist, mein Fehler. Ich hatte bei den Produkten nicht nur die Unterkategorie gesetzt, sondern auch die übergeordnete und da wurden natürlich auch Produkte aus diesen mit angezeigt. Das hatte ich gar nicht mehr auf dem Plan.

Wenn ich nur eine Kategorie setzte, dann funktioniert es.

Hat zufällig jemand einen Schnipsel parat, wie ich bei der Auflistung der ähnlichen Produkte nur Produkte aus der gleichen Kategorie anzeigen kann?

Was nicht hilft, ist diese Funktion:

add_filter( 'woocommerce_product_related_posts_relate_by_tag', '__return_false' );

Damit werden zwar die Tags nicht mehr berücksichtigt, jedoch werden trotzdem noch (fast nur) Produkte aus anderen Kategorien angezeigt.

In unserem WooCommerce-Shop biete ich ein Produkt an, bei denen der Nutzer an der Kasse keine Möglichkeit bekommen soll, ein Kundenkonto anzulegen. Bei allen anderen Produkten ist es dagegen schon wünschenswert, wenn ein Kundenkonto leicht beim Kauf angelegt werden kann.

Vom Prinzip sollen also immer die Hinweise fürs Kundenkonto erscheinen, es sei denn, ein bestimmtes Produkt liegt im Warenkorb.

Fällt euch da spontan ein Lösungsansatz ein? Welches Hooks wäre da ein guter Einstiegspunkt?

Gruß

Ja, funktioniert. Danke!

Zitat

Please note that this snippet will work for WooCommerce 2.0 and 2.1, but not 2.2+

Aber ich schaue mal, ob ich das selbst anpassen kann und ob in den Kommentaren noch was nützliches steht.

Danke!

Ich habe folgendes Problem: In unserem Online-Shop bieten wir verschiedene PDF-Dateien an, die sich der Kunde nach dem Kauf herunterladen kann. Das sind meist variable Produkte und es ist jeweils »Aktiviert«, »Herunterladbar« und »Virtuell« angeklickt. Zahlt der Kunde nach dem Kauf per PayPal (Standardmodul) oder Kreditkarte (Stripe), wird die Bestellung nach Zahlungseingang sofort freigeschaltet und der Status der Bestellung entsprechend geändert.

Nun möchte ich ein weiteres Produkt anbieten, was nur virtuell aber nicht herunterladbar ist (eine Art Mitgliedschaft). Dort habe ich nun das Problem, dass bei PayPal und Kreditkarte der Zahlungsstatus nach der Zahlung bei »In Bearbeitung« hängenbleibt.

Weiß zufällig jemand, wie man WooCommerce überreden kann, auch nur virtuelle Produkte sofort freizuschalten?

Wordpress: Version 4.5.3
WooCommerce: Version 2.6.1[COLOR=#000000][FONT=Open Sans]
[/FONT][/COLOR]WooCommerce Germanized Pro