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!)

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

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

it was a migration

Should install from scratch now.

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- 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-
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 ?

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

of course it's incredible BUT it is.

I have added this code
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 , and it's work fine everywhere.

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).

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

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

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.

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

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.

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.

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.

Quote: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(' » ', ' « ', ...)

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.

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

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 :
``

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.