The theme variant custom_css file is no longer the last one loaded. I'm seeing jquery.sceditor.css loaded after the custom css now which is overriding the changes I've made to the editor. (And this has nothing to do with the wysiwyg editor issue.)
When I was writing the custom css it was loaded last and so the recoloring of the rest of the editor besides wysiwyg did work.
Aha. Someone did break Load.php when it comes to custom.css by loading it too early in the process.
Load.php that broke custom.css
Line 1599
// Load a custom CSS file?
if (file_exists($settings['theme_dir'] . '/css/custom.css'))
loadCSSFile('custom.css');
if (!empty($context['theme_variant']) && file_exists($settings['theme_dir'] . '/css/' . $context['theme_variant'] . '/custom' . $context['theme_variant'] . '.css'))
loadCSSFile($context['theme_variant'] . '/custom' . $context['theme_variant'] . '.css');
// Compatibility.
Load.php where custom.css works
Line 1818
// Load a custom CSS file?
if (!empty($context['theme_variant']) && file_exists($settings['theme_dir'] . '/css/' . $context['theme_variant'] . '/custom' . $context['theme_variant'] . '.css'))
loadCSSFile($context['theme_variant'] . '/custom' . $context['theme_variant'] . '.css');
The new code is fine, but it's position in the file is not. If you move the new code back to line 1818 where it used to be then custom.css still loads last like it should.
This is the series I get with the current master:
<link rel="stylesheet" href="http://localhost/beta_2/themes/default/css/index.css?10beta2" id="index.css" />
<link rel="stylesheet" href="http://localhost/beta_2/themes/default/css/font-awesome.css?10beta2" id="font-awesome.css" />
<link rel="stylesheet" href="http://localhost/beta_2/themes/default/css/_light/index_light.css?10beta2" id="index_light.css" />
<link rel="stylesheet" href="http://localhost/beta_2/themes/default/css/custom.css?10beta2" id="custom.css" />
<link rel="stylesheet" href="http://localhost/beta_2/themes/default/css/_light/custom_light.css?10beta2" id="custom_light.css" />
It looks correct to me...
Yes but what about the editor files? That's what Scripple is talking about.
Look at your page source on action=post. Is the custom css below the sceditor one?
hmm... the previous place wasn't exactly correct (I'd argue it's not correct to have index.css there as well, it should go in loadTheme along with all the other css files).
Anyway, there could always be something able to override it unless it's added directly to template_css (think about any addon that will load a css file "at some random point" during the execution) and this wouldn't be a very good idea because that function (like template_javascript) is already doing much more than it should do.
Noob question: if you are touching even the editor, isn't it worth create a new variant?
Well, see my other thread about the editor wysiwyg mode not working for variants. I've not looked carefully at the code, will css files from variants be loaded from more than the three that are there in _light and the custom file?
If so yes I can move the (non-wyziwyg) sceditor into my variant and modify it.
Noob question back, I don't see how a variant will help me. jquery.sceditor.css (the file that styles the non-wysiwyg elements of the editor) is what I'm complaining about it with the change of order of loading custom.css. It's loaded as a style_sheet parameter passed to loadTemplate. loadTemplate will load admin style sheets from the theme_variant, but I don't see where theme variant is added to other style sheets in either loadTemplate or loadCSS. Did I miss something?
Okay, in the current HEAD the editor style sheet should be variant-dependent if the theme has variants, or global if it doesn't have variants.
So that should work...
And add additional custom style sheets to the editor is not possible as far as I can tell.
Considering everything that should be fixed now... right?
Do you mean the master branch on github as the head? Because I'm not seeing a fix in there. There are two style sheets for the editor. One that is handed off to the editor to style it's iframe, and another loaded as a standard style sheet to style the rest. The second one is the one I'm not seeing a fix for since you moved it to loading after the custom.css file in the variant.
Specifically, in Editor.subs.php line 149 from a master.zip just pulled.
loadTemplate('GenericControls', 'jquery.sceditor');
That call does not end up loading the style sheet from the variant, but from the main theme. Only admin sheets get loaded from the variant.
And since you now load the custom.css earlier there is no way for a variant to change the styling in the non-wysiwyg portions of the editor. loadTemplate now loads "jquery.sceditor" after custom.css and it only loads "jquery.sceditor" from the main theme.
https://github.com/emanuele45/Dialogo/commit/0f67998e35692e43aa69fa983ad96265f11b6929
https://github.com/emanuele45/Dialogo/commit/e7b12ff8aecf1cb33fcde58254ebd6600f4d3726
If that is not enough I don't know what to do... :P
I left a comment on github about using theme_url instead of default_theme_url in GenericControls.
And on the loading a custom version after the main one, I'd like you to take a look at my proposed changes to loadCSSFile. It's a potentially cleaner solution than lots of special cases everywhere. And allows addons/mods to be themed for different variants as well. (Plus it stops me from harassing you about the next css file in line like the who one or something. :P )
Done.
Which part? The default_theme to theme part or looking at my proposed fix?
Unfortunately one of the two we are talking about here, doesn't work with loadCSSFile and cannot work with it because is a style sheet added specifically to the javascript that builds the editor to style the iframe that contains the WYSIWYG editor (I wonder if calling the css "wiz" is clear enough or I should use the extended "wysiwyg", dunno).
The other... yes it may work, but... will explain in the other issue.
Yes I'm aware of the special iframe css styling sheet for the wysiwyg editor (with the _wiz name), and I'm aware that my other proposal doesn't alter that. Which is why I suggested the change about default_theme_url as I know that has to stay.
And that's what I was referring to. ;D
https://github.com/emanuele45/Dialogo/commit/be942cba3f8d721a5f9f4fb462037ad98cf95715