requinix

Great. ->setUsername([email protected]) That email address in there is supposed to be a string. That means it needs quotes. See how '/vendor/autoload.php' and 'localhost' and 'Verify your email' are? Those are also strings. The password in ->setPassword(password) also needs to be a string, but it could be that you removed your password and replaced it with that just for the post, so for all I know the version you have in front of you is already a string.

Email addresses definitely have @s in them. Do you happen to be new to PHP?

A blank page means a fatal PHP error. What do your server error logs say?

Or you could install the most common Composer globally and "install" the other composer.phar inside the projects that need it. Or, if the project is for PHP >=7.3 then have both Composers use 7.4.

Yes, it can do that. Is that fact relevant here? Even if so, that still doesn't mean Composer 1/2 should be coupled to PHP 7.3/7.4. What it means is that you should be using the version of PHP necessary for the project. Just like how you would be using the version of Composer necessary for the project. But those are still two different things.

Unless you have some error messages that say otherwise, Composer doesn't care. You can run it with PHP 7.3 or PHP 7.4, it'll do the same thing. The only thing that matters is (apparently) Composer 1 vs. Composer 2. Saying that Composer 2 should be run by PHP 7.4 and Composer 1 should be run by PHP 7.3 is pointless. There's no difference.

/usr/local/bin/composer is going to be the same file regardless of whether `php` runs PHP 7.3 or 7.4. Install Composer 1 and 2 to different files, then ln "composer" to 2 since that works with most everything you have. For the other project that doesn't work with it, always run "composer1" commands. If you have errors with Composer then you'll need to post those.

You're getting a 403 with your own site? What do the server error logs say?

Ah, that makes a lot more sense. For the library, Net_DNS2 is an option.

Not the IP address. The hostname. It sounds like you were saying you did dns_get_record to lookup the hostname and give that to the mail stuff - what I'm wondering is why you can't give the hostname to the mail stuff. Why you have to look it up yourself. And to be clear, multihoming is my best guess. IIRC there is a way to configure Windows to prefer one interface for certain things but it's not perfect. The obvious test would be to disable the other interface and see what happens. If you absolutely must do your own DNS lookups, grab a library that does DNS but that also lets you specify the outgoing interface (by name or bound address) for the lookup. Pretty sure there's going to be one out there.

That could explain it. Windows doesn't really like to be multihomed. Any reason you have to dns_get_record to begin with? Why not use the hostname directly when sending the email?

If email worked by IP address then yes, it wouldn't be a networking problem. Is the server multihomed?

Which is it? Was it sending emails or was it not sending emails? Was it ever in a state where the hostname could not be resolved (reproducibly, not just once) but stuff like file_get_contents on a remote URL did work? Because both of those involve DNS. No, the filesystem is not involved with DNS queries.

If all you want is a password prompt then you can do that with .htaccess and a password list. Apache handles it all for you. The login prompt is a bit basic 😎 but if you don't care about that then it's very easy to use. Otherwise what you're looking at having to create is a standard login system using a session. Each page verifies the session data is correct (like by require()ing an appropriate file and calling some function inside it, so you don't have to copy/paste the same verification code everywhere) and redirects to the index page if it isn't.

PHP uses DnsQuery_A to perform the DNS lookup, but the documentation doesn't mention requiring any specific permissions. Was the pool running as an underprivileged user? Does it have network access? Could you do other networking things like access remote URLs with file_get_contents()?

Have you checked error logs? Perhaps there's a "DNS Query failed" error? And are you sure it returns literally false and not an empty array?

Fake it with position:absolute and push it to the edges of the cell? Leaves you with a vertical alignment problem though.

To answer the question itself, check your assumptions about those placeholders and the template file. But this is all wrong. Creating files like this is definitely not the way to go about it. You say this is for learning purposes, right? Then you should definitely want to learn the right way to do it. Given that the template stuff isn't working correctly (or rather, why it isn't working correctly) I can't quite say for sure exactly what it is you need to do. What I can tell you is that should be having one single PHP file handling every "page". A file that will probably look a lot like your template.php, in fact. What you do is tell your web server that certain URLs it doesn't recognize should be routed to a PHP script. In this case, that URL would be something resembling the "name" you're currently templating. The PHP script takes that name, looks up the information in the database, and displays it. The term you need to research is "URL rewriting". It's not hard to do.

...which is a problem that can be solved with a very simple application of math.

As far as I know, the buffering always happens for POST requests. It's an internal detail that allows people to read the request body multiple times - no buffering means it could only be read once (and by PHP itself).

curl_setopt($ch, CURLOPT_URL, "https://connect.sandbox.creditsafe.com/v1"); Where's the /authenticate? And please, pay more attention when you try to post code. Hit the <> button, paste your code into the popup, and insert. The result looks like what I did above.

So, understand that they're not going to write code for you. For assorted reasons. What they've done is provide a fairly standard amount of documentation that assumes you already have some knowledge about using APIs. The /authenticate docs say: - POST /authenticate (that tells you the method and URL path) - Request body is JSON - Body is an object that includes "username" and "password" keys, whose values are strings - It can return 200 or 401 - The 200 returns a JSON object with a "token" key - The 401 returns a JSON object with a "message" key Again, they assume you have knowledge about working with APIs, but if you did then that information there is enough to use the authentication API. To use it, don't start by throwing stuff into the code according to whatever you found when you looked up how to send things to APIs. There are many different methods so many of them are not going to work here. For the headers you need to send to the API, include a Content-Type and stop there. Don't throw in more headers unless you know you need them. For the data, make a PHP array that matches what the /authenticate docs say, then json_encode() it. For the cURL options, (1) obviously use CURLOPT_URL, (2) use CURLOPT_POST and CURLOPT_POSTFIELDS as the standard requirements for POSTing data, (3) include CURLOPT_RETURNTRANSFER so you get the response back as a string, and stop there. Don't throw in more options unless you know you need them. Try with that and see what happens.

The problem is that all of that stuff varies with usage. Each place may want different templates, or different Javascript, or different CSS. It doesn't make logical sense to put frontend stuff into the backend. XSLT is about transforming XML into something else. Like HTML. For example, if you had XML <username>NotionCommotion</username> then you could write some XSLT which transforms <username> nodes into <span class="username"> HTML elements. It's been a long time since I've done this but the XSLT looks something like <xsl:template match="username"> <span class="username"> <xsl:value-of select="." /> </span> </xsl:template> (that's just a portion of the whole XSLT document, which would be handling other things as well) Now I'm only really bringing this up because you floated the idea of a sort of "convert JSON to HTML" thing. I think it would probably be better to go with a standardized JSON format and plain ol' HTML templates.

What's an example (with a link) of something in the documentation that you know you need to use but are having a hard time understanding?

Sure, but the result is that instead of getting a directory index you're going to get a 403 Forbidden page. So that's not going to help.