PDO stands for PHP Data Objects and it's a database abstraction layer in PHP. It provides an object-oriented interface to access different types of databases—such as MySQL, PostgreSQL, or SQLite—without needing to change much of your code.

Key Features of PDO:

✅ Consistent API
Same code style regardless of which database you use.

✅ Prepared Statements
Helps prevent SQL injection via bound parameters:

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);

✅ Transactions Support
Great for use cases like banking systems or other operations that need rollback/commit.

✅ Exception-based Error Handling

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

✅ Easy Database Switching
Switching from MySQL to PostgreSQL? Usually only the DSN and driver need to be changed.

Example: Connecting to MySQL with PDO

$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$user = 'root';
$pass = '';

try {
    $pdo = new PDO($dsn, $user, $pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Connected successfully!";
} catch (PDOException $e) {
    echo "Connection failed: " . $e->getMessage();
}

Summary:

PDO is the recommended way to work with databases in modern PHP applications—especially for its security, flexibility, and ease of use.

Doctrine DBAL (Database Abstraction Layer) is a PHP library that provides an abstraction layer for database access. It is part of the Doctrine project (a popular ORM for PHP), but it can be used independently of the ORM.

Purpose and Benefits of Doctrine DBAL:

Doctrine DBAL offers a unified API to interact with different databases (such as MySQL, PostgreSQL, SQLite, etc.) without writing raw SQL specific to each database system.

Key Features of Doctrine DBAL:

• Connection Management

• • Easily configure and manage connections to various database systems.

  • Supports connection pooling, transactions, and more.

• SQL Query Builder

• • Build SQL queries programmatically using an object-oriented API:

$qb = $conn->createQueryBuilder();
$qb->select('u.id', 'u.name')
   ->from('users', 'u')
   ->where('u.age > :age')
   ->setParameter('age', 18);
$stmt = $qb->executeQuery();

• Database Independence

  • The same code works with different database systems (e.g., MySQL, PostgreSQL) with minimal changes.

• Schema Management

  • Tools to create, update, and compare database schemas.

  • Useful for migrations and automation.

• Data Type Conversion

  • Automatically converts data between PHP types and database-native types.

use Doctrine\DBAL\DriverManager;

$conn = DriverManager::getConnection([
    'dbname' => 'test',
    'user' => 'root',
    'password' => '',
    'host' => 'localhost',
    'driver' => 'pdo_mysql',
]);

$result = $conn->fetchAllAssociative('SELECT * FROM users');

When to Use DBAL Instead of ORM:

You might choose DBAL without ORM if:

• You want full control over your SQL.

• Your project doesn't need complex object-relational mapping.

• You're working with a legacy database or custom queries.

Summary:

Doctrine DBAL is a powerful tool for clean, portable, and secure database access in PHP. It sits between raw PDO usage and a full-featured ORM like Doctrine ORM, making it ideal for developers who want abstraction and flexibility without the overhead of ORM logic.

The Whoops PHP library is a powerful and user-friendly error handling tool for PHP applications. It provides clear and well-structured error pages, making it easier to debug and fix issues.

Key Features of Whoops

✅ Beautiful, interactive error pages
✅ Detailed stack traces with code previews
✅ Easy integration into existing PHP projects
✅ Support for various frameworks (Laravel, Symfony, Slim, etc.)
✅ Customizable with custom handlers and loggers

Installation

You can install Whoops using Composer:

composer require filp/whoops

Basic Usage

Here's a simple example of how to enable Whoops in your PHP project:

require 'vendor/autoload.php';

use Whoops\Run;
use Whoops\Handler\PrettyPageHandler;

$whoops = new Run();
$whoops->pushHandler(new PrettyPageHandler());
$whoops->register();

// Trigger an error (e.g., calling an undefined variable)
echo $undefinedVariable;

If an error occurs, Whoops will display a clear and visually appealing debug page.

Customization & Extensions

You can extend Whoops by adding custom error handling, for example:

use Whoops\Handler\CallbackHandler;

$whoops->pushHandler(new CallbackHandler(function ($exception, $inspector, $run) {
    error_log($exception->getMessage());
}));

This version logs errors to a file instead of displaying them.

Use Cases

Whoops is mainly used in development environments to quickly detect and fix errors. However, in production environments, it should be disabled or replaced with a custom error page.

What is Twig?

Twig is a powerful and flexible templating engine for PHP, commonly used in Symfony but also in other PHP projects. It helps separate logic from presentation and offers many useful features for frontend development.

Key Features of Twig

1. Simple Syntax with Placeholders ({{ }})

Twig uses double curly braces to output variables:

<p>Hello, {{ name }}!</p>

→ If name = "Max", the output will be:
"Hello, Max!"

2. Control Structures ({% %})

Twig supports if-else statements, loops, and other control structures.

If-Else

{% if user.isAdmin %}
    <p>Welcome, Admin!</p>
{% else %}
    <p>Welcome, User!</p>
{% endif %}

Loops (for)

<ul>
{% for user in users %}
    <li>{{ user.name }}</li>
{% endfor %}
</ul>

3. Template Inheritance

Twig supports "Base Layouts", similar to Laravel's Blade.

Parent Template (base.html.twig)

<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}My Page{% endblock %}</title>
</head>
<body>
    <header>{% block header %}Default Header{% endblock %}</header>
    <main>{% block content %}{% endblock %}</main>
</body>
</html>

Child Template (page.html.twig)

{% extends 'base.html.twig' %}

{% block title %}Homepage{% endblock %}

{% block content %}
    <p>Welcome to my website!</p>
{% endblock %}

→ The blocks override the default content from the base template.

4. Including Templates

You can include reusable components like a navbar or footer:

{% include 'partials/navbar.html.twig' %}

5. Filters & Functions

Twig provides many filters to format content:

6. Security & Escaping

Twig automatically escapes HTML to prevent XSS attacks:

{{ "<script>alert('XSS');</script>" }}

→ Outputs: <script>alert('XSS');</script>

To output raw HTML, use |raw:

{{ "<strong>Bold</strong>"|raw }}

7. Extensibility

• Twig supports custom filters & functions.
• You can use PHP objects and arrays directly inside Twig.

PSR-12 is a coding style guideline defined by the PHP-FIG (PHP Framework Interoperability Group). It builds on PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide), extending them to include modern practices and requirements.

Purpose of PSR-12

PSR-12 aims to establish a consistent and readable code style for PHP projects, facilitating collaboration between developers and maintaining a uniform codebase.

Key Guidelines of PSR-12

1. Indentation

• Use 4 spaces for indentation (no tabs).

2. Line Length

• Maximum line length should not exceed 120 characters.
• Code may be broken into multiple lines for better readability.

3. Namespace and Use Statements

• Add one blank line after the namespace declaration.
• use statements should follow the namespace declaration.
• Imported classes, functions, and constants should be alphabetically sorted without blank lines between them.

namespace App\Controller;

use App\Service\MyService;
use Psr\Log\LoggerInterface;

4. Classes

• The opening { for a class or method must be placed on the next line.
• Visibility (public, protected, private) is mandatory for all methods and properties.

class MyClass
{
    private string $property;

    public function myMethod(): void
    {
        // code
    }
}

5. Methods and Functions

• Each parameter must be placed on a new line if the parameter list is wrapped.
• Return types should be explicitly declared.

public function myFunction(
    int $param1,
    string $param2
): string {
    return 'example';
}

6. Control Structures (if, while, for, etc.)

• The opening { must be on the same line as the control structure.
• A space is required between the control structure and the condition.

if ($condition) {
    // code
} elseif ($otherCondition) {
    // code
} else {
    // code
}

7. Arrays

• Use the short syntax ([]) for arrays.
• In multiline arrays, each element should appear on a new line.

$array = [
    'first' => 'value1',
    'second' => 'value2',
];

8. Type Declarations

• Parameter, return, and property types are mandatory (where possible).
• Nullable types are prefixed with ?.

public function getValue(?int $id): ?string
{
    return $id !== null ? (string) $id : null;
}

9. Files

• PHP files must start with the <?php tag and must not include a closing ?> tag.
• Add blank lines between declarations like classes or functions.

Differences from PSR-2

PSR-12 extends PSR-2 by:

• Supporting modern PHP features (e.g., nullable types, declare(strict_types=1), traits, type hinting).
• Clarifying rules for line lengths, wrapped method parameters, and arrays.
• Requiring explicit type declarations.

Benefits of PSR-12

• Simplifies code reviews.
• Improves readability and maintainability.
• Enhances interoperability between PHP projects.
• Ensures consistency with modern PHP practices.

Summary

PSR-12 is the standard for modern and consistent PHP code. It improves code quality and simplifies collaboration, especially in team environments. Tools like PHP_CodeSniffer or PHP-CS-Fixer can help ensure adherence to PSR-12 effortlessly.

PSR-11 is a PHP Standard Recommendation (PHP Standard Recommendation) that defines a Container Interface for dependency injection. It establishes a standard way to interact with dependency injection containers in PHP projects.

Purpose of PSR-11

PSR-11 was introduced to ensure interoperability between different frameworks, libraries, and tools that use dependency injection containers. By adhering to this standard, developers can switch or integrate various containers without modifying their code.

Core Components of PSR-11

PSR-11 specifies two main interfaces:

1. ContainerInterface
   This is the central interface providing methods to retrieve and check services in the container.

namespace Psr\Container;

interface ContainerInterface {
    public function get(string $id);
    public function has(string $id): bool;
}

• • get(string $id): Returns the instance (or service) registered in the container under the specified ID.
  • has(string $id): Checks whether the container has a service registered with the given ID.

• 2. NotFoundExceptionInterface
  This is thrown when a requested service is not found in the container.

namespace Psr\Container;

interface NotFoundExceptionInterface extends ContainerExceptionInterface {
}

3. ContainerExceptionInterface
A base exception for any general errors related to the container.

Benefits of PSR-11

• Interoperability: Enables various frameworks and libraries to use the same container.
• Standardization: Provides a consistent API for accessing containers.
• Extensibility: Allows developers to create their own containers that comply with PSR-11.

Typical Use Cases

PSR-11 is widely used in frameworks like Symfony, Laravel, and Zend Framework (now Laminas), which provide dependency injection containers. Libraries like PHP-DI or Pimple also support PSR-11.

Example

Here’s a basic example of using PSR-11:

use Psr\Container\ContainerInterface;

class MyService {
    public function __construct(private string $message) {}
    public function greet(): string {
        return $this->message;
    }
}

$container = new SomePSR11CompliantContainer();
$container->set('greeting_service', function() {
    return new MyService('Hello, PSR-11!');
});

if ($container->has('greeting_service')) {
    $service = $container->get('greeting_service');
    echo $service->greet(); // Output: Hello, PSR-11!
}

Conclusion

PSR-11 is an essential interface for modern PHP development, as it standardizes dependency management and resolution. It promotes flexibility and maintainability in application development.

PSR-7 is a PHP Standard Recommendation (PSR) that focuses on HTTP messages in PHP. It was developed by the PHP-FIG (Framework Interoperability Group) and defines interfaces for working with HTTP messages, as used by web servers and clients.

Key Features of PSR-7:

1. Request and Response:
   PSR-7 standardizes how HTTP requests and responses are represented in PHP. It provides interfaces for:

   • RequestInterface: Represents HTTP requests.
   • ResponseInterface: Represents HTTP responses.

2. Immutability:
   All objects are immutable, meaning that any modification to an HTTP object creates a new object rather than altering the existing one. This improves predictability and makes debugging easier.

3. Streams:
   PSR-7 uses stream objects to handle HTTP message bodies. The StreamInterface defines methods for interacting with streams (e.g., read(), write(), seek()).

4. ServerRequest:
   The ServerRequestInterface extends the RequestInterface to handle additional data such as cookies, server parameters, and uploaded files.

5. Middleware Compatibility:
   PSR-7 serves as the foundation for middleware architectures in PHP. It simplifies the creation of middleware components that process HTTP requests and manipulate responses.

Usage:

PSR-7 is widely used in modern PHP frameworks and libraries, including:

• Zend Diactoros
• Guzzle
• Slim Framework
• Laravel (via middleware)

Purpose:

The goal of PSR-7 is to improve interoperability between different PHP libraries and frameworks by defining a common standard for HTTP messages.

PSR-6 is a PHP-FIG (PHP Framework Interoperability Group) standard that defines a common interface for caching in PHP applications. This specification, titled "Caching Interface," aims to promote interoperability between caching libraries by providing a standardized API.

Key components of PSR-6 are:

1. Cache Pool Interface (CacheItemPoolInterface): Represents a collection of cache items. It's responsible for managing, fetching, saving, and deleting cached data.

2. Cache Item Interface (CacheItemInterface): Represents individual cache items within the pool. Each cache item contains a unique key and stored value and can be set to expire after a specific duration.

3. Standardized Methods: PSR-6 defines methods like getItem(), hasItem(), save(), and deleteItem() in the pool, and get(), set(), and expiresAt() in the item interface, to streamline caching operations and ensure consistency.

By defining these interfaces, PSR-6 allows developers to easily switch caching libraries or integrate different caching solutions without modifying the application's core logic, making it an essential part of PHP application development for caching standardization.

PSR-4 is a PHP standard recommendation that provides guidelines for autoloading classes from file paths. It is managed by the PHP-FIG (PHP Framework Interop Group) and defines a way to map the fully qualified class names to the corresponding file paths. This standard helps streamline class loading, especially in larger projects and frameworks.

Key Principles of PSR-4:

1. Namespace Mapping: PSR-4 requires that the namespace and class name match the directory structure and file name. Each namespace prefix is associated with a base directory, and within that directory, the namespace hierarchy corresponds directly to the directory structure.

2. Base Directory: For each namespace prefix, a base directory is defined. Classes within that namespace are located in subdirectories of the base directory according to their namespace structure. For example:

   • If the namespace is App\Controllers, the file would be located in a folder like /path/to/project/src/Controllers.

3. File Naming: The class name must match the filename exactly, including case sensitivity, and end with .php.

4. Autoloader Compatibility: Implementing PSR-4 ensures compatibility with modern autoloaders like Composer’s, allowing PHP to locate and include classes automatically without manual require or include statements.

Example of PSR-4 Usage:

Suppose you have the namespace App\Controllers\UserController. According to PSR-4, the directory structure would look like:

/path/to/project/src/Controllers/UserController.php

In Composer’s composer.json, this mapping is specified like so:

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

This configuration tells Composer to load classes in the App namespace from the src/ directory. When you run composer dump-autoload, it sets up the autoloading structure to follow PSR-4 standards.

Advantages of PSR-4:

• Consistency: Enforces a clear and organized file structure.
• Ease of Use: Allows seamless autoloading in large projects.
• Compatibility: Works well with frameworks and libraries that follow the PSR-4 standard.

PSR-4 has replaced the older PSR-0 standard, which had more restrictive rules on directory structure, making PSR-4 the preferred autoloading standard for modern PHP projects.

Monolog is a popular PHP logging library that implements the PSR-3 logging interface standard, making it compatible with PSR-3-compliant frameworks and applications. Monolog provides a flexible and structured way to log messages in PHP applications, which is essential for debugging and application maintenance.

Key Features and Concepts of Monolog:

1. Logger Instance: The core of Monolog is the Logger class, which provides different log levels (e.g., debug, info, warning, error). Developers use these levels to capture log messages of varying severity in their PHP applications.

2. Handlers: Handlers are central to Monolog’s functionality and determine where and how log entries are stored. Monolog supports a variety of handlers, including:

   • StreamHandler: Logs messages to a file or stream.
   • RotatingFileHandler: Manages daily rotating log files.
   • FirePHPHandler and ChromePHPHandler: Send logs to the browser console (via specific browser extensions).
   • SlackHandler, MailHandler, etc.: Send logs to external platforms like Slack or via email.

3. Formatters: Handlers can be paired with Formatters to customize the log output. Monolog includes formatters for JSON output, simple text formatting, and others to suit specific logging needs.

4. Processors: In addition to handlers and formatters, Monolog provides Processors, which attach additional contextual information (e.g., user data, IP address) to each log entry.

Example of Using Monolog:

Here is a basic example of initializing and using a Monolog logger:

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$logger = new Logger('name');
$logger->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::WARNING));

// Creating a log message
$logger->warning('This is a warning');
$logger->error('This is an error');

Advantages of Monolog:

• Modularity: Handlers allow Monolog to be highly flexible, enabling logs to be sent to different destinations.
• PSR-3 Compatibility: As it conforms to PSR-3, Monolog integrates easily into PHP projects following this standard.
• Extensibility: Handlers, formatters, and processors can be customized or extended with user specific classes to meet unique logging needs.

Widespread Usage:

Monolog is widely adopted in the PHP ecosystem and is especially popular with frameworks like Symfony and Laravel.