Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Node Search Bundle Laravel Package

kunstmaan/node-search-bundle

KunstmaanNodeSearchBundle adds Elasticsearch-powered search to Kunstmaan CMS nodes, letting you index and query page content with configurable search services and Symfony integration.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Site search scope on Kunstmaan CMS: This bundle is thin glue between KunstmaanSearchBundle and KunstmaanNodeBundle — it indexes and searches Nodes specifically. That makes it a candidate only when the product decision is "search our CMS content pages," not "search our catalog, docs, or user-generated content."
  • Build vs. buy for search: A 2014-era, 8-star bundle with zero dependents is a useful data point in the build/buy/borrow calculation. It tells you the DIY-and-own-it path was already taken by the Kunstmaan community and then abandoned — which pushes the decision toward a maintained engine (Elastic/OpenSearch, Meilisearch, Algolia, Typesense) with your own node indexer on top.
  • Legacy estate triage and modernization roadmap: If this shows up in a dependency audit, it is a signal that the surrounding app is Symfony 2.x-era and frozen. That should trigger a roadmap conversation about CMS/stack modernization, not a search feature conversation.
  • Platform-fit correction: The brief describes this as a Laravel/PHP package. It is a Symfony bundle, not Laravel. A PM should use this to correct scope early and avoid budgeting Laravel-side integration work that doesn't exist (illuminate/* support, service providers, facades — none of it).
  • Vendor/licensing risk tracking: The license reads NOASSERTION. That is unresolved IP provenance, which is a gating decision for commercial distribution or any acquisition diligence.
  • Deprecation and support-cost modelling: Last release 2014-04-05 means no security patches, no PHP 8 support, and no compatibility with current Elasticsearch clients. The PM decision is "cost of ownership if we fork" vs. "cost of replacement."

When to Consider This Package

Consider it only if all of the following hold:

  • You are already running KunstmaanNodeBundle on a Symfony 2.x application and cannot change that in the current cycle.
  • You need node-scoped search (title/body/facets over CMS pages) as an internal or low-traffic feature, fast.
  • The app is in maintenance mode with a defined sunset date, and you accept that you will own the code.
  • Legal has manually cleared the license and the transitive dependency tree.
  • You are prepared to fork and pin it, including any Elasticsearch client compatibility shims.

Look elsewhere — decisively — if any of these are true:

  • The target app is Laravel. Wrong ecosystem entirely; there is no integration path here.
  • You are on Symfony 5/6/7 or PHP 8+. The bundle predates them by a decade.
  • Search is customer-facing, revenue-adjacent, or has an availability or relevance SLA.
  • You need modern Elasticsearch/OpenSearch versions, vector or semantic search, synonyms, typo tolerance, or analytics on search queries.
  • You need a supported vendor, CVE response, or a maintainer you can escalate to. There is no maintainer.
  • You are doing a greenfield build. Start with a maintained search service and write a small, well-tested indexer for your node/content model — that is roughly the same amount of work as integrating this, minus the archaeology.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency and I do not recommend adopting it for new work. It is an abandoned 2014 Symfony bundle with no downstream users, no maintainer, and an unclear license. Its only legitimate use is as a short-lived stopgap inside an existing Kunstmaan CMS installation that is already scheduled for replacement. The real decision it surfaces is a roadmap question: our search capability should sit on a maintained engine we control, with a small in-house integration layer, rather than on a dormant third-party bundle. Recommend we fund a modest search modernization line item and treat this package as a signal of legacy debt, not a solution.

To engineering: Treat it as reference code, not a dependency. It shows how Kunstmaan wired node indexing into its search abstraction — useful reading if you are migrating that content model off the CMS. If a team genuinely must ship search on the legacy Symfony 2 app this quarter, fork it, pin the commit, vendor the license review, and log a removal ticket with the sunset date on day one. Do not add it to a new project, and do not present it as a Laravel option — it isn't one.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
cgv/localized-resource