Skip to main content ↑ ↓
Topic: Did something change in the way CSS files are loaded? (Read 4821 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Did something change in the way CSS files are loaded?

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.

Re: Did something change in the way CSS files are loaded?

Reply #1 –

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
Code: [Select]
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
Code: [Select]
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.
Last Edit: March 30, 2014, 01:19:59 pm by scripple

Re: Did something change in the way CSS files are loaded?

Reply #2 –

This is the series I get with the current master:
Code: [Select]
	<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...
Bugs creator.
Features destroyer.
Template killer.

Re: Did something change in the way CSS files are loaded?

Reply #3 –

Yes but what about the editor files? That's what Scripple is talking about.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Did something change in the way CSS files are loaded?

Reply #4 –

Look at your page source on action=post.  Is the custom css below the sceditor one?

Re: Did something change in the way CSS files are loaded?

Reply #5 –

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?
Bugs creator.
Features destroyer.
Template killer.

Re: Did something change in the way CSS files are loaded?

Reply #6 –

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.

Re: Did something change in the way CSS files are loaded?

Reply #7 –

Quote from: emanuele – Noob question: if you are touching even the editor, isn't it worth create a new variant?

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?

Re: Did something change in the way CSS files are loaded?

Reply #8 –

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?
Bugs creator.
Features destroyer.
Template killer.

Re: Did something change in the way CSS files are loaded?

Reply #9 –

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.
Code: [Select]
    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.

Last Edit: April 03, 2014, 09:15:49 pm by scripple

Re: Did something change in the way CSS files are loaded?

Reply #10 –

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
Bugs creator.
Features destroyer.
Template killer.

Re: Did something change in the way CSS files are loaded?

Reply #11 –

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 )

Re: Did something change in the way CSS files are loaded?

Reply #12 –

Done.
Bugs creator.
Features destroyer.
Template killer.

Re: Did something change in the way CSS files are loaded?

Reply #13 –

Quote from: emanuele – Done.
Which part?  The default_theme to theme part or looking at my proposed fix?

Re: Did something change in the way CSS files are loaded?

Reply #14 –

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.
Bugs creator.
Features destroyer.
Template killer.