pavelthq

Actually this was fixed in 4.7.1, and for support use our codecanyon commets or official support portal: support.wpbakery.com

We could not replicate this issue.

@ygirod, Can you provide more details about this issue?
How we can replicate (screencast would be great).

Is this repeated in frontend editor? Or only backend editor issue?

@yhirod, Thanks for reporting. We added in our bug repository and will be checked in bug fixes release.

File: A.php

$post = the_post();
$post_type = $post->post_type;

var_dump($post); // object
var_dump($post_type); // "page"
include wp-admin/edit-form-advanced;

File edit-form-advanced.php

before "global $post_type, $post..."
var_dump($post); // object
var_dump($post_type); // "page"

after "global $post_type, $post"
var_dump($post); // null
var_dump($post_type); // null

But it 4.1.1 var_dump($post); = object var_dump($post_type) = “page” in edit-form-advanced.

Hello, we solved issue itself, by defining these variables as global too.

I’m just write here to make you know that this line of code was made some issue. So others plugins can have same issue with this reason.

I will also check changelog (to see why this line is added).

Thanks you.

Hello, I understand you. Our plugin is commercial and available in https://codecanyon.net/item/visual-composer-page-builder-for-wordpress/242431

As for code.
When we rendering frontend editor we using edit-form-advanced.php
But unfortunately variables $post_type and $post is defined as local (not in $GLOBALS) so when we are including edit-form-advanced.php – they found nothing and set variables to “null”. But in 4.1.1 they use our local variables.

It is possible to fix from your side?

I understand you, our plugin is commercial and available in https://codecanyon.net/item/visual-composer-page-builder-for-wordpress/242431

As for code, we have local $post, $post_type when rendering editor
and we including edit-form-advanced.php to make available #content usage and other meta-form attributes.

But in current development wp version we found global $post_type, $post..
line added this is not defined as global when we are rendering editor.
So in master this also used as local.

Yes, sorry, looks like it is really incompatible anyway. We will add this to our backlog and try to fix this in future.

Thanks for this bug request and hope it will be solved in future.

This is expected behaviour if you not able to edit page by permissions it also will not be available with VC.

We have modified frontend editor rendering in next big update, so please check since 4.4 will be released (hopefully after 2-3weeks)

You can try to fix MU plugin, wp-content/plugins/wordpress-mu-domain-mapping/domain_mapping.php:649
add before
if ( defined( 'DOMAIN_MAPPING' ) ) {

this:

if(isset($_GET['vc_action']) || isset($_GET['vc_editable'])) {
	return;
}

this is not so secure, but this will fix this problem at least.

Please create support ticket in support.wpbakery.com, we will help you to try to solve this issue, also provide more details.

This fix is really misunderstand, and I think this is not really relative to VC.

Hi Robert, we will think about s2member compatibility in future, for now we can only say that we make product absolutely relative to wordpress basics – we have ultimately integrated system that can be enhanced very easily, and if you make everything correctly without making your own bicycle it will be easy to integrate with VC.

So it is related to plugin authors how it dependency injections is made, how filters and actions used, how properly work Do_shortcode and other NATIVE wordpress functions with this plugin.

Pavel.

WPBakery.