Leaderboard

Thanks, you helped a lot, I really appreciate it, and now I have some direction. It's funny, tho, how I can get stuck in some seemingly simple things.

There is no reason to be writing obsolete/insecure php mysql code in 2022. Literally every veteran member of this forum will offer you the same advice: The mysqli_ interface to mysql is annoying to use. Learn/use PDO instead! There is a fast easy to read guide to using PDO that will teach you everything you need to know, as well as offer best practices. Whether it be mysqli_ or PDO, all variables should be prepared/bound, as Barand advised. It's just cleaner/easier to use PDO to write your code. Now every single person like yourself that is learning, when they receive this suggestion, has the same reaction which is "thanks, I will have to learn PDO ... sometime in the future (aka never) because they will have to learn PDO and rewrite some of their existing code. I understand that this is a natural reaction to a learning curve and the unknown. With that said, aside from understanding how to set up a PDO connection, you really will thank us all later, if you make the change now.

You already have some useful answers, but I'll throw in my 2 cents which includes a bit of history. When the world wide web was first evolving, all HTML pages were static. The HTTP protocol, which enables the WWW, describes how a client (browser) can use a URL to reach a server, and request a resource (html document). I would hope that at this point you are familiar with the HTTP methods available -- GET, POST, PUT, PATCH & DELETE. So a browser made a get request via HTTP, and the first servers would resolve the location of a static html document and return that to the client. Again, somewhat obviously, an html document can specify a number of pieces, which again in the early days were images, as Javascript and css had not been invented/formalized yet. The job of the browser is to parse and assemble the html document and display it to the user, and handle hyperlinks. Eventually, people wanted to provide a more interactive experience. A simple example, would be a page that showed all the latest news stories of the day. Either someone had to manually update the index page, and add static html pages for all the stories, or a program running on the server could be enlisted to create html on the fly. Sophisticated software existed for a long time to do all of this, and in many ways the WWW was a huge step backwards. Client/Server and terminal applications had existed for years prior to the first browser and web server, and people were used to using online services like Compuserve and AOL, which had their own client/server protocol and content rendering client software. The WWW was an attempt to democratize this and provide standards that anyone could use. HTTP itself came from scientific organizations who wanted a way to easily share research papers. Much of what we know as the Internet also came from this process, where people would publish standards in the form of "Request for comment" ie RFC's. A few groups that had been involved in the creation of the first web servers got a working group together and published RFC 3875 which describes the "common gateway interface" (CGI) which standardized the way a web server could invoke a program, accepting input from the web server in the form of environment variables with specific names and purposes, and then return the results (in the form of html) to the web server, which would then return that "computed" html to the user. This was the birth of "server side" web programming, and the basic structure of that continues to this day. Web Server accepts an HTTP request with a URL If Web server detects that the URL requires a "CGI program" be run, it passes variables (user input and standardized CGI web server variables) to the program through the Operating system environment Local server program runs, returns a "response type" data structure + the actual data to the web server Web server returns html (or any other valid resource type) to the client I mention this, because the URL might have been an image, which could be generated on the fly by a server side program as in the case of a computed graph image So this brings us to the various popular server side languages. In the early days of the web, people would often write their CGI programs in C, as the primary server operating system of choice by most people involved in running servers in the early days of the WWW was Unix. As C is terse, and requires compilation, early web developers started looking for ways to simplify coding. CGI allowed any "program" to be used, which meant that early developers could use something as simple as a bash script which chained together various unix commands. The Perl scripting language was extremely popular at the time, due to its interpreted nature, advanced data structures and many available libraries. For example it had a relational database client interface (DBI/DBD) that allowed a developer to write simple code to make SQL calls to a relational database. Commercial databases like Sybase SQL server and Oracle were popular at the time, and the open source MySQL database was seeing a lot of adoption, as the commercial databases were expensive and hard to obtain. Perl, like other interpreted languages, is evaluated when the script is run (at runtime). Most developers found this highly preferable to developing in a compiled language like c or c++, which required a compilation/build process anytime you changed so much as a single line of code. It was in this time, when PHP first appeared, and it was intended to be a language/toolkit specifically aimed at making the development of serverside web scripting simpler. So one of its features as the ability to intermix HTML and php scripting blocks in an html script. This is somewhat in the spirit of a competing standard at the time, called "Server Side Includes" which had a similar objective of taking something that was mostly pure HTML and augmenting it with some markup that the server would act upon when the page was requested. With that said, PHP like Perl, is interpreted, and thus required a runtime process to parse the PHP code and execute it at runtime. Java also has a runtime, although the main difference in the case of Java is that the Runtime engine (the JVM) was designed to be a persistent server process/daemon. In the case of Perl & PHP, a web server running a Perl or PHP script needed to invoke the perl or php runtime program, which would then load the script code and run it. This script code could of course also load/include perl or PHP libraries, and do all sorts of things while running, but unlike java, it was not intended to have any persistence. This is very different from java where you can create objects and have them persist in the JVM (or in the case of Java EE, a Java application server). PHP programs are run when requested, and when the PHP script is done running, all the variables and objects that might have been created are disposed of when the script ends and has returned the response data to the web server. As PHP became popular, people wanting more performance and less overhead began to look for ways to reduce the overhead of starting up the PHP process each time. By this time, the open source Apache web server had become hugely popular, and apache was designed to be a collection of modules, with a specification for anyone who wanted to add a new feature to the server via development of a custom module. Developers within the PHP project community created an apache module (mod_php) which essentially made PHP a part of the Apache Web server. This meant that instead of the web server having to fork a child program and pass all the variables through the environment, a PHP script could receive that data and access web server variables directly from Apache's shared memory structures. The problem with this idea is complicated and has to do with how Apache services requests. I wrote about this issue on my blog if you want to read more about the underlying issues. Around this same time servers had appeared to challenge Apache, most notably the NGINX web server. NGINX has a fundamentally different architecture to Apache, and had no support for mod_php or something similar. NGINX was designed to be a highly performant proxy server, so it supports a variety of ways to proxy a request to a server process for handling. NGINX implements "Fastcgi" which was developed as an alternative to CGI. Essentially, fastcgi sought to get around the same problems that apache modules were designed to get around -- the overhead of having to create and destroy an os program for every request to a server side script. NGINX and other servers that support fastcgi (which even includes apache now, via an optional fastcgi module) assumes that there is a persistent operating system process that supports the fastcgi protocol. This was ideal for languages with a persistent runtime application server process like java. In order to make this work for php, a persistent php application server was developed within the PHP project, that supports fastcgi. This php application server is called php-fpm. Internally php-fpm maintains a number of persistent php processes which can be used to run a php script. A proxy web server like Nginx can be configured to send requests for php script to php-fpm via fastcgi protocol, and return the results to the client. I hope this somewhat long and verbose history of web servers helps answer your question and give you some background to clarify how PHP works. At the end of the day, a PHP script is a PHP script. There aren't a lot of different types of PHP files -- there is only .php. Frameworks have introduced template languages, and PHP can parse files of various flavors, but in all cases the end result is the execution of PHP code. Unlike Java, there was never an effort to define specific file formats to do different things as in the case of Java servlets/vs JSP vs JSTL. PHP was designed with the intention of being a language that would work with and be integrated with a web server via CGI. It has many design features focused on that, and is not generally considered a generic scripting language like perl or Ruby or Java, Nodejs or more recently, Python. Any one of those languages (including PHP) could be used to create a "socket server" that can run on a server and handle HTTP requests. There are other types of protocol servers (Websockets in particular) that have become popular as the web has evolved. The performance of PHP interpretation has been improved in recent years, and there are also projects that add some valuable features like "event driven non-blocking IO" which are beneficial if you are developing a server process in PHP, but that is not the typical reason people use PHP. For the most part they are using it to create server-side web applications.

All languages that power websites, including PHP and Java and Node.js/Javascript, share the same two aspects: that there is code running on the server which creates some output, and (typically) that there is code running on the client to perform additional actions. That duality is a lot more apparent with PHP than it is, say, Node.js and React, but only because that's the more traditional (and easier) style of mixing your server-side code with your output. If you wanted to use React to handle the interface instead then you could do that with PHP too, even if the approach would be different.

the code for any php page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document the code for any particular section can all be in the main file or divided between the main file and any number of separate files that get 'required' when needed. the html document should only contain simple php code, acting like a template engine, that operates on the input data supplied to the html document from the other sections of code OR more simply just use a 3rd party template engine.

You should be using prepared statements. They have the added benefit that you then dont have to worry about data values like "O'Reilly" or "The Bull's Head"