Skip Navigation

Home › Support › English Support › [Resolved] WPML overwrites gravity form - empire strikes back

[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.

Tagged: 

This topic contains 4 replies, has 0 voices.

Last updated by aigarsM 4 months ago.

Assisted by: Nicolas V..

Author Posts
December 20, 2024 at 11:58 am #16533796

aigarsM

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.
December 20, 2024 at 3:42 pm #16534825

Nicolas V.
Supporter

Languages: English (English ) French (Français )

Timezone: America/Lima (GMT-05:00)

Hello,

Welcome to the WPML support forum.

Before escalating this issue to our dev team, did you try to reapply the workaround provided in the new version?

When you update a plugin it will erase any changes you made in the past.
In the reply provided by Osama here: https://wpml.org/forums/topic/wpml-overwrites-gravity-form-2/#post-10509443
Note that last time you had to look for line 772, but in the new version it's line 685.

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.

December 21, 2024 at 10:33 am #16536281

aigarsM

Hi,

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’ve recreated the same issue on the test site. The same instructions mentioned in my previous support ticket still apply, which you can find here: https://wpml.org/forums/topic/wpml-overwrites-gravity-form-2/

Here’s a video showing proof that the bug exists in the new sandbox setup: hidden link
December 23, 2024 at 12:30 pm #16540229

Nicolas V.
Supporter

Languages: English (English ) French (Français )

Timezone: America/Lima (GMT-05:00)

Hello,

Thanks a lot for reproducing the issue and for the video shared. It will help our compatibility team.

I have escalated your ticket and will come back to you when I have some feedback from them.

Thanks for your patience,
Nico
December 23, 2024 at 1:10 pm #16540477

Nicolas V.
Supporter

Languages: English (English ) French (Français )

Timezone: America/Lima (GMT-05:00)

Hello,

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.
December 27, 2024 at 6:46 am #16548020

aigarsM

Yes, thank you. I can no longer reproduce the bug, and my issue is resolved.