Set profilepic ImageResizeTransform maxHeight and maxWidth#5468
Set profilepic ImageResizeTransform maxHeight and maxWidth#5468valadas merged 11 commits intodnnsoftware:release/9.11.1from
Conversation
|
I am confused I thought the problem was defining the max to 10px by default, can you explain the nature of this change... |
|
If you place a break point in and walk through the code eventually that 10px will become the value used by the ImageResizeTransform class. When requests are made for images in the profilepic mode(not using a maxHeight maxWidth parms) it causes problems with the renderings. The solution in this commit is to avoid using the new hard coded 10px default and set maxHeight/maxWidth to the actual image size when those values are available and the request is a profilepic mode request. This solves the rendering problems in our test environment. There may be better approaches to solving the issue which I am glad to learn from. We can close this out once it sprouts. |
|
But does this not break it for those who do pass maxHeight and maxWidth ? |
|
Are people using the maxHeight and maxWidth params for profilepic mode? I tried a global search on DnnImageHandler and I don't think those params are ever used for making requests in profilepic mode. They are used for requests made in secure mode but not for profilepic requests. We can add an additional check for those params if you want to allow for custom maxHeight maxWidth with profilepics. |
|
I was thinking maybe to only revert this change: trilogy-group@e2c302d Unless I am wrong, people could use that API if they build a module that needs a profile picture. |
|
I believe I'm in favor with @valadas recommendation here, going back to the old behavior for size. Plus I didn't really care for 10px by 10px as the default anyway |
|
You are right someone might use the maxHeight maxWidth params for pofilepic mode requests in a module. Right on default max zero handling too. I have not tested the change you're suggesting. If it fixes the rendering without impacting the rest of the commit then it is better. I stayed inside the if check that isolated changes to profilepic requests. Setting the default to 0 potentially has broader affects. I am not sure if there was some initial need to set the 10px. If you find success with the default at 0 and no side affects then mission accomplished. Close this up. |
Inside inside EMAIL_MESSAGING_DISPATCH_BODY.Text Fixes dnnsoftware#5512
Changed 2013 to [YEAR]
Merges latest fixes from 9.11.1 rc2 into develop
…ings-Null-Checker Fix dnnsoftware#5533 - Null checker on EditorHostSetting
…al-lists Fix journal list sprocs
Added UserID to the information shown in the Users module Closes dnnsoftware#4412
…o bugfix/5291-profilepic-mode
valadas
left a comment
There was a problem hiding this comment.
Looks good to me, I prefer the fix this way...
For other reviewers, further down the code there is handling for when the max values are not set by this. So it will in this scenario be unset and work like before instead of enforcing 10x10 when not specified.
|
Also, since the change in question was done between 9.10.2 and 9.11.1, this is technically a regression bug, so I retargeted the |
mitchelsellers
left a comment
There was a problem hiding this comment.
I agree this is way better. Thank you.
Update profilepic mode renderings. Enhances fix for #5291