Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage

[dramitstalbot]

WordPress has evolved beyond a blogging platform and is widely used as an application framework for building systems such as CRMs, ERPs, and healthcare software.

There is currently no supported, centralized way to disable blog/content-related functionality at the core level when it is not needed.

Problem

Even when WordPress is used purely as an application framework:

• Core blog features (posts, categories, tags, comments, feeds) are always loaded
• Associated hooks, filters, and REST endpoints remain active
• Rewrite rules and query handling for posts are still registered
• Admin UI includes unused components

This increases:

• Attack surface (especially via plugins targeting post workflows)
• Resource usage
• Complexity in securing deployments

Real-World Use Case

I am a medical doctor and developer building a Hospital Management Information System (HMIS) on WordPress.

This system includes:

• Patient records and clinical documentation
• Prescription workflows
• Medical file storage
• Billing and administration

In this context:

• WordPress is used strictly as an application framework
• Blog functionality is completely unused
• Reducing unnecessary components is critical for security, especially in healthcare environments

Proposal

Introduce a core constant:

define('DISABLE_BLOG', true);

When enabled, WordPress operates in an Application Mode.

Expected Behavior

When DISABLE_BLOG is enabled:

• Do not register:
  • post post type
  • category and post_tag taxonomies
  • comment system
• Disable:
  • Post-related REST API endpoints (e.g., /wp/v2/posts)
  • Feeds and post permalinks
  • Author archives
• Skip loading:
  • Blog-related hooks and filters
• Admin UI:
  • Remove Posts and Comments menus
  • Remove related dashboard widgets

Benefits

• Reduced attack surface
• Improved performance
• Cleaner application-focused architecture
• Better suitability for secure and regulated environments
• Encourages WordPress adoption for non-CMS use cases

Why This Matters

One of WordPress’s biggest strengths is its low learning curve and ease of use. Because of this, many developers consider WordPress first before exploring other frameworks.

Providing a native way to disable blog functionality would:

• Strengthen WordPress as a general-purpose framework
• Retain developers who might otherwise move to other stacks
• Expand adoption in enterprise and healthcare systems

Technical Considerations (Initial Thoughts)

• Conditional loading in wp-settings.php and default-filters.php
• Introduce helper:

  function wp_is_application_mode() {
    return defined('DISABLE_BLOG') && DISABLE_BLOG;
  }
  

• Wrap blog-specific registrations and hooks
• Provide filters for extensibility (e.g., REST whitelist)

Backward Compatibility

• Default behavior unchanged
• Feature is opt-in via constant
• Plugins/themes can detect and adapt

Future Scope

• Granular flags:
  • WP_DISABLE_COMMENTS
  • WP_DISABLE_FEEDS
  • WP_DISABLE_REST_POSTS
• Preset modes:
  • CMS Mode (default)
  • Application Mode

Summary

This proposal introduces a lightweight Application Mode that allows WordPress to function as a secure, minimal framework when CMS features are not required.

[dramitstalbot]

My HMIS project page

[dramitstalbot]

Consultation page (Wordpress)

[dramitstalbot]

Dashboard

[joshuadnelson]

Hey @dramitstalbot , thanks for advocating for this!

I’m invested in this idea and willing to work on implementing something in core, too. Until there’s a core path I’ll recommend the Disable Blog (​https://wordpress.org/plugins/disable-blog/) plugin, which provides a lot of this functionality.

[knutsp]

Nice. Also add basic Progressive Web Application (PWA) functionality, and WordPress will be a great framwork for making well designed web applications, outside wp-admin, not just a publishing system (CMS).

[dramitstalbot]

Thank you @joshuadnelson — really appreciate the response and willingness to explore this in core.

I reviewed the Disable Blog plugin, and it aligns closely with the direction I had in mind. However, from a framework perspective, I believe having a native core-level flag would be more reliable and secure, especially for applications in regulated domains like healthcare.

In my HMIS use case, WordPress is used strictly as an application framework, where:

• No post types are required
• REST endpoints for posts are unnecessary
• Minimizing attack surface is critical

I’d be happy to help with:

• Testing edge cases
• Identifying which components can be conditionally skipped
• Providing real-world constraints from healthcare deployments

@knutsp — I completely agree regarding Progressive Web App (PWA) functionality. In fact, combining an “Application Mode” with basic PWA support (manifest + service worker hooks) could make WordPress a very strong foundation for modern web applications beyond CMS use.

Perhaps a phased approach could work:

1. Application Mode (disable blog features)
2. Optional PWA bootstrap support in core

Happy to collaborate further and help move this forward.

[peterwilsoncc]

While WordPress can be used for many purposes, the core functionality is to use it as a content management system. A very small percentage of sites may use it for other purposes but nowhere near enough to introduce a feature to turn off the CMS in WordPress Core. I strongly doubt even 1% of sites are using it in this manner.

It's already possible to use the register_post_type_args filter to modify the registration of post types to prevent their use and display in the admin. The WP_USE_THEMES constant exists to prevent the use of traditional themes.

As this is not a common use case for WordPress, I'm closing this ticket as unplanned (wontfix).

[dramitstalbot]

Thank you @peterwilsoncc for the clarification and for taking the time to review this.

I understand the decision and the perspective that WordPress core should remain focused on its primary role as a CMS.

That said, I would like to briefly reiterate the motivation behind this proposal—not as a disagreement, but as additional context from real-world usage.

In environments like healthcare systems (such as the HMIS I’m building), WordPress is being used strictly as an application framework. In such cases, disabling unused CMS-related components is not just about preference, but about reducing attack surface, simplifying architecture, and meeting stricter security expectations.

I also understand that this may currently represent a small percentage of WordPress usage. At the same time, it’s possible that this usage remains limited in part because there isn’t yet a standardized or supported way to operate WordPress in a more application-focused mode.

This area may represent an opportunity for future exploration, especially as WordPress continues to be adopted for internal tools, enterprise systems, and regulated environments.

For now, I will continue implementing this as a custom application layer on top of WordPress, as suggested. If in the future there is any interest in exploring a more formalized or extensible approach within core (even in a limited or opt-in capacity), I would be happy to contribute, test, or provide feedback based on production use.

Thank you again for the discussion and for maintaining clarity around core direction.

[knutsp]

Replying to peterwilsoncc:

While WordPress can be used for many purposes, the core functionality is to use it as a content management system. A very small percentage of sites may use it for other purposes but nowhere near enough to introduce a feature to turn off the CMS in WordPress Core. I strongly doubt even 1% of sites are using it in this manner.

10% of the sites I manage do not use 'post' post type, but have pages, attachments, products, events and other CPTs. Post posts are regarded "news". Some use the "Disable Blog" plugin, som just ignore the menu item "Posts". It's still a CMS, still very WordPress.

Combined with basic PWA functionality I believe it would be great for WordPress, as a CMS and also a more general framework for web appliactions. This could attract new users ans sites, not just existing and guessing the need.

Disabling "blog" (posts) is not removing being basically a content mangement system (CMS) as you seem to imply. It easily opens new use, with a simple off constant, and also benefits performance for thos who do not need this.

Turning off (post) comments is even more widespread, 90% of my sites turns it off, so why not give users an opportunity to disable it completely, more effective than options and filters?