requinix

I don't know what my code would look like because I don't know anything about your application. The first problems to solve are the ones that are quite visibly wrong. Such as how you have a couple lines of PHP code that aren't within the <?php ?> tags. And those crazy if statements ginerjm mentioned. And the syntax error in your INSERT statement.

I count thirteen problems with this code. Throw it out and try again.

What have you tried so far?

Exactly what is he saying you should do and what are the reasons for it?

You already have something that will print information if it's available. What's more, it makes sense: if you have $iptc data then print what's in it. Logical. Obviously, that then means that if you don't have $iptc data then it won't print. Also logical. So then, if you don't want it to print anything, you need to make sure that "you don't have $iptc data" is true. Thoughts on how you can make that happen?

Your question is "How do I make a food delivery app like foodpanda" and no, that's not really a good question. It's not the kind of question that can be answered to any reasonable sort of degree. Do you have maybe some specific questions?

Have you tried adding code to check for and handle errors? Especially when it comes to the stuff using cURL.

Convenience, mostly.

In Docker-land, Find the Docker image for the operating system Configure the image with appropriate settings Copy the source files to /var/www/mywebsite Install other services Install other services Test the image Drink a beer That there is the process you'd follow to create one of those monolithic Docker images that can do everything you want. What kind of instructions would result in multiple images for discrete services? Download the operating system ISO image and create a bootable USB Go to the garage Boot one computer from the USB and configure it for Apache Copy relevant files to the appropriate Apache location Boot another computer from the USB and configure it for PHP Copy relevant files to the appropriate PHP location Boot a third computer from the USB and configure it for your database Maybe run initialization SQL statements Make sure all the computers can talk to each other Go back to the office and browse the website as hosted on the Apache server Those three computers can translate into three images/containers running on one Docker host. Through Docker Compose, you have all three running and talking to each other. Either (a) you have multiple Dockerfiles for the multiple images, or (b) you use buildkit and have one Dockerfile with multiple stages for the multiple images: Image #1: start with the Apache base image, add/copy appropriate Apache and website configuration (remembering that it will be accessing php-fpm across a virtual network), and copy only the files that Apache needs. Image #2: start with the php-fpm base image, add/copy appropriate configuration, and copy only the files that PHP needs. Image #3: start with whatever database base image, add/copy appropriate configuration, and copy any files it might need. Those will embed your files directly into the image - that's for a real deployment because you don't need to change any files. (If you did, that would be handled with an external volume.) Locally, you don't want files right into the image because that's a hassle, and instead you would use volume mounts so that you can develop outside of Docker and immediately get the changes inside your running container. For the Apache image, your Dockerfile would have something like: FROM whatever base image COPY your general Apache configuration files to the places they need to go COPY your website virtualhost configuration files to the places they need to go COPY whatever public assets and other such website files to the places they need to go ...and that's about it, because the base image will (should have) taken care of most annoying things from installing Apache its dependencies to getting you a reasonable default configuration that you might not even need to change. php-fpm has a little more because the base image isn't everything: FROM whatever base image RUN commands to install additional extensions/features not already provided COPY configuration files COPY source files RUN potentially more installation commands, eg. a composer install The database: FROM the right image, COPY configuration files. In terms of a file hierarchy, yours could look like /apache - Apache-related files /website.conf - virtualhost configuration /public - the web-accessible files that go in the Apache image /index.php /favicon.ico /src - PHP source code /sql - database stuff /vendor - only exists locally, isn't added to the image but instead created by a composer install composer.json Dockerfile (if using multiple stages, or else the multiple files would go elsewhere) docker-compose.yml - for your local development, has the three services with volume mounts and networking setup and so on

Maybe tutorials aren't going to be the best way to go about this. Let's say you're starting with a blank computer and you have a USB stick with your site's files. What do you need to install? Where do the files go? Be as precise as you can.

Sure sounds like a possible culprit. Have you looked into that yet?

"Somehow getting blocked" is a hard thing to understand when I can't see it happening for myself. Right now, all I can tell is that if I try to log in with a bad username and password then I get a 500 error.

It's not something you can control so as long as things work then there's no point worrying about it. Ditto. Try an earlier version? It's the Alpine version of apt/yum/dpkg. You should almost always chain commands in a RUN with && instead of semicolons: a failing command in a && chain will abort everything after and report the error back to Docker, while a failure in a semicolon chain won't stop further commands and it won't report failure to Docker unless it's the last command.

Cookies are easy to troubleshoot: use your browser's developer tools to see exactly what Set-Cookie headers your server is sending back, what the cookie data being stored inside your browser is, and whether there are outgoing Cookie headers to your server. Also, 1. Your loggedIn cookie has the wrong value. I assume that's just a mistake in your post and not true for your real code? 2. 36*24 is 14 minutes. Are you sure you want that? The Secure attribute only means that the cookie will not be sent over insecure connections. If your whole site is secure then this won't do anything - but it is still a good idea for security, Just In Case™.

Do not use an ID to identify the buttons. Find another solution. Consider learning more about HTML while you're at it. Hint: the best solution is something that you're already using elsewhere in the markup. Oh. And please don't solicit help through PMs.

Looking closer at the specifications, they still allow the browser discretion on exactly where to cut. Everything talks about how to handle trailing line whitespace but not much on leading line whitespace. So far I can't see a way to do it with CSS. I would settle for the current behavior and just let it wrap even if not exactly at 43 characters every time.

<button id="botaoPrint" IDs must be unique on the page. If you want more than one print button then you cannot use IDs for them.

You've said that you have a problem but you haven't said what the problem is.

What's the rest of the CSS? Are you sizing it at 43ch wide? Given it a better line-height, like 2ex? Eliminated margins and paddings and borders (or changed sizing model) that will mess up width measurements? Because it sounds like your problem isn't so much where line breaks happen but how you're sizing the textarea.

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.