Was just wondering about something that occurred to me. Default index.template.php has always called CSS files like this:
// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/index', $context['theme_variant'], '.css?fin20" />';
// RTL languages require an additional stylesheet.
if ($context['right_to_left'])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/rtl.css" />';
Which, on reflection, doesn't seem to make a whole lot of sense. It's ok if variants only change colours (and fair enough, most of them only do that) but if you have a variant that changes any positioning then you might want rtl_variant.css as well. And if ?fin20 is useful for preventing caching problems with index.css, then logically you'd want something similar for rtl.css, yes?
So really, it seems more sensible to call the files like this:
// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'rtl' : 'index', $context['theme_variant'], '.css?fin20" />';
Which not only provides more potential functionality but is less verbose code as well. Saves an http request too. Can anyone see anything wrong with this alternative?
The only catch I can think of is that it would require a complete rtl.css instead of a partial add-on file, but you have to go through the whole damned index.css when creating the partial add-on anyway, so in some ways it would make more sense to just use a copy of index.css and change positioning as you go rather than trying to pick out all the relevant bits for placement into another file.
(PS: If anyone wants to see awesome levels of mindf***ery in the GUI, try running the above code with a default rtl.css and an RTL language pack selected in admin. Makes one hell of a mess. :D )
Ok awesome coding dudes and dudesses: here's another question.
Given that the previous plan doesn't seem to have anything wrong with it, apart from increasing the total package size by a negligible number of kB, that led to another thought.
If I'm going to code for RTL support (one of those geek thangs, y'know) then it would be logical to also have the ability to load admin_rtl.css and editor_rtl.css when required. Bit silly if you don't, because any additional files are called after the basic CSS files and will consequently override rtl.css in the cascade, thus ensuring your admin and editor pages are configured for LTR. Not exactly an optimal result. :P
Now I can just tell that handling this effectively is going to require (cue dramatic music and gasps from the crowd) pigging around in the back end code in Sources, because forsooth that be where them monsters lurk. Unless, and here's the possibly groovy bit, there is a way of overriding the default Sources code in the theme's index.template.php.
Is this feasible? Is it sane? Answers scribbled on fag packets are fine.
ETA: The relevant Sources shiz seems to be this:
// Load a template - if the theme doesn't include it, use the default.
function loadTemplate($template_name, $style_sheets = array(), $fatal = true)
{
global $context, $settings, $txt, $scripturl, $boarddir, $db_show_debug;
// Do any style sheets first, cause we're easy with those.
if (!empty($style_sheets))
{
if (!is_array($style_sheets))
$style_sheets = array($style_sheets);
foreach ($style_sheets as $sheet)
{
// Prevent the style sheet from being included twice.
if (strpos($context['html_headers'], 'id="' . $sheet . '_css"') !== false)
continue;
$sheet_path = file_exists($settings['theme_dir']. '/css/' . $sheet . '.css') ? 'theme_url' : (file_exists($settings['default_theme_dir']. '/css/' . $sheet . '.css') ? 'default_theme_url' : '');
if ($sheet_path)
{
$context['html_headers'] .= "\n\t" . '<link rel="stylesheet" type="text/css" id="' . $sheet . '_css" href="' . $settings[$sheet_path] . '/css/' . $sheet . '.css" />';
if ($db_show_debug === true)
$context['debug']['sheets'][] = $sheet . ' (' . basename($settings[$sheet_path]) . ')';
}
}
}
Its flawed already IMO. Calling a variant CSS by just fetching a copy of the normal index.css is counter productive. I've seldom used it this way because it 1) makes the variant css less managable - that is, keeping it up with index.css and that will be just as big as it - and 2) its just a lot easier to simply call index.css first, then the variant do its work and pin-point the changed styles. That is, if your variants are more or less color variations. Which brings me to...
..In a way variants in 2.0 functions more like "subthemes", not just css color variants as it often is intended and used as. But - if its meant for actual subthemes its less powerful than for example also being able to change templates within the subtheme. Even less powerful if you dont change any default templates - then you are stuck with templates that more or less are tailored for one look only(default) AND you got to take with you as much of default css just to make it look ok. The alternative is often just making a new theme using a better base set of templates and build color variations from that IMO. Not many do that AFAIK.
But that said...it makes sense to put the whole thing also in RTL, but again, it makes for a hard job tracking those big files and keeping them in sync.
I am actually more fond of the idea to make smaller css files that rely on each other, and rather merge them into a temp css for production, something Elkarte does(and SMF 2.1? Not sure atm) which alleviates the need to minimise the number of files. Of course, within sane limits, 20 small files is just out of the question. :D
Yes, Elk and 2.1 have automatic consolidation and minification of CSS and JS files, which is nice if you can get it. Not an option for 2.0.x though, unless you go with installing a custom app of some sort to handle it.
I agree that the single call for index_thingy.css is not optimal, unless you're changing a heck of a lot in the variants. OTOH, if you're only changing colours in the variants there's something to be said for not having variants files at all, and simply using a body id or similar to call your variants, with the additional CSS for them appended to the basic index.css (ie: body id="red_thing" in the HTML, set by a ternary, and CSS like .windowbg {color: #fff;} #red_thing .windowbg {color: red;}). As long as it gets minified that's probably the best option for basic variants.
What got me thinking about how to handle RTL is that RTL support is really very easy once you are sure you have LTR sorted. You just scan through the file one declaration at a time (and FFS I know the whole thing backwards by now :D ) and swap margins, paddings and positioning as you go. It doesn't take long, and if you have to do that anyway then picking out the declarations for another file is just more work.
But I can also see the sense of splitting things down a bit, which is why I'm making the most use of files that SMF will force calls for anyway (editor.css is a good example). I just think they should be available in RTL as well as LTR, and if they aren't then I'd say that's a bug which needs fixing.
True. But is this changed for the better in 2.1? I don't see it changing in the feature-locked 2.0.x.
I don't expect the team to change it for 2.0.x. However, I do expect to be able to implement a custom workaround in 2.0.x. Obviously I can do it with a Sources hack, but I'd rather make it a standalone theme thing if feasible.
Oh and TBH, I'm not sure if it is changed for the better in 2.1. I haven't yet looked into how 2.1 supports (or doesn't support) RTL. But, given the team has always been very LTR-centric, I would not be surprised if this had been overlooked again.
ETA: Just took a quick look in the guts of 2.1. Relevant code appears to be this:
mkdir($context['to_install']['theme_dir'] . '/css', 0777);
$to_copy = array('/index.php', '/index.template.php', '/css/index.css', '/css/responsive.css', '/css/slider.min.css', '/css/rtl.css', '/css/calendar.css', '/css/calendar.rtl.css', '/css/admin.css', '/scripts/theme.js');
$to_copy = array('/index.php', '/index.template.php', '/css/index.css', '/css/responsive.css', '/css/slider.min.css', '/css/rtl.css', '/css/calendar.css', '/css/calendar.rtl.css', '/css/admin.css', '/scripts/theme.js');
Which, if I'm not missing anything, implies it will support the basic index.css and rtl.css, as you'd expect, and will also support an RTL file for the calendar, but will not support an RTL file for anything else. Which, again if I'm not missing anything, is frankly a bit bonkers. Particularly for things like responsive.css, which is inevitably going to include declarations for positioning of some elements.
Reminds me of my old sig: "Sources code - making front end changes impossible since 1863." :D
I wouldn't call it "Sources code", I'd call it design that's a little naive, because subtheme support in SMF is woefully incomplete (though, conceptually existant), what would be neat is if it were finished off and then added SCSS so SCSS imports could import across themes, then you'd ditch the variant thing and make it actual sub themes and just be done with it.
Personally I have no interest in SCSS, and would regard that as just extra crud to work around (much like Bootstrap). Although as long as you had the option of ignoring SCSS and just coding in straight CSS then sure, no problem. That should keep everyone happy.
But I think you're rather missing the point here. The point of this topic is not subthemes as such. The point is proper (ie: full) support for RTL languages. It just doesn't seem sensible to not do it comprehensively.
What I'm after is the sanest option for overriding default Sources loads of things like admin.css and editor.css, so that I can get RTL CSS for those areas of the GUI too. At the moment they don't get it, and from a CSS perspective it would be easy to do. Now presumably (haven't given it much thought) this would be possible in the template, but offhand I'm not sure how.
I could just call all of those files myself, with a ternary to select LTR or RTL, but for that to work I'd have to put in head after the default call for "HTML headers". Which then means if I call admin.css after the HTML headers that would be a second call for the same file. Which is probably not going to matter for LTR situations (albeit it's inefficient) but seems stupid for RTL situations (because there's no point loading both files when you only want the one that conflicts with the one Sources wants to load).
So what I really want is code in index.template.php, which tells Sources to eff off and die for any default loading of CSS files related to default SMF actions. Either that or I just write a mod that hacks Load.php to make it do what I want, but I'd prefer a standalone solution in the template itself.
Quote from: Antechinus on September 27, 2019, 07:27:45 PM
.. and will also support an RTL file for the calendar, but will not support an RTL file for anything else. Which, again if I'm not missing anything, is frankly a bit bonkers.
It is not bonkers, the RTL file was changed to load last after all other css files, so that it's code can override any of the others, you don't need an RTL version of every css file, you can use just the one RTL.css
As for why there is a calendar.rtl, I'm not sure but it might've been because it includes a lot of css blocks.
Relevant Pull Request
https://github.com/SimpleMachines/SMF2.1/pull/5387
Ok, I understand the idea, but look at the code. You're still loading rtl.css before admin.css, so any RTL presentation is not applicable to admin areas of the GUI. Which is fine if you have no laterally asymmetric positioning, paddings or margins in admin.css, but I'm betting you do. Safe bet, too. I just opened admin.css and on Line 9 we have:
#admin_content .button {
float: right;
}
How are you implementing RTL support for that, just as an example?
ETA: By the way, calendar.rtl.css only contains 23 lines of code. If you're planning on having one RTL file do everything, the calendar file is pretty pointless. The rtl.css file is already 687 lines of code. What's another 23?
We are talking about 2.1 right ? because that's the exact opposite of what I said,
rtl.css loads last after all other CSS files (before
responsive.css however) so that it can overwrite all other CSS codes.
(https://4.bp.blogspot.com/-9l1ehPeeFRQ/XY8jxaP1kMI/AAAAAAAAFIs/BEeiQ822UqkByenPDwMoY-X71gzbjbW7gCK4BGAYYCw/s1600/rtl_example2.png)
(https://1.bp.blogspot.com/-7bYu3Pj8WlM/XY8jr3UEISI/AAAAAAAAFIk/0cj2hJb5y-Yo0fqYSnvMfiDu0uypsRjpwCK4BGAYYCw/s1600/rtl_example.png)
Quote from: Antechinus on September 28, 2019, 04:42:57 AM
ETA: By the way, calendar.rtl.css only contains 23 lines of code. If you're planning on having one RTL file do everything, the calendar file is pretty pointless. The rtl.css file is already 687 lines of code. What's another 23?
Then it would make more sense to get rid of the file and move the code over to rtl.css imho
Ah. Ok, that's different to the stack in Themes.php. Fair enough then. Where is that code stashed? I was looking for CSS load code in Sources and the one I found was in Themes.php.
And yes, it would make sense to amalgamate the rtl code for the calendar into main rtl file. Calendar.css (LTR version) is pretty bloated at the moment. I took a look, just out of curiosity. I'm about a third of the way through it and have already knocked about 17% off the file size with no visible differences. Could have had a greater reduction by this point, but so far haven't bothered looking up hex equivalents for all the verbose rgba declarations (which are pointless when they're only showing a solid cell background anyway).
Although this still doesn't do anything to answer my original question: namely what's the best way of getting solid RTL support in a 2.0.x theme?
Quote from: Antechinus on September 28, 2019, 05:34:20 AM
Ah. Ok, that's different to the stack in Themes.php. Fair enough then. Where is that code stashed? I was looking for CSS load code in Sources and the one I found was in Themes.php.
Well, every css file is loaded from their respective source file, the main css files though are loaded from Load.php
// And of course, let's load the default CSS file.
loadCSSFile('index.css', array('minimize' => true, 'order_pos' => 1), 'smf_index');
// Here is my luvly Responsive CSS
loadCSSFile('responsive.css', array('force_current' => false, 'validate' => true, 'minimize' => true, 'order_pos' => 9000), 'smf_responsive');
if ($context['right_to_left'])
loadCSSFile('rtl.css', array('order_pos' => 4000), 'smf_rtl');https://github.com/SimpleMachines/SMF2.1/blob/fcd7b2c0acf17d3bd6f6a5e84a1840e60e0ec6ac/Sources/Load.php#L2260-L2267
Quote from: Antechinus on September 28, 2019, 05:34:20 AM
And yes, it would make sense to amalgamate the rtl code for the calendar into main rtl file. Calendar.css (LTR version) is pretty bloated at the moment. I took a look, just out of curiosity. I'm about a third of the way through it and have already knocked about 17% off the file size with no visible differences. Could have had a greater reduction by this point, but so far haven't bothered looking up hex equivalents for all the verbose rgba declarations (which are pointless when they're only showing a solid cell background anyway).
there's a lot that can be improved in the CSS of 2.1
Hey hang on a sec. What happens to RTL formatting when responsive.css kicks in? Isn't that going to bork things a bit?
I might whip through the 2.1 CSS a bit more seriously once I have my current Curve mutant plaything a bit more sorted. I can give you an edited calendar.css without much trouble though, any time you want it. Index.css is a bit more serious.
ETA: Actually responsive.css isn't too bad. There are 19 declarations that are laterally asymmetric. Not sure how important they are as I haven't checked yet.
ETA again: Lolz. The only declaration that is needed in calendar.rtl.css is the one to float the month-grid over at the right. The rest are superfluous. You could even get rid of that if you used flex or table-cell to do the main and month grids (with #calendar as the necessary parent).
I have objected to the bit about the hidden loading of CSS files before and got bitten off rough - so not going there again. :P Suffice to say, in any theme I do for 2.1 I WILL take a good look at any CSS file automatically loaded that I cannot spot or see inside index.template.php. Its "bonkers" - to rip off Antech's fav expression lol - to not have those files visible. I understand the reasoning, sure, mods and all that, but still it hinders doing great stuff when you don't see whats doing that aprtuclar pace/style going nuts...and so on.
To counteract these files in SMF 2.0 I just add them and remove everything in them. Done deal. They get loaded, not optimal, but at least they don't contain any hidden styles that will influence further out in the theme's supplied CSS.
SCSS..agree with Antech here, thats an unecessary added framework added on top of normal CSS and it will make it easier to work with CSS problems, sure. It will also make you unaware - and able - of how to make better optimsations within normal CSS limitations. Things you feel is only doable with SCSS instead of actually finding better solutions with normal CSS. IMO anyway, others may disgree.
Hey here's a thought (which still doesn't do anything to answer my original question): it should be possible to turn off minification for testing. I'd quite understand if this was mod territory, but I can see it being useful. The css directory rapidly gets full of old minified files, and they're a PITA when running recursive searches to track down gremlins. A switch to turn it off would be very handy. :)
And re the loading of shiz: if minification could be switched off, it'd be a lot easier to see what files were being loaded and in what order. Any decent web dev add-on will give you that information if it can get hold of individual files. ;)
ETA: Ha! Already has that switch hidden in admin. Easy. :D It's on ?action=admin;area=featuresettings;sa=basic; about halfway down the page.
PS: To give her credit, I remember the thread about loading shiz and Suki explained it all very well, to my satisfaction, after copping quite a bit of flack. Yes, it is a bit more work for themers, but it's certainly not impossible to deal with, and a no-minify switch would make it pretty simple.
Quote from: Bloc on September 28, 2019, 07:11:25 AMTo counteract these files in SMF 2.0 I just add them and remove everything in them. Done deal. They get loaded, not optimal, but at least they don't contain any hidden styles that will influence further out in the theme's supplied CSS.
Oh, just caught this. As you say it's not optimal, but within 2.0.x's limitations it may be the best option for a quick and dirty fix. I don't like it though. It's nasty. I'd prefer something cleaner.
You know that using CSS exactly as you are today is completely compatible with SCSS, right? It just works. But the ability to do things like give users a colour picker in the admin panel to set accents and stuff like that so you don't have to... that's worth its weight in gold to me as a platform owner.
Hell, even if you just used CSS with imports (which you can totally do even in regular CSS, the syntax is the same in SCSS, but the compiler includes it inline for performance), you could do what you were trying to do with less hassle.
Also, 2.1 has the ability to turn it off, or it did when I forked off. Admin search is probably your friend.
Resource minimization CAN be turned off, and you can see the order at which files are loaded if you check the pages html head tag.
You can also stop the forum from loading any resources if you wish
// Allow css/js files to be disabled for this specific theme.
// Add the identifier as an array key. IE array('smf_script'); Some external files might not add identifiers, on those cases SMF uses its filename as reference.
if (!isset($settings['disable_files']))
$settings['disable_files'] = array();
I already found that. And I already knew about swtiching off loading of files in 2.1
Quote from: Antechinus on September 28, 2019, 07:27:43 AMETA: Ha! Already has that switch hidden in admin. Easy. :D It's on ?action=admin;area=featuresettings;sa=basic; about halfway down the page.
PS: To give her credit, I remember the thread about loading shiz and Suki explained it all very well, to my satisfaction, after copping quite a bit of flack.
But, and I do mention this every so often, this thread is really about questions for 2.0.x.
Quote from: Antechinus on September 28, 2019, 05:34:20 AMAlthough this still doesn't do anything to answer my original question: namely what's the best way of getting solid RTL support in a 2.0.x theme?
To which the only answers seem to be:
1/ Write a mod to hack Load.php, or...
2/ Empty all the offending files, so that although they still get loaded they don't actually do anything.
If there's a third and better option I
really would like to hear about it. :)
If you don't want additional css files to override your rtl.css, then load rtl.css after this line in index.template.php
// Output any remaining HTML headers. (from mods, maybe?)
echo $context['html_headers'];
Yes I know, but I'd prefer to not load them at all. Is that possible in 2.0.x, without hacking Load.php?
I don't think it's possible
For some definition of possible. You should be able to do something by registering hooks (or futzing with global state) during template_init() which is a real PHP function which is loaded pretty early, not sure if too early or too late for that, but you can always rewrite template_html_above() to be way more picky about what it emits as things to load.
Template_init is called *after* the stylesheets are added to $context['html_headers']. So you have to mangle that one to rip them out.
No, sorry. Seems I got it wrong..loadTemplate actually checks for a template_{}_init function..which means it can check it there. I didn't even know there was such a thing. :)
The template_init is called way earlier, before stylesheets are called.
That's probably too early, then, but you can always dismember it before outputting.
Yes, taking apart $context['html_headers'] seems the only way.
Ok, this is sounding interesting. What I'm really after is preventing the loading of admin.css and editor.css. They're the only two additional default files that SMF will load in practice (IE and wireless being obsolete). Although I suppose I should add webkit.css to that list, since it has never really done anything anyway but still gets called whenever Load.php sniffs Webkit.
Quote from: Arantor on September 28, 2019, 03:30:33 PM
That's probably too early, then, but you can always dismember it before outputting.
Quote from: Bloc on September 28, 2019, 03:36:13 PM
Yes, taking apart $context['html_headers'] seems the only way.
Ok, how do I do this? This sorting of RTL handling is the last thing stopping Mutant Responsive Beastie from infesting the Themes Site.*
*Well, apart from actual approval, but I'm sure that can be dealt with.
What exactly do you want to remove from html_headers before it goes out?
Admin.css, editor.css, webkit.css.
The first two so I can call RTL versions in head, or not, depending on chosen language. The third because it's effectively deprecated these days anyway.
Ok, so I need to set up a 2.0 to see exactly what that is, but essentially you'd construct a call to str_replace to find that CSS and replace it with empty string to remove.
The other option is that, according to Theme Site rules, it is permissible to have a theme rely on a mod, and it would be easy to write a mod to edit the relevant array in Load.php.
So if the theme-only solution is going to get gnarly, and if in coding terms it would be significantly saner to use a mod, then I could be talked into going with the mod (I could easily write that myself). But I'd prefer to not have to rely on a mod, if it's possible to avoid it without going nuts on code.
Removing a given CSS call is a one liner if you happen to know exactly what the CSS call is exactly, but I can't do that without actually looking at the code, as I have no 2.0 code on my laptop any more.
I'll install it tonight and take a look.
Any joy on this?
Sorry, I just forgot about it, in the madness that has been my work lately. Will look tomorrow when I get up.
Yeah I figured you were probably busy, which is why I didn't want to hassle you too soon. :)
So if you want to remove admin, editor, webkit you can use this piece of code:
function template_html_above()
{
global $context, $settings, $options, $scripturl, $txt, $modSettings;
$remove_bundled_stylesheet = function($sheets) use ($settings, &$context)
{
foreach ($sheets as $sheet)
{
$sheet_path = file_exists($settings['theme_dir']. '/css/' . $sheet . '.css') ? 'theme_url' : (file_exists($settings['default_theme_dir']. '/css/' . $sheet . '.css') ? 'default_theme_url' : '');
if ($sheet_path)
{
$header = "\n\t" . '<link rel="stylesheet" type="text/css" id="' . $sheet . '_css" href="' . $settings[$sheet_path] . '/css/' . $sheet . '.css" />';
$context['html_headers'] = str_replace($header, '', $context['html_headers']);
}
}
};
$remove_bundled_stylesheet(['admin', 'editor', 'editor_ie']);
The first couple of lines give you the place to put it inside index.template.php, the rest of the code handles doing the work which amounts to looking for the way loadTemplate adds these things to html_headers and removes them again. You need editor_ie as well as it can load either depending on situation.
Webkit is only added inside index.template.php so you can hack that out at your leisure:
// Some browsers need an extra stylesheet due to bugs/compatibility issues.
foreach (array('ie7', 'ie6', 'webkit') as $cssfix)
if ($context['browser']['is_' . $cssfix])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['default_theme_url'], '/css/', $cssfix, '.css" />';
Cool. Thanks.
Turns out I'd already removed the call for ie/webkit anyway. I'd just forgotten about it.
Lemme know how it goes :)
Just gave it a quick run on local. Seems to be fine. Files aren't called, and no errors are logged.
Awesome, I did test it on mine but it never hurts to check :)
I'm currently (ie: quick test) calling the sheets like this:
// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'rtl' : 'index', $context['theme_variant'], '.css?fin20" />';
if (!empty($context['current_action']) && $context['current_action'] == 'admin')
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'admin_rtl' : 'admin', $context['theme_variant'], '.css?fin20" />';
if (!empty($context['current_action']) && (($context['current_action'] == 'post')||($context['current_action'] == 'pm')))
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'editor_rtl' : 'editor', $context['theme_variant'], '.css?fin20" />';
Which I might change after a bit more thinking, but which works as far as the basics go.
Yeah, that works. I could probably tweak the above to identify and return which ones, if any, that it found to remove if that would be any help?
The editor does appear in other places than just those - like the newsletter editor, plus mods.
Quote from: Arantor on December 01, 2019, 05:59:18 PMI could probably tweak the above to identify and return which ones, if any, that it found to remove if that would be any help?
Not sure what you mean there.
QuoteThe editor does appear in other places than just those - like the newsletter editor, plus mods.
Hmm. Sounds like fun. Obviously I can sort any default actions (and could just add action=admin to the current call for editor.css). Mods could be a nuisance though. To deal with those comprehensively it might end up making more sense to go back to rewriting Load.php with a mod, if they're going to make things convoluted in the template.
ETA: Although revamping Load.php is obviously going to be problematic if people have more than one theme installed, since it could screw other themes that don't use the same structure in index.template.php. Meh. :P
So right now it just removes editor, and admin from the list. But maybe it should tell you which ones it removed so you can put in your versions as needed.
As I said, other pages show the editor, not just the ones you've listed, and mods will break unless that is fixed.
I'll have a think about it today.
Poor mans solution: add all css files from default theme into your own theme, and set them all to zero content. :) They are still fetched but at least you catch them all that way. Of course, mods that add their own will not be affected unless you specifially target them too.(like tp-style.css in TinyPortal).
I found it quite refreshing to have -0- styles inherited from default theme. The freedom lol :D
Quote from: Bloc on December 02, 2019, 03:16:18 AMPoor mans solution: add all css files from default theme into your own theme, and set them all to zero content.
No. :P Do not want.
Quote from: Arantor on December 02, 2019, 02:34:38 AM
So right now it just removes editor, and admin from the list. But maybe it should tell you which ones it removed so you can put in your versions as needed.
Ah. Wouldn't worry about it. It already tells you which ones it's removing. They're listed in the array, so no problem.
$remove_bundled_stylesheet(['admin', 'editor', 'editor_ie']);Can't see why it would need anything more than that.
QuoteAs I said, other pages show the editor, not just the ones you've listed, and mods will break unless that is fixed.
I'll have a think about it today.
I'm thinking that as long as I nail all the relevant default actions, mods can be sorted later. Mutant Responsive Beastie is not going to be 100% compatible with all available mods anyway. It'll require custom tweaks for some of them, just as the old "Responsive Curve mod" does. If the necessary calls can be added easily I think that would be fine. As far as I can tell, it'd simply be a matter of adding actions to the IF conditional, which isn't that big a deal.
ETA: While I think of it, when doing the initial test I did run it with the default admin.css and editor.css knocked out by your code, but without replacing them with my custom calls. This was actually ok for the editor pages. Not as flash for eye candy, but perfectly usable. So even if a mod does run without editor.css on some obscure pages it wouldn't necessarily be a deal breaker, and could be fixed easily anyway.
Also, I don't think the textarea in the newsletters section is relevant to editor.css. It appears to just be a standard textarea, styled from index.css and/or admin.css. This custom code doesn't have to worry about most textareas. It's only the actual editor, as shown on the reply page, that matters. Is that shown anywhere other than action=post and action=pm?
You see, that's my point. You don't know where these things were called. If I have my code report on what it found, then you can know correctly to reinstate things.
The editor will be shown on the newsletter writing (not the news page but the actual newsletter constructor as it has the WYSIWYG editor) page and all sorts of mods, none of which you can know about currently.
Yes, I know it's not the news page that you're talking about.
Does anyone actually use the 2.0.x WYSIWYG? It's pretty screwed. With the WYSIWYG turned off in profile settings, the newsletter composition page appears to just show a bog-basic textarea. No BBC buttons or any other frills, so works just fine even without editor.css.
But even the non-WYSIWYG editor at action=post works without editor.css. It just doesn't look quite as slick. And the additional CSS for the WYSIWYG is trivial. I'm not sure it's even necessary. A lot of 2.0.x CSS isn't (can test to check it, just to make sure).
TBH the only reasons I'm even using editor.css are a/ it was already called by default, so I thought it might as well do something and b/ by default it did SFA, so I moved whatever I could from index.css to editor.css. But I could easily move it back to index.css, thereby making editor.css completely unnecessary. It's only a few kB. I'm pretty sure editor_ie.css isn't necessary these days either. I suspect it was only relevant for IE6 and IE7 (can test that too).
function template_html_above()
{
global $context, $settings, $options, $scripturl, $txt, $modSettings;
$remove_bundled_stylesheet = function($sheets) use ($settings, &$context)
{
$removed = [];
foreach ($sheets as $sheet)
{
$sheet_path = file_exists($settings['theme_dir']. '/css/' . $sheet . '.css') ? 'theme_url' : (file_exists($settings['default_theme_dir']. '/css/' . $sheet . '.css') ? 'default_theme_url' : '');
if ($sheet_path)
{
$header = "\n\t" . '<link rel="stylesheet" type="text/css" id="' . $sheet . '_css" href="' . $settings[$sheet_path] . '/css/' . $sheet . '.css" />';
if (strpos($context['html_headers'], $header) !== false)
{
$removed[] = $sheet;
$context['html_headers'] = str_replace($header, '', $context['html_headers']);
}
}
}
return $removed;
};
$removed = $remove_bundled_stylesheet(['admin', 'editor', 'editor_ie']);
Now you can say:
if (in_array('admin', $removed)) {
... blah blah blah include admin w/rtl CSS ...
}
And you don't have to check the action or anything for the editor, you can simply see exactly what was previously there and include your replacement.
Looks like I was wrong about the newsletter - but I still wouldn't presume that those are the only places it is used, because mods do various things, and I'd rather be able to know which was actually used and therefore what I need to add back, seems more reliable in my world.
Ok, so why don't I just move the editor CSS back to index.css and solve the whole thing that way? No need to know about any actions or arrays. Just knock out the default calls from Load and there'd be no need to worry about anything else.
That also works, just if you cared about sparing the CSS otherwise, that'd be how you'd solve it.
I also wouldn't presume that *every* case of including admin.css is inside the admin area, because mods do strange things.
Meh. Ok, I suppose going belt and brace makes sense.
Reduces the number of support questions later ;)
Well yeah, but traditionally it's up to mod authors to deal with integrating their mods into custom themes, so I could just torture them for fun. :D
It will be assumed to be your problem if it works correctly on standard Curve though ;)
Nope. It's still a custom theme. In fact it's far more heavily customised than most themes on the Theme Site. It just looks mostly like Curve (apart from the different header, different board index, different message index, etc, etc, etc). So I could torture them just for fun and still claim to be within my rights. Don't tempt me. ;)
You don't do much support here :P I guarantee you it will be presumed any weirdness in a mod that works fine on Curve but not a theme will be presumed to be the theme author's fault and people with trouble will be advised to go to the theme thread for support.
This is just how it's been for a while.
That's different. It used to be that people would be told to see the mod author about it.
And they might, right until "but it works fine on Curve" when it will become the theme's problem for any theme that isn't a pure recolour of Curve.
All mods work on Curve. They aren't approved in the first place if they don't work on the default theme.
By the way, have tested the code back here (https://www.simplemachines.org/community/index.php?topic=569782.msg4039184#msg4039184) and it works nicely. Template calls for the sheets look like this:
// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
// The first call, for index.css and rtl.css, should probably be changed to call index.css and index_rtl.css for greater consistency.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'index_rtl' : 'index', $context['theme_variant'], '.css?fin20" />';
if (in_array('admin', $removed)) {
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'admin_rtl' : 'admin', $context['theme_variant'], '.css?fin20" />';
}
if (in_array('editor', $removed)) {
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'editor_rtl' : 'editor', $context['theme_variant'], '.css?fin20" />';
}
And they all get called where they ought to be called. :)
But at the moment I'm pondering variants, so there are a stack of comments just after that lot. To whit:
// Meh. Variants. How to deal with those? For minor colour variations, with no change of layout, it makes sense to have a supplementary variant file called after the three basic files (index, admin, editor).
// Come to think of it, this may also be the best way of dealing with layout variants. One more http request, but will save a truckload of CSS duplication.
// So, calls above should likely be of the form:
// <link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'index_rtl' : 'index', '.css?fin20" />';
// With something like this coming after:
// <link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'variant_rtl' : 'variant', $context['theme_variant'], '.css?fin20" />';
// Only catch with that being that it will 404 if you don't have an RTL variant file for every variant, which is an unnecessary PITA for colour-only variants.
// So, would be nice to do the PHP so that if RTL variant file exists it gets called, otherwise basic (LTR) variant file does both LTR and RTL.
// Alternatively, for layout variants could use an extra RTL class or id in the one variant file, so any layout variations could have consecutive decalrations for LTR and RTL.
// This is probably fine, unless you go absolutely troppo with layout variants. Which you probably won't, since past a certain point a new theme makes more sense.
Just to confuse matters. :D It probably makes sense to go for the HTML tag for the ID, since that's the highest level and will therefore cover anything weird you might want to try. So something like this:
<html xmlns="http://www.w3.org/1999/xhtml"', $context['right_to_left'] ? 'id="variant_rtl" dir="rtl"' : '', '>
Then CSS can be done as (basic example):
.collapse img, .help img, .toggle, .catbg>.toggle {
position: absolute;
top: 3px;
right: -5px;
margin: 0 2px;
border: 2px solid #0000;
border-radius: 50%;
}
#variant_rtl .collapse img, #variant_rtl .help img, #variant_rtl .toggle, #variant_rtl .catbg>.toggle {
right: auto;
left: -5px;
}
I've gone back to the conventional (boo!) idea of a partial rtl.css coming after the index.css for most of the crud. It's more backwards compatible with existing mods, and will make customising multi-lingual sites easier than using two complete files. It gives a slight performance hit in RTL mode, due to the extra HTTP request and some extra CSS, but is probably best on balance, and has no effect in LTR mode anyway.
However, I had a look in the editor and admin CSS files and they have hardly any bits that need switching for RTL. It's only a couple of dozen lines of code in each one. So I figured for these files I might as well throw the RTL tweaks in with the LTR code. That way there's no need to worry about RTL files for these areas. If you're customising something you can do the RTL code at the same time if you want to.
Works perfectly, and will make supporting layout variants in LTR and RTL as easy as supporting colour variants. :)
Looks like this:
// Show right to left and the character set for ease of translating.
echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"', $context['right_to_left'] ? 'id="variant_rtl" dir="rtl"' : '', '>
<head>';
// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/index.css?fin20" />';
if ($context['right_to_left']) {
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/rtl.css?fin20" />';
}
if (in_array('editor', $removed)) {
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/editor.css?fin20" />';
}
if (in_array('admin', $removed)) {
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/admin.css?fin20" />';
}
// For layout variants, call id="variant_rtl" from the root HTML tag, for full support in the one file.
// Example CSS: .whatever {position: relative; left: 1em;} #rtl_variant .whatever {left: auto; right: 1em;}
// Then files for all variants are called by one instance of this:
// <link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/index_', $context['theme_variant'], '.css?fin20" />';
// Since it's last in the cascade it will override all the others without any problems. Sorted. :)
#error_log .checkbox_column {
width: 34px;
padding-top: 8px;
text-align: center;
position: absolute;
top: 0;
right: 0;
bottom: 0;
border-left: 1px solid #ccc;
}
#error_log ul {
margin-right: 34px;
}
/* --- For RTL languages --- */
#variant_rtl #error_log .checkbox_column {
left: 0;
right: auto;
border-left: 0;
border-right: 1px solid #ccc;
}
#variant_rtl #error_log ul {
margin-right: 0;
margin-left: 34px;
}
/* --- Back to LTR code --- */
#error_log ul li {
line-height: 2.4rem;
padding: 4px;
overflow: hidden;
border-top: 1px dashed #ccc;
}
#error_log ul li:first-child {
border: 0;
}
#error_log span {
width: 48%;
display: inline-block;
padding: 0 4px;
}
#error_log span:first-child {
border-right: 1px dashed #ccc;
}
/* --- For RTL languages --- */
#variant_rtl #error_log span:first-child {
border-right: 0;
border-left: 1px dashed #ccc;
}
/* --- Back to LTR code --- */
#error_log ul div {
padding: 4px;
}
Just realised something. I don't actually need to pull html_headers apart anymore. The original point of this cunning plan was to get editor.css and admin.css (and possibly other files) supporting RTL, without getting convoluted with calling a stack of files, but I've just gone and sorted that merely by adding a conditional ID to the base HTML tag. Which means I can put all the other code back to default and it will all work anyway. Great moments in d'oh. :P
However, the code for pulling things out of html_headers will probably come in handy for something, sometime, so good to know anyway. :)
Done some more thinking. I am going to throw this code into the Mutant Curve beastie after all. Not that it should be needed by default, but I've been thinking about mods and I can see the ability to knock files out of $context['html_headers'] being very useful for dealing with presentation issues coming from mods.
So I'll chuck it in, and set it to just kill editor_ie.css for now, just so it has something to do occasionally. Then the code is there if it's ever wanted for anything more serious, and any extra sheets can be dropped into the array in a minute.
Having thought that far, I then started contemplating having an admin input to take a comma-separated list of any sheets you want to knock out. This would be easier for teh n00bz, but on the other hand picking apart the output from Sources is something teh n00bz are probably better off not trying anyway, so it would be safer to not offer them the temptation. On this basis I decided to KISS for people who know what they're doing, so no admin page shenanigans. :D