maxxd

Yeah, honestly forget that MySQLi even exists - PDO is better and much easier.

If you have added the connection code, check your browser tools network tab to see if something is throwing an error. Just a couple weeks ago I spent several hours debugging a script that was barfing and come to find out I had typed 'context' instead of 'content' in a column name.

CodeIgniter 4 is leaps and bounds better than 3 - it was re-written from scratch to make use of modern development patterns. That being said, as gizmola mentioned it was still pretty bare-bones last time I used it, whereas Laravel is fully featured. Some may say too fully featured, but it's optimized very well and has a large and active ecosystem. For instance, if you don't want to pay for Pusher they just released Reverb, which is a Laravel-specific websocket package that isn't the easiest thing to set up, but once you do it's quite good. It has a robust queue system that allows the developer to do a lot of work asynchronously right out of the box. The learning curve is steep, but most frameworks have that problem. Just know going in that there is a lot of magic to Laravel, so making sure you're comfortable reading source code is important (although the docs are better than most, IMO). I've not used Symfony specifically but - again as gizmola says - Laravel is built heavily on Symfony components. Best bet is to try building something smallish in all three and see which sings to you. Personally, even recognizing that Laravel has plenty of warts I prefer to work in it (though that may be Stockholm Syndrome as I've been working with it almost exclusively for about 6 years now).

☝️

I agree - only use JavaScript when it makes sense to use it; there's no need to invent a reason. If you're using a SPA framework (Vue, React, whatever is hot this week in JS land) then you've got a reason to use JS to redirect the browser. At the same point, those frameworks have the foundation in place that will handle redirects in the background.

Happens to the best of us!

PHP uses the form element's name attribute to name the _POST or _GET variable. Your select element is named 'std', not 'Location_ID'.

I get the username -> email thing; it's one of those wonderful side effects of tech debt and the mitigation thereof. As far as the Laravelese, yeah - laravel is a very opinionated framework. What you can easily do for the validation on username/email is this: https://laravel.com/docs/11.x/validation#rule-unique So if I'm not mistaken (and it's late and I've had some wine so I may very well be mistaken) you can use 'username' => ['required', 'string', 'max:255', 'alpha_num', 'unique:App\Models\User,email'], PS - I'm not for hire, but if your timeline is very slow I'd be glad to help out when I've got time. Post here or DM me, but I can't guarantee I'll be able to respond quickly.

I also use intelephense in VSCode and I don't see it like it's shown in phpstorm. I have to admit i very much prefer popup on hover over inline.

That's a default feature of PHPStorm, at least. VSCode doesn't do it by default but I suspect there are plugins that will add the functionality.

Then it seems like an issue with the plugin - your best bet is to reach out to the developer about it.

Admittedly I'm not a server admin by any stretch of the imagination, but I guess it could be if you set up the right user/group permissions on the files. I will say - to me - it seems a bit more convoluted than actually just moving the files - a lot of modern IDEs will automatically update any include/include_once/require/require_once statements for you when you move a directory. Hopefully any of the multitude of people on the board that are better with server setup than I will weigh in with a more grounded opinion.

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.

Don't forget you'll be sacrificing image quality if you upscale the images. This might not be an issue, but every b2c catalog site I've built has wanted good, crisp photos of their products.

Forgot about how WP metadata works - ignore me.

I like to think of a framework as literally that - a frame you use to build your project on. So instead of having to write your database connection, display, and interconnecting code for each project you can concentrate on the actual functional logic for that specific project. Use the framework-provided database connection to get the data, write the templates to display the data (but don't worry about actually rendering the templates), and auto load the extra files you'll need to process the data the user sends to you, adjust and amend it as necessary, and send that data to the template that will render it. Basically, frameworks at their heart do the boring and repetitive stuff for you. Beyond that I think there's been a slight misunderstanding when you're talking about "controls". Most modern frameworks (Laravel, CodeIgniter, and CakePHP most notably) are based on the MVC design pattern wherein there are Models, Views, and Controllers. Controllers basically ingest the data the user submits, retrieves any additional data your system needs from the Models (and/or saves data via the Models), works on that data as necessary, and then sends that resulting data to be rendered in the View. So think of it like Models interact directly with the database, Views interact directly with the browser, and Controllers dictate the actual function of your system by interacting with the Models and Views.

Do a dd() with the credentials to make sure you've actually got what you think. You may need to clear your caches (php artisan optimize:clear). And of course, verify that the credentials you're using are correct and valid.

Each login is still dealing with a user of some role. You shouldn't be concerned with role at login, you should be concerned with role at display time. In other words everybody logs in via the same form and when the user accesses a page, what's displayed is dependent upon the role. So if there's an admin section of the menu, that's only shown to admins. And if there are pages that only mods or admin supposed to see, the user role is checked and the redirect happens at that point instead of at the login.

This is a little late, but note that in addition to using the simple '?' placeholder you can use named placeholders like so: $query = "SELECT * FROM ember_features WHERE id = :feature_id"; $stmt = $pdo->prepare($query); // prepare the query $stmt->execute(['feature_id' => 4]); // execute the query, suppyling dynamic value(s) as an associative array to the execute() call $row = $stmt->fetch(); Admittedly pointless in the query above, but when you get more placeholders in place it's easier to keep track of them using names.

A screenshot of your directory structure along side the code will help as well.

Even better, Laravel will throw an Illuminate\Database\UniqueConstraintViolationException when you try to insert a record that violates the SQL unique constraint. Just catch that before the PDOException or general Exception and you can handle it. Looking at your code, you don't have a username column in your create method. The POST['username'] field is assigned to the email column in the table, which is a bit confusing. Either way, heed Barand's advice to add a unique constraint on whatever your username column is, wrap your create() statement in a try...catch() that catches the UniqueConstraintViolationException, and make sure your create() method is inserting data into that column.

The times I've dealt with WPBakery it was a nightmare of nested divs, so it's possible you're just going to have to be more specific in targeting the element.

This is how exceptions work. You can always try it by intentionally throwing an exception from a method called within a try/catch in a different method. It'll catch - if it doesn't seem to, make sure you've got error reporting enabled.

I don't mean to be rude, but that code shouldn't appear once on your server, let alone 12 times. Just to grab the most egregious issue, the myql_* functions were deprecated over a decade ago. Beyond that, this is rife with SQL injection concerns and PHP has a whole set of functions to build an XML document dynamically as opposed to concatenating strings. The impression that I get is you're not a coder, which is absolutely fine and groovy. But given the state of the code you've posted, if there's any substantial financial concerns in it working, bite the bullet and hire someone to fix this right.