AdminThemeUIkit admin styles from multiple less files

[gornycreative]

I'm not sure if there is currently a way to do this with the code as it is. I was looking at the modules and the trait that @bernhard got set up.

Essentially I want to be able to set a LESS module object up with conditionally added files and then pass that into AdminThemeUIKit as a style - but from what I can see my options here are either declare reno or rock as the base style or else pass through a file path to a single existing .less file.

I can get the LESS module to compile an admin.css file without going through the AdminTheme stuff, but then I lose the whole minify and compile on changes features unless I reinvent the wheel for my admin theme.

I can do that if its the only way - as an alternative would it make sense to also have an option to detect a LESS module object passed through the style option?

[bernhard]

Hi @gornycreative I'm not sure I understand?

Did you see https://github.com/baumrock/AdminStyleHello ?

[gornycreative]

Yes.

It calls the loadStyle() function from the AdminStyle trait. There's a relative path to a single less file in the subdirectory that imports other files.

I want to be able to conditionally call several less files that cover different module installation requirements. No point in bulking up css for modules that aren't installed.

The Less module provides the ability to $object->addFile() in aggregate so that multiple .less files get included in the final getCss() call. I do this on the frontend for sites sometimes, and did it for the admin backend also using settings factory to allow colors and fonts to be set before the Admin Style stuff was released.

With the new setup you folks have put together, I'm trying to pull that into a single style module so deployment is a little simpler using the AdminStyle setup as a base.

There is no single .less file in my scenario, and I don't necessarily want to call every .less file in a folder either. It's not just a matter of including the uikit and including reno/rock.less and then just importing all the other less files I want in admin.less

LESS isn't really designed to be elegant in its conditionals. I could use guards to make it work, I think, but I'd rather try to keep that programming logic on the PHP side.

I don't know how many modules on the list of modules I generally choose from have weird style requirements. Maybe the bloat to always include them all is insignificant. I just don't like loading stuff on a site that isn't relevant for the site.

Hope that makes sense.

[bernhard]

Ok I get the part of conditionally loading LESS files. I think you'd have to do that on your own. See https://github.com/baumrock/AdminStyleRock/blob/4e1c42f0d09e090687fa1df8fa1a8bcfe6c9d065/AdminStyleRock.module.php#L38-L53 how that can be done.

But I don't get why you have different modules with different LESS files?! And do they all depend on each other, like do they share color variables or such?!

[gornycreative]

 

5 hours ago, bernhard said:

But I don't get why you have different modules with different LESS files?! And do they all depend on each other, like do they share color variables or such?!

Because there are modules that other people have created which add inline styles and colors and all sorts of other things that are not covered by the default pw and rock LESS styles.

They aren't my modules! ?

For example, AdminOnSteroids - the admin config interface there has all kinds of crazy styling going on. Left to its own device it looks pretty bad with a dark theme. I have a file that contains override that use the main color variables. Will probably be useful for other folks trying to style their admin and aren't sure what is going on with some crazy config screen.

But not every site uses AoS, I don't always deploy it. So why include those style rules for sites that don't have the module installed?

There's stuff in core as well that was put together before the UIkit days that have static css - I guess some of these could be resolved by "inherit" maybe? I haven't felt confident enough with the changes I've made myself to suggest pull requests but I can dig into it later.

There are a few others. Look at the modules support @flydev has added to his theme to correct/adjust the look of admin configuration interface for some of these modules.

For now I'll just load them all and see how bad the bloat is. If it ends up being negligible then great.

 

[bernhard]

On 11/7/2022 at 4:33 PM, gornycreative said:

Because there are modules that other people have created which add inline styles and colors and all sorts of other things that are not covered by the default pw and rock LESS styles.

They aren't my modules! ?

IMHO that is something that the module's authors should fix. Adding style overrides to your module would be an ugly fix. What if the module author changed the markup or a style of his/her module? You'd need to update your module as well. And you'd need to somehow make sure that the versions match. It would be a lot better to make a PR and add the styles to those modules. Ideally we'd find a standard way of doing that that all modules could implement. For example having an /site/modules/MyModule/AdminThemeUikit/style.less or something

But maybe that's even not necessary if the module's had proper styles? I'm still not 100% getting what you say I think and it's hard without having a specific example.

On 11/7/2022 at 4:33 PM, gornycreative said:

For example, AdminOnSteroids - the admin config interface there has all kinds of crazy styling going on.

It does not only add crazy styling it also adds crazy scripts and hooks that broke my admin several times. I'm sorry to say that but I'd be careful with that module ? And I'd be even more hesitant to build or use a module that fixes another module... That does not sound like a good idea.

On 11/7/2022 at 4:33 PM, gornycreative said:

But not every site uses AoS, I don't always deploy it. So why include those style rules for sites that don't have the module installed?

Yeah, that's why I think - if at all - such stylings should live in the module itself.

On 11/7/2022 at 4:33 PM, gornycreative said:

There are a few others. Look at the modules support @flydev has added to his theme to correct/adjust the look of admin configuration interface for some of these modules.

I'd be interested in what you say but it would be easier if you were more specific and maybe add screenshots or something. It's very hard to follow and I can't install modules and click around to try to find the spot that you where talking about.

[gornycreative]

I wish I could live and program in a world of "shoulds" but years of working in the WordPress ecosystem has cured me of holding free module developers to high expectations.

I do agree that the module format should have either its own css and/or less asset folder, but I also take into consideration that adding LESS and AdminStyleUIKit features to PW is a very recent endeavor. It's one I support and would have certainly argued for, but in working with many old and new modules in the directory, there are a lot of abandoned modules that are still in production which don't necessarily conform to what has been built recently.

It's worth discussing how modules should handle their assets - including scripts and styles - on the admin side.

Maybe a new thread?

[flydev]

On 11/11/2022 at 3:47 PM, gornycreative said:

Maybe a new thread?

Just my two cents here, I vote to extend the module's developer doc and/or a note in the coding style guide. That's maybe the role of the community to (help) write it and send it as proposal to @ryan by filling a github issue for an eventual revision.

[bernhard]

Just yesterday I thought about that topic... I saw that Tracy uses a custom color that comes from the reno theme I think?

Is that one example for what you mean @gornycreative ? Do you mean that the module should pick up the default color (in my case my #00BB86 baumrock-green) rather than the reno-red?

I'm not sure how we could do that best, but I'm quite sure if we find a concept that works and makes sense and explain it to Ryan he'd be helpful in implementing that or to add some kind of procedures/guidelines.

Personally I think that the rock theme should be the default. Not because I built it, but because it is close to the default UIkit theme (that was the goal of the style). UIkit already comes with the necessary standards (like having a proven concept of colors primary/secondary/muted). The reno theme is imho an opinionated set of overrides on top of that (or should be).

One restriction would be that the primary color needs to be a dark color with good contrast to white. So that all UI elements having a primary color are well visible on white screens and can have white as text color.

I'm not sure how that would work for a dark mode switch? Maybe the best would be to create a demo-module that implements our concepts?

[gornycreative]

I am working through several color calculation options that will be part of my style module. I will let folks know when it is ready.

Yes, UIKit's use of default, primary, secondary, muted provides a lot of color options.

My interest is in being able to offer option for selecting up to three colors and having caluclations to provide adequate palettes for each, including UI contrast concerns.

And yes, those highlights are part of the issue, as well as highlights/focus color changes on certain inputfields, and yes, there are buttons that appear in different places with either reno coloring or default coloring (like the delete button in certain areas).

Likewise, the alert color schemes don't always necessarily fit well with different color schemes. That's what I am experimenting with at the moment.

[bernhard]

Hey @gornycreative just installed InputfieldTinyMCE for the first time and guess what: It has reno styles applied even though I'm using the rock style. The quick and dirty solution would be to override those styles in my rock style, but IMHO it would be a lot better if they were simply not applied unless the reno theme is being used.

IMHO AdminThemeUIkit should stick to uikit conventions (primary color, secondary color) and the reno style should override those where necessary (not the other way round).

So I think if you find a good solution for that problem that would be really great and important for PW!

[gornycreative]

On 11/20/2022 at 9:18 AM, bernhard said:

IMHO AdminThemeUIkit should stick to uikit conventions (primary color, secondary color) and the reno style should override those where necessary (not the other way round).

There's blue and black in the primary and secondary, but we can't discount default (white) and muted (gray) in UIKit specs. Particularly if there is a desire to be able to engage light or dark options.

Haven't installed it yet - I'll add it to the checklist though as I plan on using it.

 

[bernhard]

@gornycreative your messages are sometimes really hard for me to read/understand. Not sure if you are native and just writing slang or just using words/grammar that I don't fully understand. But even posting your last answer into deepl translator did not produce any understandable translation. I have a guess, but I'm not sure. So I'd ask you to be more careful in your wording if possible please so that everybody (also non native english speakers) can understand what you are saying.

Could you please explain what you tried to say in your last message in other words?

[gornycreative]

UIKit uses four different color designations:

You mentioned above that UIkit conventions only have two colors. I was just saying that there are four colors to be concerned with if you are trying to create dark and light themes.

I don't use slang, but I do tend to use what are called sentence fragments if I am writing a quick note. These fragments are probably not easy to translate. I will avoid them if I can.