- Does wxiangqian/laravel-dingtalk work with Laravel 9, 10 or 11?
- It was built for Laravel 5.5, so its illuminate/support constraint will almost certainly block installs on Laravel 9, 10 and 11. Do a Composer constraint solve against your target Laravel and PHP versions before you plan anything around it. If you are on a modern stack, treat the package as a reference implementation for payload shapes and config schema rather than a dependency.
- How do I install wxiangqian/laravel-dingtalk with Composer?
- Install is a conventional composer require wxiangqian/laravel-dingtalk with package auto-discovery, so the service provider and facade alias register themselves. You then publish the config file and fill in your DingTalk webhook URLs or credentials. Verify the facade alias does not collide with anything already registered in your app, and confirm config caching works after you run config:cache.
- How do I configure and select between multiple DingTalk groups?
- The multiple-groups claim implies a config map of named webhooks, with a selector to pick one at runtime. Register each group under a key in the published config and resolve the key before dispatch rather than hard-coding URLs in code. Because the selector is the only non-trivial design surface in this thin wrapper, read the source to confirm exactly how keys are resolved and whether a default group is assumed.
- Does this package support DingTalk robot signing with HMAC-SHA256?
- A package from the Laravel 5.5 era may only support bare access_token webhooks, which fails a hardened security posture. Modern DingTalk robots require one of keyword matching, an IP allowlist, or HMAC-SHA256 signing with a timestamp plus secret, base64 encoding and URL encoding. Check the source and test against a real robot before relying on it; if signing is missing you will need to add it yourself.
- Which DingTalk message types can I send with this package?
- DingTalk robots accept text, link, markdown, actionCard and feedCard payloads, typically exposed here as message-type helpers. Verify each type individually against a live robot, since helper coverage in a 2017-era wrapper is often partial. If a type is missing you can still build the raw payload array and post it through the same client.
- Why does my DingTalk robot message fail silently even though the HTTP request returned 200?
- DingTalk returns HTTP 200 with a non-zero errcode in the body when it rejects a message, so a naive wrapper reports success on failures. Confirm the package inspects errcode and errmsg and throws or logs accordingly. If it does not, add your own validation layer before you put this on any alerting path.
- Does laravel-dingtalk respect DingTalk's rate limit of 20 messages per minute?
- DingTalk enforces roughly 20 messages per minute per robot, and this package has no rate-limit awareness or queue integration. Wrap sends in a queued job with a rate limiter, especially for fan-out to many groups or high-volume alerting. Dispatch is likely synchronous, so queuing also protects your request latency.
- Is wxiangqian/laravel-dingtalk still maintained and safe for production use?
- It has around 18 stars, a low health score and a single maintainer, which points to a dormant project with no CI, tests or semver discipline. Assume your team owns the code from day one, either through a pinned fork or an internal reimplementation. Verify the license before forking and put a named owner on any production use.
- What are the alternatives to using laravel-dingtalk on a modern Laravel app?
- The pragmatic option is to define an internal contract such as DingTalkNotifier with toGroup(string $key)->send(Message $msg) and keep the integration behind it. You can then either wrap the package where the framework version permits or reimplement the roughly 200 lines using Laravel's HTTP client with signing, errcode checking and queue dispatch. A competent PHP engineer can reproduce it in one to two days, which keeps the choice reversible.
- How do I test DingTalk notifications in a Laravel app without hitting the real API?
- Fake the underlying HTTP client with Http::fake and assert the outgoing payload for each message type, then contract-test your notifier interface rather than the package internals. Keep one sandbox test against a real DingTalk group to confirm signing and errcode handling behave as expected. Also test the queued path with Queue::fake so rate-limited dispatch is covered.