.MD files, json-ld updated with faq also twig files updated with faq

public/readme/android/listen-for-android-install-referrer.md

@@ -0,0 +1,23 @@
+---
+title: "Listen for Android install referrer"
+description: "Android market broadcasts an intent containing referrer information at install time, before the app is opened, which can be used for install tracking."
+author: "n3vrax"
+date_published: "2011-07-24"
+canonical_url: "https://new.dotkernel.com/android/listen-for-android-install-referrer/"
+category: "Android"
+language: "en"
+---
+
+# Listen for Android install referrer
+
+## Getting Referrer Data at Install Time
+
+Android market sends information at the moment of app install, delivered as a broadcasted intent by Android market at install time - even before the app is opened for the first time. This can be used to create custom links to an Android application, including bits of information about the referrer, sent directly to the app for processing at install. It can be a simple and accurate solution for mobile app install tracking, among other uses.
+
+## FAQ
+
+**Q: Does Android send information when the app is installed?**
+A: Yes. Android market broadcasts an intent containing referrer information at the moment the app is installed.
+
+**Q: When is this referrer information available to the app?**
+A: It's delivered as a broadcasted intent at install time, before the app is ever opened.

public/readme/android/multiple-broadcast-receivers-in-the-same-app-for-the-same-action.md

@@ -0,0 +1,31 @@
+---
+title: "Multiple broadcast receivers in the same app, for the same action"
+description: "Using multiple broadcast receivers to listen separately for the same intent in the same Android app can lead to unexpected results, since one receiver may consume the broadcast and leave the others with nothing."
+author: "n3vrax"
+date_published: "2011-07-22"
+canonical_url: "https://new.dotkernel.com/android/multiple-broadcast-receivers-in-the-same-app-for-the-same-action/"
+category: "Android"
+language: "en"
+---
+
+# Multiple broadcast receivers in the same app, for the same action
+
+## The problem
+
+When multiple broadcast receivers are registered separately to listen for the same intent within the same Android app, this can lead to unexpected results: one broadcast receiver might consume the broadcasted intent, leaving the others with nothing to receive. This can happen when using 3rd party libraries that define their own broadcast receivers alongside an app's own receivers.
+
+## The approach
+
+A solution for this kind of problem is a code snippet inspired by the way Admob for Android solves this, as shown in Admob's own documentation, using meta-data in the manifest file.
+
+## FAQ
+
+**Q: What problem does this article address?**
+A: When multiple broadcast receivers are registered separately to listen for the same intent in the same Android app, this can lead to unexpected results: one broadcast receiver might consume the broadcasted intent, leaving the others with nothing to receive.
+
+**Q: When is this issue most likely to occur?**
+A: This can happen when you use 3rd party libraries that already define their own broadcast receivers alongside your app's own receivers.
+
+## Resources
+
+- [Admob App Download Tracking documentation](http://developer.admob.com/wiki/Android_App_Download_Tracking)

public/readme/architecture/configprovider-bootstrap-modern-php-applications.md

@@ -0,0 +1,111 @@
+---
+title: "ConfigProvider - Bootstrap Modern PHP Applications"
+description: "An overview of the ConfigProvider pattern used in Laminas/Mezzio-based applications, including Dotkernel, to bootstrap middleware pipelines and dependency injection."
+author: "Florin Bidirean"
+date_published: "2025-08-20"
+canonical_url: "https://new.dotkernel.com/architecture/configprovider-bootstrap-modern-php-applications/"
+category: "Architecture"
+language: "en"
+---
+
+# ConfigProvider - Bootstrap Modern PHP Applications
+
+## TL;DR
+
+In PHP, a `ConfigProvider` is a class or callable that is part of an application's bootstrap process, returning configuration data that tells the platform which middleware should run, in what order, and under what conditions. Frameworks like Mezzio, Laminas, Slim, and the Dotkernel Headless Platform use ConfigProviders to declare middleware pipeline configuration, dependency injection mappings, and request handlers, which get merged together automatically during bootstrap (except in Dotkernel, where new ConfigProviders must be registered manually).
+
+## Where Is the ConfigProvider Used?
+
+Mezzio (formerly Zend Expressive), Laminas, Slim, the Dotkernel Headless Platform, and other middleware-based frameworks often have a `ConfigProvider` class. In Laminas/Mezzio specifically, each module or package may contain a `ConfigProvider` that returns:
+
+- Middleware pipeline configuration:
+  - Middleware classes or service names.
+  - Error-handling middleware, which should have the lowest priority.
+  - Middleware groups or nested arrays.
+- Dependency injection mappings.
+- Request Handlers.
+
+Example structure used in Dotkernel:
+
+```php
+class ConfigProvider
+{
+    public function __invoke(): array
+    {
+        return [ /* ... */ ];
+    }
+
+    public function getDependencies(): array
+    {
+        return [
+            'factories'  => [ /* ... */ ],
+            'invokables' => [ /* ... */ ],
+        ];
+    }
+
+    public function getTemplates(): array
+    {
+        return [
+            'paths' => [ /* ... */ ],
+            'error' => [ /* ... */ ],
+        ];
+    }
+}
+```
+
+What each item means:
+
+| Item | Meaning |
+|---|---|
+| `dependencies` | Used by the dependency injector (e.g. laminas-servicemanager) to construct every requested service. |
+| `factories` | The factory builds the service. |
+| `invokables` | The service is built with `new` directly. |
+| `aliases` | Redirects to another service name. |
+| `delegators` | Wraps the original service. |
+| `templates` | Defines the paths for the template files. |
+
+## How the ConfigProvider Works
+
+The ConfigProvider is automatically picked up by the framework during application bootstrap:
+
+1. **Merge the global configuration** - All ConfigProviders are merged into one array.
+2. **Read the configuration array** - A call similar to `$config = $container->get('config') ?? [];` reads an array of entries.
+3. **Resolve item** - `$app->pipe()` is called to resolve one of the following: resolve the service name from the container, wrap the middleware if an array is provided, or call the closure or invokable object.
+4. **Handle errors** - The error-handling middleware is the last one in the pipeline, to make sure it can handle any exceptions.
+5. **Execute at runtime** - Laminas Stratigility iterates over the pipeline in the order it was registered. Each middleware can handle the request and return a response, or delegate execution to the next middleware in the pipeline, until a `ResponseInterface` is returned to the client.
+
+## Benefits
+
+- **Centralized setup** - Instead of hardcoding bootstrap code, it's declared in a config provider so it's easy to read, change, or extend.
+- **Modular** - Each package can ship with its own config without interfering with others.
+- **Container-friendly** - Works well with frameworks using DI containers like Laminas ServiceManager, PHP-DI, or Pimple.
+- **Standardized service definitions** - Consistent rules for object creation, separate from business logic.
+- **Auto-Discovery** - In Laminas/Mezzio, the ConfigAggregator automatically loads and merges all ConfigProviders. Dotkernel is an exception: new ConfigProviders have to be added manually in `config/config.php`, because all the initial ConfigProviders required to install the applications are already injected.
+- **Environment-agnostic** - Returns an array that defines dev, test, or prod environments.
+- **Testability** - The consistent, central configuration promotes isolated (e.g. per-module) testing, easier swapping of dependencies, and assertion of pipeline setup (e.g. checking if a config key is present).
+
+## FAQ
+
+**Q: What is a ConfigProvider in PHP?**
+A: It is a class that is part of an application's bootstrap process: a class or callable that returns configuration data telling the platform which middleware should run, in what order, and sometimes under what conditions.
+
+**Q: What does the ConfigProvider return in the Laminas/Mezzio ecosystem?**
+A: In the Laminas/Mezzio ecosystem, it's literally an array of configuration, settings, or anything else the application needs, and each module or package may contain its own ConfigProvider returning middleware pipeline configuration, dependency injection mappings, and request handlers.
+
+**Q: What is the difference between 'factories' and 'invokables' in the dependencies array?**
+A: `factories` will have the factory build the service, while `invokables` will use `new` directly. You can also use `aliases` to redirect to another service name and `delegators` to wrap the original service.
+
+**Q: How does the ConfigProvider get used during application bootstrap?**
+A: It is automatically picked up by the framework during bootstrap: all ConfigProviders are merged into one array, the configuration array is read, each item is resolved via `$app->pipe()`, the error-handling middleware is placed last in the pipeline, and at runtime Laminas Stratigility iterates over the pipeline in the order it was registered.
+
+**Q: Are new ConfigProviders auto-discovered in Dotkernel?**
+A: Dotkernel is an exception to the usual auto-discovery rule: new ConfigProviders have to be added manually in `config/config.php`, because all the initial ConfigProviders required to install the applications are already injected.
+
+**Q: What are the benefits of using a ConfigProvider?**
+A: Benefits include centralized setup instead of hardcoded bootstrap code, modularity so each package can ship its own config, container-friendliness with DI containers like Laminas ServiceManager, PHP-DI or Pimple, standardized service definitions, environment-agnostic configuration for dev/test/prod, and better testability of the pipeline setup.
+
+## Resources
+
+- [Mezzio Container](https://docs.mezzio.dev/mezzio/v3/features/container/config/)
+- [Laminas Config Aggregator](https://docs.laminas.dev/laminas-config-aggregator/config-providers/)
+- [PSR-15 (HTTP Server Request Handlers)](https://www.php-fig.org/psr/psr-15/)

public/readme/architecture/request-lifecycle-for-a-mezzio-based-application.md

@@ -0,0 +1,67 @@
+---
+title: "Request Lifecycle for a Mezzio-Based Application"
+description: "A step-by-step walkthrough of how Dotkernel Light, a Mezzio-based application, handles an HTTP request from bootstrap through to the emitted response."
+author: "Florin Bidirean"
+date_published: "2026-05-26"
+canonical_url: "https://new.dotkernel.com/architecture/request-lifecycle-for-a-mezzio-based-application/"
+category: "Architecture"
+language: "en"
+---
+
+# Request Lifecycle for a Mezzio-Based Application
+
+## TL;DR
+
+The request lifecycle is the sequence of steps that happen from the moment a user makes an HTTP request until the server sends back a response. This is illustrated using Dotkernel Light, one of the applications in the Dotkernel Headless Platform suite, walking through entry point setup, routing, handler execution, template rendering, response creation, and the response emitter.
+
+## The Request Lifecycle, Step by Step
+
+### Entry Point
+
+1. **HTTP Request** - Bootstrap the application, load configuration and create the Mezzio application instance.
+2. **Service Container** - Register factories, aliases and delegators. All services are configured and ready to use.
+3. **Route Registration** - Read all available routes with their allowed request methods and dynamically register them in the application. Routes are managed by FastRoute. Example: `/page/about` -> `GetPageViewHandler`, Method: `GET`, Route name: `page::about`.
+4. **Middleware Pipeline** - Loads the predefined order of middleware. It defines how incoming HTTP requests move through the application and how responses are generated.
+
+### Processing
+
+5. **Routing** - FastRoute matches the URL and method against registered routes. Match: `GET /page/about`, Handler: `GetPageViewHandler`, Route name: `page::about`.
+6. **Handler Invocation** - Extract the matched route name from the request and pass it to the renderer:
+   ```php
+   $template = $request->getAttribute(RouteResult::class)->getMatchedRouteName();
+   // $template = 'page::about';
+   ```
+7. **Custom Logic Execution in Handler** - Execute the business logic in the handler. The process can involve services and any custom logic.
+8. **Template Rendering** - Twig loads the template, applies the layout, renders blocks and includes partials. Load: `src/Page/templates/page/about.html.twig`, Extends: `@layout/default.html.twig`, Render blocks: `title`, `content`, Include partials: `alerts.html.twig`, etc., Output: Final HTML.
+9. **Response Creation** - An `HtmlResponse` is created with status, headers and the rendered HTML body. Status: `200 OK`, Content-Type: `text/html; charset=utf-8`, Body: Rendered HTML.
+10. **Response Pipeline** - The response flows back through the middleware stack. Middleware can modify headers, cookies, compress content, etc.
+
+### Exit Point
+
+11. **Response Emitter** - The final response is sent back to the browser. The page is rendered and sent to the user, as one of `HTTP 20x/30x`, `HTTP 40x`, or `HTTP 50x`.
+
+## FAQ
+
+**Q: What is the request lifecycle?**
+A: The request lifecycle is the sequence of steps that happen from the moment a user makes an HTTP request until the server sends back a response.
+
+**Q: What happens at the entry point of a request?**
+A: The application bootstraps and loads configuration to create the Mezzio application instance, registers factories, aliases and delegators in the service container, reads all available routes with their allowed request methods and registers them (managed by FastRoute), and loads the predefined order of middleware in the pipeline.
+
+**Q: How does routing work in a Mezzio-based application?**
+A: FastRoute matches the incoming URL and method against the registered routes, for example matching a GET request to `/page/about` against the `GetPageViewHandler` handler under the route name `page::about`.
+
+**Q: What happens during handler invocation?**
+A: The matched route name is extracted from the request attribute and passed to the renderer, using code similar to `$template = $request->getAttribute(RouteResult::class)->getMatchedRouteName();`, after which the handler executes the custom business logic.
+
+**Q: What happens during template rendering?**
+A: Twig loads the matched template file, applies the layout it extends, renders its blocks, and includes any partials, producing the final HTML output.
+
+**Q: How is the response created and returned to the browser?**
+A: An `HtmlResponse` is created with a status code, headers, and the rendered HTML body. It then flows back through the middleware stack in reverse (the response pipeline), where middleware can modify headers, cookies, or compress content, before the response emitter sends the final response back to the browser as HTTP 20x/30x, 40x, or 50x.
+
+## Resources
+
+- [Dotkernel Light on GitHub](https://github.com/dotkernel/light)
+- [Dotkernel Light documentation](https://docs.dotkernel.org/light-documentation/)
+- [Dotkernel Headless Platform suite on GitHub](https://github.com/dotkernel)