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.

The Fetch API is a modern JavaScript interface for retrieving resources over the network, such as making HTTP requests to an API or loading data from a server. It largely replaces the older XMLHttpRequest method and provides a simpler, more flexible, and more powerful way to handle network requests.

Basic Functionality

• The Fetch API is based on Promises, making asynchronous operations easier.
• It allows fetching data in various formats like JSON, text, or Blob.
• By default, Fetch uses the GET method but also supports POST, PUT, DELETE, and other HTTP methods.

Simple Example

fetch('https://jsonplaceholder.typicode.com/posts/1')
  .then(response => response.json()) // Convert response to JSON
  .then(data => console.log(data)) // Log the data
  .catch(error => console.error('Error:', error)); // Handle errors

Making a POST Request

fetch('https://jsonplaceholder.typicode.com/posts', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ title: 'New Post', body: 'Post content', userId: 1 })
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

Advantages of the Fetch API

✅ Simpler syntax compared to XMLHttpRequest
✅ Supports async/await for better readability
✅ Flexible request and response handling
✅ Better error management using Promises

The Fetch API is now supported in all modern browsers and is an essential technique for web development.

A Single Page Application (SPA) is a web application that runs entirely within a single HTML page. Instead of reloading the entire page for each interaction, it dynamically updates the content using JavaScript, providing a smooth, app-like user experience.

Key Features of an SPA:

• Dynamic Content Loading: New content is fetched via AJAX or the Fetch API without a full page reload.
• Client-Side Routing: Navigation is handled by JavaScript (e.g., React Router or Vue Router).
• State Management: SPAs often use libraries like Redux, Vuex, or Zustand to manage application state.
• Separation of Frontend & Backend: The backend typically serves as an API (e.g., REST or GraphQL).

Advantages:

✅ Faster interactions after the initial load
✅ Improved user experience (no full page reloads)
✅ Offline functionality possible via Service Workers

Disadvantages:

❌ Initial load time can be slow (large JavaScript bundle)
❌ SEO challenges (since content is often loaded dynamically)
❌ More complex implementation, especially for security and routing

Popular frameworks for SPAs include React, Angular, and Vue.js.

CSS Media Queries are a technique in CSS that allows a webpage layout to adapt to different screen sizes, resolutions, and device types. They are a core feature of Responsive Web Design.

Syntax:

@media (condition) {
    /* CSS rules that apply only under this condition */
}

Examples:

1. Adjusting for different screen widths:

/* For screens with a maximum width of 600px (e.g., smartphones) */
@media (max-width: 600px) {
    body {
        background-color: lightblue;
    }
}

2. Detecting landscape vs. portrait orientation:

@media (orientation: landscape) {
    body {
        background-color: lightgreen;
    }
}

3. Styling for print output:

@media print {
    body {
        font-size: 12pt;
        color: black;
        background: none;
    }
}

Common Use Cases:

✅ Mobile-first design: Optimizing websites for small screens first and then expanding for larger screens.
✅ Dark mode: Adjusting styles based on user preference (prefers-color-scheme).
✅ Retina displays: Using high-resolution images or specific styles for high pixel density screens (min-resolution: 2dppx).

A Bearer Token is a type of access token used for authentication and authorization in web applications and APIs. The term "Bearer" means "holder," which implies that anyone in possession of the token can access protected resources—without additional verification.

Characteristics of a Bearer Token:

• Self-contained: It includes all necessary authentication information.
• No additional identity check: Whoever holds the token can use it.
• Sent in HTTP headers: Typically as Authorization: Bearer <token>.
• Often time-limited: Tokens have expiration times to reduce misuse.
• Commonly used with OAuth 2.0: For example, when authenticating with third-party services.

Example of an HTTP request with a Bearer Token:

GET /protected-data HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

Risks:

• No protection if stolen: If someone intercepts the token, they can impersonate the user.
• Must be securely stored: Should not be exposed in client-side code or URLs.

💡 Tip: To enhance security, use short-lived tokens and transmit them only over HTTPS.

OAuth (Open Authorization) is an open standard protocol for authorization that allows applications to access a user's resources without knowing their credentials (e.g., password). It is commonly used for Single Sign-On (SSO) and API access.

How Does OAuth Work?

OAuth operates using tokens, which allow an application to access a user's data on their behalf. The typical flow is as follows:

1. Authorization Request: An application (client) requests access to a user’s protected data (e.g., Facebook contacts).
2. User Authentication: The user is redirected to the provider's login page (e.g., Google, Facebook) and enters their credentials.
3. Permission Granting: The user confirms that the application can access specific data.
4. Token Issuance: The application receives an access token, which grants permission to access the approved data.
5. Resource Access: The application uses the token to make requests to the API server without needing the user's password.

OAuth 1.0 vs. OAuth 2.0

• OAuth 1.0: More complex, uses cryptographic signatures but is secure.
• OAuth 2.0: Simpler, relies on HTTPS for security, and is the most commonly used version today.

Real-World Uses of OAuth

• "Sign in with Google/Facebook/Apple" buttons
• Third-party apps accessing Google Drive, Dropbox, or Twitter APIs
• Payment services like PayPal integrating with other apps

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.

The View in Model-View-Controller (MVC)

The View is the presentation layer in the MVC architecture. It is responsible for displaying data from the Model in a user-friendly format.

Main Responsibilities of the View

✅ Displaying Data: Shows information from the Model (e.g., a list of blog posts).
✅ Reacting to User Interactions: Accepts user input and sends it to the Controller.
✅ Formatting & Layout: Structures content using HTML, CSS, or templating engines (e.g., Laravel Blade or Twig).
✅ Avoiding Business Logic: Contains only presentation logic, not data processing.

How Does the View Work in MVC?

1. The user sends a request (e.g., "Show all blog posts").
2. The Controller calls the Model to retrieve the data.
3. The Model returns the required data.
4. The View receives the data from the Controller and displays it.

Example: Blog System (View in Laravel Blade)

<!-- resources/views/blog/index.blade.php -->
@extends('layouts.app')

@section('content')
    <h1>Blog Posts</h1>
    @foreach ($posts as $post)
        <div>
            <h2>{{ $post->title }}</h2>
            <p>{{ $post->content }}</p>
        </div>
    @endforeach
@endsection

🔹 @foreach: Loops through the list of blog posts and displays them.
🔹 {{ $post->title }}: Outputs the title of the blog post.

Conclusion

✔ The View is responsible for presentation but does not process data.
✔ It ensures a clear separation between logic and display.
✔ Using templates or frontend technologies (e.g., Vue.js, React), the View can be dynamically rendered.

The Model is the data and logic layer in the MVC architecture. It manages the application's data and ensures that it is correctly stored, retrieved, and processed.

Main Responsibilities of the Model

✅ Data Management: Stores and handles data, often in a database.
✅ Business Logic: Contains rules and calculations (e.g., discount calculation for orders).
✅ Data Validation: Checks if input is correct (e.g., if an email address is valid).
✅ Database Communication: Performs CRUD operations (Create, Read, Update, Delete).

How Does the Model Work in MVC?

1. The user sends a request (e.g., "Show all blog posts").
2. The Controller processes the request and calls the Model.
3. The Model queries the database and returns the data.
4. The Controller passes the data to the View for display.

Example: Blog System (Model in Laravel)

class BlogPost extends Model {
    protected $fillable = ['title', 'content']; // Erlaubte Felder für Massenverarbeitung

    // Beziehung: Ein Blogpost gehört zu einem Benutzer
    public function user() {
        return $this->belongsTo(User::class);
    }
}

🔹 fillable: Specifies which fields can be saved.
🔹 belongsTo(User::class): Indicates that each blog post belongs to a user.

Conclusion

✔ The Model handles all data and business logic of the application.
✔ It ensures a clear separation between data and presentation.
✔ Changes to the data structure only need to be made in the Model, not throughout the entire application.

A Controller is a key component in the Model-View-Controller (MVC) architecture. It acts as an intermediary between the user interface (View) and the business logic or data (Model).

Functions of a Controller

1. Handling User Input

   • The controller receives requests (e.g., from a web form or an API call).

2. Processing the Request

   • It analyzes the input and decides which action to take.
   • If necessary, it validates the data.

3. Interacting with the Model

   • The controller forwards the request to the model to fetch, update, or store data.

4. Updating the View

   • Once the model processes the request, the controller passes the data to the view.
   • The view is then updated with the new information.

Example: Blog System

Suppose a user wants to create a new blog post:

1. The user fills out a form and clicks "Save" (input to the controller).
2. The controller receives the request, validates the input, and sends it to the model.
3. The model stores the post in the database.
4. The controller retrieves the updated list of posts and sends it to the view.
5. The view displays the new blog post.

Example Code in PHP (Laravel)

class BlogController extends Controller {
    public function store(Request $request) {
        // Validierung der Benutzereingabe
        $request->validate([
            'title' => 'required|max:255',
            'content' => 'required',
        ]);

        // Neues Blog-Post-Model erstellen und speichern
        BlogPost::create([
            'title' => $request->input('title'),
            'content' => $request->input('content'),
        ]);

        // Weiterleitung zur Blog-Übersicht
        return redirect()->route('blog.index')->with('success', 'Post erstellt!');
    }
}

Conclusion

✔ A controller manages the flow of an application and separates business logic from presentation.
✔ It ensures clean code structure, as each component (Model, View, Controller) has a specific responsibility.
✔ Modern frameworks like Laravel, Django, or ASP.NET often include built-in routing mechanisms that automatically direct requests to the appropriate controllers.