MainWP Clean and Lock - WordPress Plugin

How to Configure MainWP Clean and Lock for a Cleaner, Safer WordPress Admin Area

MainWP Clean and Lock is useful when you manage multiple WordPress sites through MainWP and want to leave clients, editors, or internal team members with only the admin area elements they actually need. This guide does not rehash the product listing. Instead, it focuses on practical decisions: how to prepare your sites, how to enable restrictions without locking anyone out, what to verify after setup, and how to troubleshoot cases where a user cannot see the menu item they need or, on the contrary, has more access than they should.

You should think of the plugin as a tool for administrators who already understand MainWP's role: the central dashboard helps maintain child sites, and this extension adds a layer of interface cleanup and restriction. That approach is especially useful for agencies, freelancers, and technical teams that need to hand off a site for day-to-day use without exposing settings that could break the theme, plugins, menus, or page structure.

This article covers pre-installation prep, a safe first-rollout workflow, detailed role and visibility setup, a real client site scenario, result verification, common issues, an FAQ, and a comparison with similar solutions. Where exact interface items may vary by version, I intentionally avoid presenting guesses as facts: use your current MainWP panel, the MainWP documentation, and a final check with a test user as your reference points.

What Problem Clean and Lock Solves Alongside MainWP

MainWP is typically used as a central control point for maintaining WordPress sites: updates, monitoring, reports, backups through extensions, child site management, and repeatable admin tasks. But once the technical setup is done, a different question appears: what will the person who logs into an individual site actually see? If a client only needs access to posts, pages, orders, or media, the full WordPress menu becomes cluttered and increases the risk of accidental changes.

MainWP Clean and Lock addresses that exact layer of work: it helps shape the child site's admin area into something more controlled and locks down what should not be available to selected users. It is important to understand the product's boundary. It does not replace WordPress's permission model, it does not turn a weak password into secure access, and it is not a standalone firewall. Its role is more practical: reduce interface noise, define clear working zones, and lower the chance of accidental mistakes in the admin area.

For administrators, this brings two benefits. First, less manual work on each site: you can prepare interface rules as part of your regular MainWP maintenance process instead of logging into every child site separately just to do small UI cleanup tasks. Second, a better handoff experience. The client does not receive "all of WordPress at once," but a working environment where only the necessary sections are visible and there is less temptation to click into something risky.

A typical example: an agency maintains a network of small sites. On one site, an editor publishes news. On another, a store manager works with products and orders. On a third, the owner updates hours and contact details. None of those users need to see the plugin editor, global settings, import tools, parts of the tools menu, or certain admin bar items. Clean and Lock helps turn the generic WordPress admin area into a narrower, task-focused workspace.

Key idea: do not start by locking down everything you can. First, list the actions the user needs to perform every day, then hide only the items that are outside that workflow.

Who This Extension Fits and When Another Approach Is Better

In most cases, MainWP Clean and Lock is not for the owner of a single personal blog. It is for someone who regularly hands sites off to other users. If you maintain two or three client projects and find yourself repeatedly explaining where not to click, the extension saves time and reduces support overhead. It is especially appropriate when a client receives administrative access but, by agreement, should not change the site's technical settings.

When the Product Is Especially Useful

The extension fits naturally into a web studio workflow where site handoff follows a repeatable pattern. For example, after launch you may leave the client in charge of pages, media files, menus, products, or orders, while your team continues to handle technical areas through MainWP. In that scenario, Clean and Lock helps you create not one generic admin experience, but a set of clear profiles: editorial, store, content, and maintenance.

Another strong use case is a site where the owner frequently gets lost in the WordPress menu. Even when the user has no intention of breaking anything, an overloaded interface invites mistakes: a widget gets removed, a plugin gets deactivated, the permalink structure gets changed, or the theme is edited without understanding the consequences. Reducing the menu does not make the site invulnerable, but it does create a calmer working environment.

When Clean and Lock May Be Unnecessary

If you have one site and all users already work comfortably within standard WordPress roles, a separate extension may be excessive. First check whether the built-in roles, the settings inside your existing plugins, and a careful permission setup already cover the need. For an online store, learning platform, or product catalog, it is often more important to configure roles correctly, define order statuses, control field access, and organize editorial workflows than to simply hide menu items.

Clean and Lock should also not be your only defense against an untrusted user. If someone must not perform an action from a security standpoint, that action needs to be blocked through role permissions and capabilities, not just visually hidden from the menu. A hidden menu item is useful for keeping the interface clean, but a real access model should rely on WordPress capabilities, plugin settings, and, when needed, dedicated role management tools.

What to Check Before Installing It on Live Sites

Before installation, do not focus only on the activation button. The extension affects how people see the admin area, so a setup mistake can hide a useful item or create extra support requests. Proper preparation takes less time than restoring a messy, over-restricted menu across several sites.

Verify the MainWP Architecture First

You should already have a working MainWP Dashboard and connected child sites with MainWP Child installed. That is the basic MainWP setup: the central site sends commands, and child sites receive them and return data. If the connection to a child site is already unstable, fix that first. Otherwise, you will not know whether the problem comes from Clean and Lock, the MainWP connection, or the site itself.

For your first test, choose one non-critical site or a prepared copy. Do not roll out new restrictions across the entire network right away. Even when the settings look straightforward, different sites may use different plugins, roles, custom menu items, and extra screens. On one site, hiding an item may have no side effects. On another, the same item may be the only entry point into an important workflow.

Map Users to Real Tasks

Before configuring anything, write down who actually works with the site. Do not stop at labels like "administrator" and "editor." Describe real tasks instead: publishing news, changing prices, processing leads, adding images, checking analytics, editing menus, handling orders, translating pages, updating schedules. That makes it less likely you will hide a section just because it looks technical at first glance.

Then divide the menu into three groups. First, the essential working sections the user must always see. Second, occasional but safe sections that can stay available to a designated person. Third, technical areas where the client should not work without an administrator. Clean and Lock makes the most sense for the third group and, in some cases, the second, but not the first.

Create a Backup Access Path

Before applying any restrictions, make sure you have a separate administrator account, hosting access, and a recent backup. This is not a formality. If you hide too much of the interface or assign the wrong role, your backup path lets you restore the settings without panic. For client sites, it is helpful to keep a technical account that is not used for everyday content work.

Safe rule: configure restrictions for a test role first, log into the site in a separate private window, and only move the rule to the real client after you have verified it.

Installation and Initial Rollout Without Risking Access

At a high level, installing MainWP Clean and Lock follows the usual MainWP extension logic: the central MainWP panel manages child sites, and the extension adds the necessary module to that workflow. Exact menu labels may change, so use the current MainWP documentation and the interface in your installed version as your guide. What matters more than memorizing one button is following a safe sequence.

The Right Order for the First Rollout

1. Confirm that MainWP Dashboard can see the selected child site and shows no connection errors.
2. Make sure MainWP Child is installed on the child site and that the site opens normally in the standard WordPress admin area.
3. Install and activate the extension in the MainWP environment without changing any rules for real users yet.
4. Choose one test child site where you can safely check menu visibility.
5. Create or use a test user whose role matches the future client role as closely as possible.
6. Enable one minimal rule: hide a single obviously unnecessary technical menu item or widget.
7. Log in as the test user in another browser or a private window and verify the result.

This sequence may feel slow, but it prevents the most common mistake: an administrator configures everything from their own session, sees a normal admin area, and only later learns from the client that a needed section has disappeared. Testing with a separate user shows the real outcome and immediately reveals where visual hiding intersects with role permissions.

What Counts as a Successful Initial Check

A successful test is not just a menu item disappearing. You need to confirm that the user can complete their workflow from start to finish. If an editor needs to add a post, upload an image, choose a category, save a draft, and submit it for publication, test the full chain. If a store manager needs to open an order, change its status, and find the buyer's email, check those exact steps.

After the test, record the setup in a short internal note: which role you checked, which items were hidden, which actions remained available, and where the backup administrator access lives. That note will help months later when the client asks to restore an item or when you add a new plugin with its own menu.

How to Configure Menu Visibility, Widgets, and Working Zones

The settings area is the core of working with Clean and Lock. The goal is not just to "hide extra stuff," but to build an admin area that makes sense for a specific role. WordPress does not know which interface will be clear to your client. It shows menus based on user capabilities and active plugins. The extension helps remove visual noise and leave only what is needed for daily work.

Start with the Top-Level Menu

First, look at the left-side WordPress menu. It usually mixes content sections with theme settings, plugins, tools, SEO, forms, caching, security, store features, analytics, and other items. To a client, that can look like a long list of equally important sections, even though in practice most of it belongs to site maintenance.

Work from top to bottom. First keep the sections involved in the user's daily tasks. Then hide the technical items that should remain available only to the administrator maintaining the site. Do not hide an item based on its name alone: some plugins place working screens inside sections that look technical. For example, form settings may be necessary for a lead manager, and a store menu item may include not only orders but also reports.

A Practical Way to Sort Menu Items

• Always keep: sections the user cannot do their main job without.
• Keep for a designated person: sections needed only occasionally and only by someone prepared to use them.
• Hide from the client: technical settings, editors, maintenance tools, and system screens.
• Review separately: items added by WooCommerce, page builders, SEO plugins, form plugins, and multilingual tools.

Remove Dashboard Widgets When They Do Not Help

Widgets on the main dashboard screen often create more noise than value. On a client site, that area may show WordPress news, plugin panels, notices, quick drafts, stats, and system hints. Some of those blocks are useful, but many are distracting or lead into sections the user should not be changing.

If your version of Clean and Lock lets you manage those elements, apply the same logic there: leave only the blocks that help the user make a decision or quickly reach a real task. For example, an editor may benefit from a list of recent drafts, while a store owner may want an order overview. But a general stream of technical notices is better left to the administrator maintaining the site.

Do Not Confuse a Clean Interface with a Real Permission Boundary

Hiding a menu item makes the interface calmer, but it does not always mean the action is fully blocked at the WordPress level. If a user knows the direct URL, or if another plugin exposes the same screen, the result may depend on the role's permissions. For critical actions, use two layers: WordPress roles and capabilities as the foundation, and Clean and Lock as the usability layer that also helps prevent accidental navigation.

This matters especially on sites using WooCommerce, membership systems, LMS platforms, page builders, and editorial teams. Those systems often have their own roles, permissions, screens, and workflows. Before applying rules broadly, test not only the left menu but also direct working links, buttons inside plugins, notice links, and actions inside list tables.

How to Roll Back a Questionable Setting

Every questionable setting should have a fast rollback path. Do not make ten changes at once. Apply one logical rule, test the result, note what changed, and only then move to the next one. If the user loses access to a needed function, you can restore one specific item instead of disabling the entire configuration blindly.

A good rollback looks like this: restore the menu item or widget, clear the admin area cache, refresh the page in a private window, test the action under the test user, and then tell the client that access has been restored. If the same issue happens after every new rule, the role map needs to be reconsidered instead of continuing to hide items by trial and error.

Agency Workflow: Handing Off a Site to the Client After Launch

The clearest real-world example is a post-launch site handoff. Suppose an agency has built a site for a small company. The client needs to update text, images, news, sometimes edit menus, and review inquiries. Technical maintenance, updates, plugins, the theme, backups, and security remain with the agency through MainWP.

Scenario Goal

The goal is to let the client complete content tasks without seeing the technical sections managed by the agency. At the same time, access should not be so restrictive that every text change turns into a developer request. The balance is simple: the user sees everything inside their agreed area of responsibility and does not see what could affect site stability.

Preparation

Before configuring anything, create a test user with the same role the client will receive. If the client needs access to several sections, do not jump straight to the administrator role just because it is faster. It is better to start with a narrower role and expand it deliberately. Check which menu items appear for that role before applying Clean and Lock. That is your baseline for comparison.

Next, open the list of client tasks. For example: create a post, upload an image, update the "Contact" page, open the inquiry form, review orders, or update business hours. For each task, note the required menu item. Anything not on that list becomes a candidate for hiding or restriction.

Configuration Steps

1. In MainWP, choose a test child site where you can verify the rule without risking other projects.
2. Build the minimal set of visible sections for the client role: pages, posts, media, forms, orders, or other working areas.
3. Hide the technical sections maintained by the agency: plugins, tools, parts of settings, system screens, and unnecessary notices.
4. Log in as the test user in a separate session so you do not confuse the admin view with the client view.
5. Complete a real task from start to finish: create a draft, upload an image, save the change, and open the public page.
6. If everything works, apply the rule to the real user or user group and keep an internal note about the configuration.

How to Verify the Outcome

The result is good when the client sees fewer menu items but still keeps working independence. Check three levels. First, the menu: unnecessary sections are gone, required ones remain. Second, the action: the user can save the content they need to manage. Third, the public site: changes display correctly, and caching or permissions do not prevent the result from showing up.

If the client cannot complete a task after the restriction is applied, do not immediately assign the administrator role. First determine which specific menu item or capability is actually required. Sometimes restoring one screen or enabling one permission in a dedicated plugin is enough. Restoring full administrative access often solves the issue quickly, but it defeats the purpose of Clean and Lock.

A Detail People Often Forget

After a new plugin is installed on a child site, a new menu item may appear. If your Clean and Lock rule was created before that installation, review the client's admin area again. The new item may be useful, unnecessary, or risky. That is why interface cleanup is not a one-time task. It belongs on the checklist after major updates, new extensions, and changes to the client's role.

Working with Roles: Where Cleanup Ends and Security Begins

MainWP Clean and Lock is most useful when you clearly separate two ideas: interface visibility and actual permissions. Visibility answers the question, "What does the user see in the menu?" Permissions answer the question, "What can the user do if they reach the screen?" Those layers are related, but they are not the same. If you blur them together, you can end up with a tidy admin area built on the wrong security model.

Why You Cannot Rely on Hidden Menu Items Alone

In WordPress, many actions are checked through capabilities. A user may not see a menu item, but direct access to the screen should still be blocked by the role's permissions. The reverse can also happen: a role may not be allowed to perform an action, yet a menu item or notice may still appear because of how a third-party plugin behaves. That is why Clean and Lock works best as a layer of interface discipline, not as your only protection mechanism.

In practical terms, that means this: configure roles and capabilities first, then clean up the interface. If the client does not need to install plugins, they should not have that capability at the role level. After that, Clean and Lock can remove the corresponding menu item so the user does not see a useless or confusing area.

Roles for Common Working Scenarios

For an editorial site, a role that handles posts, pages, categories, and media files is often enough. For a store, you need to account carefully for orders, products, coupons, reports, and integrations. For a site built around forms, the key question is whether the manager should only read submissions or also change form fields and notification settings. The more precisely you define the workflow, the less likely you are to grant administrator access "just in case."

If the standard roles are not enough, use a dedicated tool for managing roles and capabilities, then apply Clean and Lock afterward. That gives you a clear model: permissions block risky actions, and Clean and Lock makes the admin area cleaner and easier to use.

Mini Checklist for a Safe Rule

• The rule is tied to a clearly defined role or user group, not to a random account.
• The user still has access to every action that falls within their real responsibilities.
• The technical administrator keeps a separate backup login.
• The setup has been tested in a separate session, not only from the administrator account.
• The changes are documented in a short internal note.

Settings After Updates, New Plugins, and Changes in Client Responsibilities

The WordPress admin area is not static. Install a new SEO plugin and a menu item appears. Add a form and now there are submissions and notification settings. Switch to a different page builder and the editor's working screens change. That is why Clean and Lock should be part of your ongoing maintenance process, not treated as a one-time setup right after the site launches.

When to Revisit the Rules

The minimum trigger for a review is a plugin being installed or removed, a theme change, a new role being added, the site being handed to another employee, or the addition of WooCommerce, forms, multilingual tools, an SEO plugin, or a page builder. Even if Clean and Lock continues to work, a new menu item may either clutter the interface or hide something the client now needs.

For an agency, it is useful to add a specific step to the maintenance checklist: after technical changes, log in as a test user and look at the admin area from the client's perspective. It takes only a few minutes, but it prevents the standard support messages like "the section disappeared after the update" or "I now see a new item and don't know what to do with it."

How to Evaluate New Menu Items

When a new plugin adds a screen, do not automatically decide to hide it or keep it. First determine what role that screen plays. It might be a working screen, such as a list of form submissions. It might be semi-technical, such as email templates. Or it might be entirely administrative, such as integration settings or API configuration. Each case calls for a different decision.

Keep a working screen and explain why the client needs it. A semi-technical screen may be better left only to a responsible person. A service screen is usually best hidden from day-to-day users and handled by the technical administrator. The important thing is not to hide every new item out of fear: sometimes that new menu entry is exactly what the business process needs.

What to Do with Plugin Notices and Promo Blocks

Many plugins add notices to the admin area. Some notices matter: a service license problem, a mail delivery error, a caching conflict, or a required database update. Others are promotional banners, tips, or review requests. If the extension lets you remove unnecessary elements, do it carefully. Do not hide critical messages until you are sure the technical administrator can still see them somewhere else.

A practical approach is to leave the client only the messages that require a business decision and handle technical warnings through your support process. But that only works if the administrator has their own control system in place: monitoring, MainWP reports, backups, and regular logins to the site.

Verifying the Result: How to Tell Whether the Admin Area Actually Improved

After configuring Clean and Lock, it is easy to stop at the visual impression: the menu is shorter, so everything must be fine. In practice, you need to evaluate not just menu length but workflow quality. A good result means the user finds the right action faster, makes fewer mistakes, and still has access to the tasks they are responsible for.

Check It from the User's Perspective

Open the site under a test user and complete a real workflow. Do not limit yourself to the main admin screen. For an editor, create a draft, add an image, choose a category, save it, and open the preview. For a store manager, find an order, change its status in a test flow, and verify the email or internal note. For a content administrator, open the relevant page, edit a block, save it, and check the public result.

Write down where the user gets stuck. If a necessary action is hidden too deep, you may need not only a cleaner menu but also a better working instruction. If the user keeps trying to open a restricted section, that may mean either they do not yet understand the workflow or the role genuinely needs more access.

Check It from the Administrator's Perspective

The administrator also needs to confirm that the restrictions do not interfere with site maintenance. Make sure the technical account still sees the full admin area, MainWP maintains its connection to the child site, updates continue to work normally, and service notices have not disappeared from your monitoring process. If you hid notices from the client, verify that you can still access them.

Also check caching and security. Some caching or optimization plugins affect the admin area less than the public site, but after major changes it is still useful to clear the cache and reload the page. If a security plugin is active, confirm that it does not interfere with the test user's normal workflow after menu visibility changes.

Simple Metrics You Can Use Without Complex Analytics

• The user can complete a standard task without contacting a developer.
• The menu includes only working sections that are clear and relevant.
• The technical administrator still has full access and a backup path.
• New plugins and updates do not introduce unnecessary interface chaos for the client.
• The client instruction becomes shorter because the interface is no longer overloaded.

If those conditions are met, the setup has genuinely improved the site. If the menu is shorter but the client cannot finish their task, the configuration needs to be revised.

Useful Improvements Without Risky Custom Code

Clean and Lock usually does not need custom code. Its job is better solved through settings and a well-defined role map. There is no reason to add snippets just for appearance: unknown CSS or PHP in the admin area can conflict with plugins, updates, and future interface changes. It is safer to improve the workflow through documentation, a test user, and checklists.

An Internal Reference Note Instead of Custom Code

The most useful improvement is often a short reference note for the support team. It does not interfere with the site and it does not break after updates. In that note, you can record which roles exist, which items are hidden, which actions were tested, and who is responsible for reviewing the rules after new plugins are installed.

Site: example.com
Client role: Content Manager
Available sections: Pages, Posts, Media, Forms
Hidden technical areas: Plugins, Tools, selected Settings screens
Verified: post creation, image upload, form submission, public page review
Rollback: restore the hidden item in Clean and Lock, clear cache, verify in a private window

You can store that text in a task system, an internal knowledge base, or the client record. It is especially useful when a site is maintained by a team rather than one person. A new specialist can quickly understand why the interface is configured this way and will not disable restrictions blindly.

When Code Still Is Not the Right Answer

Do not edit WordPress core, plugin files, the theme, or MainWP Child just to hide elements. If the behavior you need is not available in Clean and Lock settings, first review the documentation, WordPress roles, and dedicated plugins. Code in the admin area is only justified when it is documented, reversible, tested on a staging site, and solves a narrow problem. For most interface cleanup scenarios, that is unnecessary.

If the client asks to change the appearance of the admin area, separate presentation from access. Branding, a welcome screen, and guidance elements can be useful, but they do not replace restrictions. Start with permissions and workflows, then clean up the menu, and only after that consider decorative improvements.

Common MainWP Clean and Lock Issues and How to Diagnose Them

Problems with Clean and Lock usually come not from the fact that it was installed, but from the interaction between roles, hidden items, new plugins, and client expectations. Below is a practical diagnostic flow worth following calmly and step by step.

The User Cannot See a Needed Menu Item

Symptom: the client says that after setup they can no longer open a section they used before. Sometimes they say "the page is gone" when in reality only the menu item or the screen link has disappeared.

Possible cause: a Clean and Lock rule is hiding the item for that role, a new plugin moved the screen into another section, or the user lacks the necessary capability at the WordPress level. If you changed several rules at once, the cause is harder to isolate.

What to check: log in as a test user with the same role, open the menu, and walk through the action using the direct working flow. Then compare that with the administrator account. If the administrator can see the item and the client cannot, review both the visibility rule and the role permissions.

How to fix it: restore the specific item or revise the role. Do not grant full administrator access until you know exactly what access is actually needed. After the change, test the action in a separate session and record the update in your notes.

The Item Is Hidden, but the User Can Still Open the Action

Symptom: the menu looks clean, but the user can still reach a technical screen through a direct URL, a notice, a button inside a plugin, or a browser bookmark.

Possible cause: menu hiding is acting as an interface restriction, but the role still allows the underlying action. This is the classic case where visual cleanup is mistaken for real access control.

What to check: open the questionable screen through a direct link while logged in as the test user. If the screen is accessible and allows changes to be saved, configure the role's capabilities or use the dedicated plugin that controls access to that function.

How to fix it: use WordPress roles as the first security layer and Clean and Lock as the second, usability-focused layer. After changing the role, test the menu, the direct link, and the user's workflow again.

A New Plugin Added Extra Menu Items for the Client

Symptom: the admin area used to be tidy, but after installing an extension, a form tool, an SEO plugin, or store functionality, new sections appeared.

Possible cause: the new plugin added its own menu, which was not part of the older Clean and Lock rule. This is normal in WordPress, where each major plugin can add its own screens.

What to check: determine whether the client actually needs the new item. If it is a list of submissions, orders, or a content-related working screen, it may need to stay. If it is for integrations, API settings, caching, or maintenance, it is usually better hidden from day-to-day users.

How to fix it: update the visibility rule after the plugin is installed, then perform a verification login under the test user. Add a Clean and Lock review step to the checklist after major site changes.

MainWP Does Not Apply the Changes to the Child Site

Symptom: you changed a rule in the central panel, but the child site's menu visibility did not change, or did not change right away.

Possible cause: the issue may not be Clean and Lock at all. It may be the connection between MainWP Dashboard and the child site, admin area caching, a plugin conflict, or simply testing under the wrong role. If you are viewing the site from an administrator account, you may not be seeing what the client sees.

What to check: first confirm that MainWP Dashboard is communicating with the child site normally. Then clear the cache, reload the page in a private window, and log in as a test user with the correct role. Also make sure you are not looking at a different site or a staging copy.

How to fix it: restore the MainWP connection, verify MainWP Child, and then apply the rule again to a single test site. If the problem repeats only with a specific plugin, temporarily disable conflicting settings only on a test copy and document the result.

The Client Asks to "Put Everything Back"

Symptom: the user interprets the shortened menu as a loss of control, even though the required actions are still available.

Possible cause: the rules were introduced without explanation, or sections the client was used to seeing were hidden. Sometimes the person does not need actual access, but they do need clarity about who is responsible for the technical side.

What to check: walk through the client's real tasks with them. If everything works, the issue may be communication rather than configuration. If it does not work, restore the specific missing item.

How to fix it: explain the division of responsibilities: the client manages content, and the agency handles technical settings. Provide a short guide to the remaining sections. If the client genuinely needs to manage some technical areas, create a separate role or expand access in a targeted way.

When MainWP Clean and Lock Is the Right Choice

MainWP Clean and Lock is worth testing if you already maintain sites through MainWP and want to make client admin areas cleaner, calmer, and safer for day-to-day work. It is especially useful when one technical administrator handles maintenance while other users only work with content, leads, orders, or specific business sections.

A strong setup does not begin with the urge to hide as much as possible. It begins with a task map. Define the roles, keep the sections users truly need, hide the technical noise, verify the result under a test user, and add the rule to your maintenance checklist. After installing new plugins, changing the theme, or handing the site to a different staff member, return to the configuration and check whether the admin area has changed.

If this is exactly the interface-control layer you need inside the MainWP ecosystem, you can download the ZIP archive and test the extension on one child site first. Do not start with a mass rollout across the entire network: careful, staged configuration will give you more value than a quick blanket lockout of every unfamiliar menu item.