Features request

Currently, visual regression testing focuses only on the homepage, which may not reflect issues occurring on other critical pages. It would be valuable to allow users to select specific pages or URLs to include in visual regression tests. This could include landing pages, checkout pages, contact forms, or other key templates where visual integrity is important.

Automated updates can be one of the biggest time-savers in WP Umbrella — but without control over which versions are installed, automation can quickly become a problem instead of a benefit. For agencies, developers and administrators managing production sites, blindly installing every new version (including minor and major releases) introduces unnecessary risk and reduces trust in automated updates. This feature request proposes version-aware automated updates, allowing users to automate safely without giving up control. --- The problem Today, automated updates apply to all new versions of a plugin (core or theme if added) — regardless of whether the release is a patch, minor, or major update. This is especially problematic for complex and business-critical plugins such as WooCommerce, where: Minor and major releases frequently introduce breaking or behavioural changes These updates often require testing, staging, or client approval Patch and security releases, on the other hand, should usually be installed automatically As a result, many users either: Disable automated updates entirely, or Manually babysit updates — defeating the purpose of automation This makes automated updates less usable for agencies and professionals managing real production environments. --- Proposed solution Add version-level filtering to automated updates, based on semantic versioning (SemVer). Global update rules Allow users to define a default rule for all plugins/themes: Patch releases only (e.g. 1.2.3 → 1.2.4) Patch + minor releases (e.g. 1.2.3 → 1.3.0) All releases (including major) Per-plugin overrides Allow individual plugins/themes to override the global rule, for example: WooCommerce → patch only Yoast SEO → patch + minor Small utility plugin → all releases Simple SemVer-based logic Detect version type based on version string structure Optionally allow a short delay (e.g. only auto-install patch releases after X days) This does not need to be perfect SemVer enforcement — even basic version segmentation would cover the vast majority of real-world cases. --- Why this matters (broader impact) ✅ Safer automated updates for production sites ✅ Higher adoption of automation among agencies and developers ✅ Fewer incidents caused by unintended upgrades ✅ Aligns WP Umbrella with professional update workflows already used in staging-first environments Many plugins already follow semantic versioning in practice. Even when they do not do so perfectly, having version-aware automation is still vastly safer than treating all updates as equal. --- Summary This feature does not remove automation — it makes automation trustworthy. Giving users control over which types of updates are installed automatically allows WP Umbrella to remain fast and efficient, while also being safe enough for serious production use. If this is important for your workflow as well, please upvote and share your thoughts. �

Context For some projects, we need to keep WordPress core on a specific minor branch (e.g., 6.4.x or 6.5.x) for compatibility and controlled rollout reasons. Problem Today, the update behavior forces WordPress core to the latest available version (latest major/minor), rather than allowing us to stay within a selected minor branch and only apply patch releases. Request Add an option to choose the WordPress core update policy per site (or per group), such as: • Latest version (current behavior) • Latest patch of a selected minor branch (e.g., stay on 6.4.x and automatically update to 6.4.4, 6.4.5, etc.) Expected behavior • If a site is pinned to 6.4.x, the system auto-updates only within 6.4.*. • It should not upgrade to 6.5.0+ unless the policy is changed. • UI should clearly display the chosen policy and the target branch. Benefit This enables safer, more controlled core updates for enterprise contexts: • better compatibility management (plugins/themes), • staged rollout across fleets, • reduced risk of unexpected major/minor upgrades.

We already have the "Automated" category there, but I really need the opposite. The automated updates already are... automated. There is nothing more to do about them, since they will update themselves some time in the future. What I DO need to care about are the NOT automated plugins. Whether to set them to be automated or to actually take care of the update manually.

Bulk Security Management We’re working on a new Bulk Security Management section in WP Umbrella to make it easier to keep all your sites safe, updated, and compliant from one place. With this new dashboard, you will be able to: ✅ View the security status of all your sites at a glance ✅ Monitor PHP versions and upcoming SSL expirations ✅ Track vulnerabilities in plugins and themes ✅ Manage Site-Protect deployment across multiple sites ✅ Quickly identify sites needing attention (outdated PHP, expired SSL, vulnerabilities, etc.) ✅ Use smart filters to focus on the issues that matter most to you and your clients Key Benefits Catch issues before clients do Instantly see which sites have vulnerabilities, outdated PHP, or expired SSL, and fix them before they become urgent. Focus on what matters Smart filters help you drill down to the most critical issues without getting lost in noise. One dashboard for all sites Replace dozens of manual checks with a single, centralized security view of your entire portfolio. Stronger client trust Clear insights make it easy to explain risks and fixes, showing clients you have everything under control. Scale without extra effort Whether you manage 5 sites or 200, you’ll handle security in bulk. How You Can Help Vote: Show your interest by voting for this feature. Feedback: Tell us what filters or views would be most useful in your workflow. Share your workflow: How do you currently handle security at scale? Your input will help us shape this feature.

Hello WP Umbrella Team, I’d like to suggest a new feature for the Alerting section that would allow us to receive PageSpeed Insights alerts when performance metrics exceed Google’s recommended standards for mobile. Specifically, the following thresholds would trigger alerts: Largest Contentful Paint (LCP) – send alert when LCP is above 2.5 sec (mobile). https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint/?utm_source=lighthouse&utm_medium=lr First Contentful Paint (FCP) – send alert when FCP is above 1.8 sec (mobile). https://developer.chrome.com/docs/lighthouse/performance/first-contentful-paint https://developer.chrome.com/docs/lighthouse/performance/first-contentful-paint Speed Index – send alert when Speed Index is above 3.4 sec (mobile). https://developer.chrome.com/docs/lighthouse/performance/speed-index Total Blocking Time (TBT) – send alert when TBT is above 200 ms (mobile). https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time This would help site us take immediate action when performance dips below best practices and ensure ongoing compliance with Core Web Vitals standards. Thank you! Joevil

My understanding is that there is currently no alert or differentiation of PHP errors on the dashboard when a PHP error is fatal. It seems that both should be the case: If there are fatal PHP errors, the section on the dashboard should be red. An alert, similar to the site down alerts should be available.

Add the ability to exclude WooCommerce tables from a restore so that recent order data doesn't get lost if a site needs to be restored to an older version.

On the Overview page of the report PDF, the Updates section says “Number of plugins updated: X.” This seems misleading because the count reflects total plugin updates, not unique plugins. For example, updating the same plugin twice increases the count. Could this section be updated to either display the count of unique plugins or be reworded to “Number of plugin updates: X”?

Most modern systems provide users with the ability to configure both timezone and date/time display according to their personal preferences and regional conventions. When such settings are consistently implemented and applied across all pages, views, and configuration areas, they significantly reduce confusion and errors caused by inconsistent or inappropriate timezone and time format handling. For a considerable portion of your user base, the exclusive use of CET combined with AM/PM formatting is problematic and does not align well with local conventions. As a French company with an international audience, localisation is an area where users reasonably expect a higher level of adaptation and attention to regional norms. Based on our communication with support, it appears that the current plan is to standardise on CET with AM/PM formatting as a simplified solution. While understandable from an implementation perspective, this approach risks creating avoidable usability issues for many users. Several of your competitors have addressed this more comprehensively by offering flexible and user-controlled settings for timezone and time display. The attached screenshot illustrates an example of how this can be handled in a clear and user-friendly way.