Share your ideas for improving the MainWP Core plugins, Dashboard and Child, and their functionality.
Help us shape the MainWP core plugins!
Reconnect All sites from Dashboard
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.
Vulnerability Checker: Bulk actions
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.
xcloud Integration
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.
Allow manually marking sites as Production or Staging
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.
Save Button at top or sticky.
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
Locally cache site thumbnails for Pro Reports
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.
Vulnerability Checker: Aggregate API calls
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?
Feature request: retry installation on failed target
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.
Ignore Updates for Time
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.
MCP Server AI Abilities
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.
Feature Request: Cloud-Native Enterprise Hooks (A2A OAuth 2.1 / Hosted SSE) for Gemini & Vertex AI Workspaces
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+!
Feature Request: Elevating Pro Reports for Enterprise clients and external audits
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!
Add more information in Network Activity about Events
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…
Needed: Favorite plugins/themes taken into account on updates pages
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.
Feature Request: Client Management Mode (Monitoring Only vs Full Management)
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.
WPML Secondary Language Support for Post Publishing
Hello MainWP Team, I’d like to suggest improving WPML compatibility in MainWP. Right now, when publishing posts through MainWP on a WPML website, posts are always published in the default language. There is no option to choose a secondary language like Arabic, Spanish, etc. Suggested feature: Please add a language selection option when creating or publishing posts through MainWP. This would allow users to: Choose the WPML target language Publish directly to a secondary language Keep compatibility with WPML translation structure Why this matters: Many users manage multilingual WordPress websites, and this feature would make publishing faster, easier, and more accurate. Thank you for considering this improvement. Best regards
Highlight list row on hover
A little QOL feature to help spotting a row in a long list such as Sites > Security > Sucuri, by discreetly highlighting the row background: add_action('admin_head', 'backend_custom_css'); function backend_custom_css() { echo ' '; }
See failed automatic Updates in Network Activity
It would be a great feature if the Network Activity showed whether an automatic update failed, for example, if the update package is unavailable (because the license has expired, etc.).
Sticky "Action / Filter / Unified" Toolbar for Large Management Tables
When managing large numbers of sites in MainWP (50, 100, or more), navigation across long management tables becomes cumbersome because primary action controls are not consistently accessible while scrolling. On some screens, action buttons appear at the top. On others, they may appear elsewhere. This inconsistency slows down workflows and forces users to repeatedly scroll long distances just to apply actions after reviewing or selecting items. A unified sticky toolbar/header across management screens would significantly improve usability, consistency, and efficiency. Suggested Sticky Toolbar Features Bulk action buttons (Update, Ignore, Trust, Save, Apply, etc.) Search and filtering controls Sorting controls Selection count (e.g. “27 items selected”) Select all visible / select all filtered options Context-aware actions depending on the current screen Consistent placement and behavior across MainWP admin areas Why This Matters Agency users managing large fleets of WordPress sites regularly work through: Long plugin/theme update lists Bulk maintenance tasks Large tables requiring review before action Multi-step workflows involving filtering, sorting, and selective updates Currently, users can lose context or waste time scrolling to locate the appropriate action controls, especially when UI placement differs between screens. A sticky and standardized action toolbar would: Reduce unnecessary scrolling Improve workflow speed Create a more predictable UI experience Reduce the likelihood of mistakes during bulk operations Make MainWP feel more polished and optimized for high-volume management This would be especially valuable for agencies and power users managing dozens or hundreds of websites daily.
Present Health-Check-Issues on MainWP
The healt-check sumary is already on the page MonitoringSites, but we miss the issues that wordpress itself detected. Such us: “Your site is very slow, install a cache plugin.” At the moment we have to visit most of our wordpress sides by hand to find out what exactly is the problem on the website.