SychO There would be no more backend preprocessing, LESS variables would only be scoped to your extension as the forum app itself would now receive vanilla CSS files.
Can you an example of your use case?
This could just be because I haven't done a heap of frontend dev so maybe I'm missing an obvious solution, am just thinking about themes that need to override all the colours, fonts, styling, etc. So if I want to change background colours, primary/secondary, switch elements on or off, and have that based on settings stored in the database rather than in files compiled at build time. This would allow flexible themes to alter the colour scheme entirely based on whatever logic you want.
SychO Can you explain the use case further and what you tried?
Again this could come down to my lack of understanding of frontend, or maybe Flarum in general, I wanted to remove a menu but simply removing the menu element wasn't enough as I also needed to remove some padding, so I made a LESS variable @show-side-nav set by default to true, and an override based on whether the user is logged in and a setting in the extension. I think this ended up being a bit of a hack really and uses a couple of classes marked as "internal".
(this is from some middleware)
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
$settings = $this->container->make(SettingsRepositoryInterface::class);
$actor = $request->getAttribute('actor');
$isGuest = $actor ? $actor->isGuest() : true;
$showSideNavToGuests = $settings->get('madeyedeer-pallet-theme.show_side_nav_to_guests');
$showSideNav = ($showSideNavToGuests == '1' || !$isGuest) ? 'true' : 'false';
$this->container->resolving('flarum.assets.forum', function (Assets $assets) use ($showSideNav) {
$assets->css(function (SourceCollector $sources) use ($showSideNav) {
$sources->addString(function () use ($showSideNav) {
return "@show-side-nav: {$showSideNav};";
});
});
});
return $handler->handle($request);
}
It doesn't seem to work that well anyway, maybe the order of processing variables is not reliable enough - we can't guarantee that this one will be set last and therefore override the default as expected, or maybe it gets cached, it just seems to be a bit inconsistent.
