Form-to-Email: a deliberately small PHP 8.4 library for controlled form processing and email delivery

TL;DR A simple contact form often ends up pulling a framework, a SaaS provider, or a fragile custom script. Form-to-Email is a PHP 8.4+ backend-only library that treats form handling as a strict data pipeline: sanitize, validate, transform, then send, and log.

Everything is explicit: processor order, error reporting, email delivery, and audit logging.

The goal is not flexibility or popularity, but control, predictability, and long-term maintainability.

Form-to-Email on GitHub https://github.com/jturbide/form-to-email

The problem, in code

Most PHP contact forms start small and look reasonable at first glance.

if (!empty($_POST['email']) && filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)) {
    mail('contact@example.com', 'New message', $_POST['message']);
}

This works for a demo. It even works in production for a while. The problem is not that it is wrong, but that it has no clear growth path.

As soon as requirements change, the code starts to deform. You add trimming, length checks, spam protection, logging, maybe a second recipient. Validation logic leaks into transport logic. Error handling becomes implicit. Testing becomes awkward.

A slightly more realistic version already starts to show the issue:

$errors = [];
$email = trim($_POST['email'] ?? '');
$message = trim($_POST['message'] ?? '');

if ($email === '' || !filter_var($email, FILTER_VALIDATE_EMAIL)) {
    $errors['email'][] = 'Invalid email';
}

if (strlen($message) < 10) {
    $errors['message'][] = 'Message too short';
}

if ($errors === []) {
    mail('contact@example.com', 'New message', $message);
}

At this point, several problems are already visible:

• Input normalization, validation, and side effects are mixed together
• Execution order is implicit and easy to break
• Errors are ad-hoc strings with no structure
• There is no reusable model for another form
• Testing requires simulating $_POST and global state

None of these issues are dramatic in isolation. Together, they make form handling brittle and hard to reason about.

Form-to-Email starts from the observation that this problem is not about sending an email. It is about defining a predictable pipeline where each step is explicit, ordered, and testable, and where email delivery is only the final consequence of valid data.

The pipeline, visually and concretely

Form-to-Email treats form handling as a strict, linear data pipeline. Nothing is inferred and nothing is reordered. Each step is declared upfront and executed in the order you define.

At a high level, the pipeline looks like this:

Raw input (HTTP / JSON / CLI)
        ↓
Logger (debug, stdout)
        ↓
Filters (sanitize, normalize)
        ↓
Rules (validate invariants)
        ↓
Transformers (final shape)
        ↓
Structured data
        ↓
Mailer adapter (side effect)
        ↓
Logger adapter (final data, audit log)

This model is intentionally simple. It mirrors what most developers already do mentally, but forces the steps to be explicit and testable.

A minimal working example looks like this:

$form = new FormDefinition()
    ->add(new FieldDefinition('email', roles: [FieldRole::SenderEmail], processors: [
        new TrimFilter(),
        new SanitizeEmailFilter(),
        new EmailRule(),
    ]))
    ->add(new FieldDefinition('message', roles: [FieldRole::Body], processors: [
        new TrimFilter(),
        new RequiredRule(),
    ]));

$controller = new FormToEmailController(
    form: $form,
    mailer: $mailer,
    recipients: ['contact@example.com'],
);

$controller->handle();

What matters here is not the syntax, but the shape of the code. Each field declares its own processing rules. There is no global validation layer and no hidden execution order. Reading the definition tells you exactly what will happen at runtime.

This structure also makes failure modes obvious. If input is invalid, the pipeline stops before any side effect occurs. If processing succeeds, email delivery becomes a straightforward consequence of validated data, not a place where additional logic accumulates.

By grounding the design in a visible pipeline, the library avoids the ambiguity that usually appears once form handling logic starts to grow organically.

Defining fields: where most bugs actually happen

In practice, most form-related bugs do not come from email delivery. They come from field-level assumptions: when values are cleaned, when they are validated, and which version of the data is actually being checked.

Form-to-Email pushes all of this logic into FieldDefinition. Each field owns its name, its semantic role, and its processor pipeline. There is no shared state and no cross-field magic.

A common source of subtle bugs is processor order. Consider this incorrect definition:

new FieldDefinition('email', processors: [
    new EmailRule(),
    new SanitizeEmailFilter(),
]);

At a glance this looks reasonable, but validation runs on raw input. An address with leading whitespace or mixed Unicode characters may fail validation even though it could be normalized safely.

The corrected version makes the intent explicit:

new FieldDefinition('email', processors: [
    new TrimFilter(),
    new SanitizeEmailFilter(),
    new EmailRule(),
]);

Here, validation runs on the normalized value. The difference is not theoretical; it directly affects false negatives and user-facing errors.

Transformers follow the same principle. Formatting operations such as lowercasing or canonicalization should usually happen after validation, so that rules operate on meaningful input rather than on a derived representation.

new FieldDefinition('email', processors: [
    new SanitizeEmailFilter(),
    new EmailRule(),
    new LowercaseTransformer(),
]);

By forcing processor order to be explicit, the library removes an entire class of hidden behavior. Reading the field definition is enough to understand exactly what happens to the data, in which order, and why.

This field-centric model also scales cleanly. Adding a new field does not affect existing ones, and reusing processor chains across forms does not require inheritance, traits, or global configuration. Each field remains a small, self-contained pipeline.

Roles and email mapping: removing hidden coupling

A frequent source of fragility in form handlers is the implicit coupling between field names and email composition logic. The backend often assumes that a specific input key maps to a specific email attribute, and that assumption quietly spreads across the codebase.

A typical example looks like this:

$mail->setReplyTo($data['email']);
$mail->Subject = $data['subject'] ?? 'Contact form';
$mail->Body = $data['message'];

This works, but the coupling is invisible. Renaming a field or reusing the same form logic in a different context requires touching both validation code and mail composition code. Over time, these assumptions accumulate.

Form-to-Email breaks this coupling by introducing explicit field roles. A role describes what a field represents, not how it is named. Roles do not affect validation or processing; they are only used when mapping validated data to an email payload.

new FieldDefinition('email', roles: [FieldRole::SenderEmail]);
new FieldDefinition('name', roles: [FieldRole::SenderName]);
new FieldDefinition('message', roles: [FieldRole::Body]);

With roles in place, email composition no longer depends on hard-coded field names. The controller builds the email payload by semantic intent: sender address, sender name, subject, body. Field names remain local to the form definition.

This approach has two practical consequences. First, forms become easier to refactor. Changing an input name does not ripple into mailer logic. Second, form definitions become more reusable. The same pipeline can be applied to different frontends or request formats without rewriting email code.

Roles are deliberately limited in scope. They are not validation rules, and they do not influence processor execution. Their sole purpose is to make intent explicit at the boundary between validated data and email delivery, where hidden assumptions are most costly.

Structured errors and frontend integration

Once validation becomes explicit, error handling needs to be explicit as well. Ad-hoc strings or early exit() calls make it difficult to build reliable frontends and nearly impossible to test behavior consistently.

Form-to-Email always returns a structured result. Success and failure are mutually exclusive, and failures never trigger partial side effects such as email delivery.

A typical validation error response looks like this:

{
  "code": "validation_error",
  "errors": {
    "name": [
      {
        "code": "too_short",
        "message": "The field "{field}" must be at least {min} characters long.",
        "context": {
          "field": "name",
          "min": 4,
          "length": 1
        },
        "field": "name"
      }
    ],
    "email": [
      {
        "code": "invalid_email",
        "message": "Invalid email format.",
        "context": {
          "value": "z",
          "normalized": null
        },
        "field": "email"
      },
      {
        "code": "too_short",
        "message": "The field "{field}" must be at least {min} characters long.",
        "context": {
          "field": "email",
          "min": 5,
          "length": 1
        },
        "field": "email"
      }
    ],
    "message": [
      {
        "code": "too_short",
        "message": "The field "{field}" must be at least {min} characters long.",
        "context": {
          "field": "message",
          "min": 10,
          "length": 1
        },
        "field": "message"
      }
    ]
  },
  "messages": {
    "name": [
      "The field "name" must be at least 4 characters long."
    ],
    "email": [
      "Invalid email format.",
      "The field "email" must be at least 5 characters long."
    ],
    "message": [
      "The field "message" must be at least 10 characters long."
    ]
  }
}

Each error is tied to a field and expressed with a stable error code and a human-readable message. Frontends can render these errors directly, map them to localized strings, or apply custom UI behavior without parsing free-form text.

The response format is intentionally transport-agnostic. While JSON is the most common output, the controller does not assume a specific frontend technology. A static HTML page, a JavaScript application, or a mobile client can all consume the same structure.

This explicit error model also improves testing. Assertions can be made on error codes and structure rather than brittle string comparisons. As validation rules evolve, the contract with the frontend remains stable.

By treating error shape as part of the API, the library avoids the common trap where backend validation logic and frontend presentation become tightly coupled through undocumented conventions.

From validated data to email delivery

Once the pipeline has produced validated and normalized data, the remaining responsibility is straightforward: turn that data into an email and send it. At this stage, no validation logic should remain and no assumptions about raw input should exist.

Form-to-Email keeps this boundary explicit through a small controller whose role is orchestration, not decision-making. The controller executes the form pipeline, inspects the result, and either returns structured errors or proceeds to email delivery. It does not reinterpret fields, reorder processors, or apply additional business rules.

When validation succeeds, the controller builds an immutable mail payload from the processed values. Field roles guide this step. A field tagged as a sender email becomes the reply-to address. A field tagged as the body becomes the message content. This mapping is semantic rather than positional and does not depend on field names.

$controller = new FormToEmailController(
    form: $form,
    mailer: $mailer,
    recipients: ['contact@example.com'],
    defaultSubject: 'New contact request',
);

$controller->handle();

The mail payload itself is a simple value object. It contains recipients, subject, plain-text and HTML bodies, and optional metadata such as reply-to information. Once constructed, it is not mutated further. This avoids late-stage surprises and makes delivery behavior easier to reason about.

Email delivery is treated as a terminal side effect. If sending fails, the failure is reported explicitly. If validation fails, delivery is never attempted. There is no intermediate state where partially valid data results in a message being sent.

By isolating email delivery at the end of the pipeline, the library prevents a common failure mode where transport concerns slowly absorb validation and formatting logic. Form handling remains about data correctness; email delivery remains about infrastructure.

Mailer adapters and infrastructure boundaries

Email delivery is an infrastructure concern. Treating it as such avoids leaking transport details into validation, processing, or form definitions.

Form-to-Email enforces this separation through a small mailer adapter interface. The adapter receives a fully constructed mail payload and is responsible only for delivering it. It does not know how the data was validated, and it does not participate in form processing.

The default adapter is built on PHPMailer, chosen for its maturity, wide adoption, and predictable behavior in self-hosted environments. This choice is pragmatic, not architectural. PHPMailer is an implementation detail, not a design dependency.

$mailer = new PHPMailerAdapter(
    useSmtp: true,
    host: 'mail.example.com',
    username: 'no-reply@example.com',
    password: 'secret',
    fromEmail: 'no-reply@example.com',
    fromName: 'Website Contact Form',
);

Because the adapter boundary is narrow, replacing the mailer does not affect the rest of the system. Form definitions, processor pipelines, error handling, and logging remain unchanged. Only the delivery mechanism varies.

This makes infrastructure decisions explicit and reversible. Switching from local SMTP to a different transport, or integrating an external provider later, does not require rewriting form logic or validation rules.

By constraining email delivery behind a single interface, the library keeps form handling focused on data correctness and intent, while allowing infrastructure to evolve independently.

Logging and observability in real deployments

Once a form handler is deployed, failures rarely occur where the code is obvious. They surface as missing emails, partial submissions, or user reports that cannot be reproduced easily. Without observability, even simple issues become expensive to diagnose.

Form-to-Email treats logging as an operational concern rather than a core requirement. Logging is optional, explicit, and isolated from control flow. If no logger is configured, the library remains silent. When a logger is provided, it receives structured events describing what happened during a submission.

$logger = new Logger(
    file: __DIR__ . '/../logs/contact.log',
);

new FormToEmailController(
    form: $form,
    mailer: $mailer,
    recipients: ['contact@example.com'],
    logger: $logger,
)->handle();

Logged events can include validation failures, successful submissions, and high-level execution outcomes. The intent is not to capture every intermediate value, but to provide enough context to understand behavior in production without exposing sensitive data unnecessarily.

Crucially, logging does not influence execution. A logging failure cannot prevent a valid submission from being processed, and a validation failure does not automatically trigger verbose output unless explicitly configured. This separation avoids a common class of bugs where observability concerns leak into business logic.

In practice, this makes it easier to correlate frontend reports with backend behavior, detect repeated failure patterns, and audit form activity over time. The system remains quiet by default, but observable when needed.

By keeping logging structured, optional, and non-invasive, the library supports real-world operations without imposing a monitoring strategy or forcing a particular infrastructure choice.

Security considerations

Form handling sits directly on a trust boundary. Raw user input crosses from an untrusted environment into backend logic that may trigger side effects such as email delivery, logging, or persistence. The library is designed to make that boundary explicit and difficult to bypass accidentally.

Input trust model

Form-to-Email assumes that all incoming data is untrusted. No field is considered safe by default, and no implicit sanitization occurs. Every transformation applied to input data must be declared explicitly in the field pipeline.

This design prevents a common failure mode where developers assume that validation implicitly sanitizes data, or that downstream consumers will handle unsafe values correctly.

Sanitization before validation

A core security principle enforced by the library is that normalization and sanitization should occur before validation whenever possible. Validators operate on normalized data, not on raw input. This reduces false negatives and ensures that validation rules reflect the actual data shape used later.

For example, trimming whitespace or normalizing Unicode before validating an email address avoids edge cases where valid input is rejected or inconsistently handled.

XSS and content injection

Form-to-Email does not render HTML and does not generate frontend output. This removes an entire class of cross-site scripting risks from the library itself.

However, user input may still end up in email bodies, logs, or downstream systems. For this reason, the library provides explicit filters such as HTML escaping and tag stripping. These filters are opt-in and must be applied intentionally at the field level.

The absence of automatic escaping is deliberate. It avoids double-escaping bugs and makes the security model visible in code rather than implicit.

Side effects only on valid data

Email delivery is treated as a terminal side effect. If validation fails, no email is sent and no partial action occurs. This prevents abuse scenarios where malformed or partially validated input could still trigger external effects.

Rate limiting and abuse mitigation

The library does not implement rate limiting, CAPTCHA, or IP throttling. These concerns are considered infrastructure-level responsibilities. When needed, they should be handled by a reverse proxy, web server, firewall, or dedicated middleware.

This keeps the library focused on correctness and avoids embedding policy decisions that vary widely between deployments.

References

Security-related design choices in this library align with the following guidance:

• OWASP Input Validation Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

• OWASP Cross-Site Scripting Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Built-in processors and extensibility

Form-to-Email enforces security and correctness through small, composable processors. Each processor is attached to a field and executed in a strict, explicit order. There is no global pipeline and no implicit behavior.

Processors are intentionally divided into three categories. The distinction is semantic: it defines intent, not mechanics.

All processors share the same execution contract and are combined directly on FieldDefinition.

Built-in filters (sanitization and normalization)

Filters run early in the pipeline. Their role is to make raw, untrusted input predictable so that validation operates on normalized data.

If a field has no filters, its raw value is preserved deliberately.

Filters never report validation errors. If filtering produces an invalid value, validation rules will catch it later.

Example:

$field = (new FieldDefinition('message'))
    ->addFilter(new TrimFilter())
    ->addFilter(new StripTagsFilter());

Built-in rules (validation)

Rules enforce invariants on already-normalized data. They inspect values and return structured errors without modifying input or throwing exceptions.

Rules may return zero, one, or many errors. Validation failure stops side effects such as email delivery but does not implicitly terminate execution.

Example:

$field = (new FieldDefinition('message'))
    ->addRule(new RequiredRule())
    ->addRule(new MaxLengthRule(500));

Built-in transformers (final shape)

Transformers run after validation and produce a canonical representation of accepted data. They should be pure, deterministic, and free of validation logic.

Transformers should be used for formatting and normalization, not for enforcing constraints.

Example:

$field = (new FieldDefinition('email'))
    ->addTransformer(new LowercaseTransformer());

Putting it together

A typical, well-structured field pipeline looks like this:

new FieldDefinition('email', processors: [
    new TrimFilter(),
    new SanitizeEmailFilter(),
    new EmailRule(),
    new LowercaseTransformer(),
]);

The order is intentional:

1. Filters clean untrusted input
2. Rules validate invariants
3. Transformers finalize representation

If logic both modifies data and can fail validation, it should be split into two processors. This separation keeps pipelines predictable and easy to reason about.

Internal structure (reference)

src/
├── Filter/
├── Rule/
├── Transformer/
├── Core/

This layout mirrors the execution model and keeps extension points narrow, explicit, and auditable.

Writing your own processors (custom, filters, rules, transformers)

One of the core design goals of Form-to-Email is that custom behavior should be as easy to write as built-in behavior. There is no plugin system, no registration step, and no hidden lifecycle. If you can write a small, predictable class, you can extend the pipeline.

All processors share the same execution model and are attached directly to a FieldDefinition. The difference between a filter, a rule, and a transformer is semantic, not structural.

Processor types at a glance

The table below summarizes the three processor types used throughout Form-to-Email, how they are implemented, and when they should be used.

All processors share the same execution model and are attached directly to a FieldDefinition. The distinction between types is semantic: what matters is intent, not mechanics.

Writing a custom processor

Custom behavior is added by implementing the shared processor interface. There is no separate plugin system and no global registration.

final class SlugifyTransformer implements FieldProcessor
{
    public function process(
        mixed $value,
        FieldDefinition $field,
        FormContext $context
    ): mixed {
        $value = strtolower(trim((string) $value));
        $value = preg_replace('/[^a-z0-9]+/', '-', $value) ?? '';
        return trim($value, '-');
    }
}

The processor can then be attached like any built-in component:

$field = (new FieldDefinition('title'))
    ->addTransformer(new SlugifyTransformer());

Because processors are local to fields and executed in order, custom logic remains predictable and easy to audit. There are no hidden hooks and no global side effects.

Extensibility stops at the processor and adapter boundaries. If a feature cannot be expressed cleanly at those levels, it likely belongs outside the library.

Writing a transformer

Transformers are responsible for producing a canonical representation of a value. They should not perform validation and should not reject data. Their role is to normalize or format already-validated input.

A real-world example is lowercasing user input, such as email addresses or usernames.

<?php

declare(strict_types=1);

namespace FormToEmailTransformer;

use FormToEmailCoreFieldDefinition;
use FormToEmailCoreFormContext;

/**
 * Converts string values to lowercase.
 *
 * Features:
 * - Unicode-aware by default (uses mb_strtolower)
 * - Option to disable Unicode mode for legacy or performance
 * - Skips non-string values
 */
final class LowercaseTransformer extends AbstractTransformer
{
    public function __construct(
        private readonly bool $unicodeAware = true
    ) {
    }

    #[Override]
    public function apply(mixed $value, FieldDefinition $field, FormContext $context): mixed
    {
        if (!is_string($value)) {
            return $value;
        }

        return $this->unicodeAware
            ? mb_strtolower($value, 'UTF-8')
            : strtolower($value);
    }
}

Key characteristics of a transformer:

• It is pure: the same input always produces the same output
• It never throws validation errors
• It is safe to run only after sanitization and validation

Usage:

$field = (new FieldDefinition('email'))
    ->addTransformer(new LowercaseTransformer());

Writing a validation rule

Rules enforce invariants. They inspect a value and either accept it or return one or more structured errors. Rules * *never modify values**.

A typical example is enforcing a maximum length constraint.

<?php

declare(strict_types=1);

namespace FormToEmailRule;

use FormToEmailCoreFieldDefinition;

/**
 * Rule: MaxLengthRule
 *
 * Ensures that a string does not exceed a given number of characters.
 */
final readonly class MaxLengthRule extends AbstractLengthRule
{
    public function __construct(
        private int $max,
        private string $code = 'too_long',
        private string $message = 'The field "{field}" must not exceed {max} characters.',
        bool $multibyte = true,
        string $encoding = 'UTF-8',
    ) {
        parent::__construct($multibyte, $encoding);
    }

    #[Override]
    protected function validate(mixed $value, FieldDefinition $field): array
    {
        if (!is_string($value) || $value === '') {
            return [];
        }

        $len = $this->getLength($value);
        if ($len > $this->max) {
            return [
                $this->makeError($field, $this->code, $this->message, [
                    'max' => $this->max,
                    'length' => $len,
                ]),
            ];
        }

        return [];
    }
}

Key characteristics of a rule:

• It returns structured errors, not booleans or exceptions
• It can return multiple errors
• It is deterministic and side-effect free

Usage:

$field = (new FieldDefinition('message'))
    ->addRule(new MaxLengthRule(500));

Writing a filter

Filters are applied early in the pipeline. Their purpose is to sanitize or normalize raw input so that downstream validation operates on predictable data.

A common example is phone number normalization.

<?php

declare(strict_types=1);

namespace FormToEmailFilter;

use FormToEmailCoreFieldDefinition;

/**
 * Removes any non-digit characters from phone number strings.
 * Keeps only 0–9 digits.
 */
final class SanitizePhoneFilter extends AbstractFilter
{
    #[Override]
    public function apply(mixed $value, FieldDefinition $field): mixed
    {
        if (!is_string($value)) {
            return $value;
        }

        return preg_replace('/D+/', '', $value) ?? '';
    }
}

Key characteristics of a filter:

• It operates on raw input
• It should be safe to apply before validation
• It should not generate validation errors

Usage:

$field = (new FieldDefinition('phone'))
    ->addFilter(new SanitizePhoneFilter());

Choosing the right processor type

A simple rule of thumb:

• Filter: clean or normalize untrusted input. Filters make unsafe input predictable.
• Rule: enforce a constraint and report errors. Rules decide whether data is acceptable.
• Transformer: produce a final, canonical value. Transformers make accepted data consistent

If logic both modifies data and can fail validation, it usually needs to be split into two processors. This separation keeps pipelines predictable and easy to reason about.

By keeping processors small, explicit, and local to fields, Form-to-Email makes extension straightforward without introducing global hooks or implicit behavior.

Quality guarantees and static analysis constraints

This library was written with the assumption that it will be read, audited, and modified long after its initial creation. For a small infrastructure component, correctness and predictability matter more than speed of iteration.

The guarantees below are not aspirational. They are enforced continuously through tooling and CI, and they deliberately constrain how the code can evolve.

Static analysis is treated as a design constraint rather than a safety net. When tools raise an issue, the implementation is corrected instead of relaxing the rules. This forces edge cases to be addressed early and prevents entire classes of runtime errors from occurring.

Full test coverage is not pursued as a vanity metric. In a pipeline-based system, it is the most practical way to ensure that processor order, validation behavior, and terminal side effects remain stable over time.

The absence of framework coupling further reinforces these guarantees. There are no external lifecycles, request abstractions, or configuration layers that can change independently. What the analysis tools and test suite validate is exactly what runs in production.

Together, these constraints intentionally slow down change. Adding new behavior requires justification, typing, analysis, and tests. That friction is deliberate: it keeps the library small, auditable, and reliable as a long-lived component.

When this approach makes sense (and when it does not)

Form-to-Email is not a universal solution. It is a deliberately narrow answer to a narrowly defined problem.

This approach makes sense when form handling is a small but important part of a system. Typical cases include contact forms, internal tools, low-volume submission endpoints, or self-hosted projects where infrastructure is already under control. In these situations, pulling a full framework or delegating submissions to an external provider often adds more surface area than value.

It also makes sense when predictability matters more than convenience. A strict pipeline, explicit execution order, and structured error model make behavior easy to reason about and easy to test, even years later.

There are equally clear cases where this library is not a good fit. Applications with complex workflows, authentication, persistence, and rich domain logic benefit from a full framework. High-traffic public forms exposed to constant abuse may be better served by specialized external services with built-in mitigation and monitoring.

The intent here is proportionality. Modern PHP is strong enough to support small, explicit, dependency-light components without sacrificing safety. When the problem is simple, keeping the solution simple is often the most robust choice.

In that sense, Form-to-Email is less a reusable product and more a documented engineering decision: make data flow explicit, keep side effects isolated, and avoid unnecessary abstractions.

References and sources

The design and constraints of this library are grounded in existing standards, tooling, and best practices. The following references provide context and justification for many of the decisions described in this article.

PHP language and RFCs

• PHP 8.4 language features and RFCs https://www.php.net/releases/8.4/

• Strict typing in PHP https://www.php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration.strict

Static analysis and testing

• PHPStan – Static Analysis Tool for PHP https://phpstan.org/

• PHPStan Rule Levels https://phpstan.org/user-guide/rule-levels

• Psalm – Static Analysis for PHP https://psalm.dev/

• PHPUnit – Testing framework for PHP https://phpunit.de/

Coding standards

• PSR-12: Extended Coding Style Guide https://www.php-fig.org/psr/psr-12/

• Slevomat Coding Standard https://github.com/slevomat/coding-standard

Email and security

• PHPMailer https://github.com/PHPMailer/PHPMailer

• OWASP Input Validation Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

• OWASP Cross-Site Scripting Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Project links

• Form-to-Email on GitHub https://github.com/jturbide/form-to-email

• Form-to-Email on Packagist https://packagist.org/packages/jturbide/form-to-email