Static stylesheets for themes stored in db

[Oleg]

I was going to keep this to myself due to it being fairly tied to my environment but since there's interest in such functionality maybe someone will find what I've done useful.

Generating 75k css file dynamically when its contents may only ever change as a result of deployment is a waste, thus I have a patch to phpbb that essentially replaces styles.php link with a link to static css file and a Python script to generate the stylesheets.

The generator is not perfect, and currently I'm aware of the following issue: I have maxthon (prosilver-based) style with its own images and en-us language pack with images for prosilver. If a user wants to view the board in maxthon and en-us, what images should they be seeing? I don't know this even for a vanilla board, and currently the stylesheet generator won't build maxthon+en-us combination at all, leaving users who choose this combination to view the board without styles.

[naderman]

You might want to look at the code of acp_styles.php in old_trunk or now on git the feature/ascraeus-experiment branch: http://github.com/phpbb/phpbb3/blob/fea ... styles.php It should already do what you are looking for. Chris might be able to add some more information. As mentioned in the subsilver2 topic we should include this in 3.1.

[ToonArmy]

If I get chance I'll try and work on this tonight. The dynamic CSS is a massive performance drain and urgently needs replacing.

[code reader]

... The dynamic CSS is a massive performance drain and urgently needs replacing.

i've been babbling about it for the last two years...
my first advice/question to anyone who complains about phpbb performance is always: did you try it with subsilver?
yucky, but prosilver was broken on arrival performance-wise, and was never fixed (btw: i think this is something worth backporting to 3.0)

[ToonArmy]

yucky, but prosilver was broken on arrival performance-wise, and was never fixed (btw: i think this is something worth backporting to 3.0)

That won't happen, it's going to require changes that are unsuitable for backporting to 3.0.

[code reader]

oh well....
at least i'm glad you guys are fixing it going forward.
thanks.

peace.

[Oleg]

You might want to look at the code of acp_styles.php in old_trunk or now on git the feature/ascraeus-experiment branch: http://github.com/phpbb/phpbb3/blob/fea ... styles.php It should already do what you are looking for.

Thanks for the pointer. This is the diff. I wonder if it can be obtained via git, from what I'm reading git is unable to diff path P in branch A vs path Q in branch B.

[Oleg]

The current behavior and what is in the trunk is to serve/create a file called e.g. foostyle-en_us.css when foostyle has no en-us imageset.

Either all language/style combinations "exist" and are servable (wasting disk and bandwidth), or forum code has to check whether user's language/style combination exists on each request (one disk access) and replace nonexisting with existing combinations.

I thought about this and having a file called foostyle-en_us.css which references 'en' images is misleading. Imagine the languages are not en-us and en like in my case, but that you have a foostyle-fr.css actually referencing 'en' images. In my book misleading is worse than a disk access, so I chose to only generate valid combinations.

Updated files in the first post.

Edit: the situation is complicated by the fact that correct language strings should always be served. style.php provides an S_USER_LANG variable replacement, which is not used in phpbb styles or in styles I downloaded. All my styles only reference localized images (from imageset) in stylesheets, so not generating a stylesheet for a nonexistent imageset does not reduce the number of S_USER_LANG substitutions (zero). However styles which use S_USER_LANG for something, should any exist, might need all possible language versions generated to not lose content.