VC Raw HTML Element not working in X

Support
#1

We are using VC/Wp Bakery on our production site, which runs on Zurb Foundation. We have landing pages on that site, built in VC, that use a Marketo embed code inside of a raw HTML element, which works without issue.

Using the same page layout, Raw HTML element and same Marketo embed code on X, the Marketo form (the point of the embed) will not display. Placing the Embed code below the VC components (using the classic editor), the form displays correctly.

This issue was raised with WP bakery/VC support, and they pointed to X being the issue, and that it would require custom js to fix. Since VC is bundled with X I would have assumed they would support this, but apparently not.

Please advise on how to get this working on X.

#2

Hi There,

Thanks for writing in! Is it possible to provide us with an example page URL(s) for both working and non-working scenarios, so that we can look into your issue.

Thanks!

#3

The following embed code is in a Raw HTML element on our production site (running another theme) and on our staging site running X:

<script src="//ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script><script src="//app-ab08.marketo.com/js/forms2/js/forms2.min.js"></script>
<form id="mktoForm_2674"></form>
<script>// <![CDATA[
MktoForms2.loadForm("//app-ab08.marketo.com", "229-XUE-318", 2674, function(form) {
     var TRUE_ORIGINAL_LEAD_SOURCE = "Website";
     var TRUE_ORIGINAL_LEAD_SOURCE_DESCRIPTN = "Enabling Digital Payments Transformation: How Transactional Analytics Is Delivering Business Moments";
     form.vals({ "True_Original_Lead_Source__c": TRUE_ORIGINAL_LEAD_SOURCE, "True_Original_Lead_Source_Descriptn__c": TRUE_ORIGINAL_LEAD_SOURCE_DESCRIPTN });
     form.onSuccess(function(values, followUpUrl){
           location.href = "/lp/ty-enabling-digital-payments-transformation-how-transactional-analytics-is-delivering-business-moments/";
           return false;
     });
     jQuery.getJSON('https://freegeoip.net/json/') .
     done (function(location){
     var thisCtryCode = location.country_code;
     if (thisCtryCode == "US") {
           $(".mktoForm div.mktoFormRow:nth-child(11)").css("display","none");
     } else {
     $(".mktoForm div.mktoFormRow:nth-child(11)").css("display","block");
     }
     });
});
// ]]></script><script type="text/javascript">// <![CDATA[
     document.cookie = TRUE_ORIGINAL_LEAD_SOURCE;
     document.cookie = TRUE_ORIGINAL_LEAD_SOURCE_DESCRIPTN;
// ]]></script>

This works on our prod (non-X site), but not on our X staging site. I reverted to one of the default themes (Twenty Sixteen), and the form started working within Visual Composer (but without X). We re-enabled X, and the form stopped working. The WP Bakery Support team observed the same, which is why they felt it was an X issue, not a VC issue.

#4

The first image is the working form on our production (non-X) site:

Second image is the non-working form on our staging site using X:

#5

Hello There,

Please keep in mind that Raw HTML will only accept html codes. Since your code contains javascript, please make use of the Raw JS element instead.

We would loved to know if this has work for you. Thank you.

#6

Your statement is not correct…

  1. As clearly noted, this works in another installation, with the ONLY difference being that X theme is not used
  2. This embed is NOT plain, raw JS, but legitimate HTML with proper and standards based script tags
  3. It renders the form correctly using the front end VC editor, but not the backend, and not the published page
  4. WP Bakery already confirmed that this was a JS compatibility issue between X theme and Visual Composer, which Theme.co was responsible for. They also confirmed that this was legitimate HTML for the Raw HTML VC element, since they confirmed it worked correctly when NOT using X theme.

And again, per the above and my prior notes, this works perfectly without X theme, so we need to know what the X theme incompatibility is, and how to fix it.

#7

FYI – I sent your response to WP bakery support, and they confirmed my most recent comments:

On Wed, Apr 18, 2018 at 7:57 PM, WPBakery Support support@wpbakery.com wrote:
Hi,

Unfortunately, it is not related to the raw js element as well. We created a test page: https://newstage.aerospike.com/test-page/ to add the same code via raw js element and you can see that the same issue exists there too. You can share the same page url with them for them to check it further at your end.
We hope this helps.

Thank you,

#8

Versions for non-working site:
Wordpress 4.9.4
Pro 1.2.3
WPbakery/Visual Composer 5.4.7
PHP 5.5.9

#9

Hi @dhockenberry_as

I have tested your code on my server with:

PHP 7.0.28
WordPress 4.9.5
WPBakery 5.4.7
Pro 2.0.4

And I got it working with “Raw HTML” module in WPBakery builder:

Could you please upgrade the theme & WordPress at least and give it a try?

Thanks.

#10

As you are aware, there have been a LOT of documented issues for those upgrading to X/Pro 2.0.

As well, PHP upgrades have ripple effects on multiple plugins, not always good.

This is a bug for the (still supported) Pro 1.2.3, and needs to be addressed.

#11

Hey There,

I would recommend that you create a staging site. This is very useful because you can test drive any theme updates in the staging area, do the customizations and troubleshooting without disrupting your live site. Once everything is perfect, you can easily and flawlessly proceed the update in the live site. To know how to create a staging area, please check out these articles:


In your staging area, you may install the latest version Pro 2.0.4 and we can test your code.

Thank you.

#12

I am concerned that your team is not reading my details, thereby being ineffecient with their time and mine. As I clearly stated, “This works on our prod (non-X site), but not on our X staging site”, so I clearly understand what and how to deploy staging sites, of which I have 4 running for this deployment. Sending me info that my details indicate I dont need is not effective.

More importantly, I have already done staged setups with Pro 2.0, updated OS and PHP, and irrespective of whether it fixes this issue or not, it creates more than a dozen other significant site issues, so you are directing me to eliminate one issue, but introducing numerous others.

Most importantly, is Theme.co telling me that the only solution to this is to upgrade Pro to 2.X or above? If so, that means that you are no longer supporting bugs in Pro 1.X – I have not seen this documented by Theme.co anywhere. Can you direct me to where this support was ended?

#13

Hi there,

Bug fixes are usually added along with the updates. If you wish to stay with that old version then there is nothing we could do since the fix may not be available unless you’ll update it. The purpose of staging is to update it and compare if the issue is still present in the latest version (which we already tried on our end so we need to test it on your site too).

You can also disable X integration in your Visual Composer settings section if you wish to use its native elements instead of theme’s elements.

Thanks!

#14

I have worked for Silicon Valley SW companies for 20+ years, so I am pretty familiar with standard release practices. The standard is for major releases (1.X to 2.X for example) to be feature/structure/performance changes from the previous version, and minor releases (X.1 vs X.2) to be bug fixes within the major version. The standard is also for vendors to support continue to support and patch bugs on their current and stated number of prior releases, with the emphasis being on “stated”.

If Theme.co were following industry best practice, which is assumed, with 2.0 launch, they would supporting and patching 2.0 bugs, along with bugs for 1.X going back to a specific version, which they had clearly communicated to the community, with all prior versions being No longer supported.

It is normal to suggest that new functions or features that address issues will be in the new versions only, but it is not normal within the SW industry to suggest that fixes to bugs in any currently supported version will only be fixed through linear upgrades. Hence, why I asked where this policy is documented on the Theme.co website.

So I need a clear Yes/No answer: Is Theme.co no longer fixing bugs within any version prior to 2.X?

#15

Hello There,

Thanks for your feedback.

So I need a clear Yes/No answer: Is Theme.co no longer fixing bugs within any version prior to 2.X?

  • No. All the bugs were fixed and it is available in 2.x. We do not have a versioning state policy like you suggested nor do we classify things as 1.x bugs or 2.x bugs … simply, they are bugs. Since we don’t put a limit on only supporting certain versions of our product the point is moot.

Thank you for your understanding.

#16

You stated you had it working with:
PHP 7.0.28
WordPress 4.9.5
WPBakery 5.4.7
Pro 2.0.4

I have an additional staging instance with the same, using Raw HTML Element, but the form is still NOT working.

Example page: https://newstage4.aerospike.com/lp/enabling-digital-payments-transformation-ebook/

#17

If I test using the original Pro 2.0.4 theme contents, it does not work. However, after creating a child theme, and adding our customizations to it, the form no longer works. There should be nothing in the child theme mods that affects or conflicts with this (as I stated earlier .0 version upgrades cause major changes, and major mods to migrate…)

Before I go through the arduous task of checking child theme changes one by one (of which there are dozens…), are there any know conflicting changes between Pro 1.X and 2.X where prior Theme.co recommended child theme mods would conflict with Pro 2.X?

#18

Hey @dhockenberry_as,

Can you clarify what you’ve said?

When I checked your staging site, I see the form and it is the same as @Alaa’s test and mine. The form also works on my end. I’m using Pro 2.0.4, WPBakery Page Builder 5.4.7, PHP 7.0.29 and WP 4.9.4.

Here are screenshots of my test.

There are no known conflicts with Pro 1 and 2. There is only a major feature release (Template Manager) and progression of bug fixes and improvements, please see our Changelog for more details.

We have tested that it works in Pro 2.0.4 and you’ve tested yourself that it is your child theme customization that is causing the issue. That is even if you got the codes in this forum. Those only serve as a guide and we are not responsible for the maintenance of it let alone take into account every system a user may add on their site like your code. Anyway, we already have proven that it works in Pro 2.0.4 parent theme. If it does not work with older versions, you would need to update.

Thank you for understanding.

#19

Typo in the first sentence – apologies. It DOES work with the plain 2.0.4 theme loaded, but not with the Child theme added.

After extensive iterative test changes, it is not in fact any customization in our Child theme, but something in the Ubermenu configuration (Primary) that is causing the conflict.

For example, using the original Pro 2.0.4 theme with my already configured MainMenu menu (and associated Ubermenu config), the form breaks.

I then created a single item simple menu (no Uber configs) and configured this as the top menu, and the form starts working.

I then re-enabled the child theme, keeping the single item menu as Primary, and the form works. This means the issue is in the Ubermenu config.

Doing some additional testing, I isolated one component potentially causing this: We have one Ubermenu menu item using the Ubermenu custom content type, which includes the following (used to enable our site search provider:

 <form method="get" action="/search">
  <input type="text" name="addsearch" placeholder="Search" autofocus />

Removing this from the Ubermenu custom content item allows the form to populate using the child theme and full config.

However, there is nothing unusual about this HTML inclusion in the Ubermenu Custom Content – I have used this with several other themes without issue, and is fully supported by Ubermenu.

I cannot operate or launch without enabling this search function, so I need Theme.co to determine why Pro is causing this conflict.

#20

Hi again,

Thank you for the detailed write-up! The HTML you shared has an unclosed </form> tag, that could be conflicting with the theme. Please use this HTML instead:

<form method="get" action="/search">
  <input type="text" name="addsearch" placeholder="Search" autofocus />
</form>

Let us know how this goes!