Serendipity Forums

Hi,

I'm guessing it's not possible, but please correct me if I'm wrong after trying to figure it out myself:

Is is possible to check within a tpl file if a certain file used in that tpl files even exists? An example from Bulletproof's plugin_calendar.tpl: Is it possible to include some kind of fallback, i.e. something like "If {$template_option.colorset}_back.png exists, use it. If not, use back.png"?

YL

Hi!

That's not possible, it wouldn't also be very wise, because ever extra filesystem check costs extra. So a fallback should IMHO better be solved by providing a template option, if really, really required.

Regards,
Garvin

garvinhicking wrote:That's not possible

I thought so. Thanks. Hmpf.

garvinhicking wrote:So a fallback should IMHO better be solved by providing a template option, if really, really required.

It's not really, really required. It just would've been nice

EDIT: I fixed it using a theme option now, since it's still nice to have it

YL

For a fallback when no colorset actually exists, how about this: Garvin's new code looks for available css files, always expecting to see color_style.css. It then displays everything before "_style.css" as the available colorsets and stores that info in the database. If the code would continue to display that color name only, but actually store "color_" (ie, including the underscore) then our single expression of {$template_option.colorset}_forward.png" could be changed to {$template_option.colorset}forward.png" which should evaulate to just "forward.png" if the colorset variable is blank (ie, the template does not actually contain any colorsets). We don't have to worry about the case of an image truly missing - the alt tag is displayed which should be a reasonable warning to a designer that they need to create a colorset specific image. Whatcha think?

Don Chambers wrote:Whatcha think?

I think it sounds great, but I also think it's Garvin's call. Maybe there are some performance pennies wasted, I don't know

YL

I cannot imagine any performance hit.

Don Chambers wrote:I cannot imagine any performance hit.

I don't think so, either, but with grandma's performance pennies, you never know

However, this needs more than my baby PHP. Garvin's code needs to be altered to actually use two arrays - one for the actual colorset name to be used for those $template_option.colorset calls in the tpl files and one for the colorset "description", if you will, to be used for the colorset dropdown box in the theme options. We could actually do with the current code slightly altered, but then we'd have "purple_" etc. in the dropdown box. It's a fallback option, but a workaround would be better.

I don't even know if that's possible at all, but that's probably due to my poor PHP knowledge. I'm sure Garvin (Or someone else? Anyone?) can fix this.

YL

Hi!

I believe Don contacted me privately about this. I'm sure he'll talk my offered solution through with you, yellowled?

BTW: It's so nice to catch up the "grandma's performance pennies" in these boards once in a while. Puts a smile on my face

Regards
Garvin

Garvin - The issue I contacted you about via PM has nothing to do with this request.

This started as a way to provide a default icon for our calendar arrows and graph bars if a)a colorset is defined, but the author did not create unique icons, or b) colorsets are not used, therefore there is no value for for $colorset.

We have already ruled out checking to see if a file exists due to the performance hit.

So now we are down to just covering the possibility that no colorset exists because a template is a single color.....

Now I am beginning to wonder if that scenario will actually exist. Regardless of color, we are currently loading at least 2 stylesheets (base.css and style.css) before the actual color (ie, blue_style.css).

If someone produces their own template based on bp, and only wanted a single color, they are most likely going to produce a replacement for the color stylesheet, and leave base.css and style.css in tact. Otherwise, they will end up adding their unique rulesets, most likely to style.css, then probably strip out the code in the various tpl's that deals with colorsets. MUCH easier to simply have a mycolorname_style.css file than to go through that - unless their template design actually uses its own unique tpls for some other reason.

So, I say forget my original suggestion. We can test for a blank value in $colorset and load the normal default icons, or we can move forward with YL's new template option to always use default icons. The limitation to the additional template option is that it only applies to arrows and the graphbar - not the xml icon, which is swapped via css and reverts to the default xml.gif simply by not providing the css to change it.

Don Chambers wrote:We can test for a blank value in $colorset and load the normal default icons, or we can move forward with YL's new template option to always use default icons. The limitation to the additional template option is that it only applies to arrows and the graphbar - not the xml icon, which is swapped via css and reverts to the default xml.gif simply by not providing the css to change it.

Hm. I think I got your original suggestion completely wrong ... The problem I meant is this: suppose someone has added his own colorset color_style.css, but not provided /img/color_*.png. That is the case I'd like to have a fallback for, and as far as I can see now (around midnight, meaning I could be completely wrong ), the suggestion with the "moved underscore" doesn't work. Bottom line seems to be that the theme option to use default icons is the best we can do, right?

YL

While a designer can change the default value of that new option to "yes", a user can switch it to "no" and once again be left with no icons.

The fallback, IMHO, is the alt tag. If a designer creates mycolor_style.css, and fails to provide icons (ie mycolor_back.png), they should see the alt tag as a warning and either copy the defaults we have back.png, forward.png, etc) to their colorset name, or provide their own.

Afterall, outside the bp world, what happens if the icons are not provided??? Alt tags!!!

I say we are exhausting too much energy on this issue. Leave just the one way of handing it (ie {$template_option.colorset}_back.png ) and stop trying to provide a safety net for something that should not be a problem for a competent designer. I think it was you that told me once that "it's bulletproof - not idiotproof"!!!

Don Chambers wrote:I think it was you that told me once that "it's bulletproof - not idiotproof"!!!

Right, although I should've never expressed it that way Okay, deal. I'll remove the deficons option from svn right now.

YL