Admin Dark Mode

[flydev]

Just sharing an admin dark mode theme.

Still a WIP, I need to figure out how  uikit-inverse colors work and a switcher will be pushed.

(great rock job @bernhard)

 

 

Feel free to try it, submit issue or better pull-request.

https://github.com/flydev-fr/AdminStyleDark

Edited October 8, 2022 by flydev ??
new repo name

[flydev]

It take into account:

• the official ProcessPageList
• BreadcrumbDropdowns by @Robin S
• AutocompleteModuleClassName by @Robin S
• InputfieldSelectize by @Macrura
• InputfieldSimpleMDE by @Macrura

to be continued...

[bernhard]

Hey @flydev ?? great to see another admin style coming up ? 

Check out https://github.com/baumrock/AdminStyleRock/ to see how you can create a module for 1-click-install without the need to copy files!

This is all you have to add to your module: https://github.com/baumrock/AdminStyleRock/blob/30c91c9832ac8bc54fa64fbee416919824a1983d/AdminStyleRock.module.php#L35-L53

[bernhard]

Maybe we could join forces and extend my module with a simple toggle (light mode/dark mode)?

[flydev]

Yes that is what was planned, I talked about LESS mod, but I used your module in first instance and I think he will receive the PR to give the dark-mode available by default. I might be blind, but what's the difference between the LESS or Rock in the "sharing flow" ? they don't both require the admin.less files ?

 

[bernhard]

14 minutes ago, flydev ?? said:

I might be blind, but what's the difference between the LESS or Rock in the "sharing flow" ? they don't both require the admin.less files ?

Sorry I don't understand ? 

[flydev]

I said, both module require the file `admin.less` or at least the compiled `admin.css` ? 

But forgot it, my question doesn't make sense as I didn't read the point #3 on AdminStyleRock github repo ?‍♂️

It might serve as an example how to share your own styles with the community in a modular way instead of sharing admin.less files that can't be updated/monitored by the PW upgrades module.

 

Edited September 29, 2022 by flydev ??
typo

[bernhard]

32 minutes ago, flydev ?? said:

I said, both module require the file `admin.less` or at least the compiled `admin.css` ? 

Yeah that's what I tried to explain. You don't need admin.less - you only need the module that adds the custom admin style in init() or ready() ? 

Now that I'm writing I realise that one can't customize my style once the module is installed. Because it won't pick up the admin.less file as it's overwriting this setting to use the module's style. That might be an improvement ? 

[bernhard]

On 9/29/2022 at 6:05 PM, bernhard said:

Now that I'm writing I realise that one can't customize my style once the module is installed. Because it won't pick up the admin.less file as it's overwriting this setting to use the module's style. That might be an improvement ? 

I was wrong ? Simply install AdminStyleRock and get all the benefits.

And then - if you need - add /site/templates/admin.less and customise what you need ?

[flydev]

I must admit that I didn't understood this statement as it was working as expected lol

[flydev]

@bernhard could you take a look at https://github.com/flydev-fr/AdminStyleDark

Is this the right way to do it?

[bernhard]

Hey @flydev ?? no, sorry, your way of doing it is outdated ? 

Just kidding... I just created 2 PRs which make it a lot easier to create AdminStyles (because I realised that it's harder than it could/should be to create such AdminStyle modules, thx for that!):

https://github.com/ryancramerdesign/Less/pull/2

https://github.com/processwire/processwire/pull/245

And a new module that shows the new way of creating admin styles for ProcessWire ?

https://github.com/baumrock/AdminStyleHello

What do you think?

[flydev]

?  Perfect, checking it, thanks.

[flydev]

3 hours ago, bernhard said:

What do you think?

Quite easy ?

(see:  https://github.com/baumrock/AdminStyleHello/issues/1#issue-1401993078)

https://github.com/flydev-fr/AdminStyleDark/tree/dev

[bernhard]

8 minutes ago, flydev ?? said:

https://github.com/flydev-fr/AdminStyleDark/tree/dev

Looks a lot nicer and cleaner ? Thx for giving it a try!

[bernhard]

Hey @flydev ?? I see that your style has the same issues that I had to tackle when building the rock style:

First, the notices have some (in my opinion) unnecessary spacing:

Second, the content tab should not have margin-left:

I just tried and when adding this line on top of your LESS those issues (and maybe others) are gone:

@import "../../../../wire/modules/AdminTheme/AdminThemeUikit/uikit-pw/styles/rock.less";

And finally one thing that is not related to the rock style: Tooltips are not the best in terms of contrast ? 

PS: Installation worked like a charm ?

[flydev]

Nice thanks ?

[gornycreative]

This is something I recently picked back up to try to finish, it's a bit tedious depending on how many modules/features you want to cover.

I wrapped styles in a .dark style rule in my less so that I could get the added specificity I wanted rather than use !important to override. It doesn't work for all modules (as some create pretty specific rules themselves that need a slightly different approach - like AdminOnSteroids - that are higher in the DOM than your typical rules.) Sometimes I have to insert the .dark selector deeper than a style applied to html, for example in a given rule.

I included the dark class in the body tag in my _main.php override.

When I stopped I also recall there was quite a bit of !important css rules set in the image editing popups and image fields styles in core - I started making headway with it and then had to step away. I haven't gone back to see if that has improved. I'm doing a bit of refactoring now to try to consolidate rules and get the options that I want.

The uk-inverse is not exactly what it appears to be. It gets used when you need light content in spaces where you otherwise get dark content by default - particularly in nested cards/sections/overlays and such. There are global inverse color rules that have a uk-inverse wrapper similar to the dark wrapper I described above, but it can be unpredictable in nested elements sometimes. In our case, though, with the content bring generally light, uk-inverse would provide dark text and assumes a lighter primary color IIRC.

I really like the toggle idea. In theory you could then just include the .dark class wrapper conditionally in the template override.

EDIT: Looking at different approaches, I guess I was approaching the toggle as more of a real-time DOM class change with jquery, but maybe it is better to have different variable sets that load for different color options. I'm going to play around some more with it.

[flydev]

I commited some fixes, will push it at the end of the day. But yes, some modules need to be taken case by case, thats why I think everyone using it could make it better by sending pull-requests.

There is also some hardcoded style set by js calls, I put already comments on a todo/known bugs section.

About the switch, I think the better solution is to reload the page to apply the default theme set by the user, brainstorming needed there.

Thanks for your interest ✌️

[flydev]

@bernhard as I am now using this admin theme on every setup, I had in mind that we could publish a scss file which should be used by every module’s developers. We will be using, eg., `var(—text-color-primary)` etc when writing module styles related code.

I am quite sure you already suggested something related somewhere in the forum, maybe you already put some « rock » code available ?

The next step should be to put a sentence about this process on the official module dev doc and a pinned thread here on the forum.

It should make things more standarized and easy to adapt/overwrite. I needed again to  write some more `.moduleClass .domThing !important;` to get some modules working with the dark style, like the toolbar button of EasyMDE…

⏳

 

[bernhard]

Hey @flydev it's a nice theme, just tried it again as I'm getting more used to dark mode in general.

I'm not sure about how we should approach this. I think before we ask module developers to adopt to our workflow we'd need to find a solid workflow for ourselves and find standards that we can agree on. For example it seems that your style does not use my rock-primary convention? Also why are you suggesting SCSS when the module and AdminThemeUikit use LESS for everything?

Here's a project with your style:

And here it is with my style:

What I find great about the rock style is that I can simply set a primary color in the module's settings and the backend instantly fits to the clients CI:

Your module has this yellowish primary color which in my case should be #00bb86 ? 

Another thing is that my PageBuilder uses SVGs for showing available content elements:

I'd not be extremely happy if I had to add support for dark themes here. But that's obviously only a topic of lazyness efficiency ? 

I'm happy that you try to move forward here and I agree that module authors should provide the stylesheets for supporting dark styles. But I also think we should make it as easy as possible so that it's as little effort as possible.

[flydev]

I agree, It was just an (good) idea thrown as is. And yes, about my "SCSS thing", I had in mind the LESS file, sorry (I am not a UIKit guy but a Tailwind node js/scss guy). 

I am not talking about asking devs to take care of the dark style, but using already existing LESS vars from the official theme, then when installing and using a new theme, it should fit smoothly without the need of writing hardcoded value. It could be the case for old modules optionally, but like you, I like standardized things. 

I also did myself the contrary of what we are talking here in most my modules, and then modified Duplicator's style in this way. I have more time theses days, I will self brainstorm and throw some suggestions.

[bernhard]

2 minutes ago, flydev said:

I also did myself the contrary of what we are talking here in most my modules, and then modified Duplicator's style in this way. I have more time theses days, I will self brainstorm and throw some suggestions.

Great ? It's been some time that I had my head into admin style development, so I'd have to invest time to get into it again.

Maybe it just needs better docs to get started and to clearly communicate what module authors need to watch out for so that everything works in every scenario?

3 hours ago, flydev said:

We will be using, eg., `var(—text-color-primary)` etc when writing module styles related code.

Where is that variable coming from? Is that already part of uikit or did you add that?

8 minutes ago, flydev said:

And yes, about my "SCSS thing", I had in mind the LESS file, sorry (I am not a UIKit guy but a Tailwind node js/scss guy). 

Nothing to be sorry about. Didn't want to sound offending, sorry if I did. You might have a look at https://github.com/baumrock/Scss - I developed it for the purpose of quickly creating PRs as the core uses SCSS and not LESS. I'd not really care about what to use, but I think as AdminThemeUikit uses LESS it might be better to stick to less. Also it just works for me and I have no experience when it comes to compiling uikit from scss sources (which exist I think).

Not sure if that is anything helpful but I wanted to add that to the brainstorming ? 

[flydev]

On 3/18/2023 at 2:12 PM, bernhard said:

Where is that variable coming from? Is that already part of uikit or did you add that?

From nowhere, but that's the missing part, I will push a fork of the official AdminThemeUikit so you can try it. The `pw-theme` should expose by default a `:root { --text-color; --bg-color; etc. }` to be used in CSS files shipped with our modules.

 

On 3/18/2023 at 2:12 PM, bernhard said:

You might have a look at https://github.com/baumrock/Scss 

I Will do that.

On 3/18/2023 at 2:12 PM, bernhard said:

Didn't want to sound offending, sorry if I did.

Nahh ?

[bernhard]

Yeah I'm having these css variables in my head for a long time. Though I'm not sure if it would be wise to jump onto that train. UIkit is built in a very modular way, but it relies heavily on LESS all over. It's super flexible and easy to customize just by setting different variables:

I don't think that we'd get this level of control with using css variables? The drawback of less variables is that you need to recompile everything on change whereas when using css variables you can apply changes on the fly via JS, which is cool.

For working with dark and light mode there is also https://getuikit.com/docs/inverse. It's a huge topic ?