Video Platforms Parser Laravel Package

Getting Started

This patch (v1.4.2) only adds recognition for the x.com domain, so nothing changes in setup — but if you are wiring the package up for the first time, start with the URL recognition path, since that is the surface the release touches.

• Install with composer require and publish the config (php artisan vendor:publish), then confirm the config cache is rebuilt (php artisan config:cache) as part of deploy.
• Look first at the config file's provider/domain map and at the class that performs URL matching — that is where x.com is now registered alongside twitter.com.
• First use case: accept a user-pasted link, run it through the package to identify the provider, and branch on the result (embed, link card, or plain anchor). A one-liner in php artisan tinker against an https://x.com/user/status/... URL is the fastest smoke test.
• Run the package's own test suite plus one fixture of your own for each domain you care about before touching application code.

Implementation Patterns

Normalize before you match. Pass URLs through a single normalizer (trim whitespace, strip tracking query params, resolve www./mobile. prefixes, follow t.co redirects) before handing them to the package. Detection then becomes a pure function you can unit test without HTTP.

Persist a canonical provider, not the raw host. Store provider = twitter (or whatever your enum calls it) plus the original URL for display. This is exactly what protects you from the twitter.com → x.com churn: the matcher handles both hosts, and your data model no longer cares which one the user pasted.

Wrap detection in a small application service. Keep package calls behind a LinkResolver/UrlInspector class so a future domain change is a one-file edit, and so your Blade components and jobs depend on your own DTO rather than the package's return type.

Resolve metadata out of band. If you fetch oEmbed or Open Graph data after detection, push it to a queued job and cache the result keyed on the canonical provider + status/post ID — never on the raw host, or x.com and twitter.com links to the same post will miss each other's cache entries.

Blade integration. A single <x-link-preview :url="..."> component that internally calls your resolver keeps detection logic out of templates and makes it trivial to swap rendering per provider.

Test with data providers. Add cases for twitter.com, x.com, www.x.com, mobile.x.com, uppercase hosts, and trailing punctuation (pasted text often ends in . or )). This release is a reminder that host lists drift; a table-driven test file is the cheapest insurance.

Gotchas and Tips

• Same post, two hosts. twitter.com/user/status/123 and x.com/user/status/123 are the same content. Deduplicate on the extracted ID, not the URL string, or you will render duplicates in feeds.
• Mobile and legacy subdomains. mobile.x.com and www.x.com are common in shared links; verify the matcher covers them or normalize the host yourself before detection.
• Redirect shorteners. t.co links still appear in copied tweet text. Resolve them (with a timeout and a cached result) before calling the package, or detection will simply return "unknown".
• Trailing query strings. ?s=20 and &t=... are share-tracking noise; strip them before both matching and cache keying.
• Backfill existing rows. If you already stored twitter.com URLs, normalize them in a one-off migration/command so cached previews and dedupe logic line up with newly pasted x.com links.
• Config cache. A published config with a domain list will not reflect edits until config:cache is re-run; a "works locally, fails in staging" report is almost always this.
• Pin the version and read the diff. A patch bump that only extends a domain list is low risk, but confirm no matching behaviour changed; run your URL fixtures against the new tag before promoting.
• Extension point. If the matcher exposes a way to register custom domains or patterns, use it rather than editing vendor config — that keeps you upgrade-safe for the next host rename.
• Debugging. Log the raw input alongside the detected provider for anything that falls through to "unknown"; that log is what tells you whether the problem is normalization, an unsupported host, or the package.