[The Hub] Ability to remotely disable plugins

0

We have clients who have moved from WPMUDEV hosting to another host. They canceled the account but ported the site with the plugins active. The plugins are still active. Support said disconnecting the site from the hub would remove the plugins, but it does not. We need to be able to remove access to plugins in these scenarios. Many other providers allow this. I am still seeing these sites in automate and other places showing that the site and plugin is still active on the plugins that I am paying a membership fee for. This is completely unfair to have someone cancel an account, but still be able to keep access to everything.

  • Patrick Freitas
    • FLS

    Hi David

    I hope you are doing well.

    You can disconnect the WPMU DEV dashboard from HUB, this will remove any pro access from old customers, we do have plans to implement some kind of blocklist account side but we don’t have an ETA yet.

    In case disconnecting the site from HUB is not preventing the connection back which can happen in some cases, we would need to verify with our Sysadmins if it is possible to block the server IP, we can’t guarantee as it depends on the IP but if you are having this issue feel free to create a new private ticket to share the URL and IP and we can verify the best approach for you.

    Best Regards
    Patrick Freitas

  • David
    • The Incredible Code Injector

    I no longer have access to the site. They have added it back once already. If it happens again, I will contact sysadmin. This is definitely frustrating and should be a basic assumption for us as users that there would be a way to easily keep people from hijacking the plugins. I’m sure James Farmer may be aware that this happens from time to time, but as long as WPMUDEV has been around, it seems like this would have made a priority at some point. It’s not just stealing from us, it is completely devaluing your value proposition.

  • Rosana Reyes
    • Sexy Thing

    Hi David,

    you said it’s completely unfair! Why? Being unfair is human behavior – never a technical issue ;)
    It’s just technology – manmade – never perfect! Sometimes such things happen.

    For example, just a few minutes ago I was busy with the Support Heroine Bhakti, who helped me out with a critical error that denied access from my dashboard to the site after I updated some plugins WITHOUT running a backup beforehand. Stupid me! I caused an issue and was not able to resolve it by myself. Fortunately, there are people out there, who know what they are doing a thousand times much better than me.
    I appreciate that and I am very pleased that those experts are able to fix the damage I caused myself.
    Finally, she found out, that today’s update of Smartcrawl Pro caused a plugin conflict with my overall setup for a reason which is NOT an error of WPMUDEV but WooCommerce. I am happy to have those incredible guys and girls standing by me saving my life always when I mess up something by being stupid or lazy.

    As I understand, YOU migrated a client’s website to another Provider, and after then YOU tried to deactivate the Pro plugins because YOU are paying for those plugins as a Developer or Agency and not YOUR former client anymore.
    Is that correct?

    But I got your point. As a possible solution for that problem, you mentioned, surely there is a technical solution. An option would be a Popup notification, during the migration process, that all PRO PLUGINS by WPMUDEV have to be deactivated and uninstalled before moving to another hosting company can be done.

    From my technical understanding, this should be the easiest way to resolve this issue in the future. Just like a checklist before any procedure can be executed or completed successfully you are forced to fill out a form with all required fields. It´s binary! Just 0 or 1! This means, the 0 = PRO version is deactivated and uninstalled, the 1 = Pro version is installed and activated, or the other way around as you wish! Something like that.

    In case of not have an immediate technical solution ready, I propose taking a piece of paper, like in the good all times before Webhosting even existed, and writing down a list of all the things YOU have to do BEFORE moving a client’s websites to anywhere to avoid this happen again. Pin it onto the wall in plain sight.

    Constructive critics are always good. Blaming somebody else (e.g. James Farmer) for something that can be avoided upfront is not the best way to get things resolved successfully.
    If I did understand your post in the wrong way, please apologize. English is not my native language but I try my very best.
    Generally, it is just a thought when it comes to technical failures vs. human errors. What do you think?

    With all my respect and happy greetings from Spain :wink:

  • Patrick Freitas
    • FLS

    Hi Rosana Reyes

    Thank you for jumping into the conversation.

    In the best scenario, the workflow should be more automated as possible, I do understand the point brought by David , I don’t work for any agency or don’t handle agency customers but based on some friend’s experience I see there are some customers that sometimes won’t be collaborative with the changes and just remove your access of site which makes hard to follow a to-do list on such cases.

    The WPMU DEV HUB API does trigger the logout process from the WPMU DEV dashboard but similar to what I described we can never know what a former customer will do with the website for example trying to revert a backup to a period when the dashboard was connected.

    I know those are edge cases but if we can prevent them, why not.

    The main issue with blocking the entire site or IP is that this customer could decide to start their own membership, or ends the current hosting and migrate the site to a new IP and that block wouldn’t just be valid anymore.

    The proposed solution to our developers is to create a local bock so you would decide if that IP or Domain can be connected to your account in specific.

    But to create this solution be done, it requires massive development, tests and works in our API to ensure it works well and this can take some time to be finally done.

    Until it is not created, we keep collecting all the member feedback and passing it to our developers, and our support will be always happy to help you.

    Best Regards
    Patrick Freitas