- What does shweshi/opengraph do in a Laravel application?
- It fetches and parses Open Graph metadata such as title, description, image, and site name from any URL you hand it, exposed through a simple Laravel facade. Typical uses are link previews, social sharing cards, chat or comment unfurls, and content enrichment for editor-supplied URLs. It is a thin service-provider wrapper around an HTML metadata scraper, so it has no database, queue worker, or schema of its own.
- How do I install shweshi/opengraph with Composer?
- Run composer require shweshi/opengraph, targeting the v1.x line such as ^1.2. The service provider is auto-discovered in Laravel and the facade is registered for you, so there is no manual wiring. If you need to tune request behavior, publish the package config file and review what your installed version exposes.
- Which Laravel versions does shweshi/opengraph support?
- Version 1.2.1 was released as a Laravel 13 compatibility upgrade, which is a good sign the maintainer tracks framework releases. Check the tagged composer.json for the exact illuminate/support constraint before upgrading, because a changelog line saying Laravel 13 upgrade does not tell you whether Laravel 10 and 11 are still allowed or were dropped. Run composer resolution and your test suite in CI against your pinned PHP and Laravel versions before trusting the lockfile.
- How do I fetch Open Graph tags from a URL using the facade?
- Call the facade with the URL you want to inspect, then read the returned normalized metadata for the fields you need. Map the title, description, and image into your own preview model, Blade partial, or API resource rather than passing the raw payload through. Check the README for the exact method signature and return shape in your installed version.
- Is shweshi/opengraph safe to use with user-submitted URLs?
- Be careful, because the package makes server-side HTTP requests to whatever URL you give it, which is an SSRF vector when URLs come from users or editors. Enforce a scheme allow-list of http and https, reject private and link-local IP ranges, cap redirects and timeouts, and restrict outbound egress at the network layer. Do not treat the package defaults as a substitute for that hardening.
- Can I configure the request timeout and user agent in shweshi/opengraph?
- There is an optional config file you can publish, which is where request-level settings such as timeout and user agent belong. Publish it and read what your installed version actually exposes instead of assuming the keys exist. On any user-facing request path, keep timeouts defensively low so a slow remote host cannot stall your response.
- Does shweshi/opengraph cache the results?
- The package does not provide persistence, so each call typically hits the remote host. In production, wrap it in Laravel's cache with a key derived from the URL and a sensible TTL, plus short negative caching for failures. That protects both your latency budget and the sites you are scraping.
- Can I use shweshi/opengraph outside of Laravel?
- It is a Laravel wrapper around a standalone Open Graph scraper, so on plain PHP or another framework the wrapper adds little value. Use the underlying scraper library directly there, or expose a small internal HTTP service that wraps this package when several services need link previews. That keeps one hardened scraping path instead of many.
- What are the alternatives to shweshi/opengraph for link previews?
- You could hand-roll a scraper with Guzzle and a DOM parser, but you will spend the same hours on redirects, malformed meta tags, and encoding edge cases this package already handles. Hosted link-preview or unfurl APIs are another option if you would rather not manage egress and parsing yourself. For a Laravel app, a small Composer package is usually the cheapest build-versus-buy win.
- Is shweshi/opengraph actively maintained?
- It is a single-maintainer project with a small contributor base, and the Laravel 13 compatibility release is a positive signal that framework tracking is live. Bus factor rather than code quality is the long-term risk, so pin your version, watch the repository, and re-check the composer.json constraint at every framework upgrade. Because the wrapper is thin, forking it or swapping in the base scraper is a realistic fallback.