Serendipity Forums

Hello dear Developers,

I have two possible "bugs":

1. My friends blog has many many backend users with long names. As a result, the option field is too long and does not look good. Is it possible to you to put a max-width to this option field? 2. Every backend member with german umlauts is not listed in this option field, only a blank line is visible. HTML-Source is, for example: <option value="180"></option>. Is this a bug or is this my fault because of wrong UTF-8 settings?

Thanks!

Yes, you can add a to the in 2k11/admin/style.css, which should do it -
or more specific for a new styling rule YL will for sure find a good solution in 2.0.1.

The other issue is working fine here. Is there anything special in how, where and when these authors have been added?
It looks like the charset change htmlspecialchars issue with PHP 5.4+ versions, which could have returned nothing in some cases. But I think we catched them all when fixing this...

1. Thanks.

2. In my own test-blog it works, too. Only my friends blog shows this behavior. PHP Version is 5.4.16. I have no special information regarding when or how he entered full usernames. I have opened the first invsible user and saved it but this has no effect ... All Users are shown properly in user settings.

ICE wrote:1. Thanks.

The number of bugs I would have never ever found myself in this backend still amazes me. Thanks for reporting, should be fixed in 2.0.1.

YL

Hey,

about the problem with the author names, could you do me a favor and edit the file

templates/2k11/admin/show_plugins.fnc.tpl

and at line 49 replace this:
with this:
and see if then the username gets shown there?

If that still does not display the proper username then probably the serendipity_authors database table has a collation/charset issue; but then, at no place the username would be properly displayed. Is that the case? I.e. the frontend entry view should not be able to display the username there.

If however with the patch indeed the output happens, then we have an issue with the Smarty "escape" modifier that we need to look into.

Thanks,
Garvin

Hello Garvin, thanks for your advice. Code change works a little, because every line with a german umlaut shows "--" character in front of the realname, which is not right.

Please try with

Yep, successful! ... but ... is it true, that only members with fullnames are listed here? Members with no fullname and only usernames are shown as blank line ...

ICE wrote:Yep, successful! ... but ... is it true, that only members with fullnames are listed here? Members with no fullname and only usernames are shown as blank line ...

Don't know. If a member has no fullname and a username only, you would need some instead at this place.
The escape charset issue is the follwing:
If the escape, which is htmlspecialchars() in the PHP world, refuses to transscript the db selected char by the blogs used charset, it returns false, which is nothing. That is why on these places nothing appears. This has to do with database table content already being escaped and/or in the wrong charset and htmlspecialchars() default charset switch to UTF-8 with php 5.4. I assume in your friends case, it is not actually a wrong charset "error", but all the member name Umlauts (and most probably more content overall) were placed escaped already to the database, because your friend was using a non UTF-8 charset Blog before. (Its curious though, why also the üäö Umlauts were escaped, since they are included to ISO-8859-1 charset already.)
What you can do at all these places, is to use {$foo|escape:'html':$CONST.LANG_CHARSET:false} which advises the escape modifier to not touch already escaped content twice (eg to "&uuml;"), overall, or now you have S9y 2.0 and a PHP version 5.4+, open up the member forms and save them all again with the correct Umlaut, if the form shows them scrambled. If they are empty there too because of this double encode "feature", correction and saving will be no fun! Better would be to dump all DB content by charset and then save it again with the correct charset Umlaut. You may would need to replace all eg "&uuml;" with "ü", etc. Garvin will possibly give you a more detailled instruction on how to make a whole database transition more efficient to succeed.

Oh my ... actually, i don't want to touch the database, it is huge! Only the old mysqldumper can export the database in one-piece.

Ian: Hm you mean that the smarty escape modifier uses the "bad" PHP 5.4 default to strip characters as well? Then we would need to patch smarty to use the same logic like serendipity_specialchars... or we would need to write our own "escape" modifier?! That would suck if we missed that place.

I think the database contains proper ISO-8859-1 (which the blog is configured for), so you cannot "correct" the entries. To do that, you would need to convert your whole blog to UTF-8, which is a non-trivial task and would affect all content of your blog and a whole dump re/import...

garvinhicking wrote:Ian: Hm you mean that the smarty escape modifier uses the "bad" PHP 5.4 default to strip characters as well? ...

No! I meant that this guys database seems to contain already encoded chars, why ever. We know this, since ICE confirmed it works OK with just using the double_encode false flag. They now run through the Smarty escape modifier, which (by PHP htmlspecialchars default) double_encodes these entities to eg "&uuml;".
Smarty is doing well and was aware of the Charset switch behaviour with PHP 5.4+ before we were. So infact it is a matter of double_encoding property true, not the charset and the serendipity_specialchars() function is behaving just the same.