requinix

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?

I mean it sounds unethical when it's a human doing the injecting. Keeping the database stuff separate from the business logic stuff means you don't have to try to coerce Doctrine to make things work the way you want. The database models stay simple and use straightforward Doctrine stuff, then the business models are where you design the classes to work the way you want them to work. Like the database stuff doesn't really do inheritance. You could set them up as just regular relationships. The business models are where you do real inheritance, as in "class Cat extends Animal". And you don't have to fight Doctrine to make that happen. Then there ya go: don't do it, and make the inheritance happen in a different non-Doctrine place.

Oh, it's a textarea. Take a look at these options.

They're called "snippets". What?

So I guess that means you're editing the data on the page without it refreshing? Normally table rows will grow in height according to their contents, so if that's not happening for you then it seems like there's something explicitly preventing that from happening. How all does that work? Your screenshot looks like it shows good behavior so what's a screenshot of the bad behavior? What's the HTML for the row?

You're asking in the PHP Coding Help forum so that suggests you're looking for a PHP solution to your problem. There isn't one. PHP cannot do it. But if you don't mind a CSS or potentially Javascript solution, yeah sure. Explain more about what you want from this increased height stuff.

Injecting dog DNA into some animal sounds highly unethical... Anyway, point is that you still end up creating this extra "Dna" stuff. So there's Animal, Cat, Dog, Mouse, DnaInterface, CatDna, DogDna, and MouseDna? Plus the coupling Cat <-> CatDna <-> DnaInterface and so on. It's all too much. Don't know how common. At this point I would have started switching over to distinct business models. Keep Cat, Dog, Mouse, and Animal as separate entities with their own data but probably with some helper methods to deal with the relationships, then set up real Cat, Dog, Mouse, and Animal classes using normal inheritance practices. That means you can do things like have Cat/Dog/Mouse constructors that take both a Cat/Dog/Mouse model and the Animal model (and you pass the Animal model up to the parent constructor) - or just take the Cat/Dog/Mouse and use some relationship getter to get the corresponding Animal.

http://alap.vtmk.hu/forum_topik.php?id=27 ? Can you add a post that does not use wordwrap() so I can see what the problem looks like?

Read through documentation and articles about creating plugins first. It'll make understanding existing plugins easier because you'll actually know what you're looking at. When you're ready, start with a Hello World-type plugin you make yourself. Something very basic. You can use other plugins as references for what to do, but don't blindly copy stuff from them. Then add more features as you go. Hahaha of course. I quit text editors years ago. Notepad++ is a popular non-IDE. It's a great text editor, got lots of plugins, can do a bunch of things, but ultimately it's a text editor. VS Code is relatively new and has become one of the top IDEs. It's generic which means you have to install extensions for many things, but there are tons of those. PhpStorm is older but dedicated to PHP and all-around a good choice.

Your composition is backwards. Consider if you injected Cat/Dog/Mouse into Animal. It's a simple question but how would you type that property? class Animal { /** * @var ??? */ private $dna; You can't. You'd have to make each animal itself inherit from some "Dna" thing. Which would make this all the more complicated. But if you did composition the other way around, you would have class Cat { /** * @var Animal */ private $animal; Of course this isn't quite inheritance in the normal sense. It's the concept of inheritance but implemented using composition. Actual inheritance would be "class Cat extends Animal" and thus you'd have to somehow get Animal's data directly into Cat. Not sure if Symfony/Doctrine can do that, but if it were custom code then it wouldn't be hard (SELECT * FROM cat JOIN animal...).

Stop searching StackOverflow and start learning how to write software. Getting Started guide

If you copy your code directly into the post editor then our forum will see the spoilers and convert them to HTML. Instead, click the Code <> button in the post editor, copy your code into the popup, and use that to insert into a new post. You should not need to use wordwrap(). If a long post stetches the page then that means the post is not acting like normal HTML is supposed to act. Can you give us a link to a webpage that shows a long post?

Also, that article you linked is absolutely terrible. Stop using that site, and I'm also going to ask you not to link to it in the future.

exit() can terminate all execution, yes. It is almost never appropriate to use.

If those words you wrote were intended to ask about whether your PHP script has to be executed in order for that Javascript to be sent to the client, the answer is yes. Perform obvious validation with Javascript (which you include with the form or in an external .js script), like checking required fields and value formats, then do the same stuff in PHP plus whatever else because you can't trust Javascript validation to be secure. You can use form field attributes like "required" and "pattern" to make the browser do that validation instead of needing Javascript, but in exchange for the convenience you give up most customization of the error messages. Which may be perfectly fine for you.

Okay... Not entirely sure what all that means. Mostly I was asking to see if there was some way to set things up so that you wouldn't actually need that details-control class to begin with. Honestly, I think that could be possible. Take a look at the createdRow callback option.

So, like, this is going into some sort of table, and you want to be able to add columns to list in that table without having to change a whole lot of code? Like I said, fix the query to return only the columns you care about. Want to add a new column? Add it to the query. Really easy. Then when drawing the table or whatever, you can use a simple foreach($row as $column => $value) and output it as you want because $row will only have the columns you care about.