maxxd

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.