Allow to easily change the color scheme of the backend about easyadminbundle HOT 9 CLOSED

What about providing the skeleton of the CSS file as a Twig template and then compile it with a console command to the final CSS file?

from easyadminbundle.

Or else, if you use the bundle inheritence system, you could also use blocks in twig, in order to add/change some elements. I'm thinking about banners, brand pictures or footer, or even changing the Icon's user with a gravatar one, etc.

All of these could be in classic twig blocks, or even variables (but maybe less "clean") , so in your inheritence system you can have a "layout" twig template that extends a "design" template (or vice-versa) , the last extending EasyAdmin base layout.

I hope I'm not too confusing 😝

EDIT : As an addition, why don't use a simple easy_admin: { layout: AppBundle::admin_layout.html.twig } structure, and provide the skeleton in the documentation, to help people position the twig blocks whereever they want ? They could then use their own javascripts, css, etc. ?

from easyadminbundle.

I still don't know how to solve this problem, because I'm against using Assetic or frontend-stuff tools. Right now, the best solution I've come up is to replace the static admin.css file by a admin.css.twig template and render it using the admin controller:

/* Original CSS code */
span.badge {
    background-color: #D47843;
}

{# New template code #}
span.badge {
    background-color: {{ main_color|default('#D47843') }};
}

The advantage is that the user can customize an entire backed just by defining some options in the config.yml file. No asset compiling or installing, changes are applied instantly, almost zero effort by the user:

easy_admin:
    color_scheme: { main_color: '#CC1414', ... }

The performance hit should be minimal because even if the template is long, its logic is trivial.

What do you think about this idea? If you think it's stupid, you can freely say so :)

from easyadminbundle.

If you only want to change the color scheme, then this method is probably the best, for sure.
But there's no need to make the AdminController heavier than it is, just create an "AssetsController" to handle these routes 😆

The color scheme does need some documentation, by the way

from easyadminbundle.

I'm coming back in this issue:

Why don't you set all the colors directly in the css files, and then if there are some overrides in the color scheme, add them in a <style> tag in the head?

I mean, for example, you keep your badge colors in the css at first.

Next, if the user sets the badge_color under the color_scheme param, then you just add it in the view like this:

<style type="text/css">
{% if config.color.scheme.badge_color %}
    span.badge { background-color: {{ config.color.scheme.badge_color }}; }
{% endif %}
</style>

I know it sounds heavy in terms of code, but it's slightly lighter than creating a new controller...

from easyadminbundle.

@Pierstoval thanks for your proposal. It's true that it looks simple ... but I think it would be more complex that it looks at first. Why? To ensure visual integrity, the default theme will only allow to define a small amount of colors (ideally 1, the main color; but probably 4 or 5 to also style the sidebar, etc.)

This means that a lot of different elements (with very long CSS selectors) will use the same color and we would have to extract+copy+paste 20 or more lines to change one color. I'm not rejecting your proposal yet, but I have to think more about the pros and cons of each proposal.

from easyadminbundle.

I asked my team about this issue, and in fact, both developers and html/css integrators agree with the fact that the assets override feature you already implemented is really sufficient, because you can inject a single css file to completely change the backend look. The other lead-dev also added that any developer using EasyAdmin knows how to inject css and how to change the back-end look, whether he knows the best practices or not. He'll simply search for the css selectors with "firebug-like" tool to override it in his own, and if he doesn't, a front-end specialist will do it.

I think that some code lines in the design section in the docs might be enough to give the developer the css selector he needs, but IMO and in my colleagues' opinion, what EasyAdmin already provides is really enough.

Hope it might help ;)

from easyadminbundle.

May I come back on this issue for more discussion ?

I've been looking at what is possible to ensure layout customization is easy.

And what I saw when talking about colleagues about customizing EasyAdmin's backend is simple : layout override.
The layout override is the most used way of changing the design, and right now we don't have the possibility to do this.

I've been thinking about adding a new template layer to our layout, just by using the twig blocks system.
How to do it ?

Every view extends the logical_layout, in which we have all must-have elements in the admin layout (such as navbars, assets). This logical_layout extends a skeleton_layout, in which we ONLY have the html "top-frame" code, and all the blocks names we want to use and that will be filled by the logical_layout.

Then, we use a simple request listener like the one on Orbitale CmsBundle : we inject the layout configuration (parsed with the Configuration and Extension classes), and the logical_layout extends this configured layout, still like in Orbitale CmsBundle's views, but in EasyAdmin we put this dynamic extension inside the logical_layout in order to show the navs and assets we need.

Then, a simple documentation chapter might tell the developer how to customize his back-end, and the advantage we have is that the proposed default layout will be so much a skeleton that the developer will only have to copy/paste it inside his own layout.

I start to think that back-end design shouldn't be changeable in configuration, but instead should be configurable directly inside a twig template, even if this one only contains variables setters like classes and colors by using Twig blocks.

What do you think about this?

from easyadminbundle.

Closing it because it's superseded by #208

from easyadminbundle.