I'm looking for information on how to add and connect to a custom css file in SMF 2.0 (RC1.2 currently).
While producing the MyStatus Mod (http://www.simplemachines.org/community/index.php?topic=342535.0), there are a bunch of new css controls I need to add for the layout of it's pages. All these controls are positioning oriented so the mod will still be theme universal. So I want to use my own css file, and not add to an existing css file that will most likely be changed when a theme is used on a forum that this mod is installed to.
The problem I'm having is, as hard as I look, I am not able to find where some of the existing css files are being called from.
For example, post.css or who.css
Those css file exist, but I cannot find the file that calls on them.
Basically, that's what I need to know. Where do I add a link to these files?
I know it can be done in index.template.php, but if it can be done more elegantly, I would like to do it the cleanest way possible.
Thanks!!
The cleanest way would be to add the <link> tag that calls for the stylesheet, and add that HTML inside $context['html_headers'].
Basically, just append your code to that array element (strictly append, not rewrite) somewhere in your action and it should be picked up by properly written themes.
Quote from: Arantor on October 28, 2009, 03:06:35 PM
The cleanest way would be to add the <link> tag that calls for the stylesheet, and add that HTML inside $context['html_headers'].
Basically, just append your code to that array element (strictly append, not rewrite) somewhere in your action and it should be picked up by properly written themes.
Can you be a little more specific?
Where is $context['html_headers'] located?
... and what exactly do you mean by...
Quote
(strictly append, not rewrite) somewhere in your action
I found this in Load.php
Is this what you are referring to?
// 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)
{
$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]) . ')';
}
}
}
Quote from: Arantor on October 28, 2009, 03:06:35 PM
The cleanest way would be to add the <link> tag that calls for the stylesheet,
... and where am I adding this <link> tag?
What template?
Index.template.php, like this:
// The ?rc1 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'], '/style.css?rc1" />
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/style', $context['theme_variant'], '.css?rc1" />';
echo '
<link rel="stylesheet" type="text/css" href="', $settings['default_theme_url'], '/css/print.css?rc1" media="print" />';
// IE7 needs some fixes for styles.
if ($context['browser']['is_ie7'])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['default_theme_url'], '/css/ie7.css" />';
// ..and IE6!
elseif ($context['browser']['is_ie6'])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['default_theme_url'], '/css/ie6.css" />
<script language="JavaScript" src="', $settings['theme_url'], '/scripts/topnav.js" type="text/JavaScript"></script>';
// Firefox - all versions - too!
elseif ($context['browser']['is_firefox'])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['default_theme_url'], '/css/ff.css" />';
Just add another link rel with whatever conditionals you want.
I give a Tip of My Hat to the SMF core coder who designed such a slick way of connecting to a custom CSS file.
You guys were close, but here's the super slick way of making your custom CSS file AUTOMATICALLY hook up in SMF 2.0 ...
1) Name your CSS file the same name as your main function in your template file.
2) Drop your CSS file into the CSS folder found in the default theme folder.
Your done.
That's it.
No edit to any files.
SMF 2.0 is built to take whatever the main function name is in the template file, and look for it's css file (of the same name) in the css folder.
Example:
SomeMod.template.php
function I_am_the_main_function()
CSS folder
I_am_the_main_function.css
If you had told me it was strictly for your custom action I would probably have suggested this, as it's used for the admin functions. However style invariably is used for more than just that and if any of it is used outside the custom pages (which, in fact, it often is) then it makes sense to make it more globally available.
To answer your previous question, $context['html_headers'] is an array element of the 'magical' $context, the one that gets global'd everywhere because at any given time it pretty much contains the state of SMF.
If you want to add custom stuff to <head>, there's the place to do it, e.g. custom Javascript for example.
I couldn't remember the syntax of <link> offhand and only had a limited amount of posting time earlier, but hoped you'd be able to see what I was referring to from index.template.php.
As for appending, I simply meant you must never:
$context['html_headers'] = whatever
This will destroy the existing contents. Instead:
$context['html_headers'] .= whatever
This will append the new items to the end of the existing.
Quote from: Arantor on October 28, 2009, 05:54:43 PM
As for appending, I simply meant you must never:
$context['html_headers'] = whatever
This will destroy the existing contents. Instead:
$context['html_headers'] .= whatever
This will append the new items to the end of the existing.
Is $context['html_headers'] .= whatever the same as $context['html_headers'][] = whatever?
So you guys can see the difference in what I'm asking, is .= the same as [] = in the question above?
No, quite quite different.
You add [] at the end when you're adding a new array entry. $context['html_headers'] is a string meaning you have to append to the end of it like a string. $context itself is an array, $context['html_headers'] is not.
wow... all so complicated for something oh so simple...
Say your stylesheet is called 'mystyle.css' and is located in the css directory... simply use the following code:
loadTemplate(false, 'mystyle');
Quote from: SlammedDime on October 28, 2009, 10:57:21 PM
wow... all so complicated for something oh so simple...
Say your stylesheet is called 'mystyle.css' and is located in the css directory... simply use the following code:
loadTemplate(false, 'mystyle');
Really?
Could it be that friggin easy :P
Boy, you just gave us all the smackdown.
So should
loadTemplate(false, 'mystyle'); be put in the Sources or Template file?
Source file :)
Perhaps, but you can also use my method for adding other stuff into the header such as inline Javascript should you need to.
I think it's great that we have all these ways posted here in one short topic.
I'm sure this will answer a lot of questions about this in the future, especially through site searches.
Great job guys ;D
... and thank you very much!!
Thanks, that just came in handy ;)
Both ways are good, and I prefer (for css thats only needed in custom pages) to use the loadTemplate('boo', 'css'); way.
However, if I'm creating a global mod, for example, one that provides a jquery floating bar, with tons of ajax features and stuff, I'd use Arantors method for both the CSS and javascript.
As to javascript in custom pages, I again, tend to use the other method Arantor suggested, which is appending the headers variable.
As with everything, it all depends on what you're doing. Some of the stuff I posted will come in very handy with what I have in mind shortly...
Quote from: Arantor on November 23, 2009, 01:21:33 PM
As with everything, it all depends on what you're doing. Some of the stuff I posted will come in very handy with what I have in mind shortly...
:o
Tell us more ;D
That would be telling... :P
Let's just say that when it's done it'll be in a class of its own, and if it does get approved (which I'm slightly hesitant about right now!) it'll be done by bending a rule or two.
Quote from: Arantor on November 23, 2009, 01:29:04 PM
That would be telling... :P
Let's just say that when it's done it'll be in a class of its own, and if it does get approved (which I'm slightly hesitant about right now!) it'll be done by bending a rule or two.
Now surely thats not allowed :D
You may be on the Customizer Team, but don't think you can go breaking the rules ! ;D
OK, here's a hint.
The package I'm working on uses AJAX to callback to the forum. But for that, SSI.php is way too expensive to run any more than 'occasionally', so I wanted to use the SMF API file (see Download/Tools) but it isn't ready for 2.0.
So yesterday I sat and ported it to 2.0, including adding PostgreSQL support to it as well. Depending on the testing and feedback I think it's safe to use *that* since it's as close to an official lightweight SSI.php as I can get without breaching the coding guidelines, since it is multi backend the way I coded it.
The one thing that worries me is that it sets a precedent for not using $smcFunc, which also does string cleaning - while my version of SMF API doesn't. But (personally) IMO that's no different to modding on 1.1 where mod authors have to do their own string cleaning anyway.
Quote from: Arantor on November 23, 2009, 01:49:03 PM
OK, here's a hint.
The package I'm working on uses AJAX to callback to the forum. But for that, SSI.php is way too expensive to run any more than 'occasionally', so I wanted to use the SMF API file (see Download/Tools) but it isn't ready for 2.0.
So yesterday I sat and ported it to 2.0, including adding PostgreSQL support to it as well. Depending on the testing and feedback I think it's safe to use *that* since it's as close to an official lightweight SSI.php as I can get without breaching the coding guidelines, since it is multi backend the way I coded it.
The one thing that worries me is that it sets a precedent for not using $smcFunc, which also does string cleaning - while my version of SMF API doesn't. But (personally) IMO that's no different to modding on 1.1 where mod authors have to do their own string cleaning anyway.
Ahh I see ..
Well good luck, and I hope it passes!
Well, the API is incomplete; it only has two of the three backends, and it caused a stir because of how it does things. But we'll wait and see. Even if it doesn't, I have the mod for my own use and the API for my larger project.
Quote from: Arantor on November 23, 2009, 02:07:16 PM
Well, the API is incomplete; it only has two of the three backends, and it caused a stir because of how it does things. But we'll wait and see. Even if it doesn't, I have the mod for my own use and the API for my larger project.
Well I don't quite know what it will be used for, but if it would be any use to me, even if it doesn't pass, your still allowed to give the source away right ?
I can but I'm not happy about doing so yet. I'm reasonably happy with how the MySQL stuff works, but PostgreSQL amounts to 'untested'.
PLUS, it's much much easier to have vulnerabilities here, because it is little more than raw mysql_query and pg_query statements.
Quote from: Arantor on November 23, 2009, 02:12:52 PM
I can but I'm not happy about doing so yet. I'm reasonably happy with how the MySQL stuff works, but PostgreSQL amounts to 'untested'.
PLUS, it's much much easier to have vulnerabilities here, because it is little more than raw mysql_query and pg_query statements.
Thats fine. I don't need it right now (I don't even know what it does!) I was just checking if it was still ok to give it to people if it failed.
SMF API is like an uber-lite version of SSI, but geared less to displaying content and more to integrating the code elsewhere.
Gives you the ability to authenticate a user, a function for creating a new user (without manually worrying about the DB structure) manually create the cookie, that kind of thing.
Quote from: Arantor on November 23, 2009, 02:20:25 PM
SMF API is like an uber-lite version of SSI, but geared less to displaying content and more to integrating the code elsewhere.
Gives you the ability to authenticate a user, a function for creating a new user (without manually worrying about the DB structure) manually create the cookie, that kind of thing.
Ahh I see.
I can see some uses in that, for a stand alone project I am making.