requinix

Files are nothing but big strings stored on a hard drive, right? So text encodings apply to files too.

And the webpage has to be UTF-8 too (if that's where this string is coming from) otherwise that "variable" thing might be an HTML entity-encoded string.

You can get ffmpeg as a PHP extension to bridge the gap, but you aren't going to find something purely PHP to do this.

Since the session is stored on the server (generally) you don't have to worry about it being altered. Put the bare minimum into the session: user ID/name, access level, maybe a couple other things that you might want to know frequently. You don't have to (and shouldn't) store the password in there since it's not like you have to authenticate the user with every request. Maybe you're confusing sessions with cookies? Cookies are unsafe, and while a cookie is used to locate session data the actual data itself is safe.

You do stuff with $c but it never comes from the session or gets saved into the session. It starts at 0 every time. You don't even need it though if you moved your data around to something a little better. Try a structure like $_SESSION[food] = array( array( [type] => [quantity] => [calories] => [unit] => ), array( [type] => [quantity] => [calories] => [unit] => ), array( [type] => [quantity] => [calories] => [unit] => ), ... )If the food type is a string you can use it as array keys too so it's easier to tell if one has been... "used", or whatever... yet.

I'd put my money on ffmpeg.

You aren't saving the value of $c and your for loop at the bottom is missing some $s. At least.

glob and scandir are the easiest ways to get an array of files in a directory. glob() can filter it by a filename pattern too so you could glob("/path/to/directory/*.html").

And that "/sms.php" part doesn't show up anywhere in the code you posted. I'm pretty sure that "URL address blocked" message wasn't generated by our forum.

Or is the URL a string? If so, where is it?

It sounds like you're talking about updating some third-party website because... I don't know why? I'm sure you can go into more detail about what you want to do.

So they have anything else in common? Would it make sense to combine the tables into one, then "donations" have Amount>0 and "costs" have Amount

Could use a UNION but it's still essentially two queries.

Irrelevant.

Sure: do 3 items with this random stuff and then only 7 items per page of the normal paginated stuff.

... Have you even tried to solve this yourself? I don't understand how you cannot see the answer.

You might have missed it. Let me quote it here for you so you don't need to scroll up: Write something yourself. Try it. If it doesn't work then come back, post the code, and tell us how is it not working. Then we'll give you suggestions on how to change it. Rinse and repeat.

"Stopped working" how? Errors or warnings? Maybe ones that your setup has hidden from you? What does it do and how does that compare to what it's supposed to do? Details. You know these things, not us.

Not to push the issue too far off topic but By using getters and setters, that's true. But I absolutely hate having them if only for the sake of having them - whether it's a property or a method, it's just syntax. (As I've heard it, the concept of getters and setters originated with code generation tools and I hate those too.) Meanwhile if their implementations are beyond simply getting and setting (ie, requires some amount of special logic) then that means there's underlying issues with how the data can or should be used and they require more complicated functionality beyond "change $X to Y". Take width, height, and MIME type. As far as I'm concerned outside code should be able to read those three without having to jump through hoops. It's not sensitive data. But setting any of them by themselves should not be possible because (eg) a] the image is immutable, or b] doing so is not merely a matter of setting a new value since it involves resizing (width/height) or converting the image (MIME type). And both of those are actions performed on the entity as a whole, not quick changes to some attributes. On the other hand an image caption may be arbitrary so simply getting and setting should suffice. I'm also implying, or trying to imply, that this all requires an intelligent setup (that, honestly, I'm very used to using) with concerns about visibility, immutability, validity, and issues like that. If you can't have that then you're precluding this whole idea.

header() does not immediately end your script - it will continue running. Use an exit; or die; after calling it. //not found header("location: http://www.mydomian.co"); exit;

Magic methods are that bad? What's wrong with an implementation like /** * @property-read int $id * @property string $name * @property int $size */ class Photograph extends DatabaseObject { // ... } abstract class DatabaseObject { private $data = array(); public function __get($name) { if (isset($this->data[$name])) { return $this->data[$name]; } else { // error } } public function __set($name, $value) { if (isset($this->data[$name])) { // check accessibility/validation/etc and set } else { // error } } }

Use __get, __set, (__isset and __unset too) and store the data in an array in the parent class. Magic methods

So do that.

Are you getting these arrays from a database?

As soon as you discover the thing is "empty", use a header to redirect (check the example). Make sure you do so before there has been output of any kind, including HTML and whitespace before your <?php tags.