Forum Replies Created
-
Posts
-
Some characters in the code snippet are not presented correctly, but I hope the solution is clear enough.
Just wanted to let you know that we installed the latest release ET/ETC 4.5.1 from 26th of June, and it fixes this issue.
We have only tested this with our current payment gateway, DIBS for WooCommerce.
We updated to the latest release ET/ETC 4.4.6, and this issue still remains.
To help you, we generated a backtrace by catching the event_tickets_woocommerce_ticket_created action called just before the attendee user id meta value is set in Tribe__Tickets_Plus__Commerce__WooCommerce__Main::generate_tickets().
[22-Apr-2017 13:12:15 UTC] Action: event_tickets_woocommerce_ticket_created Args: attendee_id=1650, order_id=1649, product_id=1326, order_attendee_id=0 Current state: current_user_id=0, backtrace= - /wp-content/themes/lemans1954/functions.php at line 536: ::lemans1954_debug_backtrace - (unknown file) at line ?: ::lemans1954_event_tickets_woocommerce_ticket_created - /wp-includes/class-wp-hook.php at line 298: ::call_user_func_array - /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters - /wp-includes/plugin.php at line 453: WP_Hook::do_action - /wp-content/plugins/event-tickets-plus/src/Tribe/Commerce/WooCommerce/Main.php at line 671: ::do_action - (unknown file) at line ?: Tribe__Tickets_Plus__Commerce__WooCommerce__Main::generate_tickets - /wp-includes/class-wp-hook.php at line 300: ::call_user_func_array - /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters - /wp-includes/plugin.php at line 453: WP_Hook::do_action - /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 306: ::do_action - /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 214: WC_Order::status_transition - /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 120: WC_Order::save - /wp-content/plugins/dibs-for-woocommerce/includes/gateways/class-dibs-factory.php at line 167: WC_Order::payment_complete - /wp-content/plugins/dibs-for-woocommerce/includes/class-dibs-extra.php at line 46: WC_Gateway_Dibs_Factory::successful_request - (unknown file) at line ?: WC_Gateway_Dibs_Extra::check_callback - /wp-includes/class-wp-hook.php at line 298: ::call_user_func_array - /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters - /wp-includes/plugin.php at line 453: WP_Hook::do_action - /wp-settings.php at line 449: ::do_action - /wp-config.php at line 95: ::require_once - /wp-load.php at line 37: ::require_once - /wp-blog-header.php at line 13: ::require_once - /index.php at line 17: ::require - request: /woocommerce/dibscallback/?At the top, the arguments to the action are shown (with correct values), and the current state shows that the current user id is 0 (returned by get_current_user_id()).
If we follow the backtrace from the bottom of the list, the entrance request is a callback to “dibscallback” created and handled by the payment gateway. A successful payment results in a call to WC_Order::payment_complete inside WooCommerce.
Next block is WooCommerce handling the order saving and status transition from pending to processing. This is eventually picked up by __WooCommerce__Main::generate_tickets() by the action woocommerce_order_status_changed.
The last block is the action event_tickets_woocommerce_ticket_created picked up by our own theme (lemans1954) helper function to generate this backtrace. This action is called just before the function record_attendee_user_id() is used in generate_tickets() and called with one argument. The second argument, user_id, will have default value of null, and therefore uses the get_current_user_id() function to get a user id. But as we have seen before, this call originated from a callback without a logged-in user, and the end result is that the _tribe_tickets_attendee_user_id meta value for the ticket is set to 0.
As a general rule, code that is dependent on global state, like the current logged-in user in this case, is dangerous, and must be sure that any global state value that is accessed is correct in all contexts it is called.
The function generate_ticket() already has needed values available in the current order object, where the customer user id is stored. Retrieve it by $order->get_customer_id() and send it as the user_id argument to the function record_attendee_user_id(). We have made this change and this solves this issue on our site.
Szia András,
I have thought of that type of solution for this also, hiding the incorrect content using css, but the My Tickets page should not show any ticket form at all. So it is not enough to hide the second form.cart element, the first one must also be hidden.
But I have not found any way to distinguish the page post (with defined tickets) from the My Tickets page and only hide the ticket forms on the My Tickets page.
So the issue still remains.
Yes, it does indeed!
We overrode the meta.php template instead, as you suggested, and created a special helper function combining render(), render_field(), and the contents of our version of text.php into it, and this seems to function correctly as a temporary measure.
Looking forward to your future release where this will be fixed.
Thank you for your help!
After deeper inspection of the issue, the problem seemed to be caused by ajax calls to the file /wp-admin/admin-ajax.php. When %-encoded characters are posted (international character, or [] used by custom fields), any Save call failed. When no %-encoded characters were sent, the calls were successful.
The problem was caused by security settings blocking calls to the file admin-ajax.php (in mod_security module). After excluding the file from security checks, the issue is resolved. You may contact your web hotel/provider to change these settings.
After deeper inspection of the issue, the problem seemed to be caused by ajax calls to the file /wp-admin/admin-ajax.php. When %-encoded characters are posted (international character, or [] used by custom fields), any Save call failed. When no %-encoded characters were sent, the calls were successful.
The problem was caused by security settings blocking calls to the file admin-ajax.php (in mod_security module). After excluding the file from security checks, the issue is resolved. You may contact your web hotel/provider to change these settings.
We retested the issue following the steps in your guide for testing for conflicts. With theme twenty-sixteen activated, only your plugins and woocommerce activated, the issue remains. System information is posted just before this post as private.
Looking in the html code for the “My Tickets” page, the form element with class “cart” and action attribute pointing to the cart url on the site occurs exactly twice on the page “My Tickets”, seemingly with the exact same content (this is also seen on the screen). The two form elements appear just after the comment “<!– #tribe-events-content –>”.
We have created a completely new instance of our site and copied/reinstalled all plugins, leaving only your plugins active, along with the plugins for woocommerce and DIBS payment gateway. The issue still exists.
We have tested this with the “Pay with check” payment gateway, and the issue does not occurs using that gateway. But the “pay with check” gateway does not leave the site. The DIBS payment gateway visits an external payment window.
We have this issue also in our web site with Event Tickets, Event Tickets Plus. We have reported this issue multiple times to this support forum, along with a proposed solution that works on our site.
We have not received any feedback about our proposed solution, so be advised, use it on your own risk.
I have updated the plugins to the lastest release cycle, ET 4.4.5 / ETP 4.4.4, but this issue still remains, attendee data are lost.
And to be clear, I realize these are separate issues, I will keep separate issues in separate threads from now on.
We have only tested this för the DIBS payment gateway.
After today’s maintenance release, ET 4.4.5 / ETP 4.4.4, the issue with user_id set to zero still exists.
If you refer to my previous thread, I never stated that it was “multiple types of tickets purchased at once”. I mentioned “a couple of fields” in a ticket. I have previously only tested exactly one ticket type in a single purchase, nothing else, when I encountered the attendee field issues.
