Pro Builder Conflict: Revisiting a closed thread

[foureyes]

Hi All,

I originally had this topic under this closed thread (https://theme.co/apex/forum/t/elements-not-rendering-in-pro-builder/65997). At issue is a massive conflict between Member Mouse and Pro Builder. Member Mouse has not been helpful at all and our debugging has gotten us close to fixing the issues, but not in full. I totally understand this is not your issue and I am reaching out because of this one particular site (we only use Pro or tell our clients to only use Pro). At issues are elements not rendering in the builder. I am reaching out to see if there is anything else you think we can do?

What we know is with the plugin in off everything works fine. With that being said we are thinking of doing something like this to shut the plugin off only on pro/cornerstone pages. This seems very obtrusive and if you are willing I would love your feedback and thoughts. Using the builder is imperative for us especially with the new awesome grid tools. Thank you!!!

add_filter( 'option_active_plugins', 'fe_disable_membermouse_plugin' );
function fe_disable_views_plugin($plugins){

  if( ( strpos($_SERVER['REQUEST_URI'], '/pro/') || strpos($_SERVER['REQUEST_URI'], 'cornerstone-endpoint') ) !== false ) {
         $key = array_search( 'membermouse/index.php' , $plugins );
         if ( false !== $key ) unset( $plugins[$key] );
      }

     return $plugins;
 }

[rad]

Hi Micheal,

Thanks for reaching out.

Unfortunately, it’s something that can’t be controlled by the coding of the builder or theme especially if it’s their plugin that altering the usual functionality of other themes and plugins.

What was provided on that thread is just to make sure Member mouse resources aren’t loaded within the builder and its requests. In fact, their plugin shouldn’t intercept any requests that don’t belong to them. The builder has its own ajax functionality and its own naming to make sure it doesn’t conflict with other ajax requests.

This is added to our issue tracker but we don’t have any news yet, it’s not an actual issue but feature related request on our end to see if it’s possible. But the way I see it, the fix should be added on Member mouse ends.

But for the meantime, please try changing this

if( ( strpos($_SERVER['REQUEST_URI'], '/pro/') || strpos($_SERVER['REQUEST_URI'], 'cornerstone-endpoint') ) !== false ) {

to this

if( ( strpos($_SERVER['REQUEST_URI'], '/pro/') || strpos($_SERVER['REQUEST_URI'], 'cornerstone-endpoint') ) !== false || isset( $_POST['cs_preview_state'] ) ) {

Still, I can’t guarantee that it will fix it.

Thanks!

[foureyes]

I totally agree with the Member Mouse comment. They have not been responsive and pretty much say that the MM plugin is designed to work with standard wordpress web development and they cannot fix the plugin beyond that. Thus why I reached out here and we are attempting to circumvent the MM plugin while on Pro.

[foureyes]

The following code as a mu-plugin does work. I suppose this could be extended to other plugins. Fingers crossed this is a solution!

add_filter( 'option_active_plugins', 'fe_disable_membermouse_plugin' );

function fe_disable_membermouse_plugin($plugins){
	if( ( strpos($_SERVER['REQUEST_URI'], '/pro/') !== FALSE || strpos($_SERVER['REQUEST_URI'], 'cornerstone-endpoint') ) !== FALSE || isset( $_POST['cs_preview_state'] ) ) {	
	         $key = array_search( 'membermouse/index.php' , $plugins );
	         if ( false !== $key ) unset( $plugins[$key] );
	      }
	     return $plugins;   
	 }

[jade]

Hi Michael,

Glad to hear it’s sorted and thanks for sharing the solution.

Cheers!