kicken

Your application has a composer.json file that specifies a minimum PHP version of 8.1, but the docker image you created uses version 7.4 You need to use a newer container that is built using PHP 8.1 or newer.

Again, from the docs you linked:

The API documentation you linked earlier says this: Since you're not including that header you're not getting JSON.

That is because you are getting back HTML that probably contains a redirect that the browser is following since you're outputting that HTML. You can avoid the browser interpreting the HTML by either escaping it when you output it or setting a content type of text/plain for your output. echo htmlspecialchars($response); or header('Content-type: text/plain'); echo $response; Setting the content type only works if you haven't sent other output yet.

You can use PHPSpreadSheet to generate the file. Unless you specifically need spreadsheet features I would just stick to CSV files though. It is much simpler and works just as well for sending data.

I have a simple cron entry like this to run a script each day: @daily /root/bin/update-junk.sh The update-junk.sh is a small shell script that runs the different sa-learn commands. cd /var/lib/spamassassin/vconfig sa-learn --spam --dbpath ./example.com/mailbox/bayes /var/spool/mail/virtual/example.com/mailbox/.Junk/cur sa-learn --spam --dbpath ./example.com/mailbox/bayes /var/spool/mail/virtual/example.com/mailbox/.Junk/new sa-learn --ham --dbpath ./example.com/mailbox/bayes /var/spool/mail/virtual/example.com/mailbox/cur I don't. I use Thunderbird for my mail client and when I mark something as junk it moves the message into the Junk folder. Spamassassin will process it as spam next time the @daily cron job runs.

I don't. I just setup a cron job to run it each night. I don't have PHP involved in the email setup at all.

The way I setup my email server is to just have sa-learn run nightly and train the junk folder as spam and the inbox (excluding new unread messages) as ham. Marking something as spam just requires moving it to the junk folder. Setup something similar on your server then just move the message to the appropriate folder using PHP.

If you're seeing the source code to your page displayed when you load it, then this is not some problem with prepared queries but a problem of your code not being parsed at all. This would either be due to PHP not being installed and configured correctly, or you using short tags and your PHP installation no longer being configured to allow them.

That error is telling you that the private key option is supposed to be a path to a file that contains the key. Presumable the redirectUri option should be a URL too not some random token.

You shouldn't have to decode the value, PHP does that automatically when it parses the query string and builds the $_GET array. If you're having to decode it, then you're encoding it unnecessarily.

urlencode or http_build_query.

If you use a header redirect then the browser will not render the output of that request and instead just fetch the next page. So you need to delay the redirect by returning a normal response that the browser will render and have that page then perform the redirect. That delay can be accomplished by using either JavaScript or a meta refresh to issue the redirect after the page has loaded.

You cannot send any more information other than the downloaded file's content. Any other information you try and send will just be part of the download. If you want a thank you message or similar to appear you either need to show it before you start the download, or after a delay using javascript. Before is easier, which is why you'll often see places take to you a page that read like: They show that page, then issue a redirect to the download URL so the browser will start the download.

If you want to send data but not show an input then you use input type="hidden" <input type="hidden" name="something" value="hidden">

Don't try and do content columns with float. Use grid or flexbox.

Try increasing max_execution_time. Might be your script is taking too long to process the data and getting killed as a result.

x is the center of the ball horizontally, y is the center of the ball vertically.

I don't understand what it is you are trying to say.

$_SERVER['REMOTE_ADDR'] will be the address of the remote socket endpoint that has connected to your server. For local development, this is going to be ::1 (ipv6) or 127.0.0.1 (ipv4). If you connect to the server from some other machine, you'd get that machine's endpoint. It's worth keeping in mind that this is not necessarily the user's actual IP address. It may be the address of a proxy or load balancers instead. Using the function provided by gizmola will attempt to grab what would more likely be the user's IP if the proxy/lb provides it.

Given the code you posted, there is no reason for any of that HTML. Looks like your request is being intercepted or sent to some other server which is then trying to issue a redirect using JS.

Are you saying if you upload your files to Godaddy and then load them using your domain that you see $_SERVER['REMOTE_ADDR'] as ::1? If your doing your work locally then ::1 is normal, since your loading files from the local host.

What is the HTML you are getting?

On Linux you could try parsing /proc/mounts but otherwise I don't think so.

::1 is the IPv6 version of 127.0.0.1