[SOLVED] a problem with "php sessions" and W3C validity.

[flunn]

I'm having trouble getting my code to pass the W3C validity test. The problem has something to do with php "sessions."

 

When I test the following code:

 

<?php
session_start();


require('t_header.html');

ini_set('display_errors', 1);
error_reporting(E_ALL & ~E_NOTICE);

print '<div id="content_box">';
print '<div id="box2">';
print '<p> Put the missing word in the following sentence.</p>';
print '<p> <br /> </p>';
print '<form action="t_php.php" method="post">';
print '<p> I am trying <textarea name="comments" rows="1" cols="5"></textarea> write a valid form.</p>';
print '<p><input type="submit" name="submit" value="submit answer" /></p>';
print '</form>';
print '</div>';
print '</div>'; //content-box

require('t_footer.html');
?>

 

I get this error:

 

Error Line 235 column 226: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.

...="374748b934911140ef4a80e215e9cb35" /><p> I am trying <textarea name="comment

 

 

However when I comment out the "session_start()" line, it's valid. I realize this has got something to do with the sessions id but I haven't been able to fix the problem.

 

Any advice would be much appreciated.

 

Regards to all from

 

flunn

[dbo]

I don't think that it can have anything to do with sessions. At runtime your PHP interpreter will render all PHP code and the only thing that gets spit out is HTML... which is what W3C Validators look at. They don't see any of the PHP code.

 

Now all that being said, I'm by no means an expert at W3C standards.

[mpharo]

try putting your textarea in its own line.

 

print '<p> I am trying ';
print '<textarea name="comments" rows="1" cols="5"></textarea> ';
print 'write a valid form.</p>';

[flunn]

Thanks very much to dbo and mpharo for their replies.

 

I have tried mpharo's suggestion of putting <textarea.../textarea> in a separate line but I'm afraid that that has no effect.

 

As to dbo's point (that it can't have anything to do with the php "sessions" call because that doesn't appear in the html code which is what the validator checks.) Yes, that is how I have been led to understand it too. But still, it seems to me that the fact that the problem disappears when the sessions call is removed shows that it must be that bit of php that's causing the "invalid" result. Could it be that, even though the sessions call is not visible in the html, that the html code that gets spit out when it is there is different from what gets spit out when it's not there? (I've checked "view source" for both versions, however, and as far as I can see there's no difference.)

 

Incidentally the invalid version is at http://76.163.19.175/last_try/t3_php.php and the valid version is at http://76.163.19.175/last_try/t3a_php.php

[chigley]

http://validator.w3.org/check?uri=http%3A%2F%2F76.163.19.175%2Flast_try%2Ft_php.php

 

Both are valid for me?

[dbo]

When looking at the source for the invalid one I see a stray </bo

 

I've had similar problems when using an SFTP mapping utility. When I modify files and upload them sometimes I get weird results due to what blocks of memory the file pointers are looking at.

[flunn]

Thanks to chigley and dbo for their replies.

 

This gets stranger and stranger!

 

chigley: Are you sure both pages tested valid for you? I just checked again and, as before, one was valid the other not. Could my operating system (Mac OS10.4) be a factor here? I'll check on Windows

later this afternoon .

 

dbo: The only "</bo" I can find in the source code of either page is in the "</body>" tag at the end and that seems to be the same on both pages.

 

Also: Is it possible that your last sentence (about the weird results you get when you change files and upload them) is relevant to chigley's experience of finding that both pages tested as valid?

 

I would like to be able to stop worrying about validity — and feel that that might be a reasonable thing to do after discovering, yesterday, that pages on the three or four high-traffic, high-prestige sites I checked yesterday were full of errors according to the validator; but I became concerned with all this because I was having trouble getting the pages on a quiz I've written to look the way I wanted them to on IE/Windows and I was told by someone on another forum that if I could get my pages to validate then I could be sure they'd look the same (or almost the same) on all other browsers.

 

Incidentally a sample page from the quiz can be seen at http://76.163.19.175/vqb3.php.

 

[dbo]

The stray tag wasn't there on the latest example.

 

I don't think that what I described would be related to what chigley said. Do you use a utility like I described? The one I used was called SFTPDrive and the error only occurs on certain SSH servers.

 

Best thing I can suggest you do is take out all the html... and start adding it in piece by piece and testing the validity. As soon as it breaks you'll know where the culprit is. Please let us know

[per1os]

The problem is the W3C validator does not use COOKIES. Thus the SESSION ID is added to the page inside a hidden <input tag, which is obviously not valid.

 

I believe you can fix this editing the php.ini config file under the sessions part, not sure what the setting is, but I think that is right.

 

Either way it is valid, just not valid for people who do not allow cookies.

[flunn]

Thanks very much, dbo and frost110, for your replies.

 

dbo: No I don't use a utility like SFTPDrive. (I didn't realize that you were saying that the utility was actually causing the problems you mentioned.)

As to your suggestion that I look for the cause of the problem by adding the html piece-by-piece and testing for validity at each step: that's exactly what I did, and how I found out that the problem was being caused by the Sessions call.

 

frost110: Yes, what you say makes perfect sense!  And I appreciate this bit of information very much! I'm not going to attempt to edit the php.ini config file though, not at the moment at any rate. I have no experience in doing such things, and as I explained in my last post, what's really important to me is not that my pages pass the validity test but that they look the way they're supposed to on IE/Windows. I'll keep testing for validity before I put in any sessions calls but I won't worry about it after I do that. I've suspected all along that my problems with IE/Windows were CSS problems and not php problems and what you've just told me confirms that suspicion. I'm still left with the problem, though, of how to get my pages to look right on IE/Windows. This is made all the more difficult for me by the fact that I'm working on a Mac and can only test on IE/Windows by taking a trip to an internet café. It isn't a php issue, I realize, but if anyone who reads this had any advice to give me on this subject, I'd certainly appreciate it.

[per1os]

Does Mac allow for vmware?

 

If so you can run windows and even linux with VMware for testing purposes.

[GingerRobot]

chigley: I dont think you tried the right url. It was suppoed to be t3_php.php, looks like you did t_php.php

 

Might explain the rogue valid result - it was invalid when i tried it.

 

flunn: Even once the html is valid, it's still probably going to look a least a little differant in the differant browsers. Dont get me started on the lack of cross browser compatibility/following standards. And im not a web designer. I pity those who are and who must get amazingly annoyed with this once or twice a minute.

[AndyB]

I wouldn't be surprised is the problem with validity stems from ampersands used with session ids. & will crap out, & will validate.  And the "secret" is to force the output argument ...

 

<?php 
ini_set('arg_separator.output','&'); 
?>

 

http://www.w3.org/QA/2005/04/php-session

[flunn]

Thanks to frost110, GingerRobot, and AndyB for their replies.

 

AndyB: I tried putting that 'ini_set'  function into my code, but I'm afraid it didn't have any effect. I also read the W3C article that you sent a link to. I didn't understand it very well, especially the stuff about "rewriting links" and "query strings," but I feel I did get the general idea. (And I tried putting the function at the very beginning of my code as they suggested, but that didn't help.) I  feel that even if I did understand the article better, it wouldn't be wise for someone at my level to start fooling around with editing "php.ini" and "Apache directives." Still, after reading your message and the article, I feel that most probably you have put your finger on the problem. And I feel that, as a result of getting this information, I really have made progress: at least now I'm pretty sure that the validation problem isn't just a result of carelessness or ignorance on my part.

 

frost110: I haven't heard of VMware but I'll check it out. Being able to test IE/Windows on my own computer is especially important to me now that I know that, for the time being at least, I won't be able to use W3C validity to help be sure my pages will look good on the most widely used browser. (Although I haven't heard of VMware, I know it is possible to run Windows on current Macs, although perhaps not on the vintage iBook I'm using.)

 

GingerRobot: My problems with IE/Windows aren't just a matter of things looking a little bit different. It's a matter of CSS elements ("divs") being drastically misplaced. (For example a "submit" button that's in the center of the page on other browsers being way off to one side.) Anyway, you're certainly right about the annoyance and frustration these discrepancies can cause. When I discovered this problem, I felt like I'd climbed almost to the top of a mountain only to find a barbed wire fence around the summit.

[AndyB]

Maybe it's time to give us a link to the present incarnation of the live site so we can take our own look at where you're at, validation-wise.

[wildteen88]

The problem is because PHP is adding the following HTML tag into your HTML to transport the Session id:

<input type="hidden" name="PHPSESSID" value="fa266b3bf02959848ab2ecb6d4ce1727" />

 

As you are using XHTML Strict DOCTYPE. The validator is failing because form field tags, such as input and textarea etc must be contained within block level elements. They cannot be on their own.

 

There is a few options you can take:

1. Downgrade from XHTML Strict to XHTML Transitional. XHTML Transitional does not require block level elements to be wrapped around form field tags.

2. If you want to stay XHTML Strict you are going to have change PHP's configuration to only use only cookies and not use any other method to transport the sessions id. However this will break you PHP application if your users doesn't have cookies enabled.

[flunn]

Thanks, AndyB, for your reply.

 

You asked for the url to my "live site" so:

 

My real, public website is http://flesl.net. But I'm afraid that it's a disaster validity wise. In fact most of the pages there were written on the html editor "GoLive" at a time when I never looked at source code and didn't even know what validity was. A couple of years ago, someone pointed out to me that my pages were full of validation errors and that's when I became aware of validity, and started looking at source code and slowly learning to use CSS and do hand coding.

 

I obviously didn't start thinking much about validity however (even though I was convinced it was a good idea) because, when I looked back, just now, at a page I did quite recently and which is entirely hand coded (http://flesl.net/Grammar/ErrorSheets/about%20Esheets.html) I found quite a few validation errors  I wasn't aware of.

 

A while ago when I decided my site had to have an interactive element and that I had to learn some php, I started using another public server because the one that I'd been using didn't support php. I still haven't switched the main site to the new server, but I have been putting the experimental quizzes there and using an ISP to access them. (They start at http://76.163.19.175/vq1.php and http://76.163.19.175/vqb1.php. The urls for the (even more experimental) pages I've written in the attempt to solve this sessions-validity problem have all been mentioned in earlier postings in this thread.

[flunn]

Yes, it works!!

 

Many thanks, wildteen88, for your clear, informative, and problem-solving reply!!

 

It had actually occurred to me that the problem might be with the doctype and once or twice I changed it -- but not to the right thing obviously!  As you can see from my previous post (which I somehow made without seeing yours) I'd really given up on being able to solve the problem in a simple way and decided I had to set it aside and move on. I came back to the thread this morning to see if there were any new replies, and, if not, to mark it "topic solved." I was very happy to see your post; now I can move on, but feeling satisfied that a problem has been solved rather than frustrated about having spent a lot of time flailing around and getting nowhere.

 

I am going to click on "topic solved" now but first, I'll ask a couple of out-of-curiosity type questions in case you (or anyone else who reads this) would like to answer them.

 

(1) Does the fact that I've switched from "Strict" to "Transitional" mean that sometime in the future (when the "Transition" is complete) my pages may not be valid? (And: If there is no such downside to using "Transitional," then why would anyone want to use "Strict"?)

(2) If I did change my PHP configuration in order to be able to stay with "Strict," that would presumably be a matter of changing the configuration on the public server I use; but as I understand it, that is usually not allowed. Have I got that right? (I'm not thinking of doing this. I would have no idea how to and, in any case, I wouldn't want to eliminate users with with cookies disabled. I'm just being curious.)

 

anyway, thanks again, wildteen88, and

 

regards to all from

 

flunn