[Resolved] WPML overwrites gravity form - empire strikes back
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported that WPML overwrites Gravity Form in the latest versions of Gravity Forms Multilingual, despite a previous workaround. They requested a new solution for this recurring issue. Solution: We revisited the previous workaround and found it still applicable. Here are the steps to implement the solution: 1. Open the file at /gravityforms-multilingual/inc/gravity-forms-multilingual.class.php. 2. On line 685, replace:
$snh = new GFML_String_Name_Helper();
with:
$snh = new GFML_String_Name_Helper();
// WPML workaround for compsupp-7768
$check = new \WPML\Utils\DebugBackTrace();
if ($check->is_class_function_in_call_stack('GFFormDisplay', 'process_form')) {
return $form;
}
3. Repeat the same replacement on line 822.
If this solution does not resolve your issue or seems outdated, we recommend opening a new support ticket. Please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. For further assistance, visit our support forum at https://wpml.org/forums/.
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.
Background of the issue:
I previously submitted a support ticket (https://wpml.org/forums/topic/wpml-overwrites-gravity-form-2/), and the issue was resolved. However, the problem has returned in the latest versions of Gravity Forms Multilingual, and the previous workaround no longer works. I am trying to find a new workaround for this bug.
Symptoms:
WPML overwrites Gravity Form in the latest versions of Gravity Forms Multilingual.
Questions:
Please provide a new workaround for this bug in the latest versions of Gravity Forms Multilingual.
Important: test it on a staging copy or make sure you have a backup before proceeding.
If the issue persist, I have created this clean sandbox setup on our servers here: hidden link (one click login)
- I would need you to install Gravity forms and the autocomplete plugin and try to recreate the issue.
- Please don't install any other plugins that are not necessary to reproduce the issue.
- If the issue is reproduced on that clean setup, then I can escalate the issue.
Yes, I checked, and I’m aware that custom code will be erased when a plugin is updated. If you look closely, you’ll notice that the custom code was implemented using the gform_pre_render function, which is now deprecated. This means that in newer versions, this function is no longer used.
I had a quick look while escalating the ticket and it seems that applying the workaround provided in the previous ticket works!
Could you please retest it on the sandbox provided?
The code needs to be implemented in two places on the same file.
- Open /gravityforms-multilingual/inc/gravity-forms-multilingual.class.php
- On line 685, replace:
$snh = new GFML_String_Name_Helper();
- With:
$snh = new GFML_String_Name_Helper();
// WPML workaround for compsupp-7768
$check = new \WPML\Utils\DebugBackTrace();//add this
if ( $check->is_class_function_in_call_stack( 'GFFormDisplay', 'process_form' ) ) { //add this
return $form;//add this
}//add this
- Same thing on line 822, replace:
$snh = new GFML_String_Name_Helper();
- With
$snh = new GFML_String_Name_Helper();
// WPML workaround for compsupp-7768
$check = new \WPML\Utils\DebugBackTrace();//add this
if ( $check->is_class_function_in_call_stack( 'GFFormDisplay', 'process_form' ) ) { //add this
return $form;//add this
}//add this
WP File Manager is installed, if you want to have a look at the code on the sandbox site.
