requinix

But it's the same Pokemon though, isn't it? Someone offers one up for trade and someone else makes an offer on it. Eh, whatever. It makes more sense (and it's easier) to have just the one table, but you can do whatever. Third, the whole point of a prepared statement is that it's reusable. Preparing the same statement inside a loop completely defeats the purpose of that. Create it once ahead of time, then execute it with the different values. Not that you need to do this at all, of course, since that single INSERT...SELECT will do everything for you all at once. Otherwise, I see no reason why it would only do one row. Maybe there's a key constraint getting in the way? Duplicate row?

First, question: why even do this at all? INSERT INTO user_pokemon (uid, name, level, exp, move1, move2, move3, move4, type) SELECT (user id here), name, level, exp, move1, move2, move3, move4, type FROM offer_pokemon WHERE tid = (id here) Second, question: why have two separate tables for this? Don't you think it would be easier to have one table and then just mark each row as, like, "pending" or "confirmed"?

If you "fixed it" but it doesn't work then you didn't fix it. That input type=file can work, I would think, however it will require changing some number of other things - I can't say exactly what since it's complicated and it will depend a lot on other things (which you haven't shown) but it can work. Either that, or go back to what you had before and do what I originally said about using Javascript to prevent the form from being submitted. Again, I can't say exactly how since it depends on things you haven't posted, but the principle is very simple: when the form is being/is about to be submitted, check that there is a value for that cover "file", and if not then stop the form from submitting and tell the user they missed a step.

If you've fixed it then you don't need Javascript...

Hidden inputs can't be required. They're hidden. The user can't do anything with them. Assuming you have some sort of Javascript to read a file and put its contents into that input, which is weird because it's reinventing the wheel, then use more Javascript to prevent the user from submitting the form until they've chosen the file.

Done, though the thread can remain.

"Not found" means you have the wrong URLs. Pay attention to what's going on in your browser's address bar. For instance, I see you link "about.php" in one page but "/about.html" in the other...

Have you already confirmed with your whoami that PHP is running as the same user as you use for SSH? Have you checked for error output from the command?

...and the rest of your post is... where?

Post the EXPLAIN output of your query. EXPLAIN SELECT c.branchName as Branch, ...

I'd ask exactly how confident you are that the strings are definitely going to look the way you think. If you're 100% sure they will definitely be "[Stuff] Text (Page 123)" then great, but if not then...

I don't think there's a simple way to see all the cookies Chrome has remembered across all sites. You can see what cookies are relevant to a particular site by pulling up the dev tools while on one of the site's pages. Related, you can see what cookies are being sent to the server by examining the request information of most anything in the network tab (at least, of the things going to your site) and also whether the server wanted to add or change a cookie in its response. Sites don't have any way of knowing your user account or the computer's name - unless the browser specifically sends that information, which requires some very specific and an unusual setup that only ever happens in intranet/company network environments, and certainly never with stuff on the general public internet. So yes, the value could be anything you wanted. In fact, all of those cookie, name, firstplay, and secplay values from the prompt can be whatever you want at all, as they have no actual relation to you or your computer. The truth is that the site sees you as any other visitor, and will or won't record you just like for them. However, you could make some minor changes from your browser to make your own cookie special - namely to make it last forever, rather than be temporary like everyone else's...

Now I've lost track of what you're doing. Do you want a running total of working minutes that doesn't count non-working days (even though it seems they have working minutes being counted?) or is that a second problem? But I don't see the running total already in here. Is the SUM(@working_minutes) able to do that? If you have it, I would expect a HAVING(the effective column name) <= 1500 would work. ...that being if you want days that don't go over the total (up to your example's Wednesday). If you want days before that total and then one more day after (the Thursday) then stagger a variable/column to use as a flag: determine if the running total at that row is <=1500 but before updating it for the current row's data. The effect is that the flag flips on the row after it goes over the total. Then add a HAVING to exclude rows after that point.

It works, but it's weird and confusing in how it does. There's two parts here: the Don3 value, and the "first" cookie. Everybody who visits the site is going to get a cookie (for their second and later visits) that says the user is Don3. And everybody who visits the site is going to get a cookie (ditto) for that "first" tracking. If you have either/both of those cookies set up before visiting the site then it won't count you. Regular users won't so they will get counted. But after that, everybody will have the same two cookies and won't get counted again - until those cookies disappear, of course.

Perhaps you'd be interested in a function that can strip HTML tags except for maybe some that you might want to keep?

Your schema is causing me physical pain. edit: Oh, you mean you want a running total? Then wouldn't you need a condition in here that only totals the hours if the date is a working date?

If you're going to work with PHP then I suggest you learn the fundamentals of PHP. That's going to be really important for you to be able to write code that actually works. When you have a grasp on it, spend some time learning about how your MVC framework works. About how views work, and about this $data variable it apparently sets up in the view, and about how to use view classes to pass data. I say that because I can see (1) you did not make anything public, and (2) changing $data->mPaperId to just mPaperId actually made your problem worse. What you should (as far as I can see) be doing is leaving mPaper and mPaperId alone, make your mStudylevelId and friends public (and please rename them to not have an underscore), and then using $data in the view to reference those properties. But that could be hard to understand if you don't have a basic knowledge of PHP or of the framework you need to use.

Post the code you tried, both for the class and for the view.

You can't access $StudylevelId and such because those variables do not exist. You should use what's in $data. You can't access $data->_mStudylevelId because it's private. Either make the variables public, like mPaperId is, or find some other way to make those values available outside of the class.

That sure does look like the fundamentals of RDMSes. Plus a little more than what I would call fundamentals, but still important things that someone should know if you're looking to focus on SQL and databases specifically as a career. Are you asking whether this course looks like it would be beneficial to you? If you're not already familiar with most of these things and/or want a formal setting to learn them then sure, it looks beneficial.

...Your question is how important it is for someone to know the fundamentals of what they're working with?

If you don't need multiple user accounts then why do you need signup and password resets and such? Those features are for letting (multiple) users manage their own accounts - if you don't have multiple users, or if you don't mind managing their accounts for them, then you don't need those features. Partly. A library will give you the tools to build a bookcase, but you still have to build the bookcase yourself. My opinion of Laravel is primarily technical in nature: I don't believe it is a well-designed piece of software. Laravel provides a lot of features, but it will not be everything you need: you will have to do some work yourself. Which means you'll have to understand Laravel and deal with its... eccentricities. Spoiler alert: Laravel or Symfony or CakePHP or whatever runs on the backend has approximately 0% to do with what you see on the website itself. Those things are nails and screws and paint primer and are great at keeping the bookcase together and usable, but you are absolutely not going to be judging the bookcase based on whether it used nails or screws. Whatever system you choose, the frontend is what users see and interact with, and the frontend can be whatever you want regardless of what's happening in the backend. Frameworks like Laravel will give you a starting point to build from, but unless you want to keep the stock appearance they provide you with out of the box, you're going to need something separate. Maybe you make it yourself, maybe you buy it, whatever. The problem is that things like user authentication are tricky. It's easy to do, but it's not easy to do right. Learning how to do it right will take a long time and you'll be reinventing how shelves work. If you want to do that then great, and I even encourage it, but most people want shelves they can put their books on today. Professional, huh? So how much money are you willing to spend? You willing to help pay the salary of some "professional" developers? Those are rhetorical questions. Fact is, the best stuff you're going to find is what I've already said and you've already seen. Another fact is that there is rarely, rarely ever going to be a piece of software out there that does everything you want. Because you're the only one who knows what you want, and you're not out there writing it. So you have two choices: you can lower your expectations to find common denominators already available, or you can keep your desired set of features and functionality and accept that you'll have to do some amount of work yourself.

Laravel is dumb, but a thing that exists and is popular and is dumb and people do use it. It's primarily an entire framework, as in it provides a dumb foundation for an entire website/application, but there are dumb library aspects to it too. I wouldn't suggest it because it is really more of a dumb framework than a library, so using pieces of it may not work out. Not that I ever have done so myself, given that Laravel is dumb, though I have used Laravel (as a framework) before, so take that with a grain of salt. You should also consider that Laravel is dumb. I would put far more faith in an ecosystem like Symfony, which is pretty much the de-facto choice of libraries for PHP, than I would in random things you'll find across the internet. Especially things that haven't been touched in years, which means they haven't been maintained, and since no code is ever perfect this also means it has bugs that aren't getting fixed. Meanwhile Laravel, despite being dumb, actually uses some Symfony pieces internally, which isn't dumb. Using Symfony does require a little more effort on your part as it tends to try to be powerful and this can mean it sacrifices some ease of use, but this is a good thing as you're working with a - dare I say - not dumb library. But I wouldn't be a senior developer unless I gave you the standard reply: "it depends". The primary matter is going to be what kind of "auth" you're talking about. Do you mean a full user system, like with signups and password resets and an administration tool? Do you mean something to password-protect some files, or a section of your site? Do you need something that looks nice or can it be something super simple provided it can do the job? Do you need to deal with user accounts being added and disabled, or just something quick where you can give out a password to people you want to allow access?

Probably, yes. Like I said, get yourself the email and headers in your PHP code and see what you have to work with. If the headers include the results of your provider validating the email, like apparently it does, then that's all you need to do and there's no need for what ChatGPT said about verifying it yourself.

You don't have a filename for any of those files. Is there supposed to be a filename for all of those files? If so then you need to fix that. If not then you need to change your code so that it doesn't try to show a download button if there is no file to download.