Requested in Slack @ https://drupal.slack.com/archives/C1BMUQ9U6/p1737427230495489
Thanks @avpaderno, does that mean you've contacted them directly?
Transferring as plenty of time and notice has passed.
Intent to fully take over and remove existing maintainers as there is no lineage from the old project at all.
Hoping to revisit this with D11 upgrades, but that could end up being any time this year.
Could we get a new @beta release including this one <3
Supporting @smustgrave request as he's a active, proven, competent, member of the community.
Checked the linting issues, you can ignore.
Feedback already there.
Does this work for 11.0 also? If not, might need to make the to-be-changed-to-autowired service arg optional (make nullable) and call function if service not injected. e.g $this->hookservice?->method() ?? \call_old_function();
Thanks, I can see weekly test runs are failing since core 11.1.
If you can get the tests passing again, that would satisfy this issue.
Might be a dupe of ✨ Phone number verification event dispatcher RTBC
The typical 2 week period has passed, though I'll grant extra time due to this special time period.
Thanks @gbyte, @walkingdexter, I'd accept high-level/architectural review over macro/technical review.
However, pinging with a query anytime the client collection is fetched means a lot of db roundtrips, and as such kill performance - if I am not mistaken, getClientConnection() is called anytime a transaction is opened. BTW, that would also mean that non-transactional statement executions will not be covered.
As the code is written right now, this is not correct. ->ping() is called in ->getClientConnection(), but since ->connection is always a PDO, it exits. It would only continue if the PDO object in ->connection was set to null by an explicit call to ->close().
The behavior is not wrapping every call in a safety net. If the connection was lost, and ping was not called by userland code, then indeed the app would crash. Encapulating all database calls would be quite a scope increase, and fwiw is not the behavior of Symfony+Doctrine+Messenger.
Another aspect to take care of is understanding the implications of a reconnect occurring while a db transaction is open - is the db transaction rolled back, how will the db failure reflect in the transaction manager, etc.
I'm not sure about this one.
Seems to me this is likely outdated, given version and time since last comment.
This isnt just a Gin problem, we can de-escalate, but it still seems necessary to adhere to standards.
I sent this to dbehrman today.
bdlangton has a disabled contact form.
Both users are not active in the community, so I expect this request to elapse and move into the site mainainers queue.
Hi, Barrett Langton (bdlangton) and Daniel Behrman (dbehrman),
I'm looking to take over the Notifier (notifier) namespace in order to implement Symfony Notifier functionality for Drupal.
https://www.drupal.org/project/notifier/issues/3494214 🌱 Taking over the Notifier namespace (attn: bdlangton, dbehrman) Active
I understand you may not be interested in the Drupal community any longer, for which you may choose to reply or disregard
Brought up at #3301682-21: Define bundle classes via attributes →
The discovery should probably make sure that it's not possible to register multiple classes for the same bundle. Can also happen with the alter hook, where it's much harder to detect, but at least here we could?
What about subclasses? Lets say a contrib module defines a node type and adds a bundle class for it. In a custom project you want to subclass and change that. I guess you still have the option to use the alter hook then and set it there.
Maybe you'd be interested in reviewing ✨ Add logic to determine which bundle class should take effect when multiple classes extend the same bundle Active and associated PR.
dpi → created an issue. See original summary → .
Inspired by ✨ Use attributes for DateRecurInterpreter plugin discovery Active
'source time zone' should already be UTC, how is this any different.
Your patch hard codes fields names, doesnt make much sense to me.
@socialnicheguru current plan is for sec-only. No other support. #3325334-6: Stan linting: return types, parameters, modern services, etc. →
Track was removed.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Drupal 7 version is not supported.
Replaced by 📌 Stan linting: return types, parameters, modern services, etc. Active
Most breaks from 📌 Stan linting: return types, parameters, modern services, etc. Active
Already a thing.
3.x WIP Changelog.
This is a major change.
You should update your Composer contraints to include `drupal/sms: ^3`. As usual, Composer is a requirement.
Most direct customisations to SMS Framework will need evaluation.
There is simply too many changes to list. To test compatibility, simply running PHPStan or PHPCS or running the code should make it obvious what needs to be changed, by way of exceptions, fatal PHP errors.
Third party gateways will likely need minor updates to their classes themselves. While data being passed into SMS Message objects or events should be checked for type strictness.
When passing data into SMS Framework, make sure data is exactly the right type. E.g a string-int like `$i = '1';` is not valid, compared to a true int, like `$i = 1;`
Some classes, such as services, have been final-ized. Customisations to these classes will need to be revalulated. E.g services should be modified with service decorators, and inject new dependencies using setters. Rather than direct class inheritance (extends).
If you notice discrepencies between what is documented and what is typed, please post a new support issue.
The support status is as follows. 2.x branch is now end of life, it will only receive security changes. 3.x will receive feature, bugs, and security fixes.
The 3.x roadmap continues as follows: the project intends to update to PHPStan level 9, and PHPStan Strict. This comment services as notice that API contracts may change without notice, in order to achieve this goal.
The upcoming 4.x roadmap intends to replace and gut most code, and replace with the Symfony Notifier/Texter ( #3262737: Add a first class implementation of Symfony notifier / Texter → ) systems, the impact of this includes:
- Many custom gateway plugin projects will not be necessary, as they are provided by SMS Framework itself, by way of Symfony. See list of gateway services provided by Symfony.
- Most core SMS services will exist in one way or another, with equivalents.
- Some of SMS User will be kept — Equivalent functionality should be implemented in contrib.
- SMS Blast will be removed — Equivalent functionality should be implemented in contrib.
- SMS Devel will be removed
- SMS Sendtophone will be removed.
- Migrations will be removed.
- SMS message classes will be removed in favor of Symfony equivalents.
- SMS entity will be removed — Equivalent record keeping functionality should be implemented in contrib.
- The queue worker will be removed.
- Persistence and queue workers are already supported by Symfony Messenger → , and we'll make sure SMS Framework works with that out of the box.
- "Incoming" route and processing yet to be evaluated.
There is nothing useful here.
Co-incidentally working on CI, linting and static analysis for SMS Framework. And I watch this queue. So jumping in for a moment since these are easy fixes.
You might be interested in updating to a tougher PHPStan config, or using https://github.com/previousnext/coding-standard, in another issue.
New MR, doesnt use any prior patches or MR.
2.3.0 and 2.4.0 published, including these changes.
Not yet, release management not complete.