requinix

Like much of the stupidness that is WordPress, there's one function to output something and another function to get the value. Which one do you think you have there? Can you find the one you want?

This forum is for the posting of job or contract opportunities - not for discussing the job. Replies will be moderated and very likely ignored by staff. Due to technical limitations, replies are allowed in case of situations where the original post does not include enough information, such as a means of contacting the poster or the company they represent, however this will be handled on a case-by-case basis. Staff will not monitor this forum for threads missing important information or for posts asking follow-up questions; use the reporting system if you feel such action is necessary. Abusing these privileges may get you a warning and/or ban.

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-

That would have to do with code that you haven't posted.

The right way to get the contents of a file is with file_get_contents(). Dealing with a file handle and manually reading from the file is a chore. And swapping out the fopen/fread/fclose with file_get_contents will not affect anything with the API call. The error says that the request body was null. That would mean json_encode() returned "null", which means $fileInfo was null. Probably. What's the full code, uninterrupted, between defining $fileInfo and the cURL stuff?

Look at the structure: Array ( [0] => Array ( [prices] => Array ( $prices is an array (first line) which contains a [0] key (second line) which is itself an array that contains a [prices] key (third line). foreach ($prices[0]["prices"] as $price) {Each $price looks the same as the first one, which is [0] => Array ( [price] => 4.99 ) an array that contains a [price] key. echo "<li>" . $price["price"] . "</li>";

You did define $fileInfo before the cURL call, right? And in the same scope? And $fd = fopen($file_name, "rb"); $contents = fread($fd, filesize($file_name)); fclose($fd);that is silly. I don't understand why people keep doing that.

Actually, forget the coin. Find a code style guide from a project you like and adopt that.

Consistency is good, sure. But you're spending time on a matter which is not even a matter. The name you give to a temporary variable that lasts less than a dozen lines of code is more important than this. Don't know which to choose? Flip a coin. Programming is not about copying what other people are doing. ...what coin you flip is probably more important than this...

The first number is a standardized error code that will probably only give you a general explanation as to what the problem was. Compare MySQL's error codes with PostgreSQL's and you'll see MySQL uses SQLSTATE 23000 for no less than fourteen distinct error conditions while PostgreSQL uses just the one. The second number is vendor-specific. So no.

I think it's completely and utterly irrelevant.

NULL represents a lack of information. This would be a good time to use it. In my opinion, you should have another means of knowing whether the match has been played - deciding that a match has been played should not depend on there being a score recorded. Perhaps a status ENUM (eg, "scheduled" vs. "played") or a played flag (false/0 vs. true/1).

Keep-Alive is potentially a relevant concept here: messages are periodically, on the order of seconds or even minutes, exchanged between the hosts simply to confirm that both ends are still connected and talking to each other. If you're normally exchanging messages constantly then you don't need this. TCP already has a mechanism to re-send messages so you don't need to duplicate that particular aspect. What you need to worry about is whether the recipient is in the process of responding; with your cross-client messages you also need to think about whether your connection to the server is fine but its connection to the other client has been broken. I would use Keep-Alive (eg, ping/pong messages) between each client and server. If a request is lost then either (a) the next Keep-Alive will fail and the connection should be severed, or (b) the Keep-Alive continues and you... well, you just keep waiting (unless you want to add a sort of timeout/TTL concept to your messages). A Keep-Alive can also provide a way for the server to track which clients are still connected, so if a cross-client message needs to be sent and the recipient is down then the server can immediately reply, or maybe spool the message waiting for the problematic client to reconnect. Of course TCP has Keep-Alive too, so you don't necessarily need your own version, but if it's not much overhead to implement then I like the idea of knowing not just that the connection is working but that the applications on either end are still working too (and not, say, stuck in an infinite loop somewhere). If the peers are potentially doing long-running operations then this is probably not a good idea, because regardless of what React hides under the hood PHP is still single-threaded. Regarding the excerpt, keep in mind that JSON-RPC is designed as an underlying transport mechanism for the exchange of messages. A read-through of the OSI model will help. Technically OSI deals with the actual underlying networking principles, and everything you're doing is part of the application layer, however since you're working with a communication protocol you can draw analogies between OSI and what you're working with. JSON-RPC is mostly the transport layer-side of things. It deals with the message format and how they're exchanged between peers. That part of the spec is talking about what the layer should do when the connection is severed, and is necessary not just because closed connections can happen but because JSON-RPC isn't actually the transport layer (TCP is) and is thus susceptible to what the real layer does. To communicate the connection problem with the higher layers (ie, your application) JSON-RPC 1.0 mentions exceptions. These aren't "errors" that it otherwise mentions least of all because errors are exchanged between peers and thus are useless if the connection is closed. Thus I assume they mean that an exception is raised towards the application; it had used JSON-RPC to send a request and thus it needs to receive something as a response. Ideally each request sent would have logic for a response and logic for an exception, for example try { $response = $this->transport->sendRequest($request); // handle response } catch (\TransportException $te) { // handle exception }AJAX works similarly, with the technical advantage that is uses an optional error callback instead of forcing a stack-unravelling exception. You could (and with React, probably would) do the same. The second half of that excerpt deals with an unusual situation where the client and/or server can't understand each other, so closing and re-establishing the connection brings them back to a hypothetical handshake stage (which JSON-RPC doesn't actually have...) - or in other words is the "turn it off and on again and see" approach.

Still wanted the full HTML but at least I see the problem: You're using a bunch of position:absolutes everywhere and that can easily mess everything up. Specifically, you've done it on the .container and aren't positioning those relative to a parent, which means they'll all observe the implied left:0 top:0 and move to the top of the document/page. Looks like you want to use that to position the child elements? Do position:relative instead: it allows you to position children absolutely (relative to the container) while keeping the element in its original location.

The problem is trying to do two loops at once: the first over $sorters and the second over the counts. Can you get rid of $sorters and just use the query? It will include the list of countries automatically so...

Use Javascript to set (and possibly get) a cookie.

The PHP code is irrelevant: it happens on the server and your problem is on the client. What is the full HTML of an example invoice? If you don't want to include the CSS then fine, but when I can't reproduce the problem with just the HTML then I'm going to ask for it too.

Actually it could explain it. Just copy the markup into a post.

Could be any number of things, none of which have to do with PHP. What's the full markup? Are you applying any CSS rules that affect how elements are positioned?

None of this matters if you can't use HTTPS. You could have a 4096-bit rotating API key if you want, but if it's transported over plaintext HTTP then it's all pointless. No HTTPS is a deal breaker for having anything that could resemble security on this server. The fact that it's on shared hosting is already a sign that your client doesn't actually care about keeping their system safe. Your job is now to call them on their bullshit.

Sounds like client-speak: management got scared by something and wants to know that there aren't any l33t hackers watching their super-important traffic. And since Loo said "client" it sounds like a small- to medium-scale contracting thing. If the advisor said "public/private key" then... well, that's not terribly helpful. Everything serious in security uses asymmetric keys nowadays. Given the technical context of Loo's post, I'd interpret it as doing something like using certs on both sides of the SSL socket - not a full-blown PKI infrastructure. But maybe we're talking about an unknown number of clients, in which case my solution would require some way to have the authority automatically sign certs without [much] developer involvement. Or on the other hand, maybe mere SSL would be enough to assuage fears. Some more information about the nature of this system would be nice...

Moved. Maybe if I make the warning scroll too... Making a text file and putting it in a database doesn't make sense. Just put stuff into the database. You can have your PHP get what's there, allow for editing, and have it put the new version back. Don't know where to start at all? No offense but Google is probably your best bet. You're the one who knows how you learn best, be that tutorials or videos or online courses or whatever. Look for stuff that involves "PDO".

The scheme you need is called X.509. You know how SSL/TLS uses a certificate on the server to verify identity? X.509 is the same thing but applied to both the client and server. You don't have to do any PHP to make this happen, depending how paranoid you want to be. 1. Create a certification authority; essentially a set of files (not a server) used to sign certificates. Like Verisign or Entrust or others, this authority acts as an entity that will be trusted by both parties to validate certificates. Creating your own means you can dedicate this authority to only signing certificates used in this exchange and simultaneously require that only certs signed by it are allowed; any ol' Verisign cert won't work. Back up those files somewhere safe: they're the keys to someone participating in this exchange. 2. Have the client and server generate their own certificates, then use the authority to sign them. Simply having a certificate proves the client is trustworthy, but you can also use the information in the cert to further confirm their identity (see #5). Client: 3. Have cURL perform validation. This includes both verifying the server cert (against the custom authority) as well as providing the client cert from #2. Server: 4a. Configure your web server with the server-side cert generated in #2. This is your standard SSL stuff. With Apache there are a handful of SSL* directives to enable this. Note that doing so means this HTTPS endpoint won't be easily browseable by a regular user: though it will have a cert and thus be secure, the browser will complain that the authority is not known/trusted. If this will be an issue then you should use a separate HTTPS endpoint away from the regular :443 one. 4b. Also configure it for client verification/X.509. A few more SSL* directives in Apache are relevant here too. This should involve indicating a trusting authority: that would be the one you did in #1. With this in place, the server will verify the client certificate against your authority, and only certificates signed by it should be permitted. 5. If you want to identify the client then it depends on your web server. Apache can set environment variables which will be available in $_SERVER; grab the email or DN or whatever from there and do what you want. Alternatively, you can have it pass the entire certificate and use PHP code to validate it manually (likely with openssl functions). This looks like a good reference.

If you're having problems putting that code into functions then we need to see the version where you put that code into functions.

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).