requinix

I'm sure you noticed, but you're counting from 0 to 42. Should be easy to change to count from 1 to 100, right? So you can list out all the numbers you want to output a message after, but you have to list them all out. What if you needed a loop from 1 to 1000? Or a million? What would you do then? You want to output at 5, 10, 15, etc. In other words, numbers divisible by 5. Have you tried looking for a solution using something that can tell you if a number is divisible by 5?

All the major browsers have more-or-less the same tools available. Question is which ones feel more natural to you. But that's mostly for frontend work with HTML, CSS, and even Javascript to an extent. Tends not to matter a whole lot for PHP - unless you count troubleshooting PHP's output, of course.

Also known as a CSS reset. Not as common nowadays since browsers have been better at getting their acts together, but still around. If you want something that feels like a table then you probably want the Grid layout that Strider64 mentioned. Flex and CSS 3 also have some tricks you may not be aware of.

Prepare for the most likely scenario. If something were to break, would it probably be the API or the database query? I would think the API. That suggests you do it before the query; if the query fails then you undo the API call, and if that call fails (perhaps you lost network connectivity between the API call and query) then you log what happened and let a human deal with it.

Will this whole problem go away once validation is implemented? My position? Database rules to enforce data integrity, mostly with uniqueness and foreign keys. No code should ever be able to leave the database in an invalid state - incomplete, perhaps, but never invalid. Application rules to enforce business decisions. Opinions change quickly and it's better to deal with that in code. Databases should not be modified unless the structural nature of its data has to change.

What code have you tried so far, and what kind of problem (if any) are you having with it?

Why would the update query fail?

The only real "best practice" is to use as little and as simple CSS as necessary to get the desired end result. The two main answers here are typically either (a) padding on the HTML or (b) margin on the BODY. You could use DIVs but that tends to make it more complicated. Which you use depends on the rest of your CSS, especially whether you already do anything to the HTML and/or BODY elements, but a margin on the BODY tends to conflict less with other styling.

If you only care about checking individual dates that are available, that's fairly easy: store the unavailability dates as rows of start and end dates, then search for rows based on whether the day is between them. If you care about checking date ranges then it's a bit trickier, but still not as complicated as it might sound: a conflict is any row where the desired start date is before the unavailable end date, and the desired end date is after the unavailable start date.

In general, try to use z-index as little as possible. How is overflow configured on the parent row? If it isn't allowed then the arrow will clip when you try to position it partly out of bounds.

A screenshot isn't the most helpful thing. Got a link to the webpage?

That comes from $sql2 = " SELECT order_id FROM ordered_items GROUP BY order_id WHERE order_id = '".$row[order_id]."' "; this query. So if this query isn't working then your next step is to learn more about $row.

It probably doesn't work because your "button" is actually a link. But I don't actually know what "output" you're trying to get...

Well, you could do it... you know... recursively. As in you do one query to find the next step's relations, then another query for the next, and another for the next, until you've gone as far as you want (or you run out of relations). Remember not to check IDs you've already seen before. Depending on your database server, you may be able to write a recursive SQL query using CTEs...

Don't use the version from FlatPak: it's unofficial and apparently buggy. Install VS Code from an official source.

Keep track of the previous row. When the current row's year (or whatever you want to measure by) changes then you stick an ID on the table row.

Probably? It's a package manager. See if you have it installed, and if so if it thinks VS Code was installed through it.

Did you install the "FlatPak" version of VS Code?

You need to stop saying "group by" and start describing what you want to do.

That does not help to explain why you're doing this. I'm asking because this query INSERT INTO invoice_price (order_id) SELECT order_id FROM ordered_items GROUP BY order_id WHERE order_id = '$order_id' doesn't make any sense: you take the $order_id that you already know, search for it in the ordered_items table, and then insert those results into invoice_price? Why aren't you inserting the $order_id value directly just like you did with ordered_items?

There could also be a bug with annotation support. It really should not be that inconsistent - unless there's some kind of technical limitation. Probably.

Explain what that means. "Group" how?

PHP does not parse /** */ docblocks. That's Doctrine/Symfony (I forget which one technically does the annotation support). But code doesn't behave randomly so there must be some difference between the situation that works and the one that does not. Either way, the answer is the same: don't import stuff you don't need, do import stuff you do need.

Are you saying that in one situation, having the imports in the trait file and not the class file works, but in another situation the same arrangement does not work?

In general, if you have problems with code not doing what you want, posting said code is probably a good first step. There are multiple ways of enforcing the digit rules so knowing what your current code is will help identify what approach will work best.