Issues with Event Tickets Plus and WPML Multilingual CMS

[tanyazailer]

Hi guys,
We’re using The Events Calendar on our web site http://www.cashflowtallinn.ee for a long time and we like it.
Recently, we purchased Event Tickets Plus to start selling tickets for our event over our already configured and working WooCommerce.

We experience issues with Event Tickets Plus and WPML Multilangual CMS. After we did various functionality tests this is what we came up with.

1. We switched all other plugins off and returned back to TwentySixteen theme, problem is still there
2. We turned on all plugins, and after we turn off WPML Multilangual CMS problem is gone. Conclusion: issue is related strictly to WPML Multilangual CMS and Event Tickets Plus compatibility.
3. When we turn off WPML everything works fine: tickets creation, front end, woocommerce, purchases, all…

How does this issue/bug manifests?
When we open existing or new Event, we do have option to create Ticket, BUT… after we create ticket and click save, we get message “New ticket has been saved”, but that ticket is not visible in administration nor in front-end. So, tickets aren’t printed to administrators or end users after they are created.

Technical opinion
Seems like Tickets are successfully stored to database even with WPML turned on. Issue is related to their echoing to screen from database. In plugin landing page it says this is international and translation ready, it should support basic administration entry with WPML turned on.

Is it possible to patch this up?

p.s. Our web site is using http://www.cashflowtallinn.ee/ru/somepage permalink structure, but I tested it for lang=ru permalink structure, problem is still there. I think if this issue is resolved, it will work without problem for both /ru and ?lang=ru permalink structures.

Actually, your plugin forces ?lang=ru at the end of events URI (which is good), so the end link actually has /ru and ?lang=ru inside itself. 😀

If I can help with anything in order to resolve this issue faster, please let me know. You can get access to web site if you want, of course.

All best,

[George]

Thank you so much for the detailed breakdown of things here, @tanyazailer!

At this time, it is a known issue that our plugins do not work with WPML to any meaningful degree.

The Events Calendar is the only plugin of ours that has support for WPML at this time. Events Calendar Pro, Event Tickets, Event Tickets Plus, and all other add-ons unfortunately do not support WPML at all at this time. 🙁

I’m sorry to disappoint!

Better WPML compatibility is a distant goal of ours—something we hope to achieve in the coming months and years—but it is not something we will be able to pull off in the immediate future. I just want to be honest about that. 🙁

Still, your notes here are much appreciated and may help us improve specific things. So, again: thank you!

If the lack of compatibility with WPML is a deal-breaker for your site, please do not hesitate to seek a refund from us. We’d be happy to try and make things right. You can learn how to get a refund here → https://theeventscalendar.com/knowledgebase/refund-policy/

Thank you!
George

[tanyazailer]

Hi George,

Thank you for quick answer and for clear explanation that this feature is not currently supported, as well for a possibility for refund. However, we really like your plugin, and we’re open to search for different options to make this work.

Let me tell you our business model, so we can together figure out if we can make this work.
1) Our web site has several languages, WPML, WooCommerce and Events as main plugins
2) Our Events are translated with WPML and working correctly (since your infrastructure plugin provides WPML compatibility)
3) We need to sell tickets on our Events

I was thinking about options to make this work, please tell me what you think about them:
1) We’re open to hire you for custom coding to make this plugin support WPML. We need “minimum viable product”, so we need our tickets to simply appear on admin page and on frontend after we create them. We’re open to provide support from other side for bug tracking and cooperation of course.
2) Is there a way to disable WPML for this specific plugin? Some kind of patch to “hide” your plugin from WPML? This way, we could use our web site with WPML turned on, but it wouldn’t affect your plugin?
3) What other suggestion do you have for covering Event Tickets with WooCommerce on multilingual web sites? What other plugins for Ticket selling do you find compatible with your main plugin Events?

I did research trough your forum, WPML forum and WooCommerce forum, and I found many instances of users (since late 2014) which indicates this specific problem, and WPML response that they are open for collaboration.

I found this link on WooCommerce from June 2014 https://wpml.org/forums/topic/events-calendars-woocommerce-tickets-creation/ where WPML states it’s open for cooperation in order to make these plugins friendly. Since it seems like lots of users are affected is there some way of cooperation in order to resolve this? Maybe 3 side cooperation, WPML, Modern Tribe and us as beta end user? Just an idea.

Feel free to forward this question/initiative to parts of team who decides new features, and let me know if there’s anything we can do here.

All best,

p.s. Topic closely related to https://theeventscalendar.com/support/forums/topic/event-tickets-plus-and-wpml-compatibility/ and to several more. Seems like lots of premium users are actually begging this feature. 🙂

[tanyazailer]

Hi guys,
Quick addition to previous post. After quick testing of plugin with Query Monitor, this is what I came up with.
1) All of Tickets data is stored within _postmeta table, which is expected since Event is custom _post.
2) I looked at random queries from original plugin Events Calendar and this is what example select query looks like

SELECT t.element_id, t.language_code, t.source_language_code, t.trid
FROM l9iu_icl_translations t JOIN l9iu_posts p
ON t.element_id = p.ID
AND t.element_type = CONCAT(‘post_’, p.post_type) JOIN l9iu_icl_translations tridt
ON tridt.element_type = t.element_type
AND tridt.trid = t.trid
WHERE tridt.element_id IN (66,4396,4233)

Seems like these SQL queries are actually using _translations table and source_language_code and source_language attributes, which is also expected since plugin supports WPML.

3) When I looked at example query of Tickets plugin

SELECT l9iu_posts.ID
FROM l9iu_posts
INNER JOIN l9iu_postmeta
ON ( l9iu_posts.ID = l9iu_postmeta.post_id ) JOIN l9iu_icl_translations t
ON l9iu_posts.ID = t.element_id
AND t.element_type = CONCAT(‘post_’, l9iu_posts.post_type)
WHERE 1=1
AND ( ( l9iu_postmeta.meta_key = ‘_tribe_wooticket_for_event’
AND CAST(l9iu_postmeta.meta_value AS CHAR) = ‘6137’ ) )
AND l9iu_posts.post_type = ‘product’
AND ((l9iu_posts.post_status = ‘publish’))
AND ( ( t.language_code = ‘en’
AND l9iu_posts.post_type IN (‘post’,’page’,’attachment’,’product’,’product_variation’,’tribe_events’,’mc4wp-form’,’portfolio’ ) )
OR l9iu_posts.post_type NOT IN (‘post’,’page’,’attachment’,’product’,’product_variation’,’tribe_events’,’mc4wp-form’,’portfolio’ ) )
GROUP BY l9iu_posts.ID
ORDER BY l9iu_posts.post_date DESC

Seems like this query is not reading attributes from internationalization tables what so ever.

Wild guess: Is it possible that this bug is simply BAD SQL QUERY(s) for multilanguage SELECTION bug?
Question: Could it be possible to make this plugin support WPML with semi-simple changes inside SQL queries (maybe only select queries for tickets?)

You have language translation information inside _postmeta table when user created Event, so Ticket could “reuse” SQL concept that Event is using?

I don’t know ins and outs of Event and Ticket plugin so I’m unable to create some more serious testing for different SQL queries, but this seems doable?

Please, let me know what you think. Hope this is helpful in resolving this issue.
Let’s be real Tribe and resolve this issue together! 🙂

All best,

[George]

Hi @tanyazailer

We unfortunately are not available for hire for such projects and the plugins are not compatible at this time. 🙁

I’m sorry to bear the bad news!

If you deeply want to hire someone to help you build out these features, your best bet is to hire a professional developer to write the code for you.

We have a list of great developers here → http://m.tri.be/18k1 (and have no affiliation with any of these folks—they’re simply some well-respected names in the community that we’ve compiled to share in situations like this one).

I wish you the best of luck with your project,
George

[tanyazailer]

Hi George,

I’m sorry to hear that, but ok, we’ll find some workaround for our business.

I guess you are aware that you’re suggesting us to hire third party developers (not originally connected with your plugin or code) to implement feature / or resolve a bug that your company (with full team, resources and time) didn’t implement for nearly 2 years since first user requests… 🙂

All best,

[George]

Thank you, @tanyazailer. The situation with these features is indeed not ideal, and we are racing to get these features implemented into our code base. This has taken a long time and could take many more months, unfortunately.

Best of luck with your project in the meantime!
George

[Support Droid]

This topic has not been active for quite some time and will now be closed.

If you still need assistance please simply open a new topic (linking to this one if necessary)
and one of the team will be only too happy to help.

[Author]

Posts