Protected globals

One of the easiest ways for a PHP application to become difficult to follow is for request data to be read straight from superglobals throughout the codebase.

WebEngine uses protected globals to make that problem obvious during development. The separate package is documented at https://www.php.gt/docs/ProtectedGlobal/.

Protected global variables in WebEngine

During start-up, WebEngine protects request-related globals such as:

• $_GET
• $_POST
• $_FILES
• $_COOKIE
• $_SERVER

Instead of encouraging direct access to those arrays, WebEngine exposes object-oriented alternatives such as Input, Request, Session, Cookie and ServerInfo.

Encapsulation

Encapsulation means a part of the code only receives the data and behaviour it actually needs. Instead of every function being able to inspect the whole request, dependencies are passed in deliberately.

That improves testability because a class can be exercised with a small set of known inputs. It also improves readability because the function signature always shows what the code depends on.

When global state is still necessary

Not all global state disappears. Environment variables still exist. PHP runtime behaviour still exists. Some third-party libraries may still assume raw superglobals are available.

When that happens, the answer is usually to whitelist only what is needed or to reconstruct the required input in one explicit place rather than letting it leak through the application.

---

In the next section we will learn how to build API responses.