Two small bugs (I think...)

[streeff]

Sorry, I am not on GitHub (yet)

1. Tags like {{ content.image|thumbnail(320, 240) }} do not seem to work when the filename of the image contains spaces.

2. I cannot get contenttype "divider" to work. I am now using

Code: Select all

        divider_home:
            type: divider
            label: Moet dit item op de homepage?
            line: true

[streeff]

(also note the fonts on the right hand side)

Maybe it is just a Chrome bug...

[Bob]

well, noone can blame you for not testing:

1 - Yes. Seems to be a bug. Added to github: https://github.com/bobdenotter/bolt/issues/156 On second thought.. Seems to work for me, so something else must be going on. Could you try this:

Code: Select all

{{ print(content.image) }}

, to see what name exactly it's using. then, check if that file is present in files/. Let me know, ok?

2 - "type: divider" is deprecated.. Is is still in the docs? Anyhow, you should do it like this now:

Code: Select all

        markdown:
            prefix: "This comes before"
            type: markdown
            postfix: "This comes after"


you can add postfix and prefix to any field. There's a slight bug in it, though. This won't work yet: 'postfix: "<hr>"'. I will fix that: https://github.com/bobdenotter/bolt/issues/157

3 - Chrome on Mac is my primary browser. No idea why it should do that. Have you tried updating? Mine is at Version 26.0.1386.0 now.

[streeff]

1. Sorry. Looks like something was wrong in my code or in the filerights or something. Thumb worked perfectly now, and FY the (in this case){{ print(record.sidebar_illustratie) }} gave

Code: Select all

str(28) "2013-01/factory_back (1).jpg"

2. 'divider' is (at time of writing) still mentioned here: http://docs.bolt.cm/content#field-definitions
Thanks for the update.

3. Hm, Chrome cheerfully says "Chrome has been updated" (is bijgewerkt) below my lower-than-yours version number. Maybe Den Haag receives updates before Amersfoort.
Anyway, assuming that the Chrome version, causes this, I don't think this is your concern.

[Bob]

1) Still, it _should_ escape spaces and other chars just to be sure. And it doesn't do that, so we're going to fix that.

2) Thanks! We'll update the docs! Added an issue to github for that: https://github.com/bobdenotter/bolt-docs/issues/12

3) It's still strange though.. Both the 'label' as well as the contents of the input are "Helvetica Neue". The labels show fine in your screenshot, but the textboxes don't. Odd.. Have you tried in Firefox or Safari? Does your system have "Helvetica Neue" installed?

Screen Shot 2013-01-31 at 5.21.44 PM.png (66.54 KiB) Viewed 615 times

[streeff]

You are right, it has something to do with the Helvetica Neue (which I have installed, Mac TrueType I think).
Chrome behaves well when I deselect the font-family preference in the HTML inspector window (shown below) and also when I just delete 'Helvetica Neue', in the css.





My Firefox definitely shows the inputfields in Neue Helvetica (doublechecked in Firebug).
Backend goes alright in Safari, but in Safari text looks like a (plain) Helvetica or Arial to me. (no 'Safari-Firebug-installed', so cannot check)

So maybe a -webkit-font-family without Helvetica Neue as last resort? Strange, though...

[Bob]

Safari has the developer toolbar built right in. Just right-click on the page, and choose "inspect element"

Could you try reversing the order in the ckeditor css? In app/view/lib/ckeditor/contents.css, near the bottom:

Code: Select all

/* Overrides for Bolt. */
.cke_editable {
    margin: 14px;
    font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
    font-size: 14px;
    line-height: 22px;
    color: #333333;
}


to:

Code: Select all

/* Overrides for Bolt. */
.cke_editable {
    margin: 14px;
    font-family: Helvetica,"Helvetica Neue",Arial,sans-serif;
    font-size: 14px;
    line-height: 22px;
    color: #333333;
}

[streeff]

I hope I make clear what I see:

in Firefox the font of the <input>'s are determined by
app/view/lib/ckeditor/contents.css line 103 - the one that you asked me to change.

Chrome on the other hand seems to obey
/app/view/css/bootstrap.min.css too - when I swapped the Helveticas here, all went well in the backend.

At some point I lost track of "which rule comes from which css/what comes from my browser cache" - time to stop tweaking. I hope this helped.

[Bob]

That's really odd. Are you sure that your "Helvetica Neue"'s are correct?

I mean, if it's broken in Twitter Bootstrap, I assume more people would've noticed, since it's used quite widely. Only reference to this problem i could find is here: https://github.com/twitter/bootstrap/issues/3629

could you try setting it to this, to see what happens?

Code: Select all

font-family:"Helvetica Neue Regular","Helvetica Neue",Helvetica,Arial,sans-serif;

[streeff]

I have never had Helvetica Neue Problems before, in print nor in Bootstrap, so I presume the font is OK.

My system says that I am using a 5,5 MB (it's a large family) Datafork TrueType font v 8.0d6e1, loaded from my system directory

Code: Select all

/Users/[myname]/FontExplorer X/Font Library/H/HelveticaNeue/HelveticaNeue.dfont

Applying

Code: Select all

font-family:"Helvetica Neue Regular","Helvetica Neue",Helvetica,Arial,sans-serif;

did not help. See below (and note that this one seems to come from "bootstrap.min.css according to Chrome inspector)



One more thing, to keep you off the street: the imagelist

I noticed that you can delete one image from the list and then save the page. You cannot not delete two images without saving the page between the first and the second delete action. Tested in Chrome and on Firefox.

(But even with that bug, the imagelist is a very pleasant way to make sliders.)