requinix

In case anyone comes here and wants to know what the answer was, since that wasn't shared, Problem 1 - phpunit/phpunit[9.3.3, ..., 9.5.x-dev] require ext-dom * -> it is missing from your system. Install or enable PHP's dom extension. - Root composer.json requires phpunit/phpunit ^9.3.3 -> satisfiable by phpunit/phpunit[9.3.3, ..., 9.5.x-dev]. phpunit requires ext-dom (aka the DOM extension) but apparently it's missing. Install it.

You mean you literally see a backslash and "r" or "n"?

A fairly basic website will require source code, php-fpm, a web server, and a database. You have two basic options of what to do: put everything into one image, or don't. Using one image means a large Dockerfile where you, essentially, install everything like you would on a base operating system: pick an OS, install php-fpm, install server, install database, and copy source files to the right location. Then you create a startup bash script (or not) that runs everything in the background and picks one process as the main entrypoint (eg, the web server process or a stub like "cat"). If you're used to monolithic servers then this will make sense... but it isn't very Dockery. Using multiple images lets you piece together multiple features together into one stack. Your source code has to live somewhere, but rather than build it "FROM scratch" you might as well load it into the image used for php-fpm. Then you grab an appropriate image for your webserver and another for your database. In your docker-compose, you line them all up and fill out whatever configuration is needed to get them to talk to each other - likely environment variables. The latter is the best option. It means smaller images, easier upgrades, and shorter build times. It also keeps everything separate from each other, so you could (eg) swap out a Docker image of the database server for a physical database server, or install a webserver onto a physical server and have it run sites from Docker. Modular is good.

The ellipses will show when the rendered box is too small to fit the text. If it's applying one when you think it shouldn't then that likely means the text is rendering longer than you think and/or the available space for the text is shorter than you think.

"Declare the file"? A much bigger hint so I can go to bed: the first time you run this code, will the file exist?

No no, forget "iteration". Focus only on the "if you've started writing to this file from scratch" part. What, exactly, would "from scratch" mean? Is there any way you could tell when that's the case?

So in other words, you only want to write the header line if you've started writing to this file from scratch?

Yes, it is possible to make that query happen with the query builder. Have you looked around to see what kinds of options you have available to use?

So you want a query like UPDATE posts SET count = count + 1 WHERE id = $id

You can't both change and not-change the value. Explain what you're trying to do in more detail.

That's overkill: PHP doesn't care whether your path uses backslashes (for Windows only, of course) or forward slashes, and __DIR__ isn't going to have doubled slashes that requires regular expressions to replace. All you need is const BASE_PATH = __DIR__;

This "rows": {...} and this "rows": [{...}] are two distinctly different things. To figure out what you have to use to access something, work from the outside in. 1 { 2 "column-names": [ 3 "address1", 4 "address2", 5 "address3", 6 "postcode", 7 ... 8 ], 9 "rows": [ 10 { 11 "address": "123, Imaginary Road", 12 "someotherdata": dataset, 13 ..., 14 "postcode": "H3L L00" 15 } 16 ] 17 } If you want the "address" on line 11 then you have to go through: 1. The outermost thing is an object (line 1) 2. The "rows" member is an array (line 9) 3. The first item in that array is an object (line 10) 4. The "address" member Since you told json_decode() that you want objects to be converted into arrays, then that means you: 1. Start with the thing returned to you by json_decode(), which will be an array 2. Get the "rows" member 3. Get the first member, which would be the 0th 4. Get the "address" member In the real world, if you have something called "rows" that is a JSON [ ] array then you probably shouldn't be using direct offsets on it (eg, 0) but rather a loop to get all the things inside it.

Where are you getting [0] from? I see "rows" and "address" and "postcode" but no 0... (and yes, you are formatting the JSON wrong. {} are for key/value pairs, [] are for straight lists)

Read the error messages. The first one says that "use SlimCrf" is a pointless statement. It doesn't do anything. The second one says that it couldn't session_start() because there was output. Which there was: the first error message. What course of action do you think you should take?

Sometimes I lose track of browser tabs. To be clear, for this "72 pixel 4 X 6" image, are you talking about an image that renders to 4x6in at 72 dpi? That's about 3x4.5in or 288x432px at a standard monitor resolution of 96 dpi/ppi, which could be filesizes anywhere from 50KB to 300KB. Now throw into that the fact that Base-64 encoding increases byte length by 33% and you're looking at embedding 75KB to 400KB into an <img>s src.

While possible to do in object form like that, it would be easier to have json_decode give you an array instead. $json_string = '{"name":"Jeff","age":20,"active":true,"column-names":["title1","title2"]}'; $array = json_decode($json_string, true); printf('All done! Welcome to Homepage %s', $array["column-names"][1]);

There's a slight problem here: many mail servers will not let you use RCPT TO to verify the existence of an email address. They'll always succeed, which is absolutely useless for verification. There are two things you can do to verify an email address: the general syntax of the address itself, and that the domain name exists with an A/AAAA, CNAME/DNAME, or MX DNS record. Look for a library that will do those for you.

Can't tell from your post: it doesn't contain any printable magic bytes that I recognize, and the forum will have corrupted the binary data while trying to encode it to UTF-8. And kicken points out another problem trying to roll your own caching proxy: it's not just Content-Type but also Content-Encoding and a couple other headers you'll have to care about. So the simplest answer is to not do that.

What board? "Built" as in you made it yourself? How old? Where is the spam happening? What type of spam is it? How much? Are there any existing anti-spam measures that aren't catching them for some reason? Do you require user registrations? How are you handling account validation? Tried using CAPTCHAs? Tried IP bans? Email address domain name bans?

You could save the MIME type at the time of the first download... A stupid simple cache file is one where the first line is the MIME type and everything after is the content.

I was thinking base_convert 16->2 + str_split...

If you're talking about Laravel's .env file then you should be using Laravel's procedures to access its data. https://laravel.com/docs/8.x/configuration#environment-configuration

PHP will get exactly what you typed into the form. Typed 1010101? That's what you'll get. Typed 85? That's what you'll get. Decide whether you want the input to be the completely obscure binary representation of a number or to be the very familiar human concept of a decimal number (cough) then validate the input accordingly: binary would be up to 8 digits of 0 and 1, a number would be something 0-255. What you do next depends on whether it was the binary or decimal digits, but either way you've got lots of options available: bitwise math, base_convert, str_split, string offsets, substr... The list goes on, so decide what kind of process would make sense to you and find the PHP code to express it.

There ya go: it's not a number but a string containing some number of digits - perhaps less than 8 of them if the number was <=127. So what's your next thought?

Not quite. It will look like var_dump(base_convert("A1", 16, 2)); whatever that says it looks like.