Lack of interest Move image size maps from containers to options

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

digitalpoint

Well-known member
There are a few containers that are nothing but hardcoded image resizing settings. Specifically these:
PHP:
$container['avatarSizeMap'] = [
   'o' => 384,
   'h' => 384,
   'l' => 192,
   'm' => 96,
   's' => 48
];

$container['editorToolbarSizes'] = [
   'SM' => 420,
   'MD' => 575,
   'LG' => 900
];

$container['profileBannerSizeMap'] = [
   'l' => 1280,
   'm' => 640
];

The profile banner size isn't large enough to take advantage of high dpi monitors/screens, so I wanted to change it. Being that these containers don't have any code, and are just settings, wouldn't it be more appropriate for them to exist as Options?

Not super excited about needing to create a class/more PHP files that need to be included with every request to alter a container for what is essentially changing an image size setting.

Seeing that avatar and profile banners default sizes are evenly divisible, maybe it would make sense to leave the container, which simply does the size calculations based on a new "max size" setting for each. That also would maintain backward compatibility for those that have overridden the containers already.
 
Upvote 1
This suggestion has been closed. Votes are no longer accepted.
If it was for a distributable add-on then, sure, you'd have to add a code event listener and a new function. That doesn't seem like a onerous task though.

If it's for personal customisations on your site(s) then you can change it easily with src/config.php.

Via extend:

PHP:
$c->extend('profileBannerSizeMap', function(array $map)
{
    $map['h'] = 2560;
    return $map;
});

Or just replace the map:

PHP:
$c['profileBannerSizeMap'] = [
   'h' => 2560,
   'l' => 1280,
   'm' => 640
];

EDIT: I suppose for your case you'd just be changing the existing values rather than adding a new one
 
Last edited:
Ya... it's not that it's difficult. It's all of about 2 minutes of work to do it via the event listener. However when you start getting into the realm of changing a ton of little things like that, all of a sudden you have 100+ listeners that are firing on every page request for all sorts of different things. Just seemed to me that with those particular containers essentially being hardcoded size settings, that it would be more appropriate for them to be options.

That being said, in this particular case, it's not for an addon that would get distributed beyond a couple of my own sites. So the override in the config works (I forgot that was an thing... hey, I've been up since 6am and I'm still groggy). haha I still think it's better served as an option though. :)
 
Top Bottom