Though I love the 4.x concept - the lack of database backing and views integration does really hurt. Are does things within reach?
@mornel
Small suggestion: it would be nice to have a class on the current day. Cheers!
see ✨ Add weekday classes and week numbers Fixed . Would love some reviews 🙏.
@matthieuscarset your commit 46ed0545 actually breaks (forward) week navigation starting from the "current" week (I have weeks starting with Monday). With commit 46ed0545 included, all future weeks are off by one week.
I'm a bit at a loss here. using the latest dev the issue is still present - but the patch from MR 12 does not apply (I guess as it is already been merged?).
+1 for the MR 5.
Been using this for a while know. Works good for us.
My job as maintainer is to balance the needs of the whole community. What's "hard to use" for one case might be helping another developer from making a mistake.
I agree on that. Than again being able to call Drupal\symfony_mailer\Email::setTransportDs without safeguard about it being replaced was what triggered me writing this patch in first place. So in a sense, we already are in the situation your described and as an active community member I do also seek to improve modules for everyone.
If you are programmatically setting email fields, then the recommended way is within an EmailBuilder
Good to know. What I did after poking around for a bit was to take a look at what the test-form does and create an new email object by calling Drupal\symfony_mailer\EmailFactoryInterface::newTypedEmail. I do still think that this should be the way to go as it is actually very transparent and would give module developers a very nice interface to work with emails (especially in comparison to the standard drupal way of handling mails).
a Drupal user, even a full admin, gaining ability through the GUI to run an arbitrary system (shell) command with privilege of the web user
full ack again. however I do fail to see this being possible due to the suggested changes: sender and dsn not being overridden.
Interesting idea, thank you for suggesting it. We'd need to figure out how to treat a DSN as trusted if generated from code.
In case I managed to introduce ambiguity: All used DSN are added through the symfony_mailer form and are only referenced by users. I did not create an extra place of DSN origin nor do I have the feeling that "bring you own DSN" would be a good thing. I'm merely selecting the DSN by the user who initiated the mail creation.
ps.: thanks for taking your time. hope we find a nice solution.
thank for the input.
Our workflow is a bit more complicated and involves the usage of queues.
- User entities have a reference to trasnsportDsn
- Users can create specific content (that in turn will trigger sending emails)
- A cronjob gathers all pending mail content entities and prepares them for delivery by gathering the trasnsportDsn referenced in the entity-creator (user) and passes information on to a queue
- Dedicated queue creates emails with gathered information and sends the mails off
I don't see the benefit in making the Email interface extra hard to use programmatically and enforcing the GUI.
As for your concern regarding arbitrary / rouge transportDsn: What if instead we would add a check into the Email object making sure the given transportDsn is a valid (existing) one? (though I do have to admit that if someone already has his hands in at that level - being able to execute / manipulate php - I don't see the bonus of this extra added security.
ok. should I rework this patch to always check for existing values or should I try to contribute to ✨ Enhancements to builder and adjuster annotations Fixed instead?
In our use case, we would like to be able to output all referenced media entities as a list of file links (uniformly). This currently isn't possible.
+1
#78 + views_ajax_history → = this is the way 💪