zenphoto 1.4.3 dev

vincent3569

Hi

I did my firt successfull install of 1.4.3 dev.

whouaou ! you have done a wonderfull job : there is a lot of good improvements.

my themes need to be updated, but these are small things, nothing major.

acrylian: zpMobile seems to be good (3 reponsive themes, this is a good thing and users will have the choice between modern themes!)

acrylian

Thanks! Probably we/will make the other official themes a littlte responsive sometime, too.

Michel Gagnon

Was it an install from scratch or an update?
Because I tried it last weekend and it didn't install from scratch.

vincent3569

it was a migration

sbillard

Should install from scratch now.

vincent3569

hi

in France, we have this expression "Il ne faut pas vendre la peau de l'ours avant de l'avoir tué", that means "Don't count your chickens before they're hatched" in english...

so, I try to update zpArdoise to 1.4.3 for zenphoto 1.4.3, and I have a big, big headache.

2 functions doesn't work well on my theme, and I go crazy trying to figure out what's wrong

1- <?php printHomeLink('', ' » '); ?> works well on gallery and album, but doesn't work well on other pages (404, archives, contact, image, password, register, search)

in the second case, ' » ' is filtered, and the string is not displayed.

2- <?php printParentBreadcrumb('', ' » ', ' » '); ?>
works well on album, but doesn't work well on image

have a look here
- exemple 1 (ok with printHomeLink) : http://dev.vincentbourganel.fr/20110721-vacances-ete-pays-basque/
- exemple 2 (ko both with printHomeLink and printParentBreadcrumb) : http://dev.vincentbourganel.fr/20110721-vacances-ete-pays-basque/img_5559.jpg.html

what is the problem with these functions or with these characters ?

sbillard

We have the same saying in English. (Perhaps we got it from France during our revolution?)

The Garland theme uses the same function calls and separator characters so I have checked out the situation with it. Sadly, except for a misplaced `

` tag on the archive page everything looks and works correctly.

The only difference in these functions between 1.4.2 and 1.4.3 is that these separator parameters are html encoded before being output. This and the fact that there is NO characters appearing in your HTML where the separators should be leads me to believe there is something wrong with the function calls. Specially if it works on some pages and not on others as the functions themselves CANNOT change in that interval.

See also my test site running 1.4.3-DEV [9950] and the Garland theme with » as separators for both functions:

Album page: http://testalbum.sbillard.org/clocks/
Image page:http: //testalbum.sbillard.org/clocks/Ansonia.jpg.php
Archive page: http://testalbum.sbillard.org/page/archive

vincent3569

of course it's incredible BUT it is.

I have added this code
<?php echo html_encode(' » '); ?> in each file
as told before, it works on some file, and does'nt work on other file.

I did the same thing on zpmasonry 1.4.2.2 of gjr and the result is the same.

I added this code <?php echo html_encode(' > '); ?>, and it's work fine everywhere.

acrylian

In 1.4.3 all "print" function already do encode strings. So that might be the culprit (this will btw be noted on the release post).

sbillard

The most likely problem is that the script files that fail are not encoded in UTF-8.

vincent3569

how a file may be UTF-8 encoded and not another ?

sbillard

Depends on your text editor. But the character for » is differently encoded in UTF-8 than for instance Western European. Perhaps the PHP html encoding function throws out not UTF-8 characters. (The function resides in a Zenphoto script which will be encoded UTF-8.)

We use Eclipse as out PHP editor. It has options for the default character set.

acrylian

I also often use the free Textwrangler for Mac for quick edits or smaller things. It also has an option for the encoding.

vincent3569

Ok,
I found the option to encode in UTF-8 with NotePad++
But now, after reencode all files, I can't see any " » " on my website !
Of course, I checked the site charset is UTF-8.

sbillard

Sorry. But you should enable the Garland theme and see if it is showing the " » " characters. It does so on my installs. If it does on yours then the problem is somewhere within your theme. If those do not show then there must be some other problem, perhaps with the characterset defined for your install.

[edit] I did find this in the documentation for the htmlspecialchars() function which does the output encoding:
"If the input string contains an invalid code unit sequence within the given encoding an empty string will be returned, unless either the ENT_IGNORE or ENT_SUBSTITUTE flags are set."

We do not set either of these flags, so if the » character representation in your script is not valid the result would be exactly what you are seeing.

vincent3569

sbillard, thanks for you help

I compared the Garland files with mine.
I found a difference in the encoding of files: Garland is encoded with "UTF-8 without BOM" (I do not quite understand the difference between UTF-8).
I tried to encode my files with this mode, and this seems to solve the problem...

I'm still worried: your changes are very stricts and many users will be annoyed with encoding files.

vincent3569

In 1.4.3 all "print" function already do encode strings. So that might be the culprit (this will btw be noted on the release post).

now I have found the problem, note that some print functions do not html encode strings.

- printPageListWithNav(' « ', ' » ',...)
- printNewsPageListWithNav(' » ', ' « ', ...)

sbillard

I am sorry if you have a problem with characterset encodings. But unfortunately that is the way of the world. There are many different charactersets and they are not necessarily inter-compatible. Zenphoto operates internally in UTF-8 as that caracterset is the superset. This means that anything that supplies characters MUST supply UTF-8 characters. No getting around that. Of coures it is not required that the file be UTF-8, that is just the most convenient way of accomplishing this. You could always translate the strings prior to passing them to a Zenphoto function.

You should also note that the default for the browser header is that the characterset is UTF-8, so even if a theme script tries to display a not-UTF-8 character it will probably fail.

Thank you for pointing out the printPagelist, etc. Those functions should have caused the text to be encoded. This will be corrected in the nightly build. If you find more such instances, please bring them to our attention. It is the intention of the 1.4.3 release that all strings be html encoded prior to being output. This is required for HTML validation.

acrylian

Files should always be UTF8 without BOM. BOM is likely to cause issues especially on IE browsers (if I recall correctly). Info about that: http://en.wikipedia.org/wiki/Byte_Order_Mark

vincent3569

hi
new theme, new problem.
I try to update zpBootstrap for zenphoto 1.4.3, and I have a new problem with encoded string.

in album.php, I have this code :
`<?php printParentBreadcrumb('', '<span class="divider"> » ', ' » '); ?>`

with 1.4.2, I can easily insert the `` tag (needed for css rules).
how I can do the same thing with 1.4.3 ?

thanks for you help.

sbillard

You cannot. For this you will have to implement your own version of printParentBreadcrumbs. Those parameters are presumed to be text, not HTML.

vincent3569

we will lose a number of possibilities with this version...
for example, in some news, I put words in bold with tags, in the title of the news.
it will not be possible either, I suppose.

acrylian

Not if you use the "print" versions of functions. "get" versions or the object model return raw text.

sbillard

It is possible to process HTML markup in these functions. But it is expensive (computationally) because the functions would have to parse the string rather than just html encoding it.

We do have a function to parse strings for valid html and encode the rest--that is what is used for news and page content, for instance.

So the choices are:

1. do no encoding--this leaves HTML validation issues
2. encode the string--this means that you cannot pass markup
3. tag_encode the string--this means your gallery slows down.