requinix

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.

I don't mean reading documentation about sending JSON to "an API", I mean reading CreditSafe's documentation about sending JSON to their API. Specifically. It should talk about important subjects like authentication, and how to deal with usernames and passwords and tokens.

Or put another way, no. Shared hosting needs those prefixes so that other people using the same servers won't have their database names conflict. But it's just a database name. It doesn't matter. Let it be "ccuk_hello-world" (or better, don't use a hyphen in an identifier and call it "ccuk_hello_world") and move on.

Well there ya go. The system temp directory should be writable by virtually everyone - it's the temp directory, it's supposed to be usable for creating temporary files.

There is a way, but it would be "crappy code". If the problem is seeing "index.php" everywhere then figure out a way to resolve THAT. For example, by not having a dozen tabs open. Or by seeing if NetBeans can give you more path information.

You're going to have to read the documentation about this. If it talks about something you don't understand, stop and learn about it.

Doing what you're doing is a dated practice. The industry has moved on to templates and such. But this method isn't inherently wrong. In time, you'll probably change to do something else. And that's fine.

Does it work?

You found one of the text-transforms. Now find the others.

Nothing was wrong with the rewriting... I think. Nothing that I remember seeing, at least. The rewriting isn't responsible for the directory index - the fact that your files are not called "index.php" is.

Can't diagnose a black stroke if we can't see it. The SVG on that page you cited only uses #F7F7F7 to match the page's white background color.

This behavior is related to the SAPI - that is, the thing PHP interacts with when it needs to do stuff like read incoming request bodies. So which are you using? php-fpm? mod_php? Does that have any relevant settings that may explain why it couldn't buffer the request body?