I've just added a unit test in the Composer Resolver Cloud to test
path repositories with
./ relative paths. They passed without changes so I think this might be an issue in the Manager indeed.
OptIn class also has an interface. This one's even tighter coupled to the implementation. It forces a subject and a text which is also tied to an e-mail. So I'll probably have to find a way to not use the opt in service at all. Which is a pity because it was probably meant to be decorated 🙈
Also, the context would need to be added to
find() as well as
send(). E.g. for
send() one does not get the raw data (tokens) but only the text and subject which are already parsed :/
We have an interface, we can't add that.
I see. You're the author of this service, what were the design decisions then?
My goal is to adjust the
$token->send() process but only, if it was enabled in a given FE module. That's basically the thing I'm trying to do here. Any ideas?
I agree, I would go as far as throwing an exception if the template loader detects identical templates with different extensions. I don't think this should be a supported use case. The reason for it being exactly that in the dropdowns we never show extensions.
As I said, adjust the extension to not use the
contao_backend session bag but your own session key and everything is solved.
We have an
OptInInterface as well as an
OptInTokenInterface which allows me to decorate the opt in logic. This is a great helper for me while working on Notification Center 2.0.
However, I currently have no way to find out where that token is coming from. It could've been any module ID. I need to know which one in order to be able to only apply my logic in case of the correct module ID.
Basically, the whole decoration logic is ueseless if one cannot distinguish where the token is coming from so I consider this a bug.
Can anybody else test those changes too, please?
Sure, go ahead. But until we have a real use case here, I don't think we should change this. It can be easily done in your local application to work around it in the meantime.
Do you know what
CURRENT_CE_TABLE is supposed to contain? But it looks like it's trying to remember something in order to display certain settings. I don't think these should be persisted longer than the regular session.
Contao only stores what was added to the
contao_backend session bag (https://github.com/contao/contao/blob/5.x/core-bundle/src/EventListener/UserSessionListener.php) which whould only be done for things that need to be remembered even after logging out (such as e.g. backend navigation toggle states etc.).
I would like to know what this thing is trying to store into the session so that 65kb are not enough. Can you maybe try to find out what this is? If there's a valid use case for storing more than 65kb in the back end user session field (which should only contain stuff that has to be stored in the database = remembered when you log in e.g. in a month), then we might consider it. But I haven't encountered such a use case in so many years yet :-)