requinix

If you don't know the key and there's only one entry in the array then you can use current to get the value: current($my_coupon)->coupon_amount

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?

Forget the class thing. It would be nice but it's probably too complicated for you to do right now. This code while($row = sqlsrv_fetch_array($stmt, SQLSRV_FETCH_ASSOC)) { $rows[] = $row; }is where you fetch all the data from the database. Inside, each course1 in $row will be a DateTime object. When you json_encode() everything, DateTime objects turn into that date/timezone_type/timezone thing. You don't want that.So instead of using course1 as is, change the value to be a simple string: you need "/Date(", the Unix timestamp which you can get with DateTime::getTimestamp(), and ")/". $row["course1"] = "/Date(" . $row["course1"]->getTimestamp() . ")/";Do that before you add $row into $rows. Try that, then post your code if you're still having problems.

It doesn't look like you've tried anything I said. How about doing the from earlier and seeing if that works for you? If not, post the code you tried.

What is your code?

Yeah, you'd need to do it there. course1 is apparently a DateTime - discard that and replace it with a string value. Or be fancy and replace it with class JsonDateTime extends DateTime implements JsonSerializable { public function __construct(DateTime $dt) { parent::__construct($dt->format("r")); } public function jsonSerialize() { return "/Date(" . $this->getTimestamp() . ")/"; } } $row["course1"] = new JsonDateTime($row["course1"]);and let JsonSerializable do the rest of the work. Anyway, fine, whatever, but your code is still completely different from the example. So can you resolve that? What do the two samples have to do with each other?

Using the hash as the actual key is an implementation detail you shouldn't need to care about. If you use SplObjectStorage then just deal with the objects. 1. "Told to do something to that client" can't work until the client gives the key. Why does the client wait so long to give that? It should be giving that at the beginning of the process, as part of a sort of handshake protocol. 2. Since this code doesn't matter without the key being exchanged, you don't need to bother storing the client thing until that happens. Wait until you have the key and then store the object, which consequently removes the need for SplObjectStorage in the first place because you'll have the unique key (a scalar value) available.

SplObjectStorage is basically like an associative array that works with objects as keys. You are trying to use it as such, but you're also using these IDs as keys. Doing both doesn't make sense to me. If the IDs are unique then why not use them as the keys? And if that then why use Foo at all and not just an array?

You do realize your JSON is completely different from the example, right? JSON doesn't have a "date" type. It's just a string. When you encode the date, do it with the string "/Date(" + the Unix timestamp + ")/".

The N;path syntax for the files handler means to spread the session files N directories deep, so 123456 will be at /hermes/phpsessions/1/2/3/4/123456. Can you look at the session file itself to make sure it has data at all points in the process? It could be encrypted, but even if you can still tell whether there's stuff in there and whether it changes.

Welcome to the world of software development.

When I say to look at examples, I mean look at developer documentation. Not to use an app and guess how it works - find actual technical explanations. But actually implementing OAuth would probably be the best thing for you to do. Like real OAuth. According to the specs. They can expire, sure. Like I said it depends on your application. Random string.

While the client could hold on to the credentials, it shouldn't. Refresh tokens are the better solution. Exactly how access and refresh tokens work depend on your application. Access tokens could be good for a couple minutes or an hour and may or may not be limited to one per user, while refresh tokens are good for a lot longer (possibly indefinitely) and typically have one per device or web session. Since refresh tokens are so powerful they should also be revokable. Access tokens are basically like short-lived sessions, so their time limits should be pretty short - short enough so that they don't live long, but long enough that the client is spending more time issuing requests than refreshing access. The lifetime of refresh tokens are directly tied to how often the user is required to authenticate with your system, so the first question to answer is whether you want to force the user to enter their credentials ever again after the first time. As for the process, 1. Client authenticates and gets an access token with its expiration. 2. Client can then request a refresh token if it wants one. 3. Client uses access token until shortly before it expires, and/or continues until the API returns 401s. 4. To refresh, client uses the refresh token with a specific endpoint to get a new access token (if it hasn't been revoked). 5. Refresh endpoint returns a new access token (and expiration) and client resumes using that. Remember that you can always look around to other APIs, like OAuth, to see how they do it.

If you want to change the HTML markup of the button/image thing then that isn't the code for it. If all you want to do is change the appearance of the "button" then $image looks like what you need - but it's a path to an image, not "back" or "continue". Maybe you have some screenshots that would help explain what you're trying to do?

Did you try changing $image?

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;

I think the question here is whether "machine client" and "server" have to be separate; both running on the same server would greatly simplify the architecture.

Actually you kinda did: the output from netstat in your first post shows httpd, which is Apache.

It won't help for particularly bad halting errors, but you can use register_shutdown_function to create a failsafe that closes the connection (if not already closed). But... what kind of error is terminating your code yet leaving the process running?

If you look at a number of other projects, particularly open source ones, you'll see most use memorable port numbers (eg, 1337, 6666/7, 8080, 9000) above 1024 (ports 1-1024 are restricted in Linux).

Yeah, the forum doesn't have any kind of delete or deactivate button you can hit. I don't see any personal information in your account or your post (except the broken URL, which I've removed) so I would suggest simply forgetting about it.

This is not acceptable behavior. Thread pruned.

As said, PHP does not distinguish between 123 and 123.0. If you must have 123.0 then you need to do that manually. Which would suck. Are you absolutely sure it has to be a float? Have you tried an integer and the service is returning an error?

You're comparing with $first_name but you never update that value.

Right now I don't care about $json. Listen to me, okay? This code: <?php ini_set('display_errors',"1"); header('Content-Type: text/plain'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://eu.myconnectwise.net/v2017_1/apis/3.0/services/tickets/13934"); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: basic ' . base64_encode('#######'.'+'.'##########'.':'.'##########'))); curl_exec($ch); curl_close ($ch); ?>Put the right username and password in there, then run it. What is the output? If there's sensitive information then redact it, but otherwise post exactly what you see.