Php Minecraft Query Laravel Package

Product Decisions This Supports

This package is the server-query layer for any product surface that needs live Minecraft server data: status widgets ("online / 47 players / MOTD"), server list and vote sites, uptime and player-count analytics, moderation tooling that flags servers returning spoofed or malformed responses, and onboarding flows that verify a customer actually controls the server they're claiming. The 5.0.0 release touches all three of the decisions a PM actually owns here:

• Build vs. buy on protocol speak. The Minecraft Server List Ping and Query protocols are undocumented-in-practice, versioned informally by Mojang, and drift between vanilla, Paper, Spigot, and proxy layers (BungeeCord, Velocity). This release moves handshake + status ping into MinecraftPing::Query and sets protocol to -1, which is the "I don't know / latest" sentinel. That is the package absorbing protocol churn on our behalf — a concrete argument against writing and maintaining our own socket code.
• Internationalization as a launch gate. Decoding strings from ISO-8859-1 in MinecraftQuery fixes MOTD, plugin list, and map-name garbling for non-ASCII server names. If our roadmap includes EU/LATAM/APAC server communities — or any customer-facing rendering of a server's own MOTD — this converts a "known cosmetic bug, won't fix" into shipped quality. That is a user-visible win attributable to a dependency upgrade, which is cheap roadmap credit.
• Platform support floor. The PHP 8.0 minimum is the one decision that needs a PM in the room. It is not a feature; it is a constraint that propagates. If any deploy target, customer-hosted install, or long-lived LTS branch is still on PHP 7.4, this upgrade is blocked until that is retired — and that retirement becomes a roadmap item with a date, not an engineering preference.
• Deprecation-free but behavior-changing. Nothing is marked deprecated, but "send handshake followed by status ping" and the protocol change alter wire behavior. That means the risk is not in the API surface our code calls — it's in whether responses still parse against the specific server software our customers run. Decide up front whether we validate against a matrix or trust the package.

When to Consider This Package

Adopt, or upgrade to 5.0.0, when:

• The product needs both status ping (lightweight, MOTD/player count/favicon) and full Query (plugin list, map, structured player sample). If we only ever need "is it up," a plain TCP connect plus the ping path is enough and a full dependency is overkill.
• We are already on PHP 8.0+ across every deployment target, including customer-self-hosted and any container images we no longer think about. Verify this before committing; it is the single most likely blocker.
• We can run a regression check against real servers — at minimum vanilla latest, Paper latest, and one proxy setup. The protocol -1 sentinel and the new handshake sequence should be confirmed against each, because "improved types" and a new packet order are exactly the kind of change that passes unit tests and fails in production.
• Our use case tolerates unauthenticated UDP/TCP queries — no auth, no rate-limit handling, no caching layer. If we're polling thousands of servers, we need our own queueing, backoff, and cache in front of this, and the package is only the last mile.

Look elsewhere when:

• We need Bedrock (RakNet/Unconnected Ping) — a different protocol entirely, and this package won't cover it.
• We need the RCON write path — issuing commands, whitelisting players, restarting servers. That is a separate protocol with separate security weight.
• We're on PHP 7.4 with no retirement date. Pin to the 4.x line, file a ticket for the PHP upgrade, and revisit — do not fork.
• We need formal protocol-version negotiation across the full historical version range. The -1 behavior is a compatibility convenience, not a guarantee; if we promise per-version accuracy in the UI, we need our own version table.

How to Pitch It (Stakeholders)

To executives: This is a routine major-version upgrade to a small, narrowly-scoped dependency that powers everything we show about a Minecraft server's live state. Two things matter. First, it makes our server pages correct for non-English servers — MOTDs and plugin names stop rendering as garbage, which is a visible bug fix in front of international customers, delivered by a version bump rather than a sprint. Second, it raises our PHP floor to 8.0. That's a real cost, but it's a cost we owe anyway: PHP 7.4 is end-of-life and unsupported, so this upgrade forces a security hygiene conversation we've been deferring. My recommendation is to approve the upgrade contingent on engineering confirming no customer-facing deployment is still on 7.4; if one is, we sequence the PHP retirement first and take this immediately after. Either way, we should not invest in our own Minecraft protocol implementation — this release is a good illustration of how much unwritten, community-specific protocol knowledge that would put on our plate.

To engineering: Version 5.0.0 is a major bump with no formal deprecations but several behavior changes, so treat it as a real integration, not a composer update. Concretely: it moves the handshake and status ping sequence into MinecraftPing::Query and pins protocol to -1; it changes string decoding to ISO-8859-1 in MinecraftQuery; and it tightens types. The types and charset changes should be safe or beneficial, but the packet-order and protocol changes are wire-level and need validation against the actual server software our users run — not mocks. I want a short verification note covering at least vanilla latest, Paper latest, and one BungeeCord/Velocity setup, plus confirmation that our PHP baseline is 8.0 everywhere including self-hosted installs. Also please check whether the tightened types break any array shapes we've been passing around loosely — that's the most likely source of a quiet regression in our own code, not the package's.