mainwp

I see this was resolved with an update from Bogdan in the ticket system and will be released in an official update shortly.

I believe Bogdan tracked down the issue to some .htaccess code on your Dashboard site, is it okay to mark this as resolved?

Thanks, we should have an update for the issue shortly.

Please note in Bold at the top of the MainWP Dashboard installation page we do have the following warning: “NOTE: MAINWP IS NOT TESTED ON OR DESIGNED FOR MULTISITE INSTALLS, WE HAVE REPORTS THAT MOST FUNCTIONS WORK CORRECTLY BUT SUPPORT WILL BE LIMITED. WE DO NOT RECOMMEND INSTALLING THE MAINWP DASHBOARD PLUGIN ON A MULTI-SITE INSTALL.”

We also have no reports on it ever “blowing up” a subsite when being installed on multi-site.

Thanks

I had the Development team take a look at this and we were able to see the conflict at this code: isset( $_POST[‘server’] );

in the function

public static function is_active() {
return ( (bool) get_option( ‘shipwire’ ) && function_exists( ‘simplexml_load_string’ ) ) || isset( $_POST[‘server’] );
}

call from this code

if ( WPSC_Shipwire::is_active() ) {
if ( ! in_array( ‘shipwire’, ( array ) get_option( ‘custom_shipping_options’, array() ) ) )
update_option( ‘custom_shipping_options’, array( ‘shipwire’ ) );

$wpsc_shipwire = new WPSC_Shipwire_Shipping();
$wpsc_shipping_modules[$wpsc_shipwire->getInternalName()] = $wpsc_shipwire;
}

If there is a parameter named ‘server’ in the request then the code of the plugin will reset the value of the setting ‘custom_shipping_options’ to value ‘shipwire’ so it clears the saved values

This should be fixed in the WP ECommerce code because there maybe other requests from other plugins with parameter named ‘server’ that will reset that ‘server’ valuable.

They can change that conditional to something special like as ‘wpsc_server’ … or something like that and no other plugin will conflict with it.

Marking as resolved with no reply. Please feel free to re-open if you still have issues.

Thanks, fixed in version 1.6