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 #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.