- How do I install hazaveh/php-link-preview in a Laravel application?
- Installation is Composer-based: run composer require hazaveh/php-link-preview and commit the resulting composer.lock change. Because the public repository location is not confirmed, first verify the package on Packagist, check the publisher name, and pin an explicit version constraint rather than floating to latest. Review the downloaded source and its dependency tree before deploying to production.
- Which PHP and Laravel versions does hazaveh/php-link-preview support?
- The package is described as a framework-agnostic PHP library, so it does not ship a Laravel service provider or publish Laravel-version constraints. Check the composer.json php requirement and any PSR interfaces it implements, then confirm they are compatible with your Laravel release and PHP runtime. Since Laravel support is not documented upstream, validate it yourself with a small proof-of-concept before adopting.
- Is it safe to fetch user-submitted URLs with this link preview package?
- Not out of the box. Any library that fetches arbitrary URLs introduces SSRF exposure, so you must block private and link-local IP ranges, resolve DNS before connecting, cap redirects, and enforce timeouts and maximum response sizes. Because the package documentation does not describe these protections, treat URL validation and egress filtering as application responsibilities and add them in your own wrapper service.
- Should link previews be generated synchronously during a web request?
- No. Fetching a remote page and parsing HTML is I/O-bound and depends on an external site's availability, so a slow or hanging target can stall your response. Dispatch a queued job instead, cache the normalized result, and return stored previews on subsequent requests. This also lets you apply concurrency limits, retries with backoff, and per-host throttling.
- How do I integrate hazaveh/php-link-preview cleanly into Laravel?
- Wrap it behind an application-owned interface, for example a LinkPreviewService that returns a normalized DTO with title, description, image, and source URL. Do not let controllers call the package directly; the adapter should own HTTP transport, timeouts, logging, caching, and error handling. That indirection also lets you swap or fork the package later without touching calling code, and lets you gate rollout behind a feature flag with a fallback extractor.
- Does it handle Open Graph, Twitter cards, and relative image URLs?
- The overview states it extracts Open Graph and meta data such as title, description, and images, but the exact fallback order is not documented. Test representative pages to confirm how it prioritizes og:title versus title, whether it reads twitter:image, and whether relative image paths are resolved to absolute URLs. If resolution is missing, normalize URLs in your adapter and store the resolved absolute value alongside the preview.
- How should I cache link previews to avoid repeated remote fetches?
- Cache normalized previews keyed by a hash of the canonicalized URL, using Cache::remember with a TTL that matches how often the target content changes. Store the DTO or a JSON payload rather than the raw HTML, and keep images in your own storage or CDN so previews render even if the source page later breaks. Add a refresh policy and a way to invalidate a single URL when content goes stale.
- How do I test a link preview adapter without hitting real websites?
- Fake the HTTP layer with Http::fake and return recorded HTML fixtures for each scenario: complete Open Graph tags, title-only pages, malformed markup, non-HTML content, and timeouts. Write contract tests against your LinkPreviewService interface so the real package and any fallback implementation both satisfy the same expectations. Keep a small set of opt-in live tests outside CI to catch upstream breakage.
- What are the alternatives if hazaveh/php-link-preview is abandoned?
- The underlying job is small: fetch the page with Laravel's Http client and parse meta tags with DOMDocument or symfony/dom-crawler. Because the feature is not domain-critical, keeping your own adapter and DTO means replacing the package is a contained change rather than a refactor. Evaluate that in-house option early, since a low-adoption dependency with an unclear repository has limited long-term support.
- What production risks should I plan for beyond the code itself?
- Expect external timeouts, DNS failures, redirect loops, bot-blocking, non-HTML responses, and oversized bodies, and handle each explicitly rather than letting exceptions bubble into user flows. Add concurrency limits per host, retries with backoff, logging with the target URL, and monitoring on failure rates. Pin versions, watch dependency advisories, and be prepared to vendor or fork the library, since upstream maintenance and licensing cannot be assumed.