[wp-trac] [WordPress Trac] #65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage

WordPress Trac noreply at wordpress.org
Mon Apr 20 06:37:59 UTC 2026


#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-----------------------------+------------------------------------
 Reporter:  dramitstalbot    |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:  rest-api, performance
-----------------------------+------------------------------------
Changes (by sabernhardt):

 * keywords:  feature-request needs-design-feedback =>


Old description:

> 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.

New description:

 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.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list