Hi guys, I hope you can help.
I’ve updated my staging environment from Pro v2.5.5 to Pro v3.1.2 and it seems to break Gravity Forms stylesheets from loading. I’ll create a private note with a link to a video showing the issue.
Thanks in advance.
Hi guys, I hope you can help.
I’ve updated my staging environment from Pro v2.5.5 to Pro v3.1.2 and it seems to break Gravity Forms stylesheets from loading. I’ll create a private note with a link to a video showing the issue.
Thanks in advance.
Hello Stewart,
Thanks for writing in! The Gravity form css should be loaded only in the page were there is a gravity form. To better assist you with your issue, kindly provide us access to your site so that we can check your settings. Please create a secure note with the following info:
– Link to your site
– WordPress Admin username / password
To know how to create a secure note, please check this out: https://theme.co/apex/forum/t/how-to-get-support/288
Regards.
Hi, I have updated the secure note with the login details.
Some points to note.
Thanks in advance for your help.
Hey Stewart,
The credentials you’ve provided doesn’t work. Please check and provide the correct version.
Thanks for providing the notes. Below is my response to each of your points
Regarding the styles issue, in my test site, Gravity Forms form is styled according to the Stack chosen. The form looks the same both on the regular page and in the Pro built page so I wonder if there’s something else affecting the styles.
Would you mind enabling the parent theme? I also see GF styles coming from a third-party plugin so would you mind deactivating all third-party plugins as well just for testing?
Thanks.
User now activated … sorry about that.
Responding to your points …
In Pro v2 the Gravity Forms CSS were located in the HEAD. Why does Pro v3 place it in the footer? Also, other pages that use Gravity Forms (e.g. Woocommerce) include the stylesheets in the HEAD. It’s inconsistent that the v3 now places the CSS in the footer. If the developers could look in to this it would be much appreciated.
In v2 the child stylesheet was loaded towards the end of the stylesheets hence giving it’s CSS declarations priority over other styles. This was important to overriding styles in other stylesheets without using the !important command. In v3 the child stylesheet is loaded much earlier and therefore is not overriding some of the style definitions.
With regards to deactivating other plugins etc … I have exactly the same setup in live and staging with the only different one is running v2 and the other v3. v3 has all of the issues with regards to how stylesheets are loaded. I will create you an account on live so you can see the different.
Thanks
Hey Stewart,
####To your question:
Thanks for adding detail. The adding of Gravity Forms CSS in the footer is not intentional. This is why I said:
For now, please use the Classic Gravity Forms element as that is the correct setup. I previously mentioned that.
To give you more context, this change in priority is a result of unloading Gravity Forms CSS globally and loading them only where there is Gravity Forms in a page. If you place the Gravity Forms Shortcode in the builder, it will now be loaded late because of Gravity Forms hook priorities that our developers have not investigated yet.
I understand that users can insert Gravity Forms in a Text Element. But, that is not the correct setup when using Cornerstone or Pro.
-----------------------------------------------------------------------------------
This has a connection with Gravity Forms hook priorities. But again, the correct way to override theme styles (including Gravity Forms Theme Styles) is to place override CSS in Theme Options > CSS. That is why I previously said this:
-----------------------------------------------------------------------------------
I’m sorry that the update caused conflict with your CSS. But, what was done was only for the improvement of the theme. It’s also best to follow the correct setup.
I’ll post this in our issue tracker to see if our development team will take this use case into account. For now, please follow the correct setup.
Thanks.
Hi Christian and thanks for coming back to me.
You explanation is very helpful and I appreciate this being escalated with development. I will look in to using the classic gravity forms block as suggested.
That said, there is still any issue with Gravity Forms when used with WooCommerce. We use a popular plugin called ‘Gravity Forms Product Adds Ons’ which allows product configuration using Gravity Forms. With the different loading priority of stylesheets in Pro V3 the formatting of the WooCommernce pages are also not correct when compared to v2. I’ll add a link in a secure note.
Could the developers also look in to this issue please?
I can workaround this problem by modifying the functions.php file in my child theme to force a higher priority of the child css, but this isn’t ideal.
Thanks again for the support. Much appreciated.
Hi Stewart,
Thank you for the information. We do not support any third-party add-on for the Gravity Form, but we will do test the case.
I checked the issue tracker and found out that there is already a solution found and a fix committed. So I can say that the original problem will be fixed in the upcoming release of the theme.
As our theme only enqueue the original styling of the Gravity Forms, our theme will not be responsible for other problems, and fixing the original one should fix any other issue that might be caused by the way the styles are enqueued.
Thank you for your understanding.
Many thanks. Any idea when the next release is due?
Hello Stewart,
We do not have an ETA for the release yet. Please watch out for it in your dashboard and check out our changelog every now and then.
Please bear with us.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.