VC Raw HTML Element not working in X

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:

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.

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.

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,

Versions for non-working site:
Wordpress 4.9.4
Pro 1.2.3
WPbakery/Visual Composer 5.4.7
PHP 5.5.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.

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.

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.

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?

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!

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?

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.

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/

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?

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.

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.

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!

I dropped the closing from my post to you, which was in the Custom Content menu item, so that was not the issue (typing with one hand, as I badly wrenched one a week ago, so sorry for typos and such).

However, the underlying js that this form was calling was apparently malformed. Once corrected, it appears to be working correctly. I will test further and confirm back.

Glad to know that it is working correctly now.

Have a nice day! :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.