Bulletproof - changing the background

[user1234]

Hi,

I confess I am somewhat stumped. Can someone please fill me in how to not only change the body background color (that I managed in default-style.css), but also add a background graphic? I've searched here, but none of the older tips work.

Also, is there a reason why I can't simply replace the navbar image with one of whichever title and format? I managed to change it, but ONLY after I used the same name as the old one and PNG-format. I would have preferred .jpg format instead, but S9y is not accepting that.

While we are at it, can someone of those in the know explain the rationale behind making such stuff that difficult and above all different from other CMS? It's a tiny bit frustrating to have to ask about such changes which - by all means - ought to be a piece of cake instead...

Cheers,

Dachs

[Don Chambers]

Dachs....

Any chance you can provide a URL to your site.. it is often much easier to answer questions when we can see the actual site.

[user1234]

Hi Don,

sorry, but nope, not possible, the site is on the sandbox on my computer and not yet live on a server. I can assure though that this setup is in no way different from any normal server setup. I've been building and setting up quite a few CMS locally before.

What kills me is that right now s9y is absolutely not behaving as a CMS with CSS-driven templating should. E.g. I'm currently trying to set a background for the footer. By all means a change to #footer ought to do the trick. Not. It takes my color change, but it will not display a background jpg. Same with the body background. It takes color, but no picture.

It's not as if I haven't styled a CMS before either, and I've been filching the docs for reasons for this kind of behaviour, but no such luck. I have the suspicion that some plugin is messing with what can be used and what not, but I also can't pinpoint which one that would be. It's quite simply frustrating.

Cheers

Dachs

[user1234]

Hi,

by now I'm somewhat deeper into the problem...

Indeed, Bulletproof appears to exclusively work with PNGs on template level except for the header image. I've converted my files, they display now, but I hate to have my arm twisted right up to the neck by software. Where can I turn this "only PNG" feature off, please?

The footer in Bulletproof apparently does not parse the relative path (/img/abc.png) like the rest of the template, so you need a full path to get a display.

What I also noted is that images in the content area, like e.g. the social bookmarks stuff, get loaded way ahead of basic design images. Is there a handy way to turn this around? Or what else would you suggest? The reason being that I already can see every single content area image, including those in articles, loading way ahead of basic template stuff, which wouldn't really be nice. How has everyone else solved that problem?

Cheers

Dachs

[yellowled]

Can someone please fill me in how to not only change the body background color (that I managed in default-style.css), but also add a background graphic? I've searched here, but none of the older tips work.

A) You should supply code examples by any means if you can't show your live blog. It's kind of hard to figure out what you might be doing wrong without having any idea what you're doing at all.

B) You shouldn't make those changes in the default_style.css. You should either create your own colorset or use the user.css for changes. user.css is usually the better solution if there are only some minor changes.

c)

Code: Select all

body { background: #000 url(PATH-TO-IMG) top left repeat);

should work. Doesn't work in your case?

Also, is there a reason why I can't simply replace the navbar image with one of whichever title and format? I managed to change it, but ONLY after I used the same name as the old one and PNG-format. I would have preferred .jpg format instead, but S9y is not accepting that.

In fact, you should be able to. Might always be due to your local setup, might be because of the CSS cascade. Again, we can't really help you without further details, i.e. code examples.

While we are at it, can someone of those in the know explain the rationale behind making such stuff that difficult and above all different from other CMS? It's a tiny bit frustrating to have to ask about such changes which - by all means - ought to be a piece of cake instead...

I don't think we should be held responsible for the difficulties behind HTML, CSS, xampp or other stuff. In fact, I can't remember anyone having the same problems you have, especially not with BP.

YL

[yellowled]

Where can I turn this "only PNG" feature off, please?

There is no "PNG only feature".

The footer in Bulletproof apparently does not parse the relative path (/img/abc.png) like the rest of the template, so you need a full path to get a display.

That's very likely not the footer but because you're using default_style.css. Again, please provide code examples including the name of the CSS file you're editing.

What I also noted is that images in the content area, like e.g. the social bookmarks stuff, get loaded way ahead of basic design images. Is there a handy way to turn this around?

It could help to merge the CSS files, but that's way against the design principle of BP.

Again, you're the first one to report this, like, ever. It's probably because of your slow dial-up connection.

YL

[user1234]

Hi,

There is no "PNG only feature".

Well, neither GIFs nor JPGs work at all, only PNGs.

That's very likely not the footer but because you're using default_style.css. Again, please provide code examples including the name of the CSS file you're editing.

I am using a standard installation of Bulletproof and a standard installation of s9y with a couple of added plugins.

Right now the only things I changed are colors and insertion of background pictures for sitenav, body and #footer. And yes, I am using default_style.css. Why would using yet a FOURTH stylesheet make any difference? Doesn't default_style get parsed as it should be parsed and how come?

Again, you're the first one to report this, like, ever. It's probably because of your slow dial-up connection.

There is no dialup between my comp and xampp! Still it is noticable what gets loaded first, and the content pictures get loaded first.

should work. Doesn't work in your case?

It works, but only using PNG, not using anything else.

I don't think we should be held responsible for the difficulties behind HTML, CSS, xampp or other stuff.

Well, I have no trouble whatsoever styling any other CMS on that setup, so it's definitely not the setup. I also have yet to meet with another CMS not taking all sorts of formats for images, this is a real first for me and I've been through quite a few.

The plugins I am using are (always latest issues):

Quicksearch, Categories, Recent Entries, Comments, Linklist, Syndicate this blog, Tagcloud, Currently, Adsense, Blog Administration, Markup Serendipity, Markup Emoticons, Markup NL2BR, Browser Compatibility, Spam Protector, Announce Entries, Static Pages, HTML Meta Tags, Karma, Statistics, Links to Digg etc., Contact Form.

The blog is set to deliver gzipped content. The header has a background image set via the blog administration and that's the only JPG which works. Also set is an own footer text and a counter.

So there's, at least from what is my experience, nothing which would cause such behaviour.

Cheers,

Dachs

[garvinhicking]

Hi!

Have you tried loading the JPGs that do not work inside your browser? I.e. through http://localhost/serendipity/templates/ ... icture.jpg? I believe it might be a generall access problem with your files, and be not really related to the template options themselve.

The browser usually requests all inline pictures (through <img ...>) before any StyleSheets are fully parsed and loaded. So this discrepancy is something that happens because inline pictures are available for the browser much sooner than any CSS referenced images. However, once the CSS and the referenced pictures are cached inside your browser, all things should load up much faster. Remeber that any time you use F5 to reload a page, the browser also refreshes it cache, so you will see a much more noticable lag than later, when no more changes will be made that require you to refresh the page.

Apart from that, I agree to yellowled. It would be inredibly helpful for us to see the exact CSS that you entered, and very importantly, at which place/line you changed it.

The plugin listing you mentionied is helpful, there are no plugins that could be involved with CSS parsing ("Extended properties for Categories" or "Templatechooser" or "Kubrick head image" would be great candidates of conflicting plugins).

HTH,
Garvin

[yellowled]

And yes, I am using default_style.css. Why would using yet a FOURTH stylesheet make any difference? Doesn't default_style get parsed as it should be parsed and how come?

Well, first of all, using your own colorset would not include another stylesheet. YOURSTYLE_style.css would be included instead of default_style.css Second, there is absolutely no harm in using multiple stylesheets. Usually

There is actually a difference in the parsing of stylesheets -- style.css is parsed differently, because it is "merged" (by s9y) with the plugin styles, becoming serendipity.css (not physically, but dynamically). Therefore, you can use {TEMPLATE_PATH} in style.css, but not in the other stylesheets included w/ BP.

There is no dialup between my comp and xampp! Still it is noticable what gets loaded first, and the content pictures get loaded first.

That, as well as the PNG-only stuff, sounds much more likely to be a xampp problem than a BP problem. Unfortunately, my experience with xampp is limited at best.

Well, I have no trouble whatsoever styling any other CMS on that setup, so it's definitely not the setup. I also have yet to meet with another CMS not taking all sorts of formats for images, this is a real first for me and I've been through quite a few.

I have built and ported a lot of s9y templates, and I assure you, you can use all types of image formats in s9y templates as well as the entries of the blog

The blog is set to deliver gzipped content.

Hm. Maybe that's the problem? Have you tried to deliver it w/out gzip compression? (My experiences with gzip compression are outdated, but not too good. Can't remember what the problem was, though.)

YL

[yellowled]

The browser usually requests all inline pictures (through <img ...>) before any StyleSheets are fully parsed and loaded. So this discrepancy is something that happens because inline pictures are available for the browser much sooner than any CSS referenced images.

There might be similar performance discrepancies between images referenced in actual stylesheets and inline styles (which are unavoidable in BP for various features), but those should be barely noticable, especially on a local xampp ...

YL

[Don Chambers]

I just took a copy of bulletproof, on a localhost XAMPP install, and set images using gif, jpg png-8 and png-24 formats... no problem with any of them.

[user1234]

Hi,

I just took a copy of bulletproof, on a localhost XAMPP install, and set images using gif, jpg png-8 and png-24 formats... no problem with any of them.

It definitely isn't the XAMPP install, which is set precisely as any server and never created any issues at all.

Well, first of all, using your own colorset would not include another stylesheet. YOURSTYLE_style.css would be included instead of default_style.css Second, there is absolutely no harm in using multiple stylesheets. Usually

Well, so why not call my user.css default_style.css then? I work from a full copy of that template anyway, so it's not as if I lost any information that way.

There is actually a difference in the parsing of stylesheets -- style.css is parsed differently, because it is "merged" (by s9y) with the plugin styles, becoming serendipity.css (not physically, but dynamically). Therefore, you can use {TEMPLATE_PATH} in style.css, but not in the other stylesheets included w/ BP.

Chuckling here actually. Template_Path works for the sitenav and the body, but not for the footer, all in the same stylesheet But at least that's some sort of explanation.

That, as well as the PNG-only stuff, sounds much more likely to be a xampp problem than a BP problem. Unfortunately, my experience with xampp is limited at best.

I'm currently developing a Textpattern blog on the same XAMPP install and there's no trouble with image formats, also no trouble in the CMSMS instance running there as well. It's only s9y.

Hm. Maybe that's the problem? Have you tried to deliver it w/out gzip compression? (My experiences with gzip compression are outdated, but not too good. Can't remember what the problem was, though.)

I'll change that and will see what happens.

Have you tried loading the JPGs that do not work inside your browser? I.e. through http://localhost/serendipity/templates/ ... icture.jpg? I believe it might be a generall access problem with your files, and be not really related to the template options themselve.

Yes, of course, first thing. They are all there alright, have all the proper permissions too.

The browser usually requests all inline pictures (through <img ...>) before any StyleSheets are fully parsed and loaded. So this discrepancy is something that happens because inline pictures are available for the browser much sooner than any CSS referenced images. However, once the CSS and the referenced pictures are cached inside your browser, all things should load up much faster. Remeber that any time you use F5 to reload a page, the browser also refreshes it cache, so you will see a much more noticable lag than later, when no more changes will be made that require you to refresh the page.

Anyone here who installed some preloading feature to counteract that? What would work better with s9y, a CSS or a javascript solution?

Cheers

Dachs

[yellowled]

Well, so why not call my user.css default_style.css then? I work from a full copy of that template anyway, so it's not as if I lost any information that way.

As I said before, user.css is usually recommended for minor changes only. If your changes are more than, say, 5 CSS statements, we usually recommend a seperate colorset since this is safe in case of an upgrade to either s9y or BP. If you're working with a copy of BP, you can of course do whatever you like, but default_style.css will be overwritten in case of an update. YOURSTYLE_style.css won't.

Chuckling here actually. Template_Path works for the sitenav and the body, but not for the footer, all in the same stylesheet But at least that's some sort of explanation.

Doesn't exactly surprise me given the things you report here, but unless you supply actual information (read: code), I'm afraid there's not much we can do to help you. Maybe Garvin can use his magical powers, but I'm running out of things to suggest as we speak.

Oh, wait: Which version of s9y are you running?

I'm currently developing a Textpattern blog on the same XAMPP install and there's no trouble with image formats, also no trouble in the CMSMS instance running there as well. It's only s9y.

What kind of proof is that supposed to be? Lot's of people are using s9y and BP without any problems with any kind of image format, including myself in a local development blog, and Don.

YL

[user1234]

Hi,

As I said before, user.css is usually recommended for minor changes only. If your changes are more than, say, 5 CSS statements, we usually recommend a seperate colorset since this is safe in case of an upgrade to either s9y or BP. If you're working with a copy of BP, you can of course do whatever you like, but default_style.css will be overwritten in case of an update. YOURSTYLE_style.css won't.

I will need to save apart all changes anyway before any update and as updates usually are manual, that will pose no problem.

Oh, wait: Which version of s9y are you running?

The latest full release (January 16th, 2009), 1.4.1

What kind of proof is that supposed to be?

Well, it proves that the XAMPP setup isn't interfering with CMS, CSS and database served images.

But I will try to kill that cache and gzipping later today and see what happens then. What is

Code: Select all

/plugin/pngbehavior.htc

?

Cheers,

Dachs

[garvinhicking]

Hi!

You should use Firefox + Firebug, open the "NET" tab and inspect whether the image files that don't work are requested at all, and if they are, check their HTTP header status.

I can only chime in with Don and YellowLED: This is not something on s9y's side, since all binary files come straight from the server, s9y is not touching those files at all. The only way this can get messed up if A) your server is not properly delivering files or B) your CSS does not properly reference the image path. Which is why the EXACT CSS code we requested a couple of times is REQUIRED for us to strike out that possibility.

Regards,
Garvin