DWS WP Framework
  • Welcome
  • Primary goals
    • Modular design
    • No 3rd-party dependencies
  • Key concepts and dev tools
    • PHP and WP requirements
    • Object-Oriented Programming
    • Semantic Versioning
    • Version Control (git / GitHub)
    • Dependency Management (Composer)
    • Automated Testing (Codeception + Github Actions)
    • Dependency Injection (PHP-DI)
    • Coding Standards (PHPCS and PHPMD)
    • Dependencies Scoping (PHP-Scoper)
    • TypeScript and Sass
    • Task Runners (Grunt)
  • Setting up your dev environment
    • Windows
  • Your first plugin
    • Multiple plugins using the framework on the same site
  • Frequently Asked Questions
  • Bootstrapper Module
    • Motivation
    • How it works
    • How to use
    • White Labeling
  • Helpers Module
    • Motivation
    • How to use
  • Foundations Module
    • Motivation and How to use
    • Actions
      • Local action traits
      • Extension action traits
      • Integration action traits
    • States
    • Utilities
      • Stores
      • Handlers and Services
        • Logging Service
  • Plugin
    • Main Plugin Instance
    • Plugin Components
  • Hierarchies
  • Helpers
  • Utilities Module
    • Motivation and How to use
    • Hooks Service
      • Scoped Handler
    • Shortcodes Service
    • Templating Service
    • Assets Service
      • Scripts Handler
      • Styles Handler
    • CRON Events Service
      • Action Scheduler Handler
    • Admin Notices Service
    • Dependencies Service
    • Validation Service
  • Core Module
    • Motivation and How to use
    • Plugin Tree
      • Plugin Root
      • Plugin Functionality
    • Plugin Components
      • Internationalization
      • Installation / Upgrade / Uninstallation
  • Settings Module
    • Motivation and How to use
    • Settings Service
      • WordPress Handler
      • MetaBox Handler
      • ACF Handler
    • Validated Settings
  • WooCommerce Module
    • Motivation and How to use
    • Extended WC Logger
    • WC Settings Handler
Powered by GitBook
On this page

Was this helpful?

  1. Bootstrapper Module

Motivation

PreviousFrequently Asked QuestionsNextHow it works

Last updated 4 years ago

Was this helpful?

When building a website, you (usually) know exactly what server it will run on. Or, at the very least, you will set up the server(s) afterwards to the exact requirements of your code.

For example, if you write an API using PHP8, you will assume that the server running the code will have ... well, PHP8, and probably a good caching infrastructure. In the world of CMS plugins, you can assume exactly none of that.

The only assumptions you can make are the requirements of the CMS itself. In the case of WordPress we can safely assume that we'll have the following things:

  • WordPress

  • PHP

  • A database

The list of assumptions is not PHP7. It's not even PHP5! It's simply PHP. Maybe the plugin is running on WP5+, maybe it's running on WP2.7 or lower. Maybe it's MySQL, maybe MariaDB, maybe something else.

That doesn't mean that our plugin needs to support every version under the sun, but it does mean that it must be prepared to handle less-than-ideal environments gracefully.

In 99% of the cases, we don't actually care about the underlying database system. However, we care about the WordPress and PHP versions in 100% of the cases!

Of course, WordPress has supported forever the Requires at least plugin header line that only lets you to install or update a plugin from the public repository if your WP version is higher than the minimum specified. , there also exists a Requires PHP line that does the same thing for the PHP version.

All of this doesn't apply to premium plugins however. Also, it doesn't stop people from manually uploading a plugin's files either through FTP/SFTP or via the admin GUI. One can also argue that with the release of the feature in WP5.2, such checks don't matter because the plugin will simply fail to activate so the website will keep working.

While these are valid points, they don't fulfill all the requirements:

  • Degrade gracefully, i.e. do not throw any errors and let the user know about the problem

  • What if someone actually tries to install your plugin on WP5.1?

Getting this right is not complicated, but it definitely counts as a boring, repetitive task when starting a new plugin project. The purpose of this module, therefore, is to run on as many PHP+WP combinations as possible and graciously stop the whole plugin from running if the minimum requirements are not fulfilled.

In an ideal world, the Bootstrapper module would run on all PHP versions back to the early releases of 1995. In the real world, however, we need to draw a line somewhere. In our case, that line was PHP5.3, the first one to support namespaces. According to the , that forsakes about 0.6% of users as of April 2021.

Since August 2017
PHP fatal error protection
official WP stats