maxxd

Outside the webroot - whether that's called www/ or http/. The whole point is that you don't want the casual browser to be able to access the files directly, only php can access them. So from within the webroot you'll use something along the lines of
include_once('../includes/myPhpFile.php'); The contents of myPhpFile are now accessible from the calling script.

Check out https://github.com/PHPOffice/PHPWord. It's not automatic - you'll still need to code, but it's a library to make it easier to do.

In addition to everything requinix and mac_gyver have mentioned, you have several different <form></form> elements in your HTML - this is incorrect. There should be one form that encompasses all the input fields in your form. The reason you're getting the success message every time is that the form element that surrounds the submit button contains only the submit button - the Email field is in a different form (I'm assuming - your formatting got weird and hard to follow). Add the following right before the `<?php if(isset($_POST['Email']) {` line in application.php:
<pre><?php var_export($_POST, true); ?></pre>  

If I remember correctly, you need to add the class attribute to the <img> tag. The picture tag is a container, and the source elements replace the inner image tag at the defined breakpoints.

It's been a long time since I've touched WP, but as I remember it right now you're using a global action - it fires on every page. You can either override the specific templates you're looking to add the form to, or check the template name and conditionally output the form.

You're still setting the $key variable inside a conditional.
$key = array_search('a+', $bloodType_list); Don't wrap it in a conditional, just make the assignment a statement. Then check the value of the variable against false (which you are currently doing).

$sql2 = "SELECT id, amount_charged_each, quantity, chargable_units from quote_items where quote_id = :qId"; $stmt2 = $pdo -> prepare($sql2); $stmt2 -> execute([ ':id' => $_GET['quoteId'] ]); There's also a fairly obvious problem here in that place marker names need to match the index of the values.

Totally get that about reinventing things to understand them, so I'm not going to give you any crap for going down that road if you choose to.
I will say that given that and your plans to take up a framework later on, you may want to (at this time) look into Twig as a templating language instead of Smarty - I'm sure someone here will correct me if I'm wrong but the impression that I get is that Smarty isn't all that used any more, while several frameworks either support Twig or use a dialect based on it. Heck, from looking at the Smarty repo it looks like they've taken that in a more Twig-based direction.
Another choice is to simply use PHP in your HTML files and skip a templating language entirely; this is a technique still widely used in the wild and is obviously easily extensible in plain PHP. It's not an approach I personally recommend or use these days, but again my last four or five years worth of jobs have been Laravel based, so I've gotten rather used to that.
Rounding back to your original question, the benefit of using a framework is that a framework usually takes care of the front-controller aspect of things, and you won't have to do any extra work in the .htaccess file to get the pretty URLs it sounds like you were originally asking about (before I derailed the entire conversation - sorry about that).

You can also switch to PDO and get the benefits of not having go through extra steps like explicitly binding parameters (you can pass an array to PDOStatement::execute). Granted you'll still have to pass it an array that matches the parameters in the query, but it's less typing. There are also other reasons to move to PDO; the simplified interface and much easier readability, for example.

If there's a reasonable or good chance that there will be multiple images per question, then yes make a joining table. However, if it's most likely that there's only going to be one image per question then keep the data where it is.
The thing about db normalization is that it's kind of relative; one appropriately normalized database won't look like an appropriately normalized database for a different project. I personally think first normal form is a pipe dream, and from what I've read third normal form is kinda the ideal. It has all the logical hallmarks of a well-designed database and is easy to read and reason about, but it's also true to the business logic and functional specifications for the specific project.

A sticky element needs to have a `top` value. Remember it's relative to the parent element, so if that goes off the screen, the sticky element will as well.

No, backslash is an escape character. Note how every character after a backslash is red in your screencap - that means it's being interpreted as a command character (tbh I'm not sure that's the right term - it's being interpreted as something other than a simple character in a string). So where you have `\`, you should have `\\` - this will escape the second backslash and make the interpreter read it as a character in a string. So, basically
"C:\Program Files\your\path\php.exe" becomes
"C:\\Program Files\\your\\path\\php.exe"  

It's been a while since I've used CodeIgniter - especially an older version - but I don't see where you've loaded the URL helper. Check here for more information.

Try https://www.php.net/manual/en/mysqli.insert-id.php. I'll skip the obligatory advice to switch to PDO for the moment.

In your function ecommercehints_confirm_email_field_validation() (yeesh, wordpress really promotes bad ides...), your second if() statement needs to be an elseif() branch. The reason is that in the first if() you're checking to make sure $_POST['confirm_email'] is set, which is correct. In the second, however, you're assuming it is set by trying to compare it to another value. So if you make it an elseif branch it'll only run when the variable is set, which is the behavior you want.

Not sure how that would have happened, but dude I feel ya' - losing WIP sucks. Check to see if your editor created a temp file somewhere or if there's an automated backup. Obviously, this is one of the benefits of using git but if you're not or you didn't commit or push, it may be rough. How exactly were you running the script that an infinite loop could have wiped your file?

Again - you're already in php mode, so using the opening and closing php tags is redundant and will throw an error.
Change this line:
header('link: < https://example.com<?php echo ($_SERVER['REQUEST_URI']); ?>>; rel="canonical"'); to this:
header('link: <https://example.com/'.$_SERVER['REQUEST_URI'].'>; rel="canonical"'); and see what that gives you.

A controller isn't specific to PHP - it's part of the MVC design pattern. (I've skimmed the article and it looked like it'll explain the concept and give you a place to start reading).

I'm pretty sure I don't understand the issue you're having, but right off the top I see this. This is your function definition:
function getItemsForQuote($itemType, $currency, $qty = null, $startDate = null, $endDate = null, $itemId = null, $notes = null) and this is what you're calling:
getItemsForQuote($item['itemType'], $item['quoteCurrency'], $item['quantity'], $item['itemId']); You're passing the itemId as the startDate parameter.

This is one of the major problems with echoing html from within php - your quotation marks are getting lost/confused. If you have to do this, remember using single quotes is perfectly appropriate for an echo statement in php even though it won't interpolate variables. In your case, this is fine as you're using concatenation. Try this:
echo '<option value="'.$myrow['cats'].'">'.$myrow['cats'].'</option>'; This way it's easier to see that there are quotes around the option value so you know that spaces in the value won't break the entire thing (which is what's happening to you now).
It's also a best practice in html to use double quotes for attribute values, so that's cool too. I made the quotes around the array indexes single quotes; I'm not entirely sure that's best practice for php but it's what I've seen most often and what I personally prefer, so...

Yes, using globals is frowned upon. The reason for this is the lack of any real accountability or pinpointing modification points - if the variable is global, it can be changed literally anywhere and this can lead to days of hunt and seek debugging. The current basic pattern is to either instantiate a concrete instance of the database object and pass it to the other objects that require a database connection or setting up a dependency injection pattern/system, but that's a whole extra level of difficulty.
Extending a class is, for the most part, perfectly safe and fine. Now, the presiding opinion is to prefer composition over inheritance which means most modern advice you'll see and read is that you should - as stated above - either use dependency injection or pass an object into the constructor. There's more controversy in that most people apparently have an issue with singletons, but if you always need the same database connection you'll probably want a singleton object that you pass into the constructor methods of any class that needs it.
You pass an object to a constructor method in a series of `new` statements. Any time you write, for instance:
$db = new DatabaseObject(); you're calling the __construct() method of the DatabaseObject class. So, hopefully this'll help a bit:
<?php class DatabaseObject{ private $pdo; public function __construct(){ $this->pdo = new PDO('connection_string', 'username', 'password'); $this->pdo->setAttribute(PDO::WHATEVER); } public function getDatabaseObject(){ return $this->pdo; } } class Statements{ private $pdo; public function __construct(DatabaseObject $dbo){ $this->pdo = $pdo; } } $pdo = new DatabaseObject(); $stmtnt = new Statements($pdo->getDatabaseObject()); A few additional things:
You can't access a private variable from anywhere other than the class that defines that variable, even if you're in a child class - in that case you'll want to use protected. Also, in your Database class constructor, you're missing `$this->` on your first line. $this->pdo is a different thing than just $pdo within a class or object.
Long story short, there's really no one "way" to do things - best practices adapt and change as we all learn and grow as programmers. Best bet is to do the research you're already doing, really take in and understand the information and opinions in that research, and apply that understanding to the problem you're trying to solve - but remember you (or worse, someone else) will always have to revisit the code you're currently writing later on. Don't make it harder on that person as much as you can.

You'll need to build an inner div, place it in the middle, column. Set the inner div to grid and style from there.
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing Grid</title> <style> *{ margin: 0; padding: 0; } body{ display: flex; justify-content: center; align-content: center; background: teal; } .outer-container{ background: lightcoral; margin: 0 auto; display: grid; grid-template-columns: 100px 1fr 100px; gap: 10px; justify-items: center; align-items: center; } .inner-container{ background: yellow; grid-column: 2 / 3; display: grid; grid-template-columns: repeat(2, 50%); grid-template-rows: auto; gap: 20px; } .block{ background-color: blue; padding: 20px; } </style> </head> <body> <section class="outer-container"> <div class="inner-container"> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> </div> </section> </body> </html> Pardon the eye-searing colors; I like to be able to see what I'm doing...
Your mileage may vary with the widths you're using - I'm testing on a surface tablet so the screen is smaller.

Sounds like you're looking at a facade pattern? Or maybe composite or adapter depending on how you want to use the objects.

This is typically called a toast notification. For instance, if you happen to use Laravel you'd install toastr as a dependency in pacakge.json:
"dependencies": { "toastr": "^2.1.4" } Create a toast component or partial:
<script> @if(Session::has('message')) window.toastr.success("{{ session('message') }}"); @endif @if(Session::has('error')) window.toastr.error("{{ session('error') }}"); @endif @if(Session::has('info')) toastr.info("{{ session('info') }}"); @endif @if(Session::has('warning')) window.toastr.warning("{{ session('warning') }}"); @endif </script> Include that component/partial in your main template file:
@include('components.toast') Finally, set the message in $_SESSION like so:
return Response::redirect('/dashboard')->with('message', 'Data Saved!'); Obviously if you're not using Laravel you'll have to do some digging but hopefully that's a decent starting point.

We don't know what the rest of your code looks like, so it's difficult to say what's actually happening.
My biggest question is is there a reason you're not using one of the many existing PHP template engines? Personally, I'm partial to Twig when not in Laravel land.