WebBlocks Redirect Manager

Documented package version: 0.1.18. WebBlocks CMS ^1.32; PHP >=8.1.

WebBlocks Redirect Manager is a small WebBlocks CMS plugin for creating and managing simple 301/302 redirects from the WebBlocks CMS admin area.

• Plugin handle: webblocks-redirect-manager
• Plugin version: 0.1.18
• Target host product: webblocks-cms
• Required CMS version: ^1.32
• PHP: >=8.1

1. Build the plugin artifact locally: composer plugin:build
2. Upload build/releases/webblocks-redirect-manager-0.1.18.zip to the WebBlocks CMS plugin upload flow.
3. After upload, the CMS should register the plugin in a disabled state first.
4. Review the plugin metadata and permissions.
5. Enable the plugin when ready.
6. Run the plugin migration through the CMS plugin lifecycle or migration command required by the host installation.

The plugin owns one table:

webblocks_redirect_manager_redirects

The migration creates redirect records with:

• source_path
• target_url
• status_code
• is_enabled
• hit_count
• last_hit_at
• timestamps

• webblocks-redirect-manager.view
• webblocks-redirect-manager.manage

• Enabled redirects are evaluated for unmatched public GET and HEAD requests before the CMS returns a 404.
• CMS 1.32.112 discovers installed plugin providers for definition() metadata but does not register or boot them as Laravel service providers. Redirect Manager therefore registers its public fallback route from definition() instead of relying on provider boot() middleware group mutation.
• POST, PUT, PATCH, and DELETE requests are bypassed.
• Admin and static namespaces are bypassed, including /webadmin/..., /cms/..., /storage/..., /assets/..., /static/..., /build/..., /vendor/..., and /webblocks-ui/....
• Source paths are normalized with one leading slash and no trailing slash, so /test-1, test-1, and /test-1/ match the same rule.
• Incoming query strings are ignored for matching. /test-1?x=1 matches source /test-1.
• Incoming query strings are not appended to the target URL. A rule from /test-1 to /test-2 redirects /test-1?x=1 to /test-2.
• Matching GET and HEAD redirects both increment hit_count and update last_hit_at.
• Self-target internal redirects are rejected during admin create/edit validation and bypassed at runtime as a loop guard.
• If the plugin table is missing because plugin migrations have not been run, public requests bypass the middleware without a SQL error.

Browsers may cache 301 redirects. While testing hit counters, use 302 redirects, clear browser cache, use incognito, or test with curl.

• Plugin migrations are not run automatically; run them through the CMS plugin lifecycle when installing or updating.
• No npm, Vite, Tailwind, Node, marketplace, payment, licensing, remote install, or auto-update behavior is included.