Piwigo Bugtracker

Viewing Issue Advanced Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000358 [Piwigo] display major always 2006.04.27 15:55 2006.05.26 17:39
Reporter photiolo View Status public  
Assigned To chrisaga
Priority normal Resolution fixed Platform
Status closed   OS
Projection none   OS Version XP SP2
ETA none Fixed in Version BSF branch (dev) Product Version 1.6.0RC1
  Target Version Product Build
Summary 0000358: Accent are not correctly displayed in category listing
Description In the category list, on the left pane, accent are displayed like this:
"La Réunion [63]"
Also, when browsing in category, category description have the same problem.
This problem does not appear in preceding version.
The problem do not appear in category display on top screen, neither in EXIF comment display for example.
Steps To Reproduce Just add a category with accent (actually mine was upgraded from 1.5, I dont know if a new one will have the problem)
Additional Information
Tags No tags attached.
browser any
Database engine and version
PHP version
Web server Apache 1.3.33
Attached Files

- Relationships
related to 0000291closedplg Expliciter l'encodage des caractères dans la trame HTTP 
has duplicate 0000361closed Affichage bizarre des apostrophes 
has duplicate 0000360closed Affichage des balise html dans le commentaire de catégorie 

-  Notes
(0000868)
plg (manager)
2006.04.27 16:42

Same kind of problem for me on every string modified by htmlentities. My database data are encoded in UTF8.
(0000869)
rvelices (developer)
2006.04.27 17:03

I think it is expected if language/browser encoding or MySql connection encoding (set names sql command) are not ISO-8859-1 because htmlentities without the 3rd parameter (charset) assumes ISO-8859-1.
(0000870)
chrisaga (developer)
2006.04.27 18:36

Cannot reproduce.
Did some tests. It seems that encoding of the database maters less than httpd default charset.
I had some oddities like "Nouvelle Catégorie" but nerver html entities displayed.
Please give encoding for :
- database
- httpd
- browser

We can always remove the use of htmlentities() but there is a problem if httpd default charset is set to UTF8. I think it's sets php to UTF8 too so it produces UTF8 strings in the middle of a latin-1 page.

Very tricky !
(0000871)
photiolo (reporter)
2006.04.27 19:28

I dont know exacltly how to know the encoding of all these things but,
I use EasyPhp and it says in system parameters Latin1 for database and server, utf8 for others.
My real site is on Free but I have not upgraded yet (for obvious reason). Maybe encoding is not the same on free ?

Regarding the browser, I tested with default setings on Opera and Maxthon (IE). Same result. For Httpd, dont know where to find it (Apache)

Anyway thanks for your support, I hope this helps.
(0000872)
plg (manager)
2006.04.27 19:30

- database : utf-8
- browser : utf-8

By default in PWG, encoding is iso-8859-1 but I forced the display in utf-8. Strings modified by htmlentities are badly displayed, others are correctly displayed.
(0000873)
chrisaga (developer)
2006.04.27 20:02

pierrick => what about the http server default charset ? If you set encoding to UTF8 in header.tpl, I think you must set it too for http server since we don't set the encoding in which php runs (is it settable ?)

photiolo => I don't know EasyPhp settings but I assume the following :
- database : latin1
- (Apache ?) server : latin1
what about the browser ?
(0000876)
plg (manager)
2006.04.27 20:10

chrisaga wrote:

> pierrick => what about the http server default charset ? If you set
> encoding to UTF8 in header.tpl, I think you must set it too for http
> server since we don't set the encoding in which php runs (is it
> settable ?)

The charset defined in the HTTP server has no influence if I want to overload it by setting the encoding in the HTTP request with PHP. Anyhow is set the charset of your server, it won't modify strings. No, the problem comes from the use of htmlentities. (I've worked a lot with encoding issues, at work mainly)

chrisaga, do you want me to open a discussion in the forum on this topic?
(0000877)
photiolo (reporter)
2006.04.27 21:46

Something that may help, here is the source code of the generated page:
./index.php?/category/28
We see that the & is translated wrongly to a &
(0000882)
chrisaga (developer)
2006.04.27 23:07

photiolo wrote :
>We see that the & is translated wrongly to a &

& is OK it's (normally) displayed as & by the browser

pierrick :
You are right, the strings are OK, it's just the browser wich get the wrong charset (setting it mually fixes the pb).
But we can tell from the html that the problem can't come from the use of htmlentities.
You can remove it if you want untill we figure out what the problem really is. I've no time for this now. But the browsers still wont display accents correctly if the server is UTF8 and we are latin1.
(0000883)
plg (manager)
2006.04.27 23:12

chrisaga wrote:

> But the browsers still wont display accents correctly if the server
> is UTF8 and we are latin1.

PhpWebGallery is not officialy utf-8 compliant (we don't officialy provide labels in utf-8) but my gallery runs in utf-8, and I promise there is no problem forcing the browser to display in utf-8 (the surest way is to set the encoding in the HTTP request, not in the HTML header).

My advise is to remove every htmlentities call. I must admit I don't understand why you've added them. There is a long time web pages don't have to be ASCII only.
(0000886)
chrisaga (developer)
2006.04.28 00:04

Just try to use the official PWG with a server accidentally set to UTF8. You will understand.
(0000890)
plg (manager)
2006.04.28 09:41

chrisaga wrote:

> Just try to use the official PWG with a server accidentally set
> to UTF8. You will understand.

If your server is set to UTF-8, is means that encoding will be valued to 'utf-8' in HTTP request header. As HTTP request header is more important than HTML header (which is a non sense in my opinion) and that PWG only value the encoding/charset in the HTML header, your browser think you want to display utf-8 while you are in iso-8859-1.

The solution is to set the encoding/charset in the HTTP request thanks to PHP:

> header('Content-Type: text/html; charset=iso-8859-1');

You have to do the opposite if your http server is configured to have encoding valued to iso-8859-1 while you have utf-8 encoded characters.

htmlentities is not a solution if we want to be utf-8 ready (I hope we will be in branch 1.7).
(0000892)
chrisaga (developer)
2006.04.28 13:36

pierrick wrote :
> If your server is set to UTF-8, is means that encoding will be valued to 'utf-8' > in HTTP request header. As HTTP request header is more important than HTML
> header (which is a non sense in my opinion)

I do agree !

> The solution is to set the encoding/charset in the HTTP request thanks to PHP:
>
>> header('Content-Type: text/html; charset=iso-8859-1');

Very good. Let's do it since we are officialy Latin1.

> htmlentities is not a solution if we want to be utf-8 ready
> (I hope we will be in branch 1.7).

Again, I do agree. This was just a short term fix to avoid complaints from webmasters who migth have their sites hosted by UTF-8 HTTPD (wich is the default on Fedora, and maybe others).
I still cannot figure this bug out, but since fixing the charset in the header is mutch better, lett's do that !
We'll change it later in branch 1.7. Woul'd you start a topic for "switching 1.7 to URF-8" ? Is it to UTF-8 or multi charset compliant (charset choosen on the user's LANG settings)?
(0000895)
chrisaga (developer)
2006.04.29 12:21

[Subversion] r1290

removed calls to htmlentities()
charset is set in the HTTP header (include/page_header.php)
(0000896)
chrisaga (developer)
2006.04.29 12:27

merged from trunk to branch 1.6 [Subversion] r1291
(0000898)
rub (developer)
2006.04.29 15:41

Warning, when htmlentities are added, some functions are added html_entity_decode because not diplayed content on html browser. (for example in functions_mail.inc.php)

It's necesary to remove also html_entity_decode.


But in my opinion, it's best to keep html_entity_decode and htmlentities like if that not resolved all the problems.
(0000959)
plg (manager)
2006.05.16 12:30

Is there many things remaining before closing this bug?
(0000960)
chrisaga (developer)
2006.05.16 13:45

pierrick wrote :
> Is there many things remaining before closing this bug?

I think there isn't.

Maybe removing unnecessary calls to html_entity_decode() (see last rub's Note)
(0000961)
plg (manager)
2006.05.16 13:53

chrisaga wrote:

> Maybe removing unnecessary calls to html_entity_decode()
> (see last rub's Note)

As long as you are assigned to this bug, can you take a look at the needed correction? or assign the bug to me :-)
(0000981)
chrisaga (developer)
2006.05.26 17:39

calls to html_entity_decode() removed in functions_mail.inc.php
trunk : [Subversion] r1321
branch 1.6 : [Subversion] r1322

- Issue History
Date Modified Username Field Change
2006.04.27 15:55 photiolo New Issue
2006.04.27 15:55 photiolo browser => any
2006.04.27 15:55 photiolo Web server => Apache 1.3.33
2006.04.27 16:42 plg Note Added: 0000868
2006.04.27 16:43 plg Assigned To => chrisaga
2006.04.27 16:43 plg Status new => assigned
2006.04.27 17:03 rvelices Note Added: 0000869
2006.04.27 18:36 chrisaga Note Added: 0000870
2006.04.27 18:36 chrisaga Status assigned => feedback
2006.04.27 19:28 photiolo Note Added: 0000871
2006.04.27 19:30 plg Note Added: 0000872
2006.04.27 20:02 chrisaga Note Added: 0000873
2006.04.27 20:10 plg Note Added: 0000876
2006.04.27 21:46 photiolo Note Added: 0000877
2006.04.27 23:07 chrisaga Note Added: 0000882
2006.04.27 23:07 chrisaga Status feedback => assigned
2006.04.27 23:07 chrisaga Assigned To chrisaga => plg
2006.04.27 23:12 plg Note Added: 0000883
2006.04.28 00:04 chrisaga Note Added: 0000886
2006.04.28 09:41 plg Note Added: 0000890
2006.04.28 13:36 chrisaga Note Added: 0000892
2006.04.29 12:06 chrisaga Assigned To plg => chrisaga
2006.04.29 12:21 chrisaga Status assigned => resolved
2006.04.29 12:21 chrisaga Fixed in Version => BSF branch (dev)
2006.04.29 12:21 chrisaga Resolution open => fixed
2006.04.29 12:21 chrisaga Note Added: 0000895
2006.04.29 12:27 chrisaga Status resolved => closed
2006.04.29 12:27 chrisaga Note Added: 0000896
2006.04.29 15:41 rub Status closed => feedback
2006.04.29 15:41 rub Resolution fixed => reopened
2006.04.29 15:41 rub Note Added: 0000898
2006.04.29 19:01 chrisaga Relationship added has duplicate 0000361
2006.04.29 19:03 chrisaga Relationship added has duplicate 0000360
2006.05.08 11:52 rub Issue Monitored: rub
2006.05.08 11:53 rub Issue End Monitor: rub
2006.05.16 12:25 plg Relationship added related to 0000291
2006.05.16 12:30 plg Note Added: 0000959
2006.05.16 13:45 chrisaga Note Added: 0000960
2006.05.16 13:53 plg Note Added: 0000961
2006.05.26 17:39 chrisaga Status feedback => closed
2006.05.26 17:39 chrisaga Note Added: 0000981
2006.05.26 17:39 chrisaga Resolution reopened => fixed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Contact
Powered by Mantis Bugtracker