StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2171305
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
5
CommunityOwnedDate
CreationDate
2010-01-31T10:24:22.643
FavoriteCount
0
LastActivityDate
2010-01-31T19:16:55.757
LastEditDate
2010-01-31T19:16:55.757
LastEditorUserId
165154
OwnerUserId
165154
ParentId
2171139
PostTypeId
2
Score
9
ViewCount
0
LastEditorDisplayName
text
Body
In order to understand the value of the statements you have written you need to have some basic understanding of the operations of the functions you mention. I'll try to break them down here. Let's start with <code>session_start()</code> and <code>header()</code> calls: The first function does exactly what the name implies; it starts a session. Due to the stateless nature of the HTTP protocol, there is a need for some mechanism that can remember state between page requests. This can be achieved with sessions. Although sessions, in the early days of PHP where sometimes propagated by passing along the session ID in links ( <code>someurl?sessionId=someSessionHash</code> ), this, nowadays, is considered bad practice. Nowadays, sessions are predominantly kept track of by using a cookie (in the early days they where widely used too, don't get me wrong). This session cookie (which, contrary to popular belief, is nothing more than a normal cookie, with merely the session ID in it, that (usualy) simply expires after you close your browser) is sent along to the browser with each subsequent page request. And here is where the catch is: A cookie is sent as a header of the response (meaning before the actual body), like so: <pre><code>// I've left out a lot of other headers for brevity HTTP/1.x 200 OK Date: Sun, 31 Jan 2010 09:37:35 GMT Cookie: SESSION=DRwHHwAAACpes38Ql6LlhGr2t70df // here is your Cookie header // after all response headers come the actual content: // the response body, for instance: <html> <head> </head> <body> </body> </html> </code></pre> Now, because response headers must be sent before the response body, you need to put a call to <code>session_start()</code> and <code>header()</code> before any body content is output. Here's why: if you output any response body content (could be something as simple as a whitespace character) before a call to <code>session_start()</code> or <code>header()</code>, PHP will automatically output the response headers. This is because a HTTP response must have the response headers sent out first before the response body. And it is exactly this that often leads to the infamous <code>Warning: headers already sent</code> warning in PHP. In other words; once PHP has sent out the headers, because it had to send body data too, it cannot add any headers anymore. So, now that you understand this about the HTTP protocol, there are some measurements you can take to prevent this from happening. And this is where we come to the next function(s): <code>ob_start</code>, <code>ob_flush</code>, etc...: In a default setup PHP usualy outputs anything immediately. Therefor, if you output any response body content, headers are automatically sent first. But PHP offers mechanisms of buffering output. This is the <code>ob_*</code> family of functions. With <code>ob_start</code> you tell PHP to start buffering. And with <code>ob_flush</code> you tell PHP to flush the buffer; in other words output the current content of the buffer to the standard output. With these buffering mechanisms you can still add headers to the response, after you have output body data, because you haven't actually sent body data yet, you have simply buffered it, to be output later with a call to <code>ob_flush</code> or <code>ob_end_flush</code> and what have you. Keep in mind though, that using <code>ob_*</code> functions is more than often a code smell. In other words (and this is why it is important to do certain stuff at the top), it is then used to make up for poor design. Somebody forgot to set up their order of operations properly and resorts to output buffering to circumvent this <code>header</code> and <code>session</code> drama. Having said all this, you can easily see why the outputting of html and/or other body content should come last. Apart from that, I strongly recommend you to separate PHP code from output code anyway. Because it is much more easy to read and understand. And a good way to start doing that is having the actual html come after the main <code><?php ?></code> code block. But there are other ways as well, which is beyond this questions scope. Then lastly about the <code>include</code> and <code>require</code> calls. To have these at the top of your php files is usually ment to be clarifying. It keeps these calls nicely in one place. But keep in mind, that if one of these files output anything before you call <code>session_start()</code> or <code>header()</code> without using output buffering, you're screwed again.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POwhat means by top of the page in php file
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USDecent Dabbler
UserOwnerUserId
1. USDecent Dabbler
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POwhat means by top of the page in php file
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.