New to the community? Start here

[Branda Pro] Rename WPMUDEV plugins from list for full whitelabel

3

I know we can white label our plugins by changing their names in the sidebar menu. but they’re still visible with their original names in the plugins list.

Fri, 21 Oct 2022 22:11:42
More Branda Pro discussions
Branda Pro
    • Kimmy
      • WPMU DEV Initiate

      So what if the owner of the site has admin privileges, won’t they then be able to see Branda too? Say for example you are offering WPMUDEV plugins as a feature – in my case the videos (IVT). They have full ownership of the site and they’re adding me as a 2nd admin. How do we keep our plugins white labeled if they’re showing up in the plugins section?

  • Tony G
    • Mr. LetsFixTheWorld

    Thoughts on extensive whitelabel…

    If you’re changing and hiding a lot of names, I’d recommend creating a special role for your clients that has all of the same capabilities as an admin (maybe). Then you can code tests to see if the user is in that role and change details just for them.

    Create a plugin that does just this function for you, so that you can easily port the code to another site.
    Look for plugins that do exactly what you’re looking to do, more than simply changing names with Branda.

    I think I know what you’re doing there, and if I’m right then it’s all good and I wish you well. However, what you are considering here could be illegal depending on how its done. Check the license terms of plugins. Changing the name of a plugin and the definition of creation of a derivative work, which is detailed extensively in most FOSS licenses. You can do this if this is your own SaaS site (and based on prior notes I believe this is the case), but not if you are distributing the software. Related – if you are distributing the software in any way, the GPL for WordPress and most other plugins explicitly states that consumers must have the source and be aware of their own licensing rights and obligations.

    Depending on your audience, you might not want to whitelabel so many plugins. Brands like WooCommerce, Gravity, and Yoast have value to those who recognize them. Masking those names actually removes some of that value from your own brand.

    On the other side of that of course – there is an advantage to whitelabeling. You have the freedom to change your supporting plugins without changing your main menus. That is, if your menu says “Forms”, then it doesn’t matter if the plugin under that is Gravity, Forminator, or something else – to your users, it’s simply the “Forms” feature.

    Another reason for not whitelabeling too much – if people think it’s your software then they will expect you to make it work as they want, or to take responsibility when it doesn’t work. It will not look good to your clients if you put your branding on functionality and then can’t fix issues or process enhancement requests. “Hey look, these are Our features” looks great. “Oh but it’s not really Ours” isn’t a great business response if something goes wrong. If people recognize that you are making use of the wonderful world of FOSS, they will understand better your responses to support requests for changes that you can’t actually control.

    As a SaaS host, you are a curator of works of art, not an artist. If people don’t like the colors in a painting, or the way a statue is sculpted, they don’t ask the museum to make changes, because they understand the relationships. If you openly cultivate such understanding for your own users, you can still brand your menu and screens, for example, with “Security”, “Newsletter”, and “Gallery” without hiding author credit and without taking responsibility for the behaviour of the plugins under those names.

    If you openly acknowledge the source of your components, you help to support the authors. One of your clients might want to pay a plugin author for a new feature, or simply send a donation. If you hide the author identity then both sides lose that opportunity. When a software author gets paid for their work, they are encouraged to do more. With a wall between demand and supply, the authors are not encouraged like this, and you could actually contribute to killing a plugin that you value. This is bad for the author and for you too, because now you will need to move away from that functionality and drag all of your clients with you.

    Embrace and support your Free and Open Source Software. There’s much more to this world than just the software.

  • Tony G
    • Mr. LetsFixTheWorld

    I’m revisiting this year-old request, as I was just testing whitelabeling on a test site and I thought I’d add another comment here.

    I think attempting to whitelabel plugins is overall a bad idea. See my previous notes for some reasons why. In addition it’s largely a futile effort. All someone needs to do is to mouse-over an author name that’s been text-modified and they’ll see the author’s website. All they need to do is to click View Details and they see all of the info about the plugin … with its true name. Some plugins have the author ID branded into the page name, like “page=wpmudev-videos”.

    You have to ask yourself why you are really trying to whitelabel the plugins. Do you not want a client to see the real names? Do you not want them to visit the plugin sites? If that’s the case, as I noted earlier, just don’t give them the administrator role (with manage_options capability). Give them a different role like SiteOwner which doesn’t imply the responsibilities of software administration, and then hide the plugins.php link for that role. There are some great plugins that allow for modification of the admin menus.

    Note also that at the bottom of DEV plugins there’s a footer:
    [attachments are only viewable by logged-in members]
    I don’t think DEV provides a way to whitelabel that out of these pages.

    There are simply too many ways for a client to easily see your tooling. So rather than trying to hide it, in futility, for almost no real benefit, embrace the diversity and stand behind your platform choices. If you can’t do that, you have a deeper problem that needs to be resolved.