requinix

Stop touching the raw XML. Leave it alone. If you want to fix the name and... whatever you're doing to the plot... then do it after the XML has been loaded and do it to those variables you're using.

$data = get_url('http://'.$API_SERVER.'./channels.php?token='.$API_TOKEN); header("Content-Type: text/plain"); echo $data; exit; $API_CHANNELS = simplexml_load_string($data); $title = (string)$API_CHANNEL->name; $title = preg_replace('#(.*?) \(.*?\)#s', '$1', $title);If you do what I said there then you won't see M3U stuff and you will see XML. I'll ask again: what XML do you see?

Easiest way is to go to your profile and use the Topics (topics you've started) and Posts (replies you've made) links in the navigation bit on the left.

You can't "assign" an IP address to an email. What you do is have each of those servers configured to send email, which means installing appropriate MTA software and then doing whatever it takes to get the email message to those servers to be sent.
 
The MTA software is basically up to you. Postfix and EXIM are two of the big ones that can do it.
 
The other half depends - you haven't really given any requirements besides "send from multiple servers"...
 
You mentioned MySQL? And you're posting on a PHP forum? You can set up a PHP-based cronjob on each server that scans the database for emails that it should send and then sends them.

<?php foreach (/* get list of emails from the database */ as $email) { mail($email["to"], $email["subject"], $mail["message"], $mail["headers"]); }as a very basic example. More appropriate would be to install something like PHPMailer and use that to send the emails instead of mail(), because it can do a better job of it. 
 
But this whole thing is weird. Why bother with assigning specific servers? If they're all sending on behalf of the same domain then it doesn't really matter.

Because I thought the site should participate in today's events. I'll put it back tomorrow unless too many people complain about it.
 
[Apr 2 edit] I'm not sure anybody noticed the rotating buttons
 
[Apr 3 edit] And I don't think anyone saw I renamed the PHP forum to "PHP Coding Halp". I, for one, totally forgot about it until now

function parse_structure($source, $output = null) {
if (is_object($source)) {
// objects are easy: recurse over all the properties
$output || $output = [];
foreach (get_object_vars($source) as $key => $value) {
$output[$key] = parse_structure($value, isset($output[$key]) ? $output[$key] : null);
}
return $output;
} else if (is_array($source)) {
// arrays should contain all of the same data type
$output || $output = [];
if (is_scalar($source[0])) {
// foreach on the array would be wasteful - just check the first item
isset($output[0]) || $output[0] = gettype($source[0]);
} else {
// recurse over all the items and put the merged structure into [0]
isset($output[0]) || $output[0] = [];
foreach ($source as $arrayitem) {
$output[0] = parse_structure($arrayitem, $output[0]);
}
}
return $output;
} else {
// if $output already has a type then keep it
return $output ?: gettype($source);
}
} $output = parse_structure(json_decode($json) /* decode with objects */);

Do you understand what that 503 block of code does? It will prohibit the code from moving any further. I'm not sure if you need ?curl detection at all (I wouldn't think so from what you're describing) so I'd say to get rid of that whole thing.
 
Otherwise, if you're sure you have the right form fields then the rest seems correct to me.

Construct a valid URL with something like http_build_query:

curl_setopt($ch, CURLOPT_URL, 'https://10.10.10.10/vmrest/users?' . http_build_query(['query' => '(dtmfaccessid startswith +1214820)']));

That would be much better.
 
Templating has two approaches:
1. Textual. Do stuff like {{token}} and use text replacement. Very powerful but it's easy to make mistakes and create invalid HTML.

(self-closing tags are deprecated in HTML, by the way) 2. Syntactic. XSLT is an example of this. Uses the syntax of the HTML itself. Has some restrictions, which you can workaround with added complexity, but is always valid markup. Might look like

#1 is what just about everybody does. #2 is a dated approach that is mostly suited to specific circumstances.

Check the Inbound rules to make sure there's something for HTTP (and HTTPS if you need that) for your IP address.

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.