By default Strapi image size optimization (without quality loss) has a bounch of default sizes but without any posibility for admins to set their own preferred sizes in admin panel. Of course, in fontend we can display them in any size we want, but if we have pages loading hundreds of images in a grid the render will spend pretty much extra time to scale them properly.
I consider the above mentioned option a nice to have one.
Yeah, that would be a nice to have feature in Settings. The default sizes can be modified here, by using extensions:
I know, but I try to avoid customization for a while, at least until Strapi becomes more stable, for now is like quicksand.
You can now override the breakpoints with the plugins.upload.breakpoints configuration setting.
You can now define the breakpoints without extensions.
config/plugins.js:
module.exports = {
upload: {
breakpoints: {
xlarge: 1920,
large: 1000,
medium: 750,
small: 500,
xsmall: 64
}
}
}
Thank you both for the info. So, by doing this will I be able to export the settings so that I can import them later?
What do you mean? Breakpoints are defined in your code and are not stored in DB, so there is no need for export/import.
Well, when Strapi makes a new release sometime it breaks the existing setup, leaving you with the only choice to do a fresh install. At that point I can’t remember my customizations… Think that I’m working with multiple projects, various languages, simply I just can’t fill my memory with Strapi customizations…
This is not how it should work. Have you always followed the migration guides?
I’m using strapi since beta, and since then I was able to upgrade it to all new releases, without breaking anything.
Yeah! That’s exactly what terrifies me! Do you have the impression that I have no other occupation than to migrate Strapi installations from month to month?
Imagine a router. What if someone accidentally pressed the reset button and all the settings disappeared and you had to enter them manually again? I’m telling you, you’re going to pull your hair out. Fortunately there is a button, export settings, and when the lightning strikes you import again and continue your work!
So what I need is set and forget!
Well, strapi had only 6 migrations that contained migration guides in ONE year. As I remember none of them took me more than 5 minutes. And most of them were required ONLY if you extended users-permissions model, admin configs, and so on. There were no Breaking changes that could break your apps. I also have apps that I didn’t upgraded since beta, because I don’t need that as it does the job what I’m expecting it to do.
I have more than 15 strapi apps that are running for months without any errors and I always upgrade their strapi version over time and it doesn’t take more than 30minutes to update ALL of them.
I can’t understand right now what you are doing wrong, but you are definitely doing something wrong. What settings, what customizations? 
Do you mean Admin UI customizations? LIke labels? Default sorts, and so on?
That’s exactly how it works…
Well, you can do this in 30 minutes since you are working with Strapi all the time, for other users it will not be so simple!
I can’t do something wrong because I don’t do anything! I don’t use Strapi in production yet! I just do tests, follow the evolution, make additional software.
You probably imagine that I have Strapi installations that I keep migrating … I said a long time ago that I don’t do this, it’s an unacceptable way of working for me, I don’t even think of doing such a thing. Even the idea that there is migration for a software file makes me shiver.
I just do fresh Strapi installations, I connect them to the previous database and when I find that it doesn’t work anymore I tell myself that Strapi is not yet a usable application for me!
Ok, I’m a full stack javascript developer, I can do whatever I want. But think of me as a regular user who doesn’t even know what javascript is. Think of me as a wordpress user. Can you imagine a wordpress with migration guides? It would instantly lose millions of users!
For this reason they have tools:
This is a part you both missed in my initial question …
As a developer, if I want to customize something, I write a PR, but as a user I have the following principle: If it’s not in the admin panel … it doesn’t exist!
Can you imagine what it would be like for wordpress to make guides that teach the user how and what files to edit?
Haven’t you learned anything from the questions you receive here on the forum? Don’t you see that the people who end up confused here seem to have fallen from another planet? Do you think it’s a good solution not to answer their questions?
The reason this is happening is your level of expectation from them. What I know for sure is that the vast majority of them have not scheduled enough time to get a PhD in Strapi!
Let me put it another way: I might want to give someone permission to adjust those settings, but maybe I wouldn’t want to grant access to files! As it is now, if I use an editor he wouldn’t even know what the values are, he would ask me and I would either have to waste time looking for the settings or having him study the Strapi documentation.
The admin panel sais only:
It automatically generates multiple formats (large, medium, small) of the uploaded asset
So, IMHO Strapi must separate these two concerns: the development of the Strapi project and the use of Strapi by using the following principle:
So-called “customization” by modifying files must disappear, and even if something can be customized that something must be able to be done also through the admin panel.
I hope the plugin API isn’t just an extension of the same old way of doing things…
Hi @SorinGFS ,
I can understand your concern about the migration and how difficult it’s to migrate from a version to another and I can tell you it’s pretty easy since Strapi publish migration guide for features which have breaking change.
For the second part, I’m not really ok with you when you say that “if it’s not in the admin panel… it doesn’t exit” because Strapi is a CMS and like wordpress if you want to configure some plugins, features or add custom features you have to change it in the configurations files.
Per example we can take the database configuration, it have to be in configuration file because it’s what will make it work.
So if we keep this vision, we can apply it to the media plugins and especially for the breakpoints.
The goal of the breakpoints feature (for my point of view) is to allow you to set up multiple responsive breakpoints for the image that you’ll upload and allow you to use them efficiently on your front end.
So with this goal we can conclude that the breakpoints configuration must be set once and after follow the frontend change (If you decide to change some breakpoints on your front end because you don’t want the same display then you’ll have to do the modification on the Strapi breakpoints configuration).
I hope I’ve been clear enough and that just because there is an administration panel doesn’t mean everything has to revolve around it. You just have to distinguish customization from configuration which are not the same thing and do not have the same demands
In wordpress if you want a plugin you hit add new plugin, plugin installs into plugins folder, then activate, then instantly you have access to that plugin’s settings by edit settings. As a wordpress editor you may never see the files!
Moreover, “customizing” a wordpress plugin is a realy bad idea! On that point you transform yourself into a slave, since the plugin author will update the plugin and you have to “migrate” your “customization” through versions, and there are thousands of plugins out there! So, every time you need a “customization” ask the plugin author to do it!
Understandable 
For me, I try to not compare Strapi & Wordpress since Strapi is an Headless CMS & not Wordpress.
They have many similarity but also many difference and that’s why Strapi is not a Clone of Wordpress and from my point of view, I think Strapi should stay their particularities 
it is about processes that wordpress has developed for a long time and which are already well settled. I’ve seen enough who tried to reinvent the wheel but it wasn’t good for them