Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #15701 > unrolled thread

rawurlencode problem

Started byDerek Turner <frderek@suremail.je>
First post2015-10-19 14:56 +0000
Last post2015-10-21 13:54 +0200
Articles 19 — 6 participants

Back to article view | Back to comp.lang.php


Contents

  rawurlencode problem Derek Turner <frderek@suremail.je> - 2015-10-19 14:56 +0000
    Re: rawurlencode problem Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-19 17:18 +0200
      Re: rawurlencode problem Derek Turner <frderek@suremail.je> - 2015-10-19 15:48 +0000
        Re: rawurlencode problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-20 00:02 +0200
          Re: rawurlencode problem Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-21 09:40 +0200
      Re: rawurlencode problem "J.O. Aho" <user@example.net> - 2015-10-20 18:33 +0200
    Re: rawurlencode problem "J.O. Aho" <user@example.net> - 2015-10-19 21:27 +0200
      Re: rawurlencode problem Derek Turner <frderek@suremail.je> - 2015-10-19 19:43 +0000
        Re: rawurlencode problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-20 00:03 +0200
        Re: rawurlencode problem "J.O. Aho" <user@example.net> - 2015-10-20 07:10 +0200
          Re: rawurlencode problem "J.O. Aho" <user@example.net> - 2015-10-20 07:21 +0200
            Re: rawurlencode problem Derek Turner <frderek@suremail.je> - 2015-10-20 08:29 +0000
              Re: rawurlencode problem "J.O. Aho" <user@example.net> - 2015-10-20 18:29 +0200
          Re: rawurlencode problem Arno Welzel <usenet@arnowelzel.de> - 2015-10-27 14:01 +0100
            Re: rawurlencode problem Arno Welzel <usenet@arnowelzel.de> - 2015-10-27 14:04 +0100
    Re: rawurlencode problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-20 00:00 +0200
    Re: rawurlencode problem Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-19 19:35 -0400
      Re: rawurlencode problem Derek Turner <frderek@suremail.je> - 2015-10-20 08:34 +0000
        Re: rawurlencode problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-21 13:54 +0200

#15701 — rawurlencode problem

FromDerek Turner <frderek@suremail.je>
Date2015-10-19 14:56 +0000
Subjectrawurlencode problem
Message-ID<d8kekpFmk8uU1@mid.individual.net>
Hi,

I'm using this:

echo "<ol class=\"reader\">";
    while ($row = $result->fetch_assoc()):
    echo "<li class=\"reader\"> <a href = \"#".rawurlencode($row
['name'])."\">" . $row['name'] . "</a></li>\n\n";
    endwhile;
    echo "</ol>";

to provide links for screen-readers to various points in my page
$row['name'] may and does contain white spaces in many records.

The code works fine without the rawurlencode but fails validation

similarly this code lower down:

while ($row = $result->fetch_assoc()):
        echo "<h2 id =\"" .rawurlencode($row['name']). "\">" . $row
['name'] . "</h2>";
etc.

works without the rawurlencode but fails validation as 'id' must not 
contain white space.

SO the link href and the id are identical apart from the leading #

PROBLEM: this passes validation but DOES NOT WORK. Clicking the links 
does not move the page. Without the second rawurlencode it works!

What am I missing????

[toc] | [next] | [standalone]


#15702

FromErwin Moller <erwinmollerusenet@xs4all.nl>
Date2015-10-19 17:18 +0200
Message-ID<562509b9$0$23834$e4fe514c@news.xs4all.nl>
In reply to#15701
On 10/19/2015 4:56 PM, Derek Turner wrote:
> Hi,
>
> I'm using this:
>
> echo "<ol class=\"reader\">";
>      while ($row = $result->fetch_assoc()):
>      echo "<li class=\"reader\"> <a href = \"#".rawurlencode($row
> ['name'])."\">" . $row['name'] . "</a></li>\n\n";
>      endwhile;
>      echo "</ol>";
>
> to provide links for screen-readers to various points in my page
> $row['name'] may and does contain white spaces in many records.
>
> The code works fine without the rawurlencode but fails validation
>
> similarly this code lower down:
>
> while ($row = $result->fetch_assoc()):
>          echo "<h2 id =\"" .rawurlencode($row['name']). "\">" . $row
> ['name'] . "</h2>";
> etc.
>
> works without the rawurlencode but fails validation as 'id' must not
> contain white space.
>
> SO the link href and the id are identical apart from the leading #
>
> PROBLEM: this passes validation but DOES NOT WORK. Clicking the links
> does not move the page. Without the second rawurlencode it works!
>
> What am I missing????
>

You are using urlencoding where you are not using an url. You are using 
an id and hash.
And id's should not contain spaces (but you found that out already).

My advice: Simply replace all offending characters (backslashes spaces 
etc) that might occur in your $row["name"], and use what is left for id 
and #.

Alternatively, encode with something else, like: base64
http://php.net/manual/en/function.base64-encode.php
That way you will get safe characters for id and hash (but not really 
readable for most humans).

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]


#15703

FromDerek Turner <frderek@suremail.je>
Date2015-10-19 15:48 +0000
Message-ID<d8khn6Fnj64U1@mid.individual.net>
In reply to#15702
On Mon, 19 Oct 2015 17:18:16 +0200, Erwin Moller wrote:


> 
> My advice: Simply replace all offending characters (backslashes spaces
> etc) that might occur in your $row["name"], and use what is left for id
> and #.

> Erwin Moller

Thanks, Erwin, using str_replace(' ', '', $string) worked just fine. Now 
both valid  AND working ;)

[toc] | [prev] | [next] | [standalone]


#15707

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-10-20 00:02 +0200
Message-ID<7044403.NbIso3Bgt0@PointedEars.de>
In reply to#15703
Derek Turner wrote:

> On Mon, 19 Oct 2015 17:18:16 +0200, Erwin Moller wrote:
>> My advice: Simply replace all offending characters (backslashes spaces
>> etc) that might occur in your $row["name"], and use what is left for id
>> and #.

Utter nonsense.

> Thanks, Erwin, using str_replace(' ', '', $string) worked just fine. Now
> both valid  AND working ;)

Insufficient.  The next problem you will be worrying about are XSS attacks 
using non-breaking whitespace.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#15721

FromErwin Moller <erwinmollerusenet@xs4all.nl>
Date2015-10-21 09:40 +0200
Message-ID<5627414f$0$23851$e4fe514c@news.xs4all.nl>
In reply to#15707
On 10/20/2015 12:02 AM, Thomas 'PointedEars' Lahn wrote:
> Derek Turner wrote:
>
>> On Mon, 19 Oct 2015 17:18:16 +0200, Erwin Moller wrote:
>>> My advice: Simply replace all offending characters (backslashes spaces
>>> etc) that might occur in your $row["name"], and use what is left for id
>>> and #.
>
> Utter nonsense.

Coming from you, that means little.

>
>> Thanks, Erwin, using str_replace(' ', '', $string) worked just fine. Now
>> both valid  AND working ;)
>
> Insufficient.  The next problem you will be worrying about are XSS attacks
> using non-breaking whitespace.
>

When you code it maybe....

The OP asked for a way to use a string as an id.
I gave him a few solutions.
What is it you do in c.l.php exactly again?

Erwin Moller

PS: I prefer an integer (primary key preferably) too, and always code it 
like that too, but that wasn't the question.

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]


#15715

From"J.O. Aho" <user@example.net>
Date2015-10-20 18:33 +0200
Message-ID<d8n8nbFe93sU1@mid.individual.net>
In reply to#15702
On 10/19/2015 05:18 PM, Erwin Moller wrote:

> My advice: Simply replace all offending characters (backslashes spaces
> etc) that might occur in your $row["name"], and use what is left for id
> and #.

Would advice against that, say you replace those characters with an
empty string,

"Dutch House"
"DutchHouse"

will be the same and you will get an issue.

> Alternatively, encode with something else, like: base64
> http://php.net/manual/en/function.base64-encode.php
> That way you will get safe characters for id and hash (but not really
> readable for most humans).

You can use the id from the database instead, sure it's not directly
more understandable, but far easier to check which row in the database
you are working with and generally shorter too.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]


#15704

From"J.O. Aho" <user@example.net>
Date2015-10-19 21:27 +0200
Message-ID<d8kuhsFr019U1@mid.individual.net>
In reply to#15701
On 10/19/2015 04:56 PM, Derek Turner wrote:
> Hi,
> 
> I'm using this:
> 
> echo "<ol class=\"reader\">";
>     while ($row = $result->fetch_assoc()):
>     echo "<li class=\"reader\"> <a href = \"#".rawurlencode($row
> ['name'])."\">" . $row['name'] . "</a></li>\n\n";
>     endwhile;
>     echo "</ol>";
> 
> to provide links for screen-readers to various points in my page
> $row['name'] may and does contain white spaces in many records.
> 
> The code works fine without the rawurlencode but fails validation
> 
> similarly this code lower down:
> 
> while ($row = $result->fetch_assoc()):
>         echo "<h2 id =\"" .rawurlencode($row['name']). "\">" . $row
> ['name'] . "</h2>";
> etc.
> 
> works without the rawurlencode but fails validation as 'id' must not 
> contain white space.
> 
> SO the link href and the id are identical apart from the leading #
> 
> PROBLEM: this passes validation but DOES NOT WORK. Clicking the links 
> does not move the page. Without the second rawurlencode it works!
> 
> What am I missing????
> 

The standard is to use a numeric id in the database, it's a lot easier
to validate that it seems to be okey and numeric index in the database
is faster than varchar/text based.

I would recommend a redesign of your database and it will solve your
problem too.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]


#15705

FromDerek Turner <frderek@suremail.je>
Date2015-10-19 19:43 +0000
Message-ID<d8kveuFr6aqU1@mid.individual.net>
In reply to#15704
On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:

> The standard is to use a numeric id in the database, it's a lot easier
> to validate that it seems to be okey and numeric index in the database
> is faster than varchar/text based.
> 
> I would recommend a redesign of your database and it will solve your
> problem too.

I really don't see how that even begins to answer my question. There is, 
of course, an auto-incrementing integer primary key in all four tables. 
What's that got to do with the question I asked?

[toc] | [prev] | [next] | [standalone]


#15708

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-10-20 00:03 +0200
Message-ID<2845756.yHWT6uteJy@PointedEars.de>
In reply to#15705
Derek Turner wrote:

> On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:
>> The standard is to use a numeric id in the database, it's a lot easier
>> to validate that it seems to be okey and numeric index in the database
>> is faster than varchar/text based.

That is not the problem here.  The database record ID is not even used.

>> I would recommend a redesign of your database and it will solve your
>> problem too.

Nonsense.
 
> I really don't see how that even begins to answer my question. There is,
> of course, an auto-incrementing integer primary key in all four tables.

Good.

> What's that got to do with the question I asked?

Nothing; he did not read carefully.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#15710

From"J.O. Aho" <user@example.net>
Date2015-10-20 07:10 +0200
Message-ID<d8m0lvF49nbU1@mid.individual.net>
In reply to#15705
On 10/19/2015 09:43 PM, Derek Turner wrote:
> On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:
> 
>> The standard is to use a numeric id in the database, it's a lot easier
>> to validate that it seems to be okey and numeric index in the database
>> is faster than varchar/text based.
>>
>> I would recommend a redesign of your database and it will solve your
>> problem too.
> 
> I really don't see how that even begins to answer my question. There is, 
> of course, an auto-incrementing integer primary key in all four tables. 

That wasn't in your example and your use of the "name" gave the
impression your database could be flawed.

> What's that got to do with the question I asked?

Have you thought of using id as the value, you can always make a new
request to the database to get the name in an unmodified by the user.
You can also check that the is_int() when you get the value posted back
to see if it's possibly a valid value.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]


#15711

From"J.O. Aho" <user@example.net>
Date2015-10-20 07:21 +0200
Message-ID<d8m1apF4ekcU1@mid.individual.net>
In reply to#15710
On 10/20/2015 07:10 AM, J.O. Aho wrote:
> On 10/19/2015 09:43 PM, Derek Turner wrote:
>> On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:
>>
>>> The standard is to use a numeric id in the database, it's a lot easier
>>> to validate that it seems to be okey and numeric index in the database
>>> is faster than varchar/text based.
>>>
>>> I would recommend a redesign of your database and it will solve your
>>> problem too.
>>
>> I really don't see how that even begins to answer my question. There is, 
>> of course, an auto-incrementing integer primary key in all four tables. 
> 
> That wasn't in your example and your use of the "name" gave the
> impression your database could be flawed.
> 
>> What's that got to do with the question I asked?
> 
> Have you thought of using id as the value, you can always make a new
> request to the database to get the name in an unmodified by the user.
> You can also check that the is_int() when you get the value posted back
> to see if it's possibly a valid value.
> 
Sorry, missed that you post back anything, but still more sane to use
the index, as you ALWAYS know the format of it, compare that with a
string, which has kind of unlimited formats and characters, one day
there may be a character which breaks your anchor again as it's not in
your replacement array.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]


#15712

FromDerek Turner <frderek@suremail.je>
Date2015-10-20 08:29 +0000
Message-ID<d8mcahF6vrlU1@mid.individual.net>
In reply to#15711
On Tue, 20 Oct 2015 07:21:28 +0200, J.O. Aho wrote:

> Sorry, missed that you post back anything, but still more sane to use
> the index, as you ALWAYS know the format of it, compare that with a
> string, which has kind of unlimited formats and characters, one day
> there may be a character which breaks your anchor again as it's not in
> your replacement array.

Sorry, I now realise that you are confusing the HTML 'id' property with 
the id in the database. The 'id' property in HTML serves as an anchor, 
taking the browser to the right <h2> tag which is the deginning of the 
info pointed to by the link. In other words, a completely different sort 
of 'id'.

[toc] | [prev] | [next] | [standalone]


#15714

From"J.O. Aho" <user@example.net>
Date2015-10-20 18:29 +0200
Message-ID<d8n8f4Fe6g8U1@mid.individual.net>
In reply to#15712
On 10/20/2015 10:29 AM, Derek Turner wrote:
> On Tue, 20 Oct 2015 07:21:28 +0200, J.O. Aho wrote:
> 
>> Sorry, missed that you don't post back anything, but still more sane to use
>> the index, as you ALWAYS know the format of it, compare that with a
>> string, which has kind of unlimited formats and characters, one day
>> there may be a character which breaks your anchor again as it's not in
>> your replacement array.
> 
> Sorry, I now realise that you are confusing the HTML 'id' property with 
> the id in the database. The 'id' property in HTML serves as an anchor, 
> taking the browser to the right <h2> tag which is the deginning of the 
> info pointed to by the link. In other words, a completely different sort 
> of 'id'.

Sorry, I pointed out to use the id from the database instead of the
string and I can give you another example why:

"Dutch House"
"DutchHouse"

will both be the same when you remove the space, then your anchor will
not work, if you use the id from your database to anchor, then you will
have something that is unique for that section.


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]


#15793

FromArno Welzel <usenet@arnowelzel.de>
Date2015-10-27 14:01 +0100
Message-ID<562F75B2.8060209@arnowelzel.de>
In reply to#15710
J.O. Aho schrieb am 2015-10-20 um 07:10:

> On 10/19/2015 09:43 PM, Derek Turner wrote:
>> On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:
>>
>>> The standard is to use a numeric id in the database, it's a lot easier
>>> to validate that it seems to be okey and numeric index in the database
>>> is faster than varchar/text based.
>>>
>>> I would recommend a redesign of your database and it will solve your
>>> problem too.
>>
>> I really don't see how that even begins to answer my question. There is, 
>> of course, an auto-incrementing integer primary key in all four tables. 
> 
> That wasn't in your example and your use of the "name" gave the
> impression your database could be flawed.

The name was used to create a link to another section *within* the same
document:

<a href="#SomeName">Some Name</a>

<h2 id="SomeName">Some Name</h2>


I would also advise to use the numerical IDs from the database for this
purpose and use title attributes in the links for the description:

<a href="#1" title="Some Name">Some Name</a>


<h2 id="1">Some Name</h2>

The title can be created using htmlspecialchars()

Also see here:

<http://www.w3.org/TR/WCAG20-TECHS/H33.html>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]


#15794

FromArno Welzel <usenet@arnowelzel.de>
Date2015-10-27 14:04 +0100
Message-ID<562F7643.1000508@arnowelzel.de>
In reply to#15793
Arno Welzel schrieb am 2015-10-27 um 14:01:

> J.O. Aho schrieb am 2015-10-20 um 07:10:
> 
>> On 10/19/2015 09:43 PM, Derek Turner wrote:
>>> On Mon, 19 Oct 2015 21:27:54 +0200, J.O. Aho wrote:
>>>
>>>> The standard is to use a numeric id in the database, it's a lot easier
>>>> to validate that it seems to be okey and numeric index in the database
>>>> is faster than varchar/text based.
>>>>
>>>> I would recommend a redesign of your database and it will solve your
>>>> problem too.
>>>
>>> I really don't see how that even begins to answer my question. There is, 
>>> of course, an auto-incrementing integer primary key in all four tables. 
>>
>> That wasn't in your example and your use of the "name" gave the
>> impression your database could be flawed.
> 
> The name was used to create a link to another section *within* the same
> document:
> 
> <a href="#SomeName">Some Name</a>
> 
> <h2 id="SomeName">Some Name</h2>
> 
> 
> I would also advise to use the numerical IDs from the database for this
> purpose and use title attributes in the links for the description:
> 
> <a href="#1" title="Some Name">Some Name</a>
> 
> 
> <h2 id="1">Some Name</h2>

Of course not "1" but "l1" or similar (starting with an alpha character
since numbers are not valid as IDs.

> The title can be created using htmlspecialchars()
> 
> Also see here:
> 
> <http://www.w3.org/TR/WCAG20-TECHS/H33.html>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]


#15706

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-10-20 00:00 +0200
Message-ID<6395335.3oAvEOITrP@PointedEars.de>
In reply to#15701
Derek Turner wrote:

> I'm using this:
> 
> echo "<ol class=\"reader\">";
>     while ($row = $result->fetch_assoc()):
>     echo "<li class=\"reader\"> <a href = \"#".rawurlencode($row
> ['name'])."\">" . $row['name'] . "</a></li>\n\n";
>     endwhile;
>     echo "</ol>";
> 
> to provide links for screen-readers to various points in my page

Please don’t.  This is _not_ how one properly uses PHP in the 21st century.

Instead, in your controller code, use the equivalent of

  $data = $result->fetch_all(MYSQLI_ASSOC);

and in your view template (which you include() or require() through your 
controller code), the equivalent of

  <ol class="reader">
    <?php foreach ($data as $row): ?>
      <li class="reader"><a
        href="#<?= rawurlencode($row['name']) ?>"
        ><?= htmlspecialchars($row['name']) ?></a></li>
    <?php endforeach; ?>
  </ol>

thereby cleanly *separating business logic from presentation*.

Usually you want to define template variables instead of using $data.  A 
template engine can be useful there, but is not required if your controller 
sets view "variables" instead; e.g.

  $data = $result->fetch_all(MYSQLI_ASSOC);
  $this->view->setVar('rows', $data);

and then

  <ol class="reader">
    <?php foreach ($this->rows as $row): ?>
      <li class="reader"><a
        href="#<?= rawurlencode($row['name']) ?>"
        ><?= htmlspecialchars($row['name']) ?></a></li>
    <?php endforeach; ?>
  </ol>

Also consider mysqli_result::fetch_object() which can convert records into 
model objects directly.  You can store sets of model objects in a template 
variable, and then access object properties instead of array keys which has 
several benefits thanks to the possibility of implicit setters and getters:

  /*
   * There is no other way but a loop with mysqli;
   * PDO_Mysql has
   * 
   *   $links = $pdoStatement->fetchAll(PDO::FETCH_CLASS, 'Turner\\Link', 
   *              $mapping);
   * 
   * instead.
   */
  while (($obj = $result->fetch_object('Turner\\Link', $mapping)))
  {
    $links[] = $obj;
  };

  $this->view->setVar('links', $links)

and then

  <ol class="reader">
    <?php foreach ($this->links as $link): ?>
      <li class="reader"><a
        href="#<?= rawurlencode($link->name) ?>"
        ><?= htmlspecialchars($link->name) ?></a></li>
    <?php endforeach; ?>
  </ol>

<http://php.net/manual/en/mysqli-result.fetch-object.php>
<http://php.net/manual/en/pdostatement.fetchall.php>


Use <?= … ?> instead of <?php echo … ?> if you use PHP 5.4+:

<http://php.net/manual/en/migration54.new-features.php>


The “li” elements probably do not need a CSS class each; you can write 
stylesheets using the selector context

  .reader li

to format them or their descendant elements instead.

> $row['name'] may and does contain white spaces in many records.

Given that users would want to use those references, it is prudent to 
replace consecutive white space in fragment identifiers with a different 
character that is easy for them to read and type, e.g. “-”.  You can find 
this all over the Web.
 
> The code works fine without the rawurlencode but fails validation

Presumably with the W3C Markup Validator.
 
> similarly this code lower down:
> 
> while ($row = $result->fetch_assoc()):
>         echo "<h2 id =\"" .rawurlencode($row['name']). "\">" . $row
> ['name'] . "</h2>";
> etc.

Same problem as above.  Who is going to maintain this character mess?
 
> works without the rawurlencode but fails validation as 'id' must not
> contain white space.

IDs are _not_ URLs.  Use htmlspecialchars() there instead.
 
<http://php.net/htmlspecialchars>

> SO the link href and the id are identical apart from the leading #

No, one is a *URI-reference*, the other is an *ID*.
 
> PROBLEM: this passes validation but DOES NOT WORK.

Of course it does not.

> What am I missing????

The HTML(5) Specification, a decent tutorial on modern design patterns like 
MVC, and a keyboard with working Shift and Question Mark keys.

IOW: <http://www.catb.org/~esr/faqs/smart-questions.html>

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#15709

FromJerry Stuckle <jstucklex@attglobal.net>
Date2015-10-19 19:35 -0400
Message-ID<n03uk1$m0l$1@dont-email.me>
In reply to#15701
On 10/19/2015 10:56 AM, Derek Turner wrote:
> Hi,
> 
> I'm using this:
> 
> echo "<ol class=\"reader\">";
>     while ($row = $result->fetch_assoc()):
>     echo "<li class=\"reader\"> <a href = \"#".rawurlencode($row
> ['name'])."\">" . $row['name'] . "</a></li>\n\n";
>     endwhile;
>     echo "</ol>";
> 
> to provide links for screen-readers to various points in my page
> $row['name'] may and does contain white spaces in many records.
> 
> The code works fine without the rawurlencode but fails validation
> 
> similarly this code lower down:
> 
> while ($row = $result->fetch_assoc()):
>         echo "<h2 id =\"" .rawurlencode($row['name']). "\">" . $row
> ['name'] . "</h2>";
> etc.
> 
> works without the rawurlencode but fails validation as 'id' must not 
> contain white space.
> 
> SO the link href and the id are identical apart from the leading #
> 
> PROBLEM: this passes validation but DOES NOT WORK. Clicking the links 
> does not move the page. Without the second rawurlencode it works!
> 
> What am I missing????
> 

Don't worry about "Pointed Head"'s comments.  Erwin has an excellent
suggestion for you.  The only other suggestion I would make is related
to J.O.'s suggestion - since you already have a unique id which doesn't
contain spaces, you could use that as an anchor instead of the row name,
i.e.

  <li class=\"reader\"> <a href = \"#".#row['id'])."\">" . $row['name']
. "</a></li>

This would provide an id of 'i123456' or similar without having to worry
about spaces and special characters.

And don't worry about "Pointed Head".  He's a well-known troll who
doesn't understand even the simple concepts of programming, and has to
repeatedly prove his ignorance.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#15713

FromDerek Turner <frderek@suremail.je>
Date2015-10-20 08:34 +0000
Message-ID<d8mckpF6vrlU2@mid.individual.net>
In reply to#15709
On Mon, 19 Oct 2015 19:35:33 -0400, Jerry Stuckle wrote:

> Don't worry about "Pointed Head"'s comments.  Erwin has an excellent
> suggestion for you.  The only other suggestion I would make is related
> to J.O.'s suggestion - since you already have a unique id which doesn't
> contain spaces, you could use that as an anchor instead of the row name,

Oh, I don't worry about pointed ears. ISTM that OE-php is a sort of bolt-
on making efficiency more important than readability. I'll stick with 
what I know best - at least when I revisit the code later I can figure 
out what it means :)

As regards J.O. and the anchor name, point taken but again Erwin's idea 
(stripping out the whitespace) makes for more human-readable HTML in the 
output - I'll settle for that as it makes debugging so much easier.

[toc] | [prev] | [next] | [standalone]


#15722

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-10-21 13:54 +0200
Message-ID<6987561.cYlbZIa9uJ@PointedEars.de>
In reply to#15713
Derek Turner wrote:

> Oh, I don't worry about pointed ears. ISTM that OE-php is a sort of bolt-
> on making efficiency more important than readability.

On the contrary.  If you find this character mess you are having now easy
to read or to maintain, or safe, in any way, you are beyond help and should 
consider a different vocation or avocation instead, like landscape 
gardening.

“I can only show you the door. You’re the one that has to walk through it.”

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.php


csiph-web