Currently if multiple sites are disconnected you need to change to the Sites page and use a Bulk Action to reconnect all. If you are on the dashboard you can only reconnect one at a time. It would be nice to add an option to the Dashboard Widget to have an option to Reconnect All Disconnected Sites.

Michael 4 days ago

⚒️

Core Requests (Dashboard/Child)

Currently the vulnerability checker requires us to go through all entries and click either on “ignore“ or “ignore globally“ and wait for the request to finish. Ideally we’d have a bulk-option, where we can select multiple entries and then select an action for all of them. This makes it especially easier, for false positives like “Division by zero“ in c-libraries which often matches for the Divi theme.

Dominic 6 days ago

1

⚒️

Core Requests (Dashboard/Child)

I really like the Feature Support Form in the Whitel Label Plugin. A great addition would be a “File Upload” Field for the client to be able to attach sc reenshots of his problem.

Philip 15 days ago

🔄

Extension Improvements

Hi, I have a fairly big feature request: MainWP integration with xCloud. What do I mean by integration? Automatically add new WordPress sites created in xCloud to MainWP. Show xCloud backup information and backup status directly inside MainWP. Share relevant site data between xCloud and MainWP, so the two platforms stay synchronized. Why would this be useful? xCloud is excellent for server and hosting management, but its WordPress management features are still far behind what MainWP offers today. A native integration between the two platforms could create a much more powerful ecosystem: xCloud for infrastructure and hosting management, MainWP for WordPress management. I think this would be extremely useful for agencies managing many WordPress websites.

Sascha 21 days ago

⚒️

Core Requests (Dashboard/Child)

It would be very useful to have the ability to manually define whether a site is a Production or Staging site in MainWP. Currently, the MainWP Staging extension creates a “Staging Sites” tag, and sites can be manually added to that tag. However, this does not affect the Production / Staging filter in the Updates section. A site manually added to the Staging Sites tag still does not appear when selecting Staging from the Updates page dropdown. I manage several staging sites that are not created through WP Staging or another staging integration, so MainWP cannot automatically detect them as staging environments. It would be helpful to have a setting in each site's configuration, for example: Site type Production Staging Automatic detection could remain the default, while this setting could allow users to manually override or define the site type when needed. The manually selected type should then be respected throughout MainWP, particularly by the Production / Staging filters on the Updates page. This would make the Production/Staging functionality useful for staging environments regardless of how they were created.

Kevin 22 days ago

⚒️

Core Requests (Dashboard/Child)

Just a small suggestion, is it possible to make the save button always show on screen or have one at the top also. I have a lot of sites and content and to save always requires a fair amount of scrolling. Thanks

Jane 24 days ago

⚒️

Core Requests (Dashboard/Child)

I would like to request support for locally cached website thumbnails in MainWP Pro Reports. I use a custom PDF template that displays each client site’s thumbnail via the WordPress.com mShots service. This approach, which I found in the MainWP Dashboard source code, looks clean when the image loads correctly. However, mShots can be slow to respond during PDF generation. As a result, many generated reports are missing the thumbnail image. Could MainWP download and store a thumbnail locally for each connected site, for example during site syncs or on a scheduled interval? Ideally, the cached thumbnail would then be available through a token in Pro Reports templates. This would make PDF generation much more reliable and enable more polished, client-specific reports. Thank you for considering this feature.

Stijn 28 days ago

⚒️

Core Requests (Dashboard/Child)

I thought MainWP would aggregate the core, plugins and themes info to produce less API calls, but as it seems, it calls the API for every single plugin etc., consuming a lot of credits. Is there a way to merge the single requests into one or at least fewer calls?

Florian about 1 month ago

⚒️

Core Requests (Dashboard/Child)

Howdy, from the >=6.0 version of MainWP dashboard, I've a persistent issue with "Plugin installation". Step to reproduce the issue: 1) Plugins->Install Plugins 2) select all sites 3) upload new .zip plugin's file 4) installation options active: activate after installation + overwrite existing version 5) click on "Complete Installation" —> A popup appear with the installation process, then some installations goes fine but many other sites fail. Which is the issue? With fews sites, I just redo the upload and just uncheck the sites which goes fine in previous process, but with 20/30 or more sites this process is confusionary, slow and it need a lot of time. What I propose: A feature that understand which sites failed the installation, then keep the plugin uploaded and make me able to retry only to the failed target. What do you think about? Thank you.

Gianluca about 1 month ago

⚒️

Core Requests (Dashboard/Child)

Alongside the existing options to ignore updates globally and/or for a specific version having the ability to ignore updates for an amount of time, or until a given date/time, would be nice. The use-case is related to more complex polygons, such as Woo or PM Pro, wanting to wait an amount of time before updating. I like to do this just to be sure everything is okay for these sorts of plugins, not just on local sites, but regarding how there’s an increasing amount of supply-chain issues driven in part by AI I like waiting and not being on the bleeding edge. I can just leave the updates un-updated, but being able to use the existing ignoring feature for this would be better.

Alex about 1 month ago

⚒️

Core Requests (Dashboard/Child)

Please add an official MainWP integration for JetBackup 5 via JETAPI. Many MainWP agencies use JetBackup at the cPanel-account level as their primary backup and restore system. Today, MainWP can manage WordPress updates and security, but it cannot show whether the corresponding hosting account has a recent successful JetBackup snapshot. Requested capabilities: Map each MainWP child site to its cPanel account/server. Display latest successful JetBackup backup date, age, size, retention and failure status in MainWP. Surface stale or failed backups in Dashboard Insights, site views and Pro Reports. Provide a direct link from the MainWP site record to the relevant JetBackup restore interface. Optionally allow an on-demand JetBackup backup before a MainWP update. Use a least-privilege, read-only JETAPI token for reporting by default; any create/restore capability should require a separate explicitly enabled credential. This should support the real-world model where one cPanel account may contain multiple WordPress sites, databases and mailboxes. MainWP would remain the WordPress management layer, while JetBackup remains the backup and restore authority. This would give agencies a reliable “safe to update” signal without installing a second WordPress backup plugin on every child site.

Ben about 1 month ago

💡

New Extension Ideas

When managing updates across multiple sites using staged rollout rings (tags), I need to update specific plugins across all sites in a single update ring at once. Currently: The 'per item' view shows each plugin with all sites, but doesn't allow filtering by tag The 'per tag' view groups by tag first, then sites, then plugins—requiring me to expand each site individually to find and update a specific plugin What I’d like: A way to view updates grouped as Tag → Plugin → Sites, so I can: Select my update ring (tag) See all plugins needing updates in that ring Update a specific plugin across all sites in that ring with one action Then move to the next update ring and repeat This would enable efficient staged rollouts where I update one plugin across Ring 1, then Ring 2, rather than updating all plugins on one site at a time.

Charlotte about 2 months ago

🎨

UI & Usability Suggestions

I’d like to suggest a feature that I believe is currently missing from the MainWP MCP server, but is quite important in practical use. At the moment, there is no ability for an AI agent to perform a backup of a site before executing updates (such as plugin or theme updates). From a workflow and risk management perspective, this is a critical step — and ideally, it should be something we can instruct the AI to handle automatically before making any changes. In our case, we use WPvivid across all client sites. We’ve found it to be extremely reliable, especially for full backups and migrations. Previously we used UpdraftPlus, but have since standardized on WPvivid due to its consistency and performance. Because of the current limitation, we still need to manually log into sites (or the dashboard) to trigger backups before allowing any updates. This reduces the usefulness of MCP in real-world scenarios, as it breaks the automation flow. It would be incredibly valuable if MCP could: Trigger a backup before updates (as part of an automated workflow), or At minimum, allow the AI agent to execute a backup via the installed backup plugin (e.g., WPvivid) on the connected child site or from the wpvivid plugin installed and linked to mainwp. Even a basic integration or hook into existing backup plugins would significantly improve the safety and usability of MCP. Are there any plans to introduce this kind of backup capability? I believe it would make the MCP server much more powerful and practical for day-to-day use. Thanks for all the work you’re putting into MainWP — really looking forward to seeing how MCP evolves.

Johan about 2 months ago

⚒️

Core Requests (Dashboard/Child)

I am writing to request an enterprise-grade expansion of the newly launched MainWP MCP Server. While the core philosophy from your latest blog post of "AI interprets intent, MainWP controls execution" is brilliant - especially the "fail closed" design for destructive operations and the 5-minute confirmation tokens - the current local architecture presents a roadblock for high-security agency environments. The Challenge for Agencies: Our security policies strictly prohibit team members from using local stdio transport or managing static, long-lived tokens in local.env files across multiple employee machines. Instead, our agency standardises all AI automation within cloud-native environments, specifically Google AI Studio and Vertex AI inside our Enterprise Google Workspace. Because the current setup is limited to local client configurations, we cannot safely expose our MainWP fleet to our enterprise Gemini bots. Proposed Solution / Request: We would love to see MainWP expand this architecture to support remote, zero-trust cloud-to-cloud connections. Specifically, we request: Hosted SSE (Server-Sent Events) MCP Server: To allow cloud-based LLM clients to communicate with the dashboard securely over the web without local command-line dependencies. App-to-App (A2A) OAuth 2.1 Authentication: To eliminate static developer tokens and enforce secure, audited token exchanges between our Google Cloud environment and the MainWP Dashboard. Business Impact: Bringing out cloud-native enterprise hooks would allow agencies operating in strict compliance environments to safely deploy Gemini bots across their entire WordPress fleet. We would jump on this immediately if a secure, zero-trust cloud bridge became available. Thank you for the continuous innovation on MainWP 6.0+!

Paul about 2 months ago

⚒️

Core Requests (Dashboard/Child)

Could you add a “Lifetime” option in the dropdown for renewal frequency in the cost tracker? This allows tracking association of lifetime licenses to one or more websites. Additionally, it would be handy to have a field for “License Key” for these subscriptions versus putting them in the Notes field.

Brian about 2 months ago

1

🎨

UI & Usability Suggestions

I’ve been using MainWP and the Pro Reports extension to manage and report on multiple client websites. While the core functionality of the plugin is outstanding, the reporting system falls short when dealing with high-tier clients or those subject to rigorous external audits. I would like to raise two critical points that currently limit the value of these reports: 1. Depth of Information for External Audits High-end clients often have their sites audited by external cybersecurity or IT compliance teams. They don't just need to know that an update happened; they need comprehensive, detailed logs of the service provided. The current reporting depth feels too basic for these requirements, forcing us to manually supplement the data to prove the thoroughness of our maintenance and security cycles. 2. PDF Pagination and Layout Issues From a visual and brand perspective, presentation is everything. Currently, the generated PDFs suffer from severe pagination issues, such as text overlapping, awkward page breaks, and cut-offs in tables or logs. This look highly unprofessional when delivered to a corporate client and dilutes the perceived quality of our agency's work. Suggestion: MainWP is an incredible tool, but the reporting feature needs to evolve to match enterprise standards. We need: More granular data options for security, performance, and maintenance logs. A robust PDF rendering engine (or better CSS/page-break control within the templates) to prevent layout breakages. Is anyone else facing these limitations with demanding clients? I’d love to know if the team has plans to revamp the Pro Reports layout engine and data depth anytime soon. Thanks!

Alvaro 2 months ago

⚒️

Core Requests (Dashboard/Child)

For example if a post is viewed, added, updated, or deleted show which one (or at least allow us to click on the record to see more info) Do the same for plugins, users, etc…

Tom 2 months ago

⚒️

Core Requests (Dashboard/Child)

We add many ‘Favorites’ so we can easily install. We only just found out that, despite version updating for favorites, these new versions are not taken into account at all on the normal ‘needing upgrade’ pages. This means we, and others, are likely to miss the need to update them, especially if someone updates a custom plugin but someone else handles the updating of the sites. We assumed the favorites were integrated in the ‘showing updates’ but just got told they are not. (so someone updates one of the favorites, this will Not show on your normal update pages). We would think it essential that any plugin, theme, etc that MainWP knows to have a new version should be visible as upgrade needed. So please vote for this so we can actually keep things as updated and secure as we think we do.

Hein 3 months ago

⚒️

Core Requests (Dashboard/Child)

Feature Request: Client Management Mode (Monitoring Only vs Full Management) Overview I use MainWP to manage different clients, and not all of them have the same maintenance agreement. Some clients are fully managed by my agency, where we handle: WordPress core updates Plugin updates Theme updates Maintenance and monitoring However, other clients are connected to my MainWP infrastructure only for monitoring purposes, such as: Uptime monitoring Security checks Backup status Reports and general statistics For these clients, I do not want their websites to be included in bulk update operations, maintenance tasks, or automated update workflows. Suggested Feature Add a "Management Mode" setting at the Client level, allowing administrators to define how all websites belonging to that client should be handled. Example: Full Management Include all client websites in bulk WordPress updates Include all client websites in bulk plugin updates Include all client websites in bulk theme updates Include all maintenance and automation workflows Monitoring Only Keep the client's websites connected to MainWP Allow uptime and security monitoring Keep reports, statistics, and backups visibility Exclude all websites from update-related actions and maintenance automations Why this would be useful Many agencies and freelancers offer different service plans. Some clients pay for complete website maintenance, while others only use the agency infrastructure for monitoring and reporting. A Client Management Mode would make MainWP more flexible, improve organization, and reduce the risk of accidentally applying updates to websites that are not covered under a maintenance contract. Thank you for considering this feature.

Lucas 3 months ago

⚒️

Core Requests (Dashboard/Child)

Please add a new column, that is showing the current and the latest version numbers of plugins or themes in the main row of the plugins and themes. As there could be different current versions of plugins and themes on the different websites, the “current” version number should show a sum of the version number, which could be clear and we can understand. Examples: When all the current versions are the same on all sites: 6.3.1 → 6.4.0 When there are different security versions on the sites: 6.3.x → 6.4.0 When there are different sub versions on the sites: 6.x.x → 6.4.0 When there are different main versions on the sites: x.x.x → 6.4.0 So we don’t need to open all plugins to check the version numbers, if the versions are the same or only the security versions are different. In this way we could make decisions much faster to update the plugins and themes.

Peter 3 months ago

🎨

UI & Usability Suggestions