Menu

#422 Some text badly truncated or not shown at all

3.5.5
closed-fixed
General (123)
5
2019-10-13
2012-07-28
No

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682954

I've received a report from a Debian user where text in some table (see the screenshot) got truncated, apparently in the middle of some utf8 character. Some other cell is reported as being empty where it should have some content.

--------------

Date: Fri, 27 Jul 2012 11:35:25 +0200
From: Csanyi Pal <csanyipal@gmail.com>
Subject: Bug#682954: [phppgadmin] The phpPgAdmin displays table data poorly

Package: phppgadmin
Version: 5.0.4-1
Severity: important

Hi,

in the Table Browse view some of the datas are poorly displayed.

What I'm mean here is visible if one download the image of this
display problem from here (one must click on the download icon):

http://cspl.me/joomla/index.php/itt-helyben/kepek

I can try to explain the problem here in words.
(English isn't my first language.)

On the image one can see 9 rows in the Table.
All rows are displayed properly but but the second, third and sixth.

In the column named 'unnep_neve' phpPgAdmin display the column
too strait so one can see the text in the second row as
'A II. világháború szerb áldozatainak emlékna&#8230;'
in place of the proper text:
'A II. világháború szerb áldozatainak emléknapja'.

In the second row in the 'megjegyzes' column one can see empty field,
but there should to be the text:
'November 11. a napja, de az vasárnapra esik, ezért hétfőn ünnepeljük meg.'

In the sixth row the problem is the same as in the second row,
but with different text.

So it seems to me that that phpPgAdmin displays Table data poorly because if
a text in a column exceeds some length then it can't be seen properly or at all.

Certainly in the psql prompt these rows can be seen properly when I run the
SELECT statement on this table.

Discussion

  • Christoph Berg

    Christoph Berg - 2012-07-28

    Screenshot

     
  • Robert Treat

    Robert Treat - 2012-11-28
    • assigned_to: nobody --> xzilla
    • status: open --> pending
     
  • Robert Treat

    Robert Treat - 2012-11-28

    The screenshot is no longer valid, so it's hard to say for sure, but we do show only partial data for very long text fields. If you want to see the full data, there is an "expand" option at the bottom of most display pages which should show the full data. IIRC, you can control how much data to show before truncating in the config.

    If your problem was something else, please update the ticket and or provide a new screen shot, but hopefully that solves it.

     
  • Christoph Berg

    Christoph Berg - 2012-11-28

    The strrings there were not that long. I guess it was UTF-8 strings clipped in the middle of some wide character, or something like that. I've asked the OP to provide the screenshot again.

     
  • Christoph Berg

    Christoph Berg - 2012-11-28
    • status: pending --> open
     
  • J.Guillaume (ioguix) de Rorthais

    The new screenshot.

    http://en.zimagez.com/zimage/thephppgadmindisplaystabledatapoorly.php

    I'm pretty sure this bug comes from badly truncated UTF-8 chars. We do not take care of mb-strings at all in PPA...

    ISTM a thread or bug report is already floating around about that. By this time, we discussed the possiblity to replace all string functions by the mb equivalent when possible, as this module is often available in default PHP installations.

     
  • Cyril Chaboisseau

    I had the same problem, and I can give you some a way reproduce this bug:
    create a table with 2 columns (but 1 would suffice):

    id      | integer                | non NULL Par défaut, nextval('oea.test_id_seq'::regclass)
     label   | character varying(256) | 
    

    (the label column can be "text" as well)

    and then, insert a line with the following text:
    "AA: Abcdefghijlmnop Abcdefghijklmnop xüx das abücdef"
    (without the quotes)

    the text will not show on a normal table browsing, but it will if you show the full value of the text field (with the "Expand" function)

    it looks like the bug has to do with the 50 characters limit that might be cutting the UTF-8 value right in the middle of a 2 bytes character (if you take off 1 character at the beggining, the problem dissapear).

     

    Last edit: Cyril Chaboisseau 2017-05-04
  • Robert Treat

    Robert Treat - 2019-10-13

    This is fixed in git master and will be released soon. Thanks so much for the repeatable test case!

     
  • Robert Treat

    Robert Treat - 2019-10-13
    • status: open --> closed-fixed
    • Group: --> 3.5.5
     

Log in to post a comment.