I can confirm that the Visual Composer update does fix the drag and drop issue. And yes I do have a license to Visual Composer.

OK SOLVED!!!! It took me hours…. literally two days of work to narrow this down. Basically there are two database entries that could be put into the WP_OPTIONS table that specifically relate to WordPress Bakery’s Visual Composer.

In my case the two database entries specifically set parameters for the Columns and Rows of WPB’s Visual Composer. Of course components of “Pages” built on this theme use the columns from the Visual Composer.

Deleting those two entries will fix the problem.

This is likely going to be rare for most, unless you are moving directly from Newspaper and had configured some Column and Row functions in the Visual Composer.

I found this by installing a fresh copy of WordPress onto the same NGINX system and comparing the database entries in the old and new instance.

I imported the old database tables into the new one to see which one broke it. Once the options table was imported that caused the rendering issues. Going through hundreds of lines, I found the two responsible.

Easy way to find them is search for an “Option Name” with %___% wild cards in phpmyadmin. Use this specific term “wpb”.

You may get several options listed in rows in the output. The ones with Column and/or Row specifically in the Option Name should be deleted.

Actually you “can” delete all related options but keep the “wpb_js_templates” option as that is common to both a fresh install and a legacy install.

Well, now rendering is fixed for pages and columns and rows work as expected! Yay.

PS: This has nothing to do with NGINX. I confirmed the exact same issue is present on both Apache 2.4.10 with MPM-Prefork and PHP-FPM.

OK SOLVED!!!! It took me hours…. literally two days of work to narrow this down. Basically there are two database entries that could be put into the WP_OPTIONS table that specifically relate to WordPress Bakery’s Visual Composer.

In my case the two database entries specifically set parameters for the Columns and Rows of WPB’s Visual Composer. Of course components of “Pages” built on this theme use the columns from the Visual Composer.

Deleting those two entries will fix the problem.

This is likely going to be rare for most, unless you are moving directly from Newspaper and had configured some Column and Row functions in the Visual Composer.

I found this by installing a fresh copy of WordPress onto the same NGINX system and comparing the database entries in the old and new instance.

I imported the old database tables into the new one to see which one broke it. Once the options table was imported that caused the rendering issues. Going through hundreds of lines, I found the two responsible.

Easy way to find them is search for an “Option Name” with %___% wild cards in phpmyadmin. Use this specific term “wpb”.

You may get several options listed in rows in the output. The ones with Column and/or Row specifically in the Option Name should be deleted.

Actually you “can” delete all related options but keep the “wpb_js_templates” option as that is common to both a fresh install and a legacy install.

Well, now rendering is fixed for pages and columns and rows work as expected! Yay.

PS: This has nothing to do with NGINX. I confirmed the exact same issue is present on both Apache 2.4.10 with MPM-Prefork and PHP-FPM.

Thanks Christopher,

You are always very helpful on these forums. If I may ask, I am very confused as to what could be causing this odd rendering issue with columns on the site. Could I send you a private message with link to my site? (It’s a rather large publication so I’d rather not broadcast it here.)

Any insight you might have would be most helpful.

Thanks,
Luca

Hi Lucian,

Thanks for the reply. I believe it may be some sort of incompatibility with Nginx which is what my web server is running on. I may try switching to Apache to see if that fixes the problem.

Also, this appears to be an issue specific to the Visual Composer column function.

Thanks,
Lua

Hi Radu,

Please forgive me if the tone of my message seemed overly critical. Believe me when I say you do a PHENOMENAL job supporting this template. Honestly, one of the best efforts I’ve seen from any developer.

As far as caching is concerned, if there is caching then something must be malfunctioning on my deployment because it was definitely making requests to twitter each time an uncached page was loaded. Twitter has been having some API challenges since sometime this weekend for the social counter so it was causing page loads for admins, and writers on my staff to take over 1 minute. I traced the problem to the counter, disabled it and the problem went away.

We run a LAMP stack with Varnish, W3 Total Cache, Memcached and PHP-FPM on the latest Apache and Cent OS distributions. Two core i7 web servers with 32GB of Ram each and a separate database server with a load balancer.

The hardware and OS / PHP / Apache settings have been finely tuned for performance so I know from many, many hours of testing the issue does not lie there.

I am happy to help you test any issues out but I cannot do it on our production environment, I’ll have to setup a separate domain for testing with a separate instance of WordPress.

Thanks and I greatly look forward to the Async version of the Social Counter! 🙂

– Best
Luca

I ended up deleting the counter. Honestly, the biggest problem with the social counter is it doesn’t refresh in parallel. It is called on each page load event that isn’t cached and then if there is a problem with the API connecting to any of the services it causes a massive delay in page response.

I would suggest avoiding the counter until Radu and Lucian can fix the code so it runs parallel to page load, not as a render blocking element. Even though the code appears to be based on Ajax it is NOT running in parallel. (or asynchronously)

Thanks Lucian,

That was the setting I used, but a line was missing from the CSS file that applied the setting to the smaller (3 boxes to the right of the big box) boxes in the big grid on the big slider for th home page.

I am not sure if this is a problem with the latest version of the theme or if somehow the line was edited by me accidentally. Regardless if anyone else has this problem they can use my solution above to correct it.

Best Regards,
Luca

OK, missing code identified, I’m not sure exactly where it should sit in the long stream of CSS, but placing this entry at the bottom of the main CSS file or in the theme child or custom areas will work.

.td-big-grid-title .td-sbig-title-wrap a:hover{
color: white !important;
}

Please look into this to make sure it’s fixed in the next release. Thanks!

I put this code in but it did not work. I am using version 4.2 of the theme.

That sounds plausible as my site is making extensive use of megamenus.

The damn twitter counter STILL does not work. Seriously tedious.

Any chance I could get that solution as well? Thanks!

Hey Radu,

Thanks for getting this fixed quickly. My team and I will gladly support you with beta testing when ever you are setup to do so. We have a test environment we can load code into that is a mirror of production so the testing can be pretty concise.

Best of luck with the rest of your updates and I look forward to more from you.

Best Regards,
Luca

Oh no don’t get me wrong… livingsmarttv, your recommended process is usually what I follow. The issue is, it’s improper to release the code to production (i.e. for “SALE”) on Themeforest when these sorts of bugs have not been ironed out.

This is why RADU should have a beta test group that includes users like ourselves who can test for this functionality.

Remember that anyone buying the theme from Themeforest right now is getting broken code and they have no fallback unless RADU sends them an older version of the code. Why bother with that hassle when a closed beta group can sniff out this stuff quickly and discreetly?

Quite frustrating… another page administrator has also reported this bug. For anyone using a site for anything other than the most basic ecommerce and in individual blogging this functionality must be tested with each release.

Apparently the author just doesn’t give a damn about these problems. I posted the same thing in another thread. No response. It’s honestly sad that basic testing on such essential functionality isn’t being done.

Any role below administrator CANNOT use any of the drop down menus, set post status or schedule posts. This needs to be fixed!

Is anyone else experiencing this issue? Or does anyone have a recommendation for alternative forum software?

Thanks!

I agree it’s probably a conflicting plugin and I think I know which one it is.

I tried your solution but apparently it deletes everything but the @ symbol and the last seven or so characters.

Thanks for the clarification Neotrope 🙂 And I go by Luca 🙂 haha

Hi there, I need a solution to this Twitter link issue for the author bio as well. Neotrope, can you please walk me through what needs to be changed to fix this so at least the link works on the author page? Thanks!

All and Radu,

I’m glad my little bit of research was able to help. Obviously the best fixes will come from the dev himself. By and large Radu does an excellent job supporting us, just this fix was rather urgent so I stepped in to help.

I look forward to the next version Radu and if there is anything “we” as a community can do to help support each other please let’s all keep the feedback flowing. 🙂

PS: neotrope – in Laguna Beach here, so ‘dude’ you’re totally welcome! 🙂

– Luca

FYI: You can hard code the colors you want to use by editing the CSS and LESS files of the respective elements AND still use the Speed Booster plugin.

I personally haven’t experienced any issues with the slider.