Contacts with commas in the full name do not display in the People list

[Christopher Adams]

If a contact's full_name as shown in the database contains a comma, then the name is not displayed in the People List!

I have confirmed this with 25 email addresses from my address book, which all have a full name containing a comma.

The names appear correctly in the database, and also correctly on the profile page and in the People Without Pictures list.

[Bassel Safadi (bassel)]

confirmed, it's actually the <php substr( ((full_name)), 0, 30); php> thing

[Christopher Adams (christopheradams)]

What is the solution?

On Wed, Jan 12, 2011 at 12:16 AM, Bassel Safadi <email address hidden> wrote:

> confirmed, it's actually the <php substr( ((full_name)), 0, 30); php>
> thing
>
>
> ** Changed in: ppl
> Assignee: (unassigned) => Bassel Safadi (bassel)
>
> --
> You received this bug notification because you are a member of PPL
> Developers, which is subscribed to PPL.
> https://bugs.launchpad.net/bugs/701746
>
> Title:
> Contacts with commas in the full name do not display in the People
> list
>
> Status in PPL:
> Confirmed
>
> Bug description:
> If a contact's full_name as shown in the database contains a comma,
> then the name is not displayed in the People List!
>
> I have confirmed this with 25 email addresses from my address book,
> which all have a full name containing a comma.
>
> The names appear correctly in the database, and also correctly on the
> profile page and in the People Without Pictures list.
>
>
>

[Bassel Safadi (bassel)]

working to fix this on aiki core

[Bassel Safadi (bassel)]

Roger is helping fixing this at aiki core as well

[Bassel Safadi (bassel)]

fixed the problem in aiki core and in pple
now if you use substr or str_replace without quotes like in:
<php substr( ((full_name)), 0, 30); php>

it will work but will break if full_name has comma or quotes.
so the solution is to add quotes like in:

<php substr('((full_name))', 0, 30); php>

and then it will read full_name as one string even if there are commas and quotes inside

[Christopher Adams (christopheradams)]

So that means the parsers was doing the expansion of ((full_name)) before
breaking the arguments into separate tokens?

That just seems wrong. I dunno.

But having the quotes around '((full_name))' at least makes it clear it's a
string.

This is yet another example where mixing aiki markup in with something that
looks like <php ... php> can be confusing.

On Sat, Jan 15, 2011 at 12:26 PM, Bassel Safadi <email address hidden> wrote:

> fixed the problem in aiki core and in pple
> now if you use substr or str_replace without quotes like in:
> <php substr( ((full_name)), 0, 30); php>
>
> it will work but will break if full_name has comma or quotes.
> so the solution is to add quotes like in:
>
> <php substr('((full_name))', 0, 30); php>
>
> and then it will read full_name as one string even if there are commas
> and quotes inside
>
> ** Changed in: ppl
> Status: In Progress => Fix Released
>
> --
> You received this bug notification because you are a member of PPL
> Developers, which is subscribed to PPL.
> https://bugs.launchpad.net/bugs/701746
>
> Title:
> Contacts with commas in the full name do not display in the People
> list
>
> Status in PPL:
> Fix Released
>
> Bug description:
> If a contact's full_name as shown in the database contains a comma,
> then the name is not displayed in the People List!
>
> I have confirmed this with 25 email addresses from my address book,
> which all have a full name containing a comma.
>
> The names appear correctly in the database, and also correctly on the
> profile page and in the People Without Pictures list.
>
>
>

[Bassel Safadi (bassel)]

yeah right Christopher, if the parser was to break the arguments into separate tokens before doing the expansion of ((full_name)) then it would have to run over the same <php php> call twice. one for splitting and the second for executing. while currently it does the expansion of all ((vars)) then run over the markups. which save 33% of processing power and 50% of memory usage on the function it self.

the priority system in the markup parser can improve over time, but it's totally possible to mix markups now.. but yeah I agree it can be confusing at many points.. we need to work this out