requinix

A password hash will always consist of alphanumeric ASCII characters. You will always be able to save that in your database. The fact that you're saying "if the password has non-alphanumeric ASCII characters then I can't save it in the database" means you're doing something wrong.

No, password_hash handles all the work for you. Including salting. Don't do anything extra.

You mean $time_stamp is that string value? Well, there's your problem. Also, the code you have there just isn't very good. Barand's solution(s) are simpler and make more sense. Might not be helpful to you, but it could be helpful to someone else in the future who has a similar problem.

"window" is an object. window.close closes the current window because that's what the variable means. If you have a variable for a different window, like one returned by open(), then you can call close() on it.

Those are access logs, not error logs. PHP may be writing its errors (if any) to the same place where IIS's error logs are going.

Then it's correct. You can be even more sure by outputting the error_reporting() value in code. What's the actual and full deprecation message? And have you searched the code itself to see if anything changes the error_reporting value at runtime?

Why are you guessing? Check the server and PHP error logs for why you're getting a 500.

And php -i says (at the top) that it's reading /etc/php.ini? What number is it showing for the error_reporting setting? You can figure out the meaning using this page (you're looking for 22527).

You've skipped past one very particular problem: you want an existing menu item's text to reflect something that can change. Using a variable for the addItem's label doesn't mean that you can change the variable's value later and the label will update. You would have to add and remove these items every time the custom-lc is clicked. So the truth is actually that no, the code you've posted doesn't work. Not that you're using it wrong but that it can't do what you want. And I don't see anything in the library you're using that lets you edit menu labels. I'm not sure how you came across that library, but when I search for "jQuery context menu" the very first result is this one, which looks like a much better option given that it's been updated during this year and, you know, it has actual documentation.

How many php.ini files do you have? Did you edit the right one? Use phpinfo or php -i to see which file it's using.

private static $templateMail = BASEURL . 'assets/mail/template.html'; This is probably wrong: the template should be a file, not a URL. You need a different constant (or none at all) instead of BASEURL.

Did you edit any of the configuration yourself? It pretty much works out of the box... and given that XAMPP said the port was already in use means that it was, in fact, running. It's a common thing that even English speakers will do. It annoys me, personally. I was unnecessarily harsh on you for it. I mean more that you (probably) shouldn't be creating this file at all. What is it? Most of the time, someone will do this sort of thing because the file acts as a database instead of, you know, using an actual database (which is the "M" in XAMPP).

1. You're using XAMPP on Linux? 😆 Just install Apache, PHP, and whatever else you need through your package manager. Normally. 2. It's code. Singular. "Codes" are things you enter into videogames. 3. Don't reference w3schools. Sometimes they tell you the right thing to do, sometimes they tell you the wrong thing to do, and if you're learning then you won't be able to tell the difference between them. Where did you put main.js? /opt/lampp/htdocs/js/main.js? Then the first form you had is correct. If not then (a) why not? and (b) the second form was correct (except "js/main.js" - no ./ - is cleaner and means the same thing), however you might discover problems with this approach... And changing that won't affect any of your PHP code. The thing with file_put_contents is a completely separate issue. That error is telling you that /opt/lampp/htdocs/pages does not exist. It's also a red flag that you're using code to create this filesList.txt file, but I'm going to ignore it. Also, please tell me you're not running this as root. Use your user account - give it ownership of /opt/lampp/htdocs and everything inside it.

A cover page is just a DIV with a page break after. Headers and footers are harder: HTML and CSS don't really do those. There are hacks for specific browsers that can mostly do it, but really if you need these sorts of things then you should be generating PDFs. Depending what library you use, there may be some special markup you can use to specify a page header and footer.

DIVs representing pages is a weird way of doing this. Normally you don't and you just create a regular page... You can use CSS to affect printing, though, such as break-before and break-after.

Some searching suggests the Twitch player has to do it itself, but in case that's not accurate, I would try using the FullScreen API triggered by when the screen orientation changes.

1. In order for Javascript to find the #input-id element, it needs to exist in the browser's DOM - that's the internal model that the browser uses to manage the page. 2. When you put things into the <head>, they happen immediately as the browser is loading the HTML markup it's receiving from the server. 3. Your datepicker input is somewhere down on the page. Putting those together means that DOM stuff in the <head>, such as using getElementById, is not going to work in 99% of cases. You're simply trying to do things too early and they're not available yet. The right way of doing this is to wait until the DOM is ready. Exactly how depends on what/whether you're using Javascript libraries, as most tend to give you an easy way to hook into that without worrying about the details; the classic example is jQuery's $(function) syntax. But for a simple, non-library method, it's generally sufficient to put your DOM <script> stuff at the bottom of the page. Browsers build up the DOM as they go, so putting your scripting at the bottom of the page generally means that the rest of it is ready to use. <html> <head> <!-- these resources will be loaded immediately when the browser reads the page --> <link href="css/hotel-datepicker.css" rel="stylesheet"> <script src="js/fecha.js"></script> <script src="js/hotel-datepicker.min.js"></script> </head> <body> <script> // #input-id does not exist yet... </script> ... <input type="text" id="input-id" name="datepicker"> ... <script> // now it does var hdpkr = new HotelDatepicker(document.getElementById("input-id"), options); </script> </body> </html>

This page lists their supported platforms. It doesn't go back far enough to list MySQL versions that existed around the time of Windows XP. Unsurprisingly. If you look at the Important Platform Support Updates, you'll see they killed XP support around 2014. Pull up the platforms page on archive.org around that timeframe, or a little later, and I bet you'll have an answer.

If the scanner cannot be told to ignore this warning, there is a minor modification you can make to the code that I suspect will "resolve" it...

There's no way we can tell you whether this file meets "legal regulations" and, since we don't know anything about you, all we can do to judge whether the file is safe is to venture guesses. It appears to be a valid file, even if it does some risky things - the scanner may have noticed the "eval" at the bottom, which allows executing arbitrary code - and follows some outdated and discouraged practices, and it does not appear to be malicious. You should confirm that the file hasn't been modified recently: something like this should not have received any recent modifications, and likely would be dated to the same time frame as many other files on the site.

String needs to be in quotes. You've got one set on the outside for PHP, another set on the inside for the HTML attribute, and now you need a third set for the Javascript string. You have three options: // raw double quotes, but escaped because of the PHP quotes $out .="<tr class='align-middle custom-lc' onclick='triggerClientContextMenu($cId, \"$coName\")'>" // double quotes as HTML entities, which won't conflict with PHP's quotes $out .="<tr class='align-middle custom-lc' onclick='triggerClientContextMenu($cId, &quot;$coName&quot;)'>" // single quotes as HTML entities, which won't conflict with the HTML's quotes $out .="<tr class='align-middle custom-lc' onclick='triggerClientContextMenu($cId, &apos;$coName&apos;)'>" These three options may leave you open to problems if $coName contains apostrophes and you haven't protected yourself against that. A fourth option is to run $coName through json_encode and then htmlspecialchars with the ENT_QUOTES flag (and them in that order), after which you can put it directly into the "code" without manually adding quotes. But the fifth option is better: take a whole different approach to this by not using 1990s' web techniques like inline Javascript handlers...

Does this triggerClientContextMenu(1, Company Name) look like valid Javascript code?

If you need a count then array_unique won't help you. There is one that can help, though, in this list. To output something before each "word", what have you tried so far?

I've heard opinions that if a piece of data (read: column) will often be null then it should be moved into its own table. I don't agree. Ah, then that means a one-to-many relationship and you're forced into creating that third table.

Generally, the first step for something like this is to figure out what sorts of "entities" you have. Don't think about it in terms of database tables: you're modelling the real world right now, not what you put into the software. These things tend to stand out on their own, like you could look up the data for each one individually. "A question" and "an answer" are the two most obvious things; you could think of "an image used in a question" as one as well, but I don't. Then you figure out relationships between your various entities and the pieces of data - "has one of", "has many of", that stuff. If you could have more than one of a thing then it almost always needs to be a separate entity (if it wasn't already). So here, I think Questions ID Type Text Image path Whether the image is inline or opens separately Answers ID Question FK Text Maybe a priority/sort order for arranging the answers Whether it's the/a correct answer The questions and the answers are obviously their own logical entities. I don't think the images are, like I said, unless you wanted to reuse images for multiple questions. You could still do it if you really wanted to, of course. The relationships are "each question has one-or-more answers" and "each answer belongs to one question" (I assume). That means answers must be their own entities, but that was already established. The fact that it's one-to-many means you don't need an association table and can just use regular FKs; if you were to decide that "each answer could belong to multiple questions" then you have a many-to-many and be forced into creating that third table. Likewise, I wouldn't say you need a separate table to associate a question's correct answers: the relationships there are "each question has one-or-more correct answers" and "each correct answer belongs to one question" (unless not, but this one's even less likely), which is identical to their general relationship and so fits into that system naturally without needing anything more than an "is a correct answer" flag.