requinix

When in doubt, Wikipedia.
 
tl;dr: they will be in order.

According to the documentation, file_data is not simply the raw contents of the file. Take a look. Do you know what you need to do to fix that? It could be MailChimp is trying to un-

Mapping tends to be a thing when you're working with a framework that already has its own model system - and mapping practices.
 
If I were implementing this idea on my own then I would keep it simple: form model's properties match the form fields and it has load/save methods to import/export a database model, or models as the case may be (and obviously another method, likely inherited, for populating from request data).

It needs to be on. If it keeps turning off, I don't know, but it does have to be on for this to work.

The issue is that file_get_contents doesn't work on directories - "Permission denied" is Windows' weird way of telling you that.
 
If you want all files in a directory, and including the paths with the names, then use a simple * wildcard with glob().

glob($dir . "\\*")And note the escaped backslash since it's a double-quoted string. (Or use forward slashes.) The fact that
"C:\php\Inventories\Json"worked without them is a coincidence: there are no \p \I \J metacharacters.

Only if you have PHP 7.1.
 
Since backtrace information is decided at instantiation and not when thrown (unlike other languages), you could do the less glamorous
 

} catch (Exception $e) { if ($e instanceof PDOException || $e instanceof BarException) { $this->pdo->rollBack(); $rsp = $e->getMessage(); } else { throw $e; } }but for only two lines of code it's not worth the added complexity. 
That said, you should rollback the transaction for every exception, so I suggest changing your code regardless. Using a finally means you can skip the $rsp variable too.

$e = null; try { $this->pdo->beginTransaction(); $this->doQuery(); return $this->doMethodWhichThrowsBarException(); } catch (PDOException $e) { return $e->getMessage(); } catch (BarException $e) { return $e->getMessage(); } finally { if ($e || !$this->pdo->commit()) { $this->pdo->rollBack(); } } Demonstration

Unless you have a weird PHP configuration that's possible but one I've never actually seen anyone do (because it's so stupid) then data in $_SESSION is safe. But remember that sessions use cookies, so if a bad person gets a hold of a good person's session cookie then they could hijack their session. There's a lot written on the subject of session hijacking, but that's besides the point.
Also consider that people using shared hosting are sharing the same machine with other hosting accounts, and since sessions are normally stored as files, it's possible (again, depends on the server configuration) for one of those other accounts to look at session data.
 
Since it's safe, storing only the ID is fine. Storing the password is flat-out bad, regardless of hashing or encryption, and that applies to dedicated hosting as well.
 
Speaking of, passwords should be hashed. Not encrypted. Hashing can't be reversed but encryption can be. Use PHP's password_hash/_verify functions for that.
 
When a user wants to change their password, you should prompt them to enter their current one anyways - either through a secondary login screen (eg, "confirm your account") or through a confirmation box in the form. You should then change their session ID via session_regenerate_id(), which is actually something you should do on a regular basis anyways but is a bit more complicated than just that.
 
As for catching the password change, that's a question for you. Do you want to boot a secondary session because the password changed on another one? I probably wouldn't. You can always give the user a sort of "log out all other devices"-type action; if that was in place then you would have to check the DB on every page load anyways.

There's a fair bit of boilerplate code in your factory - particularly in createUserModel. You'll find yourself repeating that in all the factories.
Consider any of
a) Subclassing the factory, so the parent class handles the general work and the child classes provide the specialized logic for the particular models
b) Doing something similiar with the model; a parent class would handle the constructor and setting properties while the children implement any other logic they need
c) Using traits to at least move the logic into a centralized place, if you don't want a class hierarchy
 
For DI, you've already changed it up a bit so what I said is less applicable now.
Having to pass around various classes and such in constructors is annoying, right? It provides a sort of "perfect" dependency injection because you can customize absolutely everything, but at the cost of increasing complexity and of being a nuisance to the developer. You can take a step back from that and use a sort of (gasp!) registry instead; as a demonstration, I use something like

$this->tableGateway = Dependencies::get(userTableGateway::class); final class Dependencies { private static $classes = []; private function __construct() { } public static function get($class) { if (isset(self::$classes[$class])) { $class = self::$classes[$class]; } return new $class(); } public static function register($dependency, $class) { self::$classes[$dependency] = $class; } }But that's one of many ways, and they all have advantages and disadvantages. Use whatever works for you.

Use a backslash to escape, not an apostrophe.

Seems you're a little confused here. $row is the keys in the user_cards object ("1", "2", etc.), $v is the corresponding object; $key is "num_owned/num_used/is_locked", and $val is the corresponding value.
 
So looking at $val doesn't make sense.
 
Get rid of the inner foreach loop. It gets you $key and $val and those are worthless. Instead, decide what to do with $v if $v['num_owned'] > 0.

How about we try to solve the earlier problem instead?
 
What conflict? What was it doing and what was it supposed to be doing? Any error messages? And most importantly, what was the code?

Note that what you have will check if there's that 5-4 somewhere inside $input. As in it will quite happily match with

$input = "a bunch of stuff then 12345-6789 and then more stuff";If you want to make sure $input has only that 5-4 then you need ^ and $ anchors to mark the beginning and end of the string.
'/^\d{5}-\d{4}$/'

Your form has method="get" but you are using $_POST.
 
method=get goes with $_GET, method=post goes with $_POST.

If you moved done, valid, and file into the visitas table then rel_visitas_utilizador would not be needed anymore.

It means somewhere you did an unbuffered query and didn't read all of the rows and/or didn't ->close the statement. It was probably earlier in your code.
 
Switch to buffered queries, which won't have that problem and are generally better for everyone involved.
 
[edit] 2 minutes.

Yup, some features are limited for new users.
 
You seem to be a human so I've moved you out of the restricted group and into the regular user group. You should be able to set an avatar now.

Hidden inputs are all sent with the form when it's submitted. However submit buttons ( and ) and image buttons () will only send themselves when they are used to submit the form - and only one of those can happen at a time.
 
So what you need to do is figure out what image button was clicked.
 
1. Remove the hidden inputs since they're not helping you.
2. Give names to the image buttons (eg, "toner").
3. Look for each button to tell which was clicked. Note that there will not be a "toner" but instead "toner_x" and "toner_y" values.

You don't know about backslashes? How do you not know about backslashes?

echo "String with a " quote"; // nope echo "String with a \" quote"; // winner

That's right, and I don't know. It's quite possible - likely, even - that I don't know the full story behind what the number is and how it works.  

Only when debugging.  

Right.  

Nope.

You can't. You're the one who talked about resizing before the upload, which I took to mean you were doing something manually. It doesn't make sense but that's the only logical conclusion I could make. That resize class runs in PHP, which is on the server, which means you would have to use it to resize after the upload.
 
And by "upload" I mean the technical mechanism of a user using their browser to submit a form containing a file-type input, wherein the file data gets sent to your server and processed by your PHP code.

Variables defined outside functions are not available inside functions.
 
Pass $db as an argument to the method.

That output is for $my_coupon, right?
 
$my_coupon

Array (is an array
[test]with a "test" key
=> WC_Coupon Objectwith a WC_Coupon object as the value
[coupon_amount]which has a "coupon_amount" property
=> 10with the value 10. 
So

$my_coupon["test"]->coupon_amountDoing it this way means you need to know the coupon code. Do you?

The code is suspicious but I'll give the benefit of doubt.
 
http://php.net/manual/pt_BR/language.types.string.php#language.types.string.parsing
$script = "<?php \$conecta = mysql_connect('HOST', 'LOGIN', 'SENHA') or print (mysql_error()); mysql_select_db('BANCO', \$conecta) or print(mysql_error()); print 'Conexão e Seleção OK!'; mysql_close(\$conecta); ?>" . $script;

If you don't mind forcing a download instead of presenting it in the browser then you can do

header('Content-Disposition: attachment; filename="quote-123.pdf"');Otherwise make the URL to the PDF be something that ends in /quote-123.pdf. You can use URL rewriting (nicer) or change your /path/to/script.php to be like /path/to/script.php/quote-123.pdf which should still invoke your PHP script (easier).

You also need a line of code that adds the month category into the array. Outside of the loop.

$out[$element['category']]['category'] = $element['category'];Take a look at the documentation for array_values. Do you see what it does to arrays? It strips off the custom keys and replaces them with regular numeric keys. You need to do that to your array before you json_encode() it - those custom keys vs numeric keys are what makes the difference between getting {} objects or [] arrays in the JSON.