maxxd

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.

A more efficient way is to only select the 8 rows you're looking for instead of selecting the entire table.

In the commented out version, $column is between $where and $rule. So, when you use the second block of code on the commented-out version of get(), 'OREDER BY RAND()' becomes $column and $rule is blank.

PHP 8 requires parentheses when using nested ternary operations - https://lindevs.com/nested-ternary-operators-requires-explicit-parentheses-in-php-8-0/.

You can use plain php curl, but honestly I think it'll be easier to deal with if you use Guzzle. I find it much easier, especially when dealing with passing tokens and keys and whatnot; as the docs say:
$client = new GuzzleHttp\Client(); $res = $client->request('GET', 'https://api.github.com/user', [ 'auth' => ['user', 'pass'] ]); echo $res->getStatusCode(); // "200" echo $res->getHeader('content-type')[0]; // 'application/json; charset=utf8' echo $res->getBody(); // {"type":"User"...' Give it a shot and come back with code if something goes weird.

The data you're sending from AJAX doesn't include a 'submit' index, which loginizer.php requires to do anything.

Personally I like to refine and/or finesse the data as necessary in the controller before it reaches the view. This sets up basically very dumb views where any business logic is taken care of before the view is rendered. However, part of the system I'm currently working on does pretty much what you describe and passes raw data directly to the view where it decides what to display and how and it works just fine. As requinix points out, some degree of coupling is pretty much unavoidable so I guess it depends on what's easiest for you reason about.

Check boxes aren't be set in $_POST (so it won't be in $attachment, I believe) if they're not checked on the form. So, the isset() won't update the record if the user deselects the check box. What I'd recommend is get the existing post_meta for the record before you try to update. If the value exists, your system will know that the user has deselected the previously selected checkbox and you can delete the post_meta record. If the post_meta data didn't previously exist, then the user never has checked the box and you can skip the update.

I assume you've got the authorization functionality working? So, instead of hitting the database and checking the user's access level or user role, just return the appropriate value to allow the user in thereby fooling the system into thinking the authorization mechanism returned true.

OK - is anything being displayed? Add
<?php error_reporting(E_ALL); ini_set('display_errors', true); ?> to the very top of your script. Do you get an error before you try to submit the form? Or after?
 
Just looking at it, it could be that you're trying to send an email to the literal string '$name' - single quotes in PHP don't allow variable parsing. Plus, they're not necessary in this instance.
 
And all joking aside, please do check into some validation before you use the mail() function. You'll be glad for it later.

Typically this happens when PHP outputs an error. Check your console and see what the output is from the server. Looking at your $queryForCheckInLijst, it may be a SQL error - it looks like you've added a couple column names without commas. I haven't looked through the rest of the code, but that's a place to start.

The cookie superglobal in PHP is $_COOKIE[], not $COOKIE[]. So that may be part of the problem you're seeing. And as long as you're using the jQuery cookie plugin (which I assume you are from the snippet you posted), you should be able to read the contents of the cookie with:
console.log($.cookie('calc')); See this SO question for more details. Also note that the jQuery cookie plugin has been deprecated in favor of a non-jQuery dependent version.