Welcome to Geeklog, Anonymous Saturday, December 21 2024 @ 08:48 am EST
Geeklog Forums
plugin stylesheets
Status: Banned
machinari
Forum User
Full Member
Registered: 03/22/04
Posts: 1512
just a quick note for plugin developers...
to make installing your plugin less confusing for joe user and more convenient for those who run multiple themes, make use of the function plugin_getheadercode_pluginname() in your plugin's functions.php file to deliver an extra stylesheet link to the page's header code.
no more need to copy a plugin's style sheet to every theme in the layout dir.
This function will shoot additional header information to the page being built. In the case of any extra style rules, such as we see with the forum for example, this function can add a link to the plugin's style sheet and those rules will be followed in addition to your regular theme's rules.
just need to make sure your plugin's stylesheet is in a world-readable dir.
and don't use the title attribute for this link--you want a persistant style, not an alternate style.
here is an example
the function:
* This function is called from COM_siteHeader and will return additional Header information
* This can be Javascript functions required for the plugin or extra Metatags
*
* @return string returns a concatenated string of all plugins extra header code
*/
function plugin_getheadercode_myplugin()
{
global $_CONF;
//deliver custom style sheet
$style = '<link rel="stylesheet" type="text/css" href="'.$_CONF['site_url'].'/myplugin/myplugin.css" />';
return $style;
}
and the resulting header code:
<link rel="stylesheet" type="text/css" href="http://mysite.com/myplugin/myplugin.css" />
to make installing your plugin less confusing for joe user and more convenient for those who run multiple themes, make use of the function plugin_getheadercode_pluginname() in your plugin's functions.php file to deliver an extra stylesheet link to the page's header code.
no more need to copy a plugin's style sheet to every theme in the layout dir.
This function will shoot additional header information to the page being built. In the case of any extra style rules, such as we see with the forum for example, this function can add a link to the plugin's style sheet and those rules will be followed in addition to your regular theme's rules.
just need to make sure your plugin's stylesheet is in a world-readable dir.
and don't use the title attribute for this link--you want a persistant style, not an alternate style.
here is an example
the function:
Text Formatted Code
/*** This function is called from COM_siteHeader and will return additional Header information
* This can be Javascript functions required for the plugin or extra Metatags
*
* @return string returns a concatenated string of all plugins extra header code
*/
function plugin_getheadercode_myplugin()
{
global $_CONF;
//deliver custom style sheet
$style = '<link rel="stylesheet" type="text/css" href="'.$_CONF['site_url'].'/myplugin/myplugin.css" />';
return $style;
}
and the resulting header code:
Text Formatted Code
<link rel="stylesheet" type="text/css" href="http://mysite.com/layout/mytheme/style.css" title="cps"><link rel="stylesheet" type="text/css" href="http://mysite.com/myplugin/myplugin.css" />
8
11
Quote
Status: offline
Blaine
Forum User
Moderator
Registered: 07/16/02
Posts: 1232
Location:Canada
This is one of the reasons I added the getheadercode API and as you point out would make it easier for users to install. The API's primary reason is to allow plugin developers to include needed Javascrript functions or includes.
Using this API to include a plugin specific CSS file will save coping a style sheet to each theme if users only have one theme - otherwise they may need to tweak the plugin CSS for each theme. They would not be able to do so if the CSS was being loaded from the same location for all themes. If the themes are similar it may not matter.
I've had plugins with their own CSS file but moved back to having users copy the CSS into the theme's style.css file because I was starting to re-use a lot of the same CSS declarations and users generally were getting familiar with the style.css file and it was the most flexible.
I have been reworking the CSS that I use for many months as part of my plugin development and strongly feel the best option for this is for plugin developers to standardize on a common set of CSS. I made a recommendation to the plugin developers list several months ago and posted the recommended CSS. I think it can handle the most needed cases and I've used it for example in my recent forum plugin work. I think if it can work there - it should work for most plugins.
The big advantage with approach for users is that they only need to alter the CSS once and all plugins would be themed
These CSS declarations will be part of the next base GL release theme. We can add or tweak this CSS based on input. I'm not a CSS guru so anyone that is or a wana-be guru may want to review and comment.
/* New Plugin CSS Declarations */
.pluginBG { background-color: #1C1E2D; }
.pluginTitle { color: #1C1E2D; background-color:#EFEFEF; font-weight: bold; font-size: 11px; font-family: Verdana, sans-serif; }
.pluginHeader { color: #FFFFFF; font-weight: bold; font-size: 100%; background-color: #767D8D; }
.pluginFooter { background-color:#EFEFEF; }
.pluginAlert { padding:5px 15px 5px 15px; color:#D8010E; background-color: #FEF1B4; font-weight:bold;}
.pluginSolidOutline { background-color: #396998; }
.pluginSolidFill { background-color: #1A3955; }
.pluginCellTitle { color: #1C1E2D; font-weight: bold; font-size: 10px; font-family: Verdana, sans-serif; background-color: #E5E5EA; }
.pluginCellFill { background-color: #E5E5EA; }
.pluginCellText { color: #000; font-weight: plain; font-size: 75%; font-family: Verdana, sans-serif; background-color: #F7F7F7; }
.pluginTinyText { font-size:70%; }
.pluginSmallText { font-size:80%; }
.pluginMediumText { font-size:85%; }
.pluginLargeText { font-size:90%; }
.pluginRow1 { background-color: #F7F7F7; }
.pluginRow2 { background-color: #E5E5EA; }
.pluginRollOver { color: #1C1E2D; background-color: #E5E5EA; text-align: left; font-weight: plain; font-size: 100%; font-family: Verdana, sans-serif; }
.pluginRollOut { color: #1C1E2D; background-color: #F7F7F7; text-align: left; font-weight: plain; font-size: 100%; font-family: Verdana, sans-serif; }
.pluginLinks A:link { color: #0000FF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginLinks A:visited { color: #1E1E8E; font-style: normal; font-weight: plain; text-decoration: none }
.pluginLinks A:hover { color: #0000FF; font-style: normal; font-weight: plain; text-decoration: underline }
.pluginBreadCrumbs, .pluginBreadCrumbs A:link { color: #EFEFEF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginBreadCrumbs A:visited { color: #EFEFEF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginBreadCrumbs A:hover { color: gold; font-style: normal; font-weight: plain; text-decoration: none }
A.pluginButton:link, A.pluginButton:visited {
color: #000;
text-align: center;
padding-top: 2px;
display: block;
height: 19px;
text-decoration: none;
background-color: transparent;
}
A.pluginButton:hover {
color: blue;
text-align: center;
padding-top: 2px;
background: center url(navbar/images/button_over.gif);
background-repeat: repeat-x;
display: block;
height: 19px;
text-decoration: none;
background-color:
transparent;
}
Geeklog components by PortalParts -- www.portalparts.com
Using this API to include a plugin specific CSS file will save coping a style sheet to each theme if users only have one theme - otherwise they may need to tweak the plugin CSS for each theme. They would not be able to do so if the CSS was being loaded from the same location for all themes. If the themes are similar it may not matter.
I've had plugins with their own CSS file but moved back to having users copy the CSS into the theme's style.css file because I was starting to re-use a lot of the same CSS declarations and users generally were getting familiar with the style.css file and it was the most flexible.
I have been reworking the CSS that I use for many months as part of my plugin development and strongly feel the best option for this is for plugin developers to standardize on a common set of CSS. I made a recommendation to the plugin developers list several months ago and posted the recommended CSS. I think it can handle the most needed cases and I've used it for example in my recent forum plugin work. I think if it can work there - it should work for most plugins.
The big advantage with approach for users is that they only need to alter the CSS once and all plugins would be themed
These CSS declarations will be part of the next base GL release theme. We can add or tweak this CSS based on input. I'm not a CSS guru so anyone that is or a wana-be guru may want to review and comment.
Text Formatted Code
/* New Plugin CSS Declarations */
.pluginBG { background-color: #1C1E2D; }
.pluginTitle { color: #1C1E2D; background-color:#EFEFEF; font-weight: bold; font-size: 11px; font-family: Verdana, sans-serif; }
.pluginHeader { color: #FFFFFF; font-weight: bold; font-size: 100%; background-color: #767D8D; }
.pluginFooter { background-color:#EFEFEF; }
.pluginAlert { padding:5px 15px 5px 15px; color:#D8010E; background-color: #FEF1B4; font-weight:bold;}
.pluginSolidOutline { background-color: #396998; }
.pluginSolidFill { background-color: #1A3955; }
.pluginCellTitle { color: #1C1E2D; font-weight: bold; font-size: 10px; font-family: Verdana, sans-serif; background-color: #E5E5EA; }
.pluginCellFill { background-color: #E5E5EA; }
.pluginCellText { color: #000; font-weight: plain; font-size: 75%; font-family: Verdana, sans-serif; background-color: #F7F7F7; }
.pluginTinyText { font-size:70%; }
.pluginSmallText { font-size:80%; }
.pluginMediumText { font-size:85%; }
.pluginLargeText { font-size:90%; }
.pluginRow1 { background-color: #F7F7F7; }
.pluginRow2 { background-color: #E5E5EA; }
.pluginRollOver { color: #1C1E2D; background-color: #E5E5EA; text-align: left; font-weight: plain; font-size: 100%; font-family: Verdana, sans-serif; }
.pluginRollOut { color: #1C1E2D; background-color: #F7F7F7; text-align: left; font-weight: plain; font-size: 100%; font-family: Verdana, sans-serif; }
.pluginLinks A:link { color: #0000FF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginLinks A:visited { color: #1E1E8E; font-style: normal; font-weight: plain; text-decoration: none }
.pluginLinks A:hover { color: #0000FF; font-style: normal; font-weight: plain; text-decoration: underline }
.pluginBreadCrumbs, .pluginBreadCrumbs A:link { color: #EFEFEF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginBreadCrumbs A:visited { color: #EFEFEF; font-style: normal; font-weight: plain; text-decoration: none }
.pluginBreadCrumbs A:hover { color: gold; font-style: normal; font-weight: plain; text-decoration: none }
A.pluginButton:link, A.pluginButton:visited {
color: #000;
text-align: center;
padding-top: 2px;
display: block;
height: 19px;
text-decoration: none;
background-color: transparent;
}
A.pluginButton:hover {
color: blue;
text-align: center;
padding-top: 2px;
background: center url(navbar/images/button_over.gif);
background-repeat: repeat-x;
display: block;
height: 19px;
text-decoration: none;
background-color:
transparent;
}
Geeklog components by PortalParts -- www.portalparts.com
14
12
Quote
Status: Banned
machinari
Forum User
Full Member
Registered: 03/22/04
Posts: 1512
yes yes, good call. your plan to include those styles (properly named) is an excellent idea. It adds what will be a convenient and well used standard.
My thinking was that if you were to include the plugin's css link then you would have to make sure that your rules were properly named and defined (esp. with regard to color) so as to not overwrite any standard rules already declared (much like your forum rules are properly named), or to intrude to much into themes of significantly different color or layout schemes. Otherwise, as you have implied, problems would creep in from theme to theme.
Guess I should rename my style rules
perhaps this idea for including the extra css would still be useful for very specialized situations where a plugin's inclusion of a style would accomodate a necessary format, for example, if it was necessary to use a drop cap in the 2nd paragraph on 3 of 5 plugin pages (ok, so that is a bad example, but you see the point I'm sure). On the other hand, the ability to encorporate more than one class per element makes this that much less necessary.
I think I just argued myself out of this idea.
My thinking was that if you were to include the plugin's css link then you would have to make sure that your rules were properly named and defined (esp. with regard to color) so as to not overwrite any standard rules already declared (much like your forum rules are properly named), or to intrude to much into themes of significantly different color or layout schemes. Otherwise, as you have implied, problems would creep in from theme to theme.
Guess I should rename my style rules
perhaps this idea for including the extra css would still be useful for very specialized situations where a plugin's inclusion of a style would accomodate a necessary format, for example, if it was necessary to use a drop cap in the 2nd paragraph on 3 of 5 plugin pages (ok, so that is a bad example, but you see the point I'm sure). On the other hand, the ability to encorporate more than one class per element makes this that much less necessary.
I think I just argued myself out of this idea.
15
11
Quote
Status: offline
drshakagee
Forum User
Full Member
Registered: 10/01/03
Posts: 231
I really like the idea of plugins using standard CSS but I use a lot of id's instead of classes, and although its valid to have both a class and and id on the same item it just seemed like more work to me. On the other hand my style sheets are getting ridiculously large though so I have to do something soon.
Every theme I have is different to the point where the style sheet needs to be adjusted accordingly and adding a few lines to the theme's style sheet seems the easiest way to do this.
Adding styles to the header code in the functions.inc file isn't really a good option because as Blaine pointed out there are quite a few differences between themes.
Yes I am mental.
Every theme I have is different to the point where the style sheet needs to be adjusted accordingly and adding a few lines to the theme's style sheet seems the easiest way to do this.
Adding styles to the header code in the functions.inc file isn't really a good option because as Blaine pointed out there are quite a few differences between themes.
Yes I am mental.
10
14
Quote
All times are EST. The time is now 08:48 am.
- Normal Topic
- Sticky Topic
- Locked Topic
- New Post
- Sticky Topic W/ New Post
- Locked Topic W/ New Post
- View Anonymous Posts
- Able to post
- Filtered HTML Allowed
- Censored Content