Conflict with Event Tickets plugin - builder doesn't load

This thread is resolved. Here is a description of the problem and solution.

Problem:
When the WPML plugin is active, creating a new ticket on an existing event using the Event Tickets Plus plugin results in a blank screen instead of displaying editable attendee information fields. Disabling WPML resolves the issue, indicating a conflict between WPML and Event Tickets Plus.
Solution:
We have identified that the Event Tickets Plus plugin is not fully compatible with WPML. Although we attempted to establish a partnership with the plugin's author, they were not responsive. As a workaround, you can add the following code to your functions.php file to handle the language details for ticket products using WPML:

function set_wpml_language_for_ticket_product( $sourcepost, $ticket ) {<br />    if ( ! $ticket->ID || get_post_type( $ticket->ID ) !== 'product' ) {<br />        return;<br />    }<br />    $set_language_args = array(<br />        'element_id'    => $ticket->ID,<br />        'element_type'  => 'post_product',<br />        'trid'          => false,<br />        'language_code' => apply_filters( 'wpml_current_language', NULL ),<br />        'source_language_code' => NULL<br />    );<br />    do_action( 'wpml_set_element_language_details', $set_language_args );<br />}<br />add_action( 'event_tickets_after_create_ticket', 'set_wpml_language_for_ticket_product', 10, 2 );

This code snippet ensures that the language details are set correctly for ticket products when they are created. If this solution does not resolve your issue or becomes outdated, we recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please open a new support ticket at WPML support forum.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: Bug

This topic contains 19 replies, has 2 voices.

Last updated by barjD 9 months ago.

Assisted by: Bruno Kos.

Author	Posts
October 9, 2024 at 6:51 pm #16272102
barjD	Hello, can you confirm if you've tested this already? This is highly technical. Did this solve the issue in your own tests? Also, we understand we are not supposed to edit plugin files. Even if this did work for you, how could it become a long term solution?
October 10, 2024 at 5:31 am #16272872
Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	We've tested the solution and found that adjusting these codes worked for us. Unfortunately, beyond this, we don't have any further suggestions. This plugin is not fully compatible. We have attempted to establish a partnership with the plugin's author, but unfortunately, they were not responsive. You can share our workaround with them or invite them to join our Go Global Program https://wpml.org/documentation/support/go-global-program/.
October 10, 2024 at 6:45 pm #16276705
barjD	Thank you. We really appreciate the time you put into this. We can confirm the workaround works. However, can you please confirm that if we put this code in our functions.php file it will work the same way? The thing that is not understood about this solution is that it is expecting a change to a plugin file, and that code is specifically referencing WPML's functionality, no? This seems to be a non-standardized way of implementing a solution in a case like this. Because, as you know, once we update the plugin, the file will be overwritten with new code. We can send this to the Event Tickets Plus author. But the code seems to be asking the plugin author to reference a very specific piece of code relating to another specific, single plugin that is not theirs. And, the code here seems to regard the way that WPML handles the language details, which could apply in other cases where this type of pop up window is used (such as with other plugins or editors). Shouldn't WPML's code be able to handle these cases, and not just that of this one plugin we're speaking of here? If we have misunderstood the process, or something else, please us know. At the end of the day, if you can please help us with a code snippet we can use in our functions.php file, that would help, so the solution can remain long term, even if we update the plugin.
October 11, 2024 at 7:57 am #16277862
Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	How about this? function set_wpml_language_for_ticket_product( $sourcepost, $ticket ) { // Check if the product is a valid ticket if ( ! $ticket->ID \|\| get_post_type( $ticket->ID ) !== 'product' ) { return; } // Workaround to set the language details for the post product using WPML $set_language_args = array( 'element_id' => $ticket->ID, 'element_type' => 'post_product', 'trid' => false, 'language_code' => apply_filters( 'wpml_current_language', NULL ), 'source_language_code' => NULL ); do_action( 'wpml_set_element_language_details', $set_language_args ); } add_action( 'event_tickets_after_create_ticket', 'set_wpml_language_for_ticket_product', 10, 2 );
October 12, 2024 at 7:33 pm #16282397
barjD	This solution works, thank you very much. Event Tickets Plus creator has been notified of this thread and the issue at hand.
October 12, 2024 at 7:34 pm #16282398
barjD	Thank you for your detailed and timely help