Validate please!

I am very glad that so many new templates or modified templates are created and presented here, it shows the appreciation that is given to PixelPost

but I have one great whish:

before posting a new template, validate it please!!!

I often described here already how to do this. If you have no validator-software installed, use an online validator:

1) validate html: http://validator.w3.org/

2) validate css: http://jigsaw.w3.org/css-validator/validator-uri.html

or use Firefox, install the web-developer-extension, and validate using via TOOLS / validate HTML or TOOLS / validate CSS

and a third plea: please comment what you are doing in the template so users can identify what's going on..

please do it! It will reduce the problems with displaying the page in different browsers absolutely, it will be of great value, your site will get better ranking, will load faster and and and

please, at least: do it for me! I spend a lot of time for PixelPost, trying to help here in the forum, suggesting solutions etc., but I want to be more productive :cry: not repeating the same everytime :cry:

[Joe[y]+]

i'm going to make this a sticky. if only to make more users aware of validation - i don't think it's something we should concern ourselves with too much as developers as long as we churn out valid templates.

[riken]

Ah, but some errors are caused by the developers. See my website: http://photoblog.distantwisdom.net

Currently newlines in the text of an entry is converted to <br>, not <br /> which breaks xhtml.

Also I found this in the code:

$tpl = str_replace("<EXIF_ISO>",$iso,$tpl);
if($iso != "") {
$iso = "$lang_iso $iso";
$tpl = str_replace("<LANG_ISO>",$iso,$tpl);
}

Which means that if there is no ISO info for a picture, then the <LANG_ISO> tag doesn't get replaced. <LANG_ISO> isn't valid for xhtml and you can't use <LANG_ISO /> because then pixelpost won't pick it up. Also <LANG_ISO> is an invalid tag in HTML 4.01. This problem exists for all the <LANG_???> tags.

These would appear to be all the problems with my page validating, and they are all produced by the code, not the template.

EDIT: I'm running Pixelpost 1.4.1.

Riken,

please do not mix apples with pears!

And do not start to change <PIXELPOST TAGS> to <PIXELPOST TAGS/>!!!!!

these Tags are changed by the real content, you did not understand the functionality of the template tags

template tags will never appear in a Pixelpost HTML-site, as they sit in the the template and will be replaced to real content!

try to understand the meaning and then you will know

the first argument, that we change something to <br> is not right as well, as this is a PHP function to convert newlines to breaks and if you have a better PHP-function for us you are gladly wellcome! :wink:

[riken]

Originally Posted by Connie

these Tags are changed by the real content, you did not understand the functionality of the template tags

template tags will never appear in a Pixelpost HTML-site, as they sit in the the template and will be replaced to real content!

I did understand how tags worked, but I think you misread my post.

The <LANG_ISO> tag is not replaced by the real content if the real content is an empty string (""). That's what the if statement is doing in the code snippet above. I'm assuming this is a bug in pixelpost 1.4.1.

I'm an applications programmer so I know my way around source code. PHP isn't that complex.

If you don't believe me, check out my photoblog. Check the source of the main page. The <LANG_ISO> tag is still on the page because pixelpost didn't replace it.

As for the <br> thing, are you using nl2br? According to http://www.php.net/nl2br nl2br has been xhtml compliant since PHP 4.0.3.

I found the line in pixelpost:

$message = clean(nl2br($_POST['message']));

Could the clean function be removing the "/"? I'm at work atm but when I get home I'll try:

$message = nl2br(clean($_POST['message']));

Finally, http://www.php.net/addslashes mentions that POST data already has slashes if magic_quotes_gpc is on. The "clean" function uses addslashes without first checking magic_quotes_gpc, and that could be a problem on some systems.

Riken

PS. I don't know how many of these problems have been fixed in the next version.

Check the empty EXIF-data at http://www.bildgier.de/cvs141/index.php, please!

It will be in the next release

Thanks for the hints, I will have a look for the <br>-feature today as well

Connie

[riken]

Originally Posted by Connie

Check the empty EXIF-data at http://www.bildgier.de/cvs141/index.php, please!

It will be in the next release

Cool! 8)

Originally Posted by Connie

Thanks for the hints, I will have a look for the <br>-feature today as well

I realised I had made a mistake here. I found the nl2br call in the code where comments are saved, not image entries. There is no markup performed on entries so I must have been entering the tags in wrong when I'm writing them. ops:

My mistake. Sorry.

Riken,

I am just controlling this in the moment and I was disappointed, because I could not find any <br> in the comment output, only <br /> :cry:

<li>asfd sdf afs<br /><a href='http://www.hafenfotografen.de/pixelpost1' title='Visit Homepage' target='_blank'>Connie Müller</a> @ 2005-07-02 17:32:59</li><li>das ist ein langer text ohne linebreaks mal sehen was er macht und wie er das macht<br />
<br />

kdslfl sdflk asjdl jsdflk sjflksjl jlkasdfj lkajsdf lksdjf lsadfj lsdfj lsdfj lsda jlsdfj lsadfj<br />
<br />
sklj fdlsd falksdfj sldf<br /><a href='http://www.hafenfotografen.de/pixelpost1' title='Visit Homepage' target='_blank'>Connie Müller</a> @ 2005-07-02 17:34:13</li>

I am glad that it is ok!

by the way, your hint for empty EXIF was very helpful. as we run into the same situation with <SITE_CALENDAR> if the admin chooses the option "no calendar at all" for the image-template.html
this is fixed and it is good! thanks again,

Connie