- How do I install phrity/websocket in a Laravel project?
- Install it with composer require phrity/websocket. It is a framework-agnostic PHP library, so no Laravel service provider ships with it; bind WebSocket\Client or WebSocket\Server into the container yourself, or write one small provider that reads config/websockets.php. Pin the constraint deliberately: ^4.0 only after migration, or ~3.8 / ^3.7 while you are still on the 3.x line. Do not use a floating constraint that spans the 3 to 4 boundary.
- Does phrity/websocket support Laravel 10 and Laravel 11?
- The library is PHP-native and fits Laravel's event-driven and dependency-injection patterns, so it works alongside Laravel 10 and later. The 3.x line was documented at PHP 8.5+ and Laravel 10+, but v4's minimum PHP version is not stated in its release notes, so confirm it from composer.json before assuming it is unchanged. Also verify the resolved constraints against your laravel/framework release, because v4 adds a direct nyholm/psr7 dependency.
- How do I create a WebSocket client in Laravel with phrity/websocket?
- Create one with new WebSocket\Client('wss://example.com/') and add the middlewares you need, such as CloseHandler and PingResponder. For request/response work you send with text() and read the reply; for continuous subscription you register onText() callbacks and call start(). In Laravel, keep long-running clients inside queued jobs or dedicated workers rather than in a normal request cycle.
- How do I run a multi-connection WebSocket server in Laravel?
- Use WebSocket\Server with listener callbacks such as onText(), which map cleanly onto Laravel events and listeners. Enumerate connections through getConnections(), which in v4 returns a Connections collection rather than a plain array. Run the server as a long-lived process, for example a supervised artisan command or a queue worker, never inside a standard HTTP request.
- How do I handle ping/pong and closed connections with phrity/websocket?
- Add WebSocket\Middleware\CloseHandler and WebSocket\Middleware\PingResponder to the middleware chain; they handle close frames and answer pings automatically. Register your own callbacks for close and ping/pong events if you need to log them or trigger Laravel events. Without these middlewares, idle connections are more likely to be dropped by proxies or server timeouts.
- How do I enable Deflate compression and handle MessageEncodingException?
- Add WebSocket\Middleware\DeflateCompression to the middleware chain to negotiate permessage-deflate. In v4, compression failures raise MessageEncodingException instead of surfacing as a vague encoding fault, so catch it inside the middleware chain. If it escapes, it bubbles into the connection loop and can terminate a server process. If you do not use Deflate at all, this failure path is a non-event for you.
- Is phrity/websocket a drop-in replacement for textalk/websocket?
- It is the maintained successor, but not a blind swap. phrity/websocket replaces the abandoned textalk/websocket and is maintained by the same developer who looked after textalk since v1.3. The client and server APIs are similar in spirit, yet the 3.x to 4.x jump is a breaking release with a reworked exception hierarchy and changed Client/Server configuration. Follow the migration guide instead of only changing the package name.
- What are the breaking changes in phrity/websocket v4?
- v4 removes deprecated code, restructures the exception hierarchy, and changes how Client and Server are configured. It also drops internal PSR-7 stubs in favour of a direct Nyholm dependency, and getConnections() now returns a Connections collection. Catch blocks that referenced renamed exception classes will silently stop matching and let failures reach Laravel's global handler, so map the new classes into Handler::$dontReport and your alerting rules. Review every options array built in your service provider or config/websockets.php against the migration guide.
- Why does getConnections() break array functions after upgrading to v4?
- In v3 getConnections() returned an array; in v4 it returns a Connections collection. array_filter(), array_map(), count() semantics and array type hints therefore fail at runtime, not at static analysis time unless you type strictly. Iterate the collection or use its own methods, and update any code that type-hints array for a connection list.
- How do I resolve nyholm/psr7 Composer conflicts with phrity/websocket v4?
- v4 depends directly on Nyholm PSR HTTP, which may conflict with the nyholm/psr7 version pinned by your laravel/framework release. Run composer why-not nyholm/psr7 to see exactly which constraint blocks resolution before committing to v4. If it conflicts, stay on the 3.x line with a pinned constraint until the framework or package constraints align.