requinix

Given that browsers tend to decide for themselves whether to use a cached version of a page or not (though you can influence that), the most reliable method would be to do two things: 1. Randomize the order of questions in a reproduceable way. shuffle() is always random and you can't control it, but if you moved the randomization into your SELECT query (which is possible) then you could get the same "random" ordering every time. You would then need some identifier in the URL that you can use or turn into a number suitable for this purpose. Exactly how depends. 2. Instead of telling people to go back, give them a link to click to "return" to the questions. This is a great idea because not only do you eliminate the Back button problem, you can give people a link that shows what their answers were and which ones were correct or incorrect. (If you want to.)

Stop that. Do it now. It does not have to be all-or-nothing, it's okay if older parts of your code don't and the newer parts do. Like Barand's code shows, it's easy to implement. No excuse for not doing it.

Well there's your first problem. Store it as an actual DATE and format it when you display the value to the user, then working with it in your SQL will be much easier - and faster, more efficient, using fewer system resources, etc.

$query = "SELECT * FROM locations WHERE location_name LIKE '{$_GET['term']}%' LIMIT 25"; Stop that. You have mysqli so use its prepared statements. If you want the phone number to show up somewhere then you're going to have to return it with your AJAX. Look into the documentation for your autocomplete plugin to see how you should proceed. For example, one possibility is that your AJAX (autocomplete.php) returns an array of [location_name, phone number], you tell the plugin that it should use the "location_name" value, and you provide a callback function when an entry is selected so you can take the phone number and set it in the textbox.

The error message says it's switch.php and that you're starting the session on line 10. That doesn't match up with what you've posted.

If you want to take the value "2021-06-21 01:00" and get the time portion then look at strtotime and date.

Is that what you want to do? Access it through http://computername?

Have you set up DNS inside the network yet? Do that, and add a DNS entry for the site.

1. Figure out which one was just submitted. Best method would be to create the location, note the location ID (you have an ID, right?), and check $r for a match (after you've added that ID column to the query). 2. As you output <option>s, mark the new one as selected. <option data-location_name="..." data-location_phone="..." value="..." selected>

If you have errors then the solution would be to fix those errors, wouldn't it?

Your HTML markup doesn't close the </div> properly. It also puts a <br> after it.

next() operates on array variables. You are trying to give it an array that is not a variable. It's trying to get the second item in that backtrace array. Use regular array offset [ ] notation instead - yes, you can do it right after a function call.

Yes to the Database/Entity stuff, yes to the constructor. Maybe yes to the composition. See what Doctrine wants you to do. The whole point of separating Database/Entity from Business is that your database classes don't need to fight against your ORM. So the question is not what you think you should do but what Doctrine says you should do.

Probably not? Maybe there's an extension to do what you want?

Impossible. The only way is_uploaded_file will return false is if you give it a file path for something that is not $_FILES[something]["tmp_name"]. Which, if it happens, is a sign that the code is very fundamentally broken.

Nope. At least not the typical image formats - I wouldn't be surprised if SVG could do that, but that's a special image format that doesn't work like the others. It's all about compression. Raw images aren't, JPEG images use algorithms that are very well suited to photographs but will lose some information to do that, PNG images compress in different ways that don't lose information, and so on.

Yes. I don't know what "maximum display size" is supposed to be, but reducing an image will always have some effect on the image depending on the image. If you store the file in the database then the file is stored in the database. Whether it's a "string" or not is debatable but the answer is basically "yes". The size of a PHP string is exactly equal to the size of the file. Please, think about that question until you arrive at the same conclusion yourself.

My point is that there is a function to load any supported image type from a string, so why not a function to load any supported image type from a file too? Error message and no image. But there are still going to be guidelines. Or do you want to be able to support images up to many MBs in size? The only limitations with limiting file size are the limitations on the file size. Not sure what you're getting at. One thing to remember is that loading an image into memory with functions like imagecreatefromjpeg will use a lot of memory. A 1MB file does not mean 1MB of memory. It means quite a bit more than that. So if you aren't careful, someone could upload a 10MB image and have your PHP script crash with OOM errors because it tried to use, I dunno, 200MB of memory to hold the image. Because the size of an image file does not correlate with the size of the image it contains: I can create a <100KB GIF file that is 10000x10000px in size, and if each pixel required a mere 10 bytes of memory to represent then that's 1GB of memory needed to load it.

imagecreate creates a brand new image with nothing in it. I want you to spend the rest of the day thinking how that could help you validate an image file. imagecreatefromjpeg is great for loading an image file, but only when you know it's a JPEG. A more versatile function is imagecreatefromstring because it can detect the image type, but you have to load the file's contents into a string. Is there a "imagecreatefromfile" that's like imagecreatefromstring but works on files directly? No. Why not? See above. That function is a safeguard to make sure you don't accidentally try to process a file somewhere on the server. If you throw in that check then you can be sure the filename is truly an uploaded file your script just received. Yes. It can guess at what type of image is contained in a file. It does not also then validate that the rest of the file is a valid image. For sufficiently small images, getimagesize to detect image type + imagecreatefrom(format) to load into memory + image(format) to save to a new location.

imagecreate: Create a new image imagecreatefromjpeg: Load a JPEG from a file is_uploaded_file: Check that the file path given was truly from a file upload Very, very different. If you can, yes. Saves the user from uploading a file that is going to be rejected. But you still have to verify it in PHP. For validation, examine with getimagesize. For sanitization, load the image into memory and resave it to file.

Step 1. Create classes that only handle database stuff. Do what Doctrine says you should do for "inheritance". Worst case there's no real inheritance feature and what you do is standard relationship stuff (with foreign keys and such). Step 2. Create classes that only handle the "application specific business" stuff. They use proper inheritance because that's what you do. They have whatever your application actually needs from them. Step 3. Make those application classes use the database classes to get data. I mean like abstract class BusinessAnimal { private $animal; protected function __construct(DatabaseAnimal $animal) { $this->animal = $animal; } } class BusinessCat extends BusinessAnimal { private $cat; public function __construct(DatabaseCat $cat) { parent::__construct($cat->animal()); $this->cat = $cat; } } That's proper inheritance, BusinessCat can have whatever methods to do things, DatabaseCat can work however it needs to work for database stuff, and BusinessCat uses DatabaseCat extensively to do things.

Alt + Shift + arrow key? I can't tell what you're talking about. Try looking through the keybindings list for something relevant.

And they'll do that. You can't stop them from attempting it, and there's no way to totally defeat brute forcing. But what proper password hashing does is make it difficult to get many passwords at once. People using "password" or "123456" aren't protected, those will be broken quickly, but people using real passwords will be somewhat safe because the sheer number of passwords to try hashing * the amount of time it takes to hash a password = a very long time. There are techniques to speed up cracking passwords, but they 100% don't work if each password has its own salt. In other words, using the password_* functions correctly is what you are supposed to do, so that's what you need to do.

Sure. Here's some commentary on the questions and answers they give: Variables vs constants. Decent except they say constants are defined with define() when modern PHP should be using the "const" keyword. Sessions. They really gloss over what they are, and they almost suggest that it's done without using cookies. PEAR is irrelevant. Almost nobody uses it. Variable variables should not even be mentioned. It's bad to use them at all. And saying things like "reference variable" and "stores data about the variable" is not right. Partial case-sensitivity is right. Variable types is basically right but the graphic pointless. What it says about resources is close but not quite right. Variable name rules is right. echo vs print. I hate that they say print is slower. Even if technically true, that is not the kind of optimization that new PHP developers should be concerned about. Oh boy, the disadvantages of PHP: "Not suitable for giant web apps". Wrong. "Open source is not secure". Wrong. "Changing the core behavior of online apps isn't allowed". I don't know what this is trying to say but I'm pretty sure it's wrong. "Using features causes poor performance". Wrong. "Poor error handling". Wrong. "Lacks debugging tools". Wrong. PHP vs HTML. Basically right. They should not be mentioning @. Again, not something new PHP developers should be learning about. Parser. Why are they even mentioning this? There is only one "type" of array in PHP. Thinking that there are three types will only create confusion. Notices vs warnings vs fatals. Eh, fine. Traits. Also fine. Javascript vs PHP. Saying "PHP has the ability to generate Javascript variables" is dumb. They don't even mention the concept of AJAX. foreach. I can't tell why this is in here. Why aren't they mentioning all the other loop types? Why not also mention if and switch and other constructs? This doesn't fit. Mentioning crypt() for hashing is incredibly bad. I threw out the whole article when I got to this point. include vs require. They do not "copy all the contents of a file". That's a terrible description of what they do. Poor description of cookies. Nothing is "installed", they are not just about "storing data about the user", cookies are always and necessarily "URL particular", and the comments about cookie limits seem to be lifted from a StackOverflow thread from 11 years ago. Why the hell are they bothering with ASP.NET? "Escaping to PHP" is a weird way of saying what backslashes are for. Path traversal attacks are important, yeah, but beyond the scope of this article. Do not get security advice from "Top PHP Interview Questions" clickbait. Final vs not. Correct, but what is this about "creating an immutable class like String"? Creating a database in MySQL. This is silly. session_start/destroy. Fine. memcache is dead. (memcached is not) Talks about "different ways of handling MySQL result sets" using mysqli functions without even mentioning the more common PDO. The code for using cURL has smart quotes. Smart quotes. "How to create an API in PHP" does not belong here. They are trying to give a precise answer with database tables and code and someone is going to try to copy it. Problems: Using latin1 charset Using procedural mysqli Using root as the database user Using the "connect or die" approach to error handling SQL injection Defining a function inside a (MVC-style) view Finally mentioning PDO. The article is just a series of FAQ questions in random order. GET vs POST. Decent, except where they try to say that POST is secure and GET is not. Type hinting explanation is... adequate. Yes, exit() can abort a script, but it should not be used for regular error handling. Finally, the quiz at the bottom asks questions that the article does not have the answers to.

That is what I see. It looks like long text is working correctly. Can you post a screenshot of what your problem looks like?