maxxd

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.

https://www.php.net/manual/en/mysqli.quickstart.prepared-statements.php Honestly, if it's a possibility at this stage in your project I recommend switching to PDO. It's a much easier to deal with. And while you're at it, go ahead and look at OOP standards - they really do make a system easier to reason about IMO.

XHTML was a thing quite some time ago. Modern HTML has the semantic benefits that XHTML (as I understood it at the time) claimed to have, while not being as strict in terms of some of the usage. You'll also find modern HTML referred to as HTML5, though honestly these days I'm not sure if the version number even means anything anymore.

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>

It sounds like you're getting what you wanted in the OP - you're triggering the function from a mouse event on a form element. What you do now is up to you - we don't know what your goal is.

Try dumping out $data['products'] like so: dd($data['products']); Make sure there's actually anything there to loop through. You can also add try/catch blocks around the orderProduct and product creation and log any exceptions you catch.

Have you looked into Guzzle? You'll still need to write your own code, but it's certainly easier using Guzzle than using native php cURL.

I'm also a bit confused by the percent width comment - you can use percentage as measurement, but you certainly don't have to.

Use media queries to create rules based on screen size or browser device as requinix suggested. Though admittedly you may have some work ahead of you as WPBakery (as far as I recall - thankfully it's been a while since I've had to deal with its output) has a tendency to overdo it with the built in CSS.

Just a point of clarification, in this case json_decode is returning an object not an array. To access any of the values in the object, call the property key. For instance, to loop through the players you'd do this: foreach($obj->event_match_details as $detail){ echo "{$detail->playerfirstname} {$detail->playerlastname}" }

So you're saying you don't like HTML?

I hope this makes sense - it's how I thought about it a millennia ago when I was learning php - you can mix php and html, but you can't combine them. In other words, as Barand said above, if you want to output html without using the print or echo functionality of php, you need to exit php mode and enter the browser's default mode of html output by using the '?>' php closing tag. By the same regard, if you intend to inject php into your html you need to specifically enter php mode using the '<?php' opening tag. There are obviously exceptions to this (certain templating languages, etc.) but these are things to think about later on - right now don't worry about it. Just make sure all of the php code you're executing within html is contained in the '<?php ?>' tags.

Where is the data coming from? There could be several different reasons why you're not seeing whatever it is you're expecting. Which is a good point - what exactly are you expecting to see?

What you're seeing is the default landing page for Laravel. If you're surfing to http://localhost:8000/ it's matching the '/' route in the web.php file, so it'll render the welcome.blade.php file. If you want to see your questions/* routes you need to request them - go to http://localhost:8000/questions.

First and foremost, don't run the query in a loop. Chances are you can use a join to get a full dataset before you begin your loop. The other benefit of doing this is that your data will more than likely present itself in a way that makes what you're trying to do easier. Can't help you with how to do that as we don't have all the code and what we do have is clearly not the actual code (there's no $sqlb2 for you to loop over in what you've posted).

I take it there's a class called 'frontpage' with a non-static method called 'index'?

Does that mean that you've made sure you're using prepared statements, nonces for your CSRF, and proper XSS request headers or do you mean you feel fine altering user input because what you have looks like it's working as it is?

The image tag is the main element in this situation - it's wrapped in a picture tag (the container), and the src elements can be thought of in the same way that media queries are in css. You need to have the img tag in the picture element to actually display the image source as defined by the src elements depending on their media attribute. Basically, in your situation the <img> tag is the only actual element in the structure. The rest of it is conditionals.

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.

XMLHttpRequest is a bit outdated these days with the rise of the fetch API. That having been said, the fetch API can be a bit rough to wrap one's brain around if you're new to it. Either way, one option is to add an additional parameter to the AJAX calls (for instance, 'ajaxRequest') that isn't set in the normal call expecting a full page refresh. Check for that extra parameter in the processing code and you know how to return the data - either a JSON string of just the data or the entire page. I'm a little brain-fried, so I hope that makes sense...

This is where an MVC-style approach to the server-side code comes in handy. The display logic is in the view, and the controller decides what to return. If the request to the controller is AJAX-based (or POST, in this case) the controller returns JSON-encoded data whereas if it's not, it returns the full compiled HTML.

Whatever you end up doing with the email itself, do yourself a favor and use one of the major libraries instead of php's native mail() function. I'm most familiar with PHPMailer, but I believe laravel uses Symfony Mailer. Either is going to make your like much easier in the long run.

You require_once and use statements need to be outside the function; they're global functions. You can then use the classes inside a function. So, the instance that works, just put everything after require statements into a function and call it normally.

Structure-wise, I agree with mac_gyver. This is really no different than the hotel booking system you were working on before. A single cinema booking can consist of multiple seats, much like a single hotel booking can consist of multiple rooms. Take a step back, think about what you know from past experience, and re-evaluate your current data design; in this case I very much doubt that a "booking" is a single seat.