E9li postal3 patch #60599
E9li postal3 patch #60599
Conversation
released v7.3.0
…o-store is set (alexander-schranz) Discussion ---------- [HttpKernel] Do not superseed private cache-control when no-store is set | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | - | License | MIT I don't think its a good idea to superseed the private cache control via the new noStore option * #59301 If somebody want to set it to `private` they should explicit do it. via `#[Cache(private: true, noStore: true)]`. I would avoid this non transparent changes in general. I had usecases in the past where the response is still public for the symfony cache and varnish public and the no store was only for the third party caches and in browser caches. This specially come into play with usage of `ESI` where the general page is cached, but no-store set to not allow back forwards caches, because of the ESI content. /cc `@smnandre` Commits ------- 7e6e33e [HttpKernel] Do not superseed private cache-control when no-store is set
in postal 3 is not password, only the api key. getPassword() causes an "Password is not set" error.
postal 3 returns the message_id in the data array.
|
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
|
Hey! Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.3 for bug fixes". Cheers! Carsonbot |
when using postal 3 with api key not password is needed. currently getPassword() is used which returns of course an error. getUser() works fine. also the message_id is now nested in ['data']['message_id']. i did not use postal before version 3 so i don't know how is was before. with this two "fixes" sending work perfectly fine.