Phpquery Laravel Package

Product Decisions This Supports

• Scoping scraping/ingestion features. Any roadmap item that pulls structured data out of third-party HTML — competitor pricing, partner catalogs, job boards, regulatory filings — gets its effort estimate from the parsing layer. jQuery-style selectors typically turn a week of DOMDocument/XPath work into a one- or two-day spike, which changes whether the feature is "spike it" or "staff it."
• Build vs. buy on the extraction layer. phpQuery is the free/"buy" option. The decision it actually forces is whether we build a thin internal HTML-extraction abstraction over symfony/dom-crawler or accept a dependency on an unmaintained library we will eventually have to fork and own. Either way, "adopt phpQuery" is a maintenance commitment line item, not a footnote.
• Content migration and HTML transformation. One-off ETL for CMS migrations, rewriting links in imported bodies, normalizing legacy markup, sanitizing stored fragments. Ideal fit: a single artisan command, internal audience, run-once.
• SEO/QA auditing tooling. Crawling our own site to extract headings, meta, canonical tags, or broken links. Low blast radius because the HTML is ours and the output is a report.
• Template manipulation. DOM-level edits to HTML fragments in notification/email templates — viable, but usually better solved upstream at the template source.
• Roadmap signal. Because the package self-describes as abandonware and buggy, adoption is a commitment to pinning, wrapping, and eventually replacing it. That belongs in the plan, not in a code comment.

When to Consider This Package

Consider it when:

• The use case is internal, one-off, or behind a flag with no user-facing blast radius.
• The team already knows the jQuery selector API — onboarding cost is effectively zero, which is the package's one durable advantage.
• You are prototyping a scraper to validate a business case before committing engineering headcount.
• You are maintaining an existing codebase already on it. Migrating off is a separate project, not a prerequisite for shipping.
• The HTML is trusted or semi-trusted (our own templates, known-good vendor pages) and volume is low.

Look elsewhere when:

• You target PHP 8.x and cannot absorb silent breakage. The package's own description is "abandonware and buggy: use at your own risk" — validate against your runtime before anything else, and expect to fork.
• You parse untrusted or attacker-influenceable HTML at scale. That is a security surface (XXE, SSRF, entity expansion, parser DoS), and there is no one upstream to patch it. Use symfony/dom-crawler + symfony/css-selector, or a real browser via Dusk/Panther for JS-rendered pages.
• You need a support contract, a security patch cadence, or a predictable release train. Prefer symfony/dom-crawler, voku/simple_html_dom, or RoachPHP for spider orchestration in Laravel.
• The scraper is revenue-critical. Then the parser is infrastructure and you should own it explicitly.
• Provenance matters. The repository is unknown for this listing and the package is a third-party fork (164 stars, low health score). Verify the Packagist vendor, the commit history, and the fork's divergence from upstream before a single composer require — typosquatting on abandoned packages is a real supply-chain vector.

How to Pitch It (Stakeholders)

Executives: This is a free, jQuery-style HTML parser we can wire into a Laravel service in an afternoon. It lets us validate a data-ingestion idea cheaply, before we staff it. The trade-off is unambiguous and the package states it itself: abandoned and known-buggy, so it is a prototyping tool, not a platform. Recommendation: timebox it to the spike, isolate it behind an internal interface, and pre-approve a swap to a maintained library if the feature graduates to production.

Engineering: Familiar CSS-selector API, Composer-installable, no exotic extensions beyond dom/libxml. Guardrails are non-negotiable: pin the exact version, run it inside a queued job with timeouts and a memory cap, never feed it unsanitized or third-party markup, and wrap it in a small adapter class so replacing it with symfony/dom-crawler is a one-file change. Add fixture-based tests at adoption time — realistically, we become the maintainer.