Features request

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.

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.

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”?

Just a quick note: I deleted an inactive plugin from two sites. The UI here is not very clear, since about 30 seconds after deletion the display switches back to the default "update available" view, and clicking on "update all" after having deleted the plugin gets an " We detected an error" warning (see screenshots). (Additional small rant: taking screenshots for Advanced Safe Update before updating inactive plugins might be unnecessary, no?) I'm aware this might get fixed in an upcoming Umbrella UI, just wanted to document this.

Too many recent cases where the back-up is not executed as planned and not beoing notified about this bug, specifically for hourly back-up. Is it possible to setup a monitoring about back-up execution, so we receive an alert when the back-up execution deviates from the frequency planning. Thanks !

At the moment, the update button / bar is at the top which makes it easy to access (no scrolling). However, the update button for themes is at the bottom and I'm forced to scroll down / look for it. It would be better if all update buttons were located in the same location, at the top.

Hello WP Umbrella team, First, thank you for the reporting tools you’ve built into WP Umbrella. They’ve become a core part of how I communicate ongoing maintenance value to my clients. I’d like to suggest adding an optional “Recommendations” section to maintenance reports. This would be a standalone reporting component focused on forward-looking guidance, rather than completed work. I’m referencing the existing Custom Work section only as an example of how WP Umbrella already supports manual, client-specific report content — not to suggest a direct functional or architectural link. --- ## Purpose During routine maintenance, it’s common to identify: upcoming risks optimization opportunities deferred improvements plan-dependent or out-of-scope items A Recommendations section would allow these insights to be communicated clearly within the report itself, without mixing them into completed work or requiring separate documentation. --- ## Suggested Recommendation Fields (Intentionally Lightweight) Each recommendation could include: Title – short summary of the recommendation Description – recommendation details Urgency level (e.g. Low / Moderate / High) Recommended implementation date (optional) Included in maintenance plan (yes/no) Estimated cost (optional, only if not included) --- ## Report Presentation A dedicated Recommendations page within the report Clear heading and short intro explaining that items are advisory and not yet executed No implied workflow, approval, or automation — strictly informational --- ## Scope Considerations I’m intentionally not suggesting: approval workflows task or invoice generation dependencies on Custom Work status automation The goal would be to keep this feature simple, focused, and aligned with WP Umbrella’s existing reporting philosophy. Thanks for considering this request, and for continuing to evolve a tool that makes maintenance reporting both clear and professional.

It would be extremely helpful to be able to pin a note to the top of the management page for each website. While admin notes exist today, they’re easy to miss because you have to actively open the notes section to see them. The use case is for important, site-specific context that needs to be visible immediately. For example, I manage a site with custom post types that occasionally require permalink regeneration after theme updates. Having a pinned note would act as a visible reminder whenever I open that site, helping prevent missed steps during maintenance. It would also be valuable to tag notes to specific update types (such as Theme Updates or Plugin Updates). If a note were tagged to “Theme Updates,” it could surface a small indicator or message on the theme updates screen and in the bulk update manager, such as “See note,” to flag that additional steps or cautions apply for that update. This would significantly improve operational awareness for edge cases and reduce the chance of issues during routine updates.