Jump to content

requinix

Administrators
  • Content Count

    12,396
  • Joined

  • Last visited

  • Days Won

    270

Everything posted by requinix

  1. Take a look at the things in conf-available and see if your custom directives seem to fit in with what's there.
  2. Honestly I don't quite follow exactly what's going on, but if all you need to do is cut off the hours at 20 then I'd think you should simply check the updated $sum and do a bit of math if it's above $horas.
  3. I suspect there's a cleaner way, but the only thing I can think of now is to turn those department IDs into a fake JOINed table (using a SELECT 1 UNION SELECT 2 UNION... chain, or VALUES), then use FIND_IN_SET.
  4. Don't put multiple pieces of data (multiple departments) into one field (dept_code). The correct way to deal with that sort of situation is to create a new table where each row contains (1) the user and (2) one of their departments. Most people will have only one row in the table but some will have more.
  5. Think about how the code is working. "If the sum is less than the hour limit, add more to the sum." That will keep adding and adding until you go over the limit. You have to stop before you go over the limit.
  6. Alright, that's confirmation enough for me. You are not using UTF-8 right now. You need to be. There are a lot of places you will need to check to see what they're doing. It will take more than 5 minutes for you to fix this problem so don't rush it. This looks like a good resource. A lot of it applies to you. Some of it does not.
  7. What is the JSON and what is the error? And are you using correct character encodings? UTF-8 for the database connection and tables and columns and strings and webpages and PHP settings and I could keep going?
  8. You get an undefined variable warning because the variable was not defined. Since you haven't posted the code for it, my guess is that you might have misspelled its name somewhere.
  9. Given that you wrote the minifier yourself, it's going to be very hard for us to recommend anything given we have absolutely no idea what the minifier is or how it works. I mean, I can't even tell if it's written in PHP... And on that note, why did you write it yourself? There are plenty of existing minifiers out there that don't have bugs like stripping significant whitespace.
  10. You are safe against SQL injection. Now the problem you have to solve is that you're storing plain passwords in your database. That's super bad. Fix it.
  11. You do know that ".class1.class2" and ".class1 .class2" mean two different things, right? Is the minifier buggy and incorrectly removing the space? Or is the source it's processing incorrect? How about more of a description about what's going on, why you have this problem in the first place, and exactly what you need when you say "find strings that match a pattern of"?
  12. What the heck is that? No. No no no. There's absolutely no reason to be doing that.
  13. Right: let PHP "cast", as in convert as it wants to. The loose typing system. There's no reason why a literal should be of the wrong type. If you need a float then write 123.4, and if you need a string that contains a float (why?) then write '123.4'. Well, actually, with floats there are potential issues with floating-point accuracy, so there could be technical reasons for having to express a float value as a string. I don't think there are accuracy problems with literals though, but worst case an inline round() would fix that. Besides in strict_types situations, the only time I would ever really use casts (or the function equivalents) is if I wanted to sanitize what was probably already a safe value. Like, if I had a paginate function for a SQL query, I would int-cast a hypothetical $offset argument before inserting it into the query.
  14. Actually PDO as a whole doesn't support floats. If you must have literal floats then yes, you have to cast them. Or instead of fighting the language you can let PHP cast them as needed.
  15. "£{$pom}" ?? "Even"; "£{$pom}" is a string. It will never, ever be null. It may be a shock to you, but the ?? operator is not the right hammer for this screw.
  16. That is not valid PHP syntax. Besides, the base-64 stuff is for file_put_contents. According to the documentation, file_put_contents returns "the number of bytes that were written to the file". That does not help you. Close, except you're not using valid PHP syntax here either. Programming is not a matter of throwing stuff into your IDE until it works. You have to actually understand what things mean and how to use them. Copying and pasting stuff might eventually get you the right answer but it's going to be a pain in the butt until you get there.
  17. The "actual filename" will be file_put_contents('./Collection_Posts/'.$file, base64_decode($uri)); ./Collection_Posts/$file. If you can write to that file then you can read from it and attach it to an email too.
  18. Look at what that query does. It returns an ID and a name. But how do you know what table they came from? You don't. You need to put something into the query that tells you the table. Something that is different for the two table sources. For example, one could use the string "pr" and the other "pt". Or maybe a nicer value than those, such as something I wouldn't know because "pr" and "pt" are terrible names for guessing about what their tables are for. Or why there are two tables as similar as they are.
  19. I don't see any syntax errors in what you posted. Get yourself a decent IDE that supports syntax highlighting for PHP and it should be able to pinpoint where the issue is.
  20. Then there's something going on that I can't see. Most likely because I'm not sitting at your computer. Change the alert() to a console.log() and make sure you see that happening.
  21. Are you sure your script is even running at all? Can you see the network request happen? Can you see the response?
  22. Then what do you get? Have you checked your browser's developer tools to see if there were any errors?
  23. Unless you are somehow processing those images, PHP isn't doing anything. In fact if you're linking to the images directly then PHP really isn't doing anything. The fact that the images are displayed using HTML that was outputted through PHP is completely irrelevant. The orientation is controlled by EXIF data. It acts as a suggestion to things displaying the image, informing them of how the image is intended to be displayed. When you see the image oriented incorrectly, that's the actual image. So my advice is to not use EXIF data. Before you upload those images, load them into some image editor and have it fix the orientation for you. Most editors are capable of this - some even prompt you about it when you first open the image.
  24. How are you uploading these images to your website? Is there any image processing happen? What and why?
  25. I understand what the problem is. Do you understand what I said the solution is?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.