What’re you eating? Part 6

we all know I’m perfect and nothing will go wrong

Yeah, so something went wrong.

I was lulled into a false sense of security by how easy everything was. I set up the HTML page, created the form, set up the PHP back-end, had a database ready - but when I tried to submit, I was met with the dreaded:

..../food_updater.php - "405 Not Allowed"

Now, I searched high and low for a solution to this and consistently saw the same list of things:

1. NGINX doesn't serve static content - this didn’t make a lot of sense to me because it served up my HTML page without problem

2. Put error_page 405 =200 $uri into the server block - essentially: if you get an error, say it was a success! (save some brain wrinkles for the rest of us)

3. Do something with ProxyPass - honestly, I still don’t have an idea on what this was, let alone how it could help

4. Check out the beginner's guide - provided me no help at all

Essentially, none of these were any help - all I managed to work out was that it wasn’t a problem with the page, the server wasn’t even letting me get that far. No one spelled out how to get around this error and I was growing frustrated. More frustrating was that no one seemed to be even acknowledging that there was an issue, how was I somehow the first person to experience this?? In a dark moment I even signed up to chatGPT and asked it for a working configuration, but I guess it was reading the same docco as me because that output didn’t work either. Genuinely, I felt like shelving the project and doing something else - that’s how hopeless it seemed.

Until I came across a single line of code someone suggested for troubleshooting:

echo "<?php echo phpinfo();?>" > info.php

What this does is it displays all your PHP server information to screen - a huge opportunity to troubleshoot and leak data conveniently packaged into one line! So I create the file in my directory and load it through my browser……and it downloads the PHP file? Huh, that’s………..not meant to happen. PHP code is meant to execute and send an error if it has a problem (like if I was passing the wrong variables) so this entirely changed how I approached the issue. Why was my webserver downloading PHP rather than executing - well, dear reader, that problem had been encountered before. As always, stackoverflow came to rescue, with these amazing points explaining the situation:

1. nginx is a web server (and not an application server) and thus, it can only serve static pages

2. whenever, we try rendering/returning a .php file, nginx doesn't know what to do, since it just can't understand a .php file

3. In order to run other kinds of files we need something that sits between nginx and the application. This is where common gateway interface (CGI) comes in. It's a piece of software that manages this communication. CGIs can be implemented in any possible language Python (uWSGI), PHP (FPM) and even C. FastCGI is basically an upgraded version of CGI which is much much faster than CGI.

It hit me like a lightning bolt - Coda had explained in a comment what pages and pages dedicated to this hadn’t managed to, the server just needed an interpreter for the php file. After I worked that out, it was a simple matter of following some of the answers in that same thread, managing to edit /etc/nginx/sites-available/default to include references to fastcgi and then I was off! Now the PHP code was working and my database entry code was working. A quick check on the back-end:

sqlite3 pantry.db
sqlite> SELECT * FROM currentStock;
1|McKenzie's Bi-Carb Soda|350|G|2023-08-17|bb|747599803512

Eureka! Finally it works! Now, I have a working webserver that has data entry into a database and a bunch of digitalised recipes. From here I’ll probably look to add a couple of other functions to website before I look to pivot to another part of the project. Thanks for checking in!