Support

Home › Forums › Event Espresso Premium › EventEspresso 4 + WPML

EventEspresso 4 + WPML

Posted: March 22, 2018 at 4:00 pm


Stichting Festival Aangeschoten Wild

March 22, 2018 at 4:00 pm

Hi all,

Call me stubborn, call me stupid. I’ve seen all the signs that EE4 won’t work with WPML, but I’m still (quite desperately) looking for workarounds. I’ve seen the post over at WPML (https://wpml.org/forums/topic/i-cant-translate-the-event-espresso-registration-form-in-english/) and incorporated that suggestion, but that doesn’t solve (all of) the problems. With the experience and knowledge of the EE developers around, I’m hoping we can together work through this an come up with a (temporary, at least) solution. Demand is high up, judging from the various posts.

Situation:
The Dutch shop is located at http://www.aangeschotenwild.com/2018/tickets, the English at http://www.aangeschotenwild.com/2018/en/tickets. Below details on the relevant software and plugins.
– WordPress 4.9.4, network installation, custom theme
– WPML Multilingual CMS 3.5.3.1, WPML String Translation 2.4.2.1, WPML Widgets 1.0.6, WPML Media 2.1.23
– EventEspresso 4.9.57.p, EE MER 2.0.14.p, EE Barcode Scanner 1.0.11.0, EE App Customization 1.0.2.p, EE iDeal Mollie Gateway 1.1.4.p, EE Ticketing 1.0.7.p.
Dutch and English EE-related pages have been translated using WPML, keeping the original Dutch slugs (also for the English pages). They therefore only vary by /en/ in the URL.

Current bottleneck:
The main shop page (with TICKET_SELECTOR shortcode) works quite fine, with the exception of untranslated ticket names. The form (in a hidden field) shows the correct tkt-slctr-return-url-ID-value. (Confirmed in logging MER.form_data in multi_event_registration.js.) The problem arises when I select a number of tickets and click the ‘Add to Event Cart’ button. This sends a POST-request to admin-ajax.php, which (somehow) reverts the original ICL_LANGUAGE_CODE (the variable in which WPML stores the current language) to ‘nl’ (rather than ‘en’). I’ve checked this by echo’ing ICL_LANGUAGE_CODE in the function get_cart_results (in EED_Multi_Event_Registration.module.php:~800). When I then go on to dump $template_args used in that function, the register_url is the Dutch version. That seems weird, as register_url points to EE_EVENT_QUEUE_BASE_URL. When I echo that variable in the function where it’s defined (set_definitions, same file, ~ line 250), it does give the proper (English) cart link: https://aangeschotenwild.com/2018/en/tickets/bestellen/?uts=1521755472#checkout.

Approaching this step by step, I’m interested in any ideas/explanations for this behaviour, as well as possible workarounds. It feels as if this bottleneck is actually the bottleneck, as (for example) the ‘cancel registration’-link later on in the registration flow points to the correct language version of the ‘Cancelled’-page.

Thanks in advance,
Bram


Josh

  • Support Staff

    •

March 23, 2018 at 2:13 pm

Hi Bram,

I’m afraid I have no idea why a POST-request to admin-ajax.php would revert the original ICL_LANGUAGE_CODE. Since you’re having issues with using the cart, and it appears there’s only one event, why not deactivate MER and avoid the cart functions altogether?


Stichting Festival Aangeschoten Wild

March 25, 2018 at 3:18 am

Hi Josh,

Thanks for your reply! Deactivating MER actually is an idea I hadn’t thought of before, but something that might work! Back in the EE3-days we used MER to sell multiple products (ticket, tokens, merch), but as we’re currently doing that with the different ticketing options, the MER indeed might be redundant.

I’ll give this a try in our development environment and see whether this solves the issue!

Thanks again,
Bram


Stichting Festival Aangeschoten Wild

March 25, 2018 at 6:14 am

Hi Josh,

So… I think I’ve got it working =)! Disabling the MER plugin indeed helps, as it removes the cart-modal. Next problem was that the (English-language) checkout page showed up empty. This was solved by adjusting the function _is_reg_checkout in event-espresso-core-reg/modules/single_page_checkout/EED_Single_Page_Checkout.module.php. This functions checks the current request URL against the registration page URL (the URL from the page set as Registration Page, on the EE Settings > Critical Pages page). As the English request URL contained a language code, this check found these two pages not equal and killed further script execution.

I’ve added the following code, between $current_request_uri = trim($current_request_uri, '?/'); and the return-statement.


// find current language permalink of reg_page_url
$reg_page_id = url_to_postid($reg_page_url);
$reg_page_id_current_language = apply_filters( 'wpml_object_id', $reg_page_id, 'page', true);
$reg_page_url = get_permalink($reg_page_id_current_language);

Documentation of used functions: url_to_postid(), wpml_object_id-filter.

To also make sure the redirections to other critical pages (transactions page, thank you page, cancelled page) work, I’ve changed the definitions of the txn_page_url, thank_you_page_url and cancel_page_url (in event-espresso-core-reg/core/EE_Config.core.php) as follows:


$this->txn_page_url = get_permalink( apply_filters( 'wpml_object_id', $this->txn_page_id, 'page', true ) );

$this->thank_you_page_url = get_permalink( apply_filters( 'wpml_object_id', $this->thank_you_page_id, 'page', true ) );

$this->thank_you_page_url = get_permalink( apply_filters( 'wpml_object_id', $this->thank_you_page_id, 'page', true ) );

This is basically another application of the registration-page-translation-fix that was posed over at the WPML-forums.

We’ll be testing this over the coming few days, but until then I’m hoping this can also help other people struggling with this. Josh, if you see any issues / risk associated to my changes, please let me know!

Bram


Josh

  • Support Staff

    •

March 26, 2018 at 9:32 am

Hi Bram,

I can recommend moving the custom code into its own plugin, then add a filter hook where needed.

For example, for the Reg. page, right after this line:
$reg_page_url = \get_permalink(EE_Config::instance()->core->reg_page_id);
you could add this (a new filter hook) :
$reg_page_url = apply_filters('FHEE__EED_Single_Page_Checkout___is_reg_checkout__reg_page_url', $reg_page_url);

Then you can do a pull request on Github and the filter hook can make it into an upcoming version of Event Espresso. This way you can keep your copy of Event Espresso free of modified code and avoid maintenance headaches later on.

Then your custom code will be neatly tucked away into its own plugin, for example:

add_filter(
 'FHEE__EED_Single_Page_Checkout___is_reg_checkout__reg_page_url',
 'sti_reg_page_url_current_lang'
);
function sti_reg_page_url_current_lang($reg_page_url) {
 $reg_page_id = url_to_postid($reg_page_url);
 $reg_page_id_current_language = apply_filters( 'wpml_object_id', $reg_page_id, 'page', true);
 $reg_page_url = get_permalink($reg_page_id_current_language);
 return $reg_page_url;
}

The support post ‘EventEspresso 4 + WPML’ is closed to new replies.

Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3 Documentation for Event Espresso 4

Status: closed

Updated by  Josh 6 years, 1 month ago ago

Topic Tags

Tagged: ,

Notifications

This topic is: not resolved
Event Espresso