Shape the Future of MainWP – Your Voice Matters!

Share your ideas, vote and comment on others, and collaborate to make MainWP even better for everyone! Not sure how to get started?

For Developers: Want to fast-track your feature? Submit a well-crafted pull request in GitHub. Quality submissions that align with MainWP's core purpose will be included in upcoming releases.

ℹ️ Having trouble logging in? Try clearing your browser cache and cookies or use a different browser.

Feature Request: Branch Lock for WordPress Core Updates

Hi MainWP Team and Community, with WordPress 7.0 approaching, many agency owners face a situation that MainWP currently cannot handle natively: staying on a minor branch deliberately while a new major version is available. The current limitation MainWP lets you ignore a core update or update to the latest version. There is no option to say: "Stay on the 6.9.x branch. Apply minor updates within that branch. Do not touch 7.0." The only workaround would be wp-config.php edits per site — which defeats the entire purpose of centralized management. The Feature Request: Branch Lock A simple, MWP-native control on the Updates or Site Settings level: A toggle: Enable Branch Lock — yes / no A branch input field: e.g. 6.9 Behavior: MWP recognizes any 6.9.x update as valid and applicable. Any version outside that branch (7.0, 7.1 etc.) is treated as "up to date — no action required." This is different from "Ignore Core Update" because it does not lock a specific version — it locks a branch, so minor and security updates within that branch still flow through normally. Why this matters WordPress 7.0 is announced as a significant architectural release. Many agencies managing dozens or hundreds of client sites need time to test compatibility before committing to a major version jump — but they still want to keep client sites patched within the current branch in the meantime. A Branch Lock feature would make MainWP the go-to solution for exactly this kind of professional, risk-aware update management. There was a standalone WordPress plugin once that allowed locking to a specific version number. It’s long outdated and had a critical flaw: it required manually entering the exact version per site, not a branch. The Branch Lock concept improves on this significantly by being branch-aware, centrally managed, and integrated into the MainWP workflow. Thanks for considering this.

Benjamin about 1 hour ago

⚒️

Core Requests (Dashboard/Child)

Track plugin/theme/WP activity regardless of the CRON setting

It is understandable to turn CRON monitoring off since there is a lot of unneeded things happening via CRON. But I think a few things are still important enough to track regardless if they happen through CRON or not. Major things like WP updates, plugin updates (or delete, add, etc), and theme updates (new, deleted, activate). Even user activity as well (deleted user, change user role). One context for this is when using Solid Security. If a plugin has a critical security vulnerability, SS will update it automatically even if it’s not normally set to auto-update. However, this plugin update is not in the MainWP Child Reports log and thus not in the Advanced Reports either. I don’t want to turn on logging all CRON activity just to catch a stray plugin/theme/WP activity. I think those things are important enough to track no matter how they are done.

Zack 20 days ago

⚒️

Core Requests (Dashboard/Child)

WPML Secondary Language Support for Post Publishing

Hello MainWP Team, I would like to suggest a feature improvement regarding WPML compatibility. Currently, when publishing posts through MainWP on a website that uses WPML, the posts are always published in the default language. This creates a limitation for users managing multilingual websites, as there is no option to directly publish content in a secondary language. The issue: When I try to publish a post intended for a secondary language (e.g., Arabic, Spanish, etc.), MainWP publishes it under the default language instead of the selected WPML language. Suggested improvement: Please add support for WPML language selection when creating or publishing posts via MainWP. Ideally, this would include: A dropdown or option to choose the target language (as defined in WPML) Proper assignment of the post to the selected secondary language Compatibility with WPML translation structure Why this is important: Many users manage multilingual WordPress sites, and being able to publish directly to a specific language would significantly improve workflow efficiency and automation accuracy. Thank you for considering this feature. It would be a valuable addition for WPML users. Best regards

a about 1 month ago

⚒️

Core Requests (Dashboard/Child)

Force / Enforce / Report 2FA

Chatted with Dennis on Discord. I have a few clients looking for better security managment for their WordPress websites. Not only with the enforcement of User Password changes ( https://discord.com/channels/1153750602086621194/1153750602086621197/1470527736740057223) but also to have some sort of Enforcement to ensure eveyone is actively using 2FA and have a way to pull a report of some sort on users to show who has changed their password recently, and if they’re using 2FA (for compliance, security training and liability training). We currently have the USER MANAGEMENT tab for a site’s users, and it shows users, but for us, only if WordFence is active can we enforce 2FA, but even with the Wordfence add on, there is no where to manage that. In today’s protocols, this is becoming more standard, and a necessity for all web applications for most businesses. It would be great if we either integrate with a software to enforce the 2FA our if it can be added in some way, as well as the site Manager to be able to run a report on the Users to show a client who is compliant with protocols and whose account access needs to be reviewed.

Julia 2 months ago

⚒️

Core Requests (Dashboard/Child)

Force User User Password Changes

Chatted with Dennis on Discord, about having something added for User Management in V6 Updates. We have the need to be able to force a user to change their password after 60 or 90 days, for managing internal security protocols. The ideal situation would be to insert a column on the MANAGE USERS tab, that shows the last date of Password Access, and maybe last date of login. The idea from the “Site Manager” perspective would be to periodically notify Administrators of inactive users, and to take a more active role in user management on their end either by us forcing them to change passwords at a certain interval or the Administrator to be notified in some way of active users, and to use that as a catalist to keep active user access managed, and more quickly identify those whose access needs to be revoked or updated.

Julia 2 months ago

⚒️

Core Requests (Dashboard/Child)