Skip to main content ↑ ↓
Topic: Custom theme... and then confusion set in (Read 2257 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Custom theme... and then confusion set in

Please excuse my ignorance (new to ElkArte), but what the hey?!??

In trying to port one of my custom SMF themes over, I discovered that my .css changes were not being implemented. After some head scratching and searching, I discovered that the reason is that, while set up to use my custom theme-in-development, which did have its own .css files, the settings in default/css/_light/index_light.css were being used.

Now if my reasoning is correct, first, this should not be happening, second, I should not have to make changes to the default theme or its variants in order to create a custom theme (thus far I have only gotten as far as trying to establish the background for the custom theme), and third, if I make changes to the default theme it will muck things up for any theme but the one I am creating.

What am I missing?!??

Also if anyone can help me understand the basic template differences between ElkArte and SMF, it would save me from a LOT of bouncing around looking for what depends on who to do which. Evidently ElkArte has taken a quite different approach somewhere, and I can't seem to put my finger on it. SMF, by contrast, feels "familiar". For example, the portal that I've been working on adds a couple of javascript bits to the index.template file. In SMF I loaded the custom code into $context['javascript'] by way of a PHP file included in index.php, and from there it was simply a matter of tacking that onto the end of the code labeled "Here comes the JavaScript bits!". In ElkArte I'm confronted with a call to template_javascript(), so it almost looks like I'm going to have to learn everything from scratch.

Background: I've been working with SMF for a number of years, and learned PHP coding and related skills by reverse-engineering, mostly SMF. I'm a throwback, working on XP machines and doing my best to resist the constant need (?) to upgrade everything; I'm actually PROUD that I have decades-old clothes that still fit me! My HTML/CSS familiarity is largely circa HTML4, and some of the newer implementations, like "responsive" style sheets, are a mystery to me. I develop using xampp 1.74 and debug with Opera 9.

For what it's worth, I'm ECSTATIC (ex-static?) to have discovered this site, as while I find SMF much more intuitive to reassemble than any other CMS I've tampered with, I am NOT happy with it. Based on what I've read, this project is much more in line with where I think I'm going, and I would like to help!

Re: Custom theme... and then confusion set in

Reply #1 –

Hi and welcome. :)

Quote from: Cutter – and debug with Opera 9.
This may or may not be a problem depending on what Opera 9 supports (from time to time I use it as well, especially for javascript, but always less frequently because honestly is becoming largely obsolete and can miss some features, I'm not sure but it is likely to happen).

That said, the internal of the theming are not really that different from SMF (at least in 1.0, 1.1 has some new stuff, but the "core" is still basically the same, just heavily re-shaped), we just exposed much more the "variants" aspect (that is present in SMF as well), using it to separate "structure" from ... "colors". The idea of the default ElkArte theme is that index.css holds the structure of the page, while the variants CSSes (e.g. _light/index_light.css or _besocial/index_besocial.css) hold the colors of the theme.

The problem you were/are facing (i.e. index_light.css overriding your changes) is something that may have different root causes, maybe, just explain a bit more in details how you started working on the theme, for example: how did you create your new theme?

Quote from: Cutter – so it almost looks like I'm going to have to learn everything from scratch.
Some things are similar, some are pretty different. :P
If you want to add javascript, what I would suggest is... well, it kind of depends where you want to use that javascript and if you want to create it "in-line" or have a separated file.
But let's assume you want this javascript in each and every page, that is the easiest thing, and you want it in-line (later we can do the example for files, that is very similar).
My suggestion is to use the template_init function in index.template.php, you can add something at the beginning of the function:
Code: [Select]
function template_init()
{
	return array(
to have something like this:
Code: [Select]
function template_init()
{
	addInlineJavascript('alert(\'This is some javascript I added\');');

	return array(

Then if you want to also load a javascript file, you can do:
Code: [Select]
function template_init()
{
	loadJavascriptFile('my_js_file.js');
	addInlineJavascript('alert(\'This is some javascript I added\');');

	return array(
"my_js_file.js" should be in the "script" folder of your theme, of course.

You then do not need to care about where and when the js bit is added to the template, that's ElkArte's own problem.

Actually, you can control if the in-line js and the files are added/loaded in the head or just before the closing body tag passing true as second parameter of addInlineJavascript, or passing array('defer' => true) as second parameter of loadJavascriptFile, like this:
Code: [Select]
function template_init()
{
	loadJavascriptFile('my_js_file.js', array('defer' => true));
	addInlineJavascript('alert(\'This is some javascript I added\');', true);

	return array(
it depends on how you write your js, but by your description I guess you don't like jQuery and events, so you are probably going to use in-line functions a lot, so load the scripts in the head is what you probably want.
Last Edit: April 15, 2017, 03:28:04 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: Custom theme... and then confusion set in

Reply #2 –

Emanuele,

Thank you for the explanation about the javascript. That simplifies at least THAT part for me. However, that having been said I am running into some STRANGE issues I've never encountered before. Previously my theme porting attempt got as far as trying to combine the old CSS file with the new, and interleave the index.template customization with the default version. In SMF this was done automatically through the package installer, as I've been working on several different themes for my own use, each of which are compatible with the portal system I've been developing. As an aside, my package installer comments every change, for example by adding ##==>INSERT and ##==>END INSERT before and after newly inserted code, which makes it a bit easier to figure out where clashes occur. But anyway, although I can see my customization in the modified SMF index.template, even manually it's gonna take some time to weave it in there.

Here's an example of the type of problems I've been having. Since I got lost in all the changes I was making to the various CSS files, I decided to start over. So I replaced all the files in the new theme directory with the default files (CSS, images and index.template.php). Then I tried to track down where the variants come in, eventually finding the setting in the admin area. Then I tracked down 'ElkArte light' and 'Elarte Be Social!' to the language file in the default theme. Fair enough, but those variant names in the DEFAULT theme show up in the new theme. Next I tried adding my own variant folder; at this point I'm not sure what is and is not needed, but I'm just going with a folder named variant and containing a file named index_variant, and it - ALMOST - works.

Obviously, the variants are defined in the index.template. Not so obvious, going back to what I was doing earlier, is from where information is being pulled when the definition is deleted. But back to the present, I added the name of my variant, without the leading just like the others, and the theme variants disappeared. After much shuffling I discovered what was causing the problem, namely that my editor (Homesite 4.5) was set to save files in PC rather than Unix format. This was causing the theme variants not to be shown, even if all I did was copy the default file and save it with no changes. Winmerge reported the files as being identical (there was a size difference), Homesite didn't care, but for some reason, the file format (of a TEXT file) matters to the ElkArte system. (Never had this problem in SMF).

Anyway I much appreciate your help, I'm sorry for rambling, and please let me know how and when best to report such issues or how I can help in ElkArte's development. I realize I'm a bit of a maverick, and will do my best to conform, and will NOT be offended if told to just shut up and play in the corner. Oh, as to the Opera 9, first, I strive for backward compatibility, and second, I do check with other and newer browsers once everything looks like it's working.

Re: Custom theme... and then confusion set in

Reply #3 –

The variants "indexes" (i.e. the code-oriented name of the variant) are defined (like it was for SMF) in index.template.php, in the function template_init, at:
Code: [Select]
		// This is used for the color variants.
		'theme_variants' => array('light', 'besocial'),
so, if you want to use a new variant, you change this bit to something like:
Code: [Select]
		// This is used for the color variants.
		'theme_variants' => array('my_variant'),
of course, you are not forced to use variants at all, just leave an empty array:
Code: [Select]
		// This is used for the color variants.
		'theme_variants' => array(),
and Elk will ignore the variants. :)

Quote from: Cutter – Previously my theme porting attempt got as far as trying to combine the old CSS file with the new, and interleave the index.template customization with the default version. In SMF this was done automatically through the package installer,
So, if I got it right, in SMF you were basically creating mods to modify the default theme?
In general, even for SMF, I would suggest not to use this approach, because even tough you can better keep track of your changes, you'll face troubles at some point.
The best way is always to have a theme and use any custom file you'd need (index.template.php being the first to use).
And if you want to track the changes, you can always add comments in your new file. :)

Quote from: Cutter – But anyway, although I can see my customization in the modified SMF index.template, even manually it's gonna take some time to weave it in there.
If you mean port the changes from SMF to Elk, then I guess this is something that will take a bit of efforts regardless. :)

Quote from: Cutter – [...]
But back to the present, I added the name of my variant, without the leading _ just like the others, and the theme variants disappeared. After much shuffling I discovered what was causing the problem, namely that my editor (Homesite 4.5) was set to save files in PC rather than Unix format. This was causing the theme variants not to be shown, even if all I did was copy the default file and save it with no changes. Winmerge reported the files as being identical (there was a size difference), Homesite didn't care, but for some reason, the file format (of a TEXT file) matters to the ElkArte system. (Never had this problem in SMF).
Would you mind attaching here a non working file? I'd like to give it a try.
Please ,before attaching it, compress the file into a zip, just to be sure the attachment system doesn't mess with the new-lines.
Bugs creator.
Features destroyer.
Template killer.

Re: Custom theme... and then confusion set in

Reply #4 –

Emanuele,

Quote from: emanuele – Would you mind attaching here a non working file? I'd like to give it a try.
The file you requested is attached.

While I did find where in the index.template the variants are defined, I'm still trying to discover what happens when you do something unexpected. As I recall, removing the entire 'theme_variants' definition or using an empty array gave different results than what was defined in the theme stylesheet. I think there was also an issue when I strayed from the format of using a variant name in index.template and the name preceded with an underscore as the folder or index_variantname.css for the stylesheet. I will investigate all these things and once I figure something out, bring it to your attention. Please let me know if there's a more appropriate format or location for doing so.

Quote from: emanuele – So, if I got it right, in SMF you were basically creating mods to modify the default theme?

My SMF themes add a lot of custom code to the index.template file, causing many mods not to install. I manually patched the theme files to make the ones I use to work and then included the patched files to my own mod. This way I (hopefully) don't end up with multiple versions of manually patched theme files on a live server. Once I get ElkArte beaten into submission (sorry!  :-[ ) I will offer up my project(s) for inspection if anyone is interested.