Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #15701 > unrolled thread
| Started by | Derek Turner <frderek@suremail.je> |
|---|---|
| First post | 2015-10-19 14:56 +0000 |
| Last post | 2015-10-21 13:54 +0200 |
| Articles | 19 — 6 participants |
Back to article view | Back to comp.lang.php
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
| From | Derek Turner <frderek@suremail.je> |
|---|---|
| Date | 2015-10-19 14:56 +0000 |
| Subject | rawurlencode 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]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2015-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]
| From | Derek Turner <frderek@suremail.je> |
|---|---|
| Date | 2015-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-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]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2015-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2015-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2015-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]
| From | Derek Turner <frderek@suremail.je> |
|---|---|
| Date | 2015-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2015-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2015-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]
| From | Derek Turner <frderek@suremail.je> |
|---|---|
| Date | 2015-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2015-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]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-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]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-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]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-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]
| From | Derek Turner <frderek@suremail.je> |
|---|---|
| Date | 2015-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-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