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.

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.

To build on what requinix has said about git, there are GUIs available to make life easier. Especially when you're starting out using the command line to deal with git can be confusing and a bit daunting. I've been coding for decades and still use Sourcetree because I'm more comfortable when I can see the graph (don't worry about what that means for now). And my memory is crap so remembering the exact commands and parameters is tiring. As for VS Code, I'll just agree that PHP Intelephense is required - I also use PHP DocBlocker, which rocks. There are other extensions for HTML, MySQL, and JavaScript as you grow, as well as framework-specific extensions depending on where your journey takes you.

If you're not getting any errors and everything in the $_POST array is where and what you expect, it sounds like things are working so far as you can control. I don't use MailJet, but I assume there's a dashboard where you can see emails sent through your account, or at least how many were sent per day. It's possible something is catching it between send and receive, but again you'd need to verify they're actually getting sent through the service first.

I don't see where you've posted your form code in the thread - just to confirm that you've got all the data you think you have, put the following right after the `if($_SERVER['REQUEST_METHOD'] == 'POST') {` line: die('<pre>'.var_export($_POST, true).'</pre>'); Then check to make sure there's keys for email, subject, and msg in the $_POST array.

I feel like there's an echo in here.

jodunno is correct - you need some sort of persistence to make this work. The web is an inherently stateless medium, which means that by default any work a visitor does on a page (start a timer, set a variable, write a book, etc) is gone as soon as they navigate away from or refresh the page - nothing on that page remembers what was done on it before the refresh. I don't see any php in either of your code samples so I assume you'd rather stay in javascript. Look at sessions (https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) because it's gonna be the easiest way to do what you want. You'll save the expiration time to a session variable when the timer is started, and on every page load check to see if that session variable is set. If it is, check to see if it's expired - if it's set but not expired, don't re-initialize the countdown. If it's not set, initialize the countdown. If it's set but expired, tell the user that.

You've gotten quite a bit of good advice here - what have you looked up or tried after reading it?

Yeah, I had a fairly robust component library before I ended up at jobs that used or were moving to Laravel - it's a good way to go whether you're using a framework or not. And it's always possible to use packages as bits and pieces in your own home-grown PHP code. Symfony is modular and it's easy to use composer install to use the packages you're interested in. Same with some of the Laravel packages, though I think that's probably more difficult as there's a lot of inheritance in Laravel and that could cause some issues.

Using a framework like Laravel or CodeIgniter will cut down on the boilerplate code you're creating, but you still need to code. So while in vanilla PHP you'll write the DB connection script once then include it in an object and use that to persist the data to the database, with a framework you'll still be doing the same basic thing. The only difference is that someone has already written the DB connection for you - you still need to assign the values to the columns and tell the framework to save the record. Where frameworks really come in handy is convenience and convention. Most frameworks that I know of these days are OOP-based so they're using either PDO or MySQLi behind the scenes, and most will parse the insert/select queries you pass to them into prepared statements. This is obviously convenient because you don't have to specifically write that code. It's still very possible to screw it up and bypass it, but you kinda have to try to do it. The convention part is less obvious and arguably less ... good, I guess. Frameworks have their own dialect of PHP and it's not always easy to learn or keep track of. On top of that, there's a lot of magic some frameworks (cough cough ... Laravel) inject that can make it difficult at times to reason about the path the data takes through your system. Once you learn the dialect you can get things done quite quickly, but sometimes that dialect changes in an update and that can make life difficult. Again, Laravel was most notorious for just changing major things in minor updates but they've lately stopped doing that and the upgrade path is much easier and safer than it was just a few years ago. That having been said, some of the major updates can still be rather jarring. I'm not a blind fan of Laravel, but I've been using it for about 5 years now almost exclusively and I've gotten used to it and find it enjoyable for the most part. It offers a lot by default and once you get used to the syntax, service layer, and some of the other magic involved it's possible to get a lot done quickly. I've also worked with and enjoyed CodeIgniter 4 but it offers less built-in functionality and magic out of the box (or at least it did at the time). Yii sucks in my experience and opinion, but YMMV. Oh, and obviously there's a learning curve with a framework - regardless of which you choose.

Making the transition from procedural to object-oriented can be daunting at first, but it's worth it in the long run. The code (when written correctly) ends up being much easier to parse and reason about and - as mac_gyver alluded to with the comment about exceptions - much safer and more stable. Not only that it's the way the core is headed, and most if not all frameworks are object-oriented by this point. There are a ton of resources online, and of course you've got a great resource in this forum.