YouNeed.dev — home
Yavor ZagorskiSenior Full-Stack Developer
CV Let’s build
← All work

VTX Redirect / Custom WordPress software / v2.1.1

A URL changes.
The decision shouldn’t.

/old-page/review/…/page/…ROUTING ENGINENORMALIZEMATCH / DECISIONDESTINATIONRULE MANAGEMENT

Request lifecycle / exact-path rules

Normalize. Match.
Make one decision.

The path is standardized before lookup. One enabled rule supplies the destination; unmatched requests remain with WordPress.

MATCH → CONFIGURED DESTINATION

The control plane behind the behavior

A rule you can
actually inspect.

I built both sides: the request lifecycle and the WordPress workspace that controls it.

VTX REDIRECTREAL RULE MANAGEMENT
Actual Redirect WordPress rule administration
REAL PROJECT EVIDENCE Inspect original ↗
REQUEST → NORMALIZE → MATCH → DESTINATIONSCROLL TO EXPOSE THE CONTROL PLANE

01 / Runtime contract

One request.
One explicit outcome.

The runtime joins WordPress at template_redirect, before template output. Administration, AJAX and cron requests are left alone.

template_redirect → Normalizer → Repository → wp_safe_redirect

Source-derived flow. This diagram does not send requests or change rules.

02 / Operator control

A rule you can
actually inspect.

Source, destination, status and enabled state stay visible together. Changing a URL shouldn’t require editing a theme or scattering redirect logic through it.

Control plane / Runtime

Save deliberately.
Resolve consistently.

Permission before persistence
Administration requires manage_options and action-specific nonce validation.
Normalize once per request
The repository caches normalized rules within the request. Enabled rules are keyed by source path for matching.
Destination is a decision
301, 302, 307 or 308. Preserve the incoming query only when configured and the target has no query already.
Real VTX Redirect new-rule drawer with source, destination, status and active controls
Detail crop · the actual new-rule drawer

03 / Several changes, one workspace

A readable
migration list.

The bulk editor uses one rule per line. An administration activity log records changes; the usage lookup searches WordPress post text for references.

It is not a traffic analytics engine or a complete scan of builder metadata. Bulk input needs review: malformed lines can be skipped.

Actual VTX Redirect bulk editor with its line-based rule format
Real interface · bulk replacement, not an invented code sample

Engineering includes knowing the limits

Predictable doesn’t
mean unlimited.

What is implemented

Exact-path matching; paused rules excluded from runtime; duplicate checks in individual editing; relative-path cycle validation; WordPress safe-redirect handling with configured destination hosts.

Inspect the source ↗

What I would harden next

Absolute same-site cycles need broader graph validation. Bulk edits need the same destination validation as individual edits. Rules live in one option, so large rule sets need measurement—not an unqualified performance claim.