Here’s some browser/client http request and web server response - 101.
Browsers make http(s) requests to web servers. Web servers do their best to satisfy that request by outputting the requested html document back to the browser as a response. Browsers do NOT read anything from web servers. If the request is for a html document that corresponds to a server-side language, such as php, the web server invokes the server-side language engine to process the body of the request. As has already been written, the server-side language engine outputs the result from running the server-side code. When browsers/clients receive a response from a web server that contains a html document (content type text/html), they parse and attempt to render the html, css, and javascript in that html document, to produce the web page that you see in the browser.
For your example, when the address of index.html was entered in the browser’s address bar, the browser made a http request to the web server identified by the domain in the URL. That web server responded by outputting the contents of index.html as a html document. The browser received that content and rendered any html, css, and js to produce the web page that you see in the browser. If the user clicks on a link on that web page, the browser makes a http request to the URL in that link. For the case of requesting your form, the server outputs the result of running the php code at the requested .php URL. The browser receives that content and renders any html, css, and js to produce the web page (form) that you see in the browser. When the user submits the form, the browser makes a http request to the web server identified in the action=’…’ attribute in the form tag, and includes the form data as part of the request.
So…. perhaps here is where PHP’s Backronym comes into play - Pre-Hypertext Processor.
From the web-server’s perspective, your request goes as follows:
Request .html file. (If request unintelligible: 400)
Does HTML File Exist? Yes. (If No: 404)
Does user have permission to request this file? Yes (If No: 401 or 403) [PS: You see why all the 400s were grouped together. 4xx = “The User Did Something Wrong”]
Anything more to do? No.
Read contents of file into response, and send.
And it will do the same for images, css files, javascript - it doesnt have anything to do with interpreting those kinds of files.
a PHP file is different.
When you request a PHP file, and the server gets to the “Anything more to do” question, it has a rule that says “Stop, send the file to this executable, and await its response, which will be used.”
The PHP engine will take the file, process all of the PHP code in it, and return the resultant (typically HTML) file to the web server process with none of the PHP code included. Which dutifully takes it, and transmits it like any other file.
If the form is all HTML, it probably doesn’t need the whole thing wrapped in PHP tags, even if it has a .php extension. You only need the tags where there is actual PHP code to execute.
Though we really need to see it in context to see what you are doing right or wrong:-
It looks like you need to work on understanding the fundamental core concepts server-side (back-end) processing, Vs client-side (front-end), before you can proceed.
Though to be clear, it shouldnt hurt anything to invoke the PHP engine without executing any actual code. It will slow down the request by (a few nanoseconds? A very small amount of time, anyway) unnecessarily.
My file changed from HTML to PHP because I added code to it that populates a drop down list from a db file. The drop down list provides relationship choices … son, daughter, mother, father, wife, … going to about 40 entries. I chose to do this because I wanted to have a single place to manage the list, not in the HTML and in the db (and perhaps elsewhere in future development). I need to make use of this or a similar technique to provide dropdown options for choosing state abbreviations and maybe even country code abbreviations in future development, but I have not as yet gone back to the multiple HTML forms that contain explicity values in <select … <option… tags.
I suppose this reason and function in the code answers my question about the PHP file’s place of execution: It has to execute on the backend in order to populate the drop down list before serving the page to the frontend for user presentation and interaction. That was the souce of my confusion (that and advanced age ). It matters because I want to keep frontend and backend code in separate folders both to keep the functionality straight in my mind and to separate files on my localhost and webhost uploads.
I will gladly admit that my choice or its implementation might not be the best one. Remember that I’m working with AI (Claude and ChatGPT) as I hit things that I need help with.
require_once is not a function. The () around the path/filename do nothing and should be removed.
There’s no point in first defining/setting the $pdo variable to null.
There’s no point in defining the $relationshipTypes variable. The fetchAll() statement will correctly set it to either an array of the fetched data or an empty array.
When using exceptions for errors, your code only ‘sees’ error free execution. No discrete error checking logic will ever get executed upon an error and should be removed.
For a database dependent application, if the database connection fails, it is a fatal problem. If you do the next item on this list, the user will get a http 500 error, indicating that the page doesn’t work. If you are tempted to let the user know what type of back-end error is causing this, don’t. This only gives hackers useful feedback when they intentionally do things to trigger errors on a site. All a legitimate user needs to know is that a page doesn’t work.
There’s no point in catching and handling database exceptions in your code for things that the user cannot do anything about. The user cannot do anything about a connection error or a SELECT query error. The only database exceptions you should catch and handle in your code are for things like duplicate or out of range data in insert/update queries. By letting php catch and handle exceptions, php will use its error related settings to control what happens with the actual error information, via an uncaught exception error.
‘Form will still work, but with empty dropdowns’. A query that matches no rows of data is a successful, error free query. The exception catch logic will NOT be executed when a query simply matches no data.
The code producing the option lists needs the ability to pre-select any existing option choice (output the selected attribute), for when you are either editing existing data or when there is a user/validation error and you are repopulating the fields from the submitted form data. Note: when editing existing data, you would use the existing data’s id as the html array field name’s index value, inside the […]
All the ‘optional’ prospect rows should be handled in the looping, or even better, dynamically add a row as needed, using javascript in the browser. The user can then add as few or as many rows as needed.
Thank you for taking the time to examine my code and give such useful feedback. I can see that I have much to learn.
My approach to this problem was to pose it to the AI, Claude, whereupon I got the code supplied that you reviewed wrapped around the HTML I wrote. I have to admit to not understanding the code fully. I am only just beginning to learn PHP (plus I’ve never been a particularly good programmer). This is a good lesson in not relying on code AI provides without being able to read and fully understand it.
Again, thank you for taking the time to evaluate and respond to the code posting. It gives me a place to dig in my heels. I’m going to pause any ongoing web development and turn to learning more PHP.
This, for the record, is optional. You will find plenty of people who do it both ways. things likerequire, include, and echo are called Language Constructs; they don’t require parentheses, but can accept them. ‘should’ is a strong word here.
Thank you to everyone who read my post and answered. You’ve given me lots to chew on.
I would come back to a question, though:
Is there a better way to handle using a db table to populate a pull down list than the one using PHP to make it happen?
My thought was that this particular list might change over time. Certainly the order of the list will change based on user feed back and my own experience. Because it is likely to change, and because the list belongs in the db for other reasons, I decided that I could maintenance the db in a single place instead of having to keep track of multiple places to make changes and risking ommissions and typos. I also thought of making the fields a datalist, rather than a pulldown populated with options, if that gives you other ideas. So, please, tell me if I’ve chosen the wrong solution to maintain the list and / or the wrong way to implement it.
As I’ve said in this thread, I know next to nothing about PHP and got the code I used from the AI, Claude.
There are generally two ways to create a dynamic dropdown:
you request the complete HTML with the option tags from the server. In that case the server is creating the HTML for you.
I will call this the old way, you have the big disadvantage, that if the contents of the dropdown needs to change (for example because you have a cascade of drop-down, where the selection of the first changes the items of the second) you need to reload the full page,
you send a request to the backend which returns the items of the dropdown and you add these item to the dropdown with JavaScript.
this is much more elegant as you will only need to load the HTML once and can change the contents of the dropdown on the fly. But of course it is more complex to implement.
I do not understand. The word standard might be inappropriate in this context but all major browsers have a JavaScript runtime environment.
And the JavaScript runtime environment is provided by all major browsers.
You need to use the server’s (operating system’s) permissions to prevent access to data you do not want the public to see.
In my first reply I did not get into some relevant details that would help. The following is what I said previously.
In the beginning HTML had (and still has) a form tag that can have a submit button. When the submit button is selected a special request goes to the server and the server can execute a script and then return another HTML file as a response. The script is often called a Common Gateway Interface (CGI) script. Search for articles about the Common Gateway Interface, I think you will find that interesting. Originally a CGI script executed as a separate process, which used too many resources when very many of these processes ran. The CGI mechanism was made more efficient and had other improvements made that are not relevant here. The important thing is that when a server is configured it is told that when it gets a request for a specific file type, such as php, then the file (from the server’s file system) is to be provided as input to a specific program, such as the PHP compiler. The program (compiler) reads the file from beginning to end, processes it and the output is sent to the client.
This paragraph might seem off-topic but when you get to the end you will understand it is on-topic. In Unix, Linux, Windows and probably other OSs a console (also called command prompt or shell) script or program has a standard input and a standard output. As I said, a CGI script executes as a program. It has a Standard Input and a Standard Output. The input file is the file read from the server’s filesystem, such as a php file. The output file is HTML sent to the browser.
Another typical process done for a form is database. The database would be in the server and processed for the form. The database would be protected; we do not want the public to be able to access the database directly.
I think another way to say that is that when HTML is read in (by PHP) and there is no PHP it is written out as-is.
I think what is happening is that the PHP of the page that contains the form is processed by PHP and the PHP version of the form gets converted to a HTML form. You can use a browser’s developer tools to confirm that. Then when the form is submitted the form data is processed by PHP in the server.
I think others will disagree with the following but I am confidant this is what happens. First the browser parses the URL except probably less than you think. It just validates the syntax but I think not much. Then in the server if there is not a page specified then the server checks the configuration for what to look for. The names index.html and index.php are common names but anything can be configured for the server as a default; the name index.html is a common default name. You can find in server (Apache, Nginx, IIS or whatever) configuration files how the default names are configured.
I think that some servers, if not all, first determine what to do about a request. The filename to look for might be changed by server configuration. This is where servers can be really complicated.
I think so too. The data would be read in and written out without any other processing.
I do not think so. I am advanced too. I think the only relevance of age is that doing this stuff will keep your brain working better longer.
The point was that i can remember a time before all browsers supported javascript. Even more people will remember it before it was properly standardized…
I would say that the input file is the user-supplied information, not a file read from the server’s filesystem. In the case of a script to process a form, standard-input (or stdin) contains the form variables.
I did remember vaguely that form data is provided to the CGI script either by standard input or environment variables. How does the PHP compiler get the source code then?
The important thing relevant to this discussion is that a PHP source file is read from beginning to end and the output is generated during the reading. Portions of a source file that are further down are not yet accessible to the compiler. That is a bit of an over-simplification but close enough. The following is more technical but probably does not need to be understood if it is too advanced.
Most server-side programs are executed using FastCGI or something like that. Everything I read says that for FastCGI all input to a script is in standard input. As best as I tell, that includes the source code when that is relevant. Do you have a different explanation of where the PHP compiler reads the source code from? Either FastCGI reads the source code and passes it as part of standard input or it passes a file name and PHP reads that file, I think that the result is the same for this context. Oh, and note that one of the features of FastCGI is that it is possible for the request to be processed on a different physical machine (by FastCGI). The source code file would probably not be available in another system; the data would need to be sent over the network.
Under CGI/FastCGI the script filename is passed to PHP via an environment variable (I think either SCRIPT_NAME, or PATH_INFO, not sure though). The PHP interpreter reads that variable, locates the file and reads it to load the source code.
STDIN is tied to the request’s body (ie, form or json data for a POST/PUT request). STDOUT is sent back as the response. Other information about the request (like the URL, Query string parameters, headers, etc) is sent via environment variables.
Surely that would mean that I would be required to put all function definitions physically before any place that I call them, and a missing } or ; at the bottom end of a loop far down the code wouldn’t kill the entire script until it gets to that point. I believe (though I don’t know, I haven’t done any work at that level with PHP) that it reads the entire script into memory, parses it, processes any includes / requires, performs syntax checking, and then starts to execute it.
Is it correct to say that “output is generated during the reading”? I read that by the time I see anything on my browser, the PHP script has finished execution, but I can’t see whether the output was done piece by piece, or in one go at the end of the execution. If stdout is being captured by the web server to redirect to the browser, it’s probably academic.
As for where it gets the source from, in my mind Apache (or whichever HTTP server is running) is executing this command line when you call, say, test.php on your web server:
php test.php < temp_input_file > temp_output_file
In this case, test.php comes into the executable as argv[0] command line argument, and the executable opens that file to get the source code. Standard-input is redirected to take data from temp_input_file or whatever temporary filename Apache uses to send the user-supplied data to PHP, and Standard-output is redirected to temp_output_file which is grabbed by Apache and sent to the browser that made the request.
I’ve no idea whether they’re actually files or pipes or some other method of passing the data in and the browser output out.
I don’t know about FastCGI, in particular how it would access a PHP script file on a different server, and I’m going to stop writing now because all that I’ve written is how I think it works, rather than how I know PHP specifically works, and it’s based on other web servers and other language processors rather than specifically PHP. And it’s a bit of a diversion from the original question.
CLI calls are active - something invokes PHP, which starts up its engine, processes the file, and spits out the result (if any). It then shuts down and is done.
FPM (FastCGI Process Manager) basically sets up its own server that lives and is running on the machine. It doesnt need to spin up the engine each time, because its holding the engine open. This allows it to process requests quicker, because its passively sitting there, waiting to go.
Most of this thread is over my head (and WAY over my pay grade). I get the gist of it, but some of the details don’t take root.
One thing I have to ask. Somewhere in the thread there is mention of a compiler. I thought we were discussing processing done by an interpreter. IOW, frontend to backend processing is all done by an interpreter (unless of course the author has chosed to compile the code into executables).
). It matters because I want to keep frontend and backend code in separate folders both to keep the functionality straight in my mind and to separate files on my localhost and webhost uploads.