requinix

😆 Physical printed books are out of date by the time they get published (coughphpsix). Use online resources as much as you can.

Just one. With certbot running on a public server, a file is much easier to work with than DNS. For larger organizations with multiple servers, the renewal process running somewhere internally and writing to DNS is easier than having to replicate files. certbot handles all that magic for you. The important thing is that you are given a key and token to prove you have ownership, and those two need to be discoverable by Let's Encrypt. More certbot magic. It handles certificate files - you just point your webserver to the relevant file paths and specify a reload command for it to pick up any changes.

If your public server is the one with the cert then it should be the one handling the cert. Think about it as SSL termination. What this site does is use a custom authenticator script that writes certbot's generated key/token pair to a publicly-accessible /.well-known/acme-challenge file (plus a custom cleanup script to remove it). Your server could do that too - just don't proxy /.well-known/acme-challenge/* to the backend server.

I see one command with a typo and another command with output that tells you something important (assuming that sometime before those commands you did what I think you did). Neither of those commands are what the man page told you to do regarding insecurity of an individual apt source.

+1 for DOM. If you want to insert an ad between paragraphs then you likely want to insert it between top-level paragraphs, and simple iteration on the top node's children will do the job quite easily.

Perhaps because what you had before was better. In fact it wasn't just better, it was correct. All it was missing was an equals sign.

"Borrow" implies that they will eventually return the book. Are you not going to keep track of who has returned their books? I would think that's a crucial piece of information. I don't see any problematic code regarding $sql. I do see a ton of other problematic code in other places, though. How about posting your real code and the real error message(s) you're getting? Well, if you're putting in the bare minimum then I should probably do the same. I have critiqued your structure and no, the quantity column does not make sense.

Step away from the computer, make yourself a sandwich or watch some TV or whatever you like, then come back to your code and look at the first line.

That's actually not a great idea. Having that counter means you have to keep that number in sync, and if something happens and interrupts the process then your quantity will be off. If you have a table for borrowed books then it's easy to find out whether you have available books or not: compare the "all books" quantity with the number of books out being borrowed. Not sure how the borrowed books table works... Is there also a column for the date the book is returned? If you do something like that then you're guaranteed to always be accurate. Don't have to manage a counter for it because you already have all the information you need - just in a slightly different form and location. What this gets at is a concept where you don't store duplicate information in different places. You know the available books with a quick query so storing the available books in a second place would be duplication. And if there's duplication then there's a problem that the two (or more) values could get out of sync. And if that happens then you have a problem because you don't necessarily know which value is correct (if either actually is) and which is incorrect. That aside, If you get errors and need help resolving them, posting what those errors are would be really helpful for us. Kinda hard to do anything if we don't know what the problem is, eh?

It's not about PDO but about MySQL. If you tell MySQL that you want to run a certain query, it will remember that for a while in case you want to run it again. And not in a literal sense of "here is the query as a string and does it match a previous query" but in a more sophisticated way that doesn't care much about LIMITs or the exact values submitted with a prepared statement. So you're probably good to go without trying to do anything special. Remember: databases like MySQL are built by very smart people who know a lot about what they're doing and how the system needs to be used, so just use it normally and see how it goes.

The part where it talks about how you can mark one single repository to allow it being insecure.

E: The repository 'http://ppa.launchpad.net/indicator-brightness/ppa/ubuntu focal Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Did you see that part? Because I just did what it said to do and I think I can see the solution right in front of me.

Can't you just put the old files back? I mean, if your host "decided" to delete your files, that's a really bad thing and you ought to move to another host who won't, you know, delete your stuff.

The current "the IDE everyone is using" is VS Code. It's a multi-purpose IDE which means you install extensions to do whatever you want. And for better or worse, there are a lot of extensions. For PHP development specifically, PhpStorm is basically the reigning champion.

Do you still feel the same way if I tell you that MySQL caches queries in memory? That if you prepare a statement one time, preparing it again later will be easier? That to an extent, queries themselves are cached too? In other words, that kind of performance isn't something you need to worry about right now, and the level of performance you should care more about is of the queries themselves.

AMPPS or WAMP or XAMPP or whatever, they're all basically the same thing. They're convenient for primarily Windows and Mac people who don't want to have to set up a local environment manually the "normal" way. Go ahead and use it if you like it. Just make sure you have a similar web server (eg, Apache or nginx) and about the same versions of PHP and MySQL as your live site. Would suck to find out your code you wrote for PHP 8 locally doesn't work as well on a PHP 7 server, right?

Oh. Also, when it comes to new features, if you're not sure where in the manual you have to look to find more information about them, try the RFC list. https://wiki.php.net/rfc Constructor Property Promotion's mentions the different ways it could handle attributes, and that it opts for making attributes on arguments apply both to the arguments and the promoted properties.

It's in there.

It would be easier to do this with Javascript, actually, by creating an <a> with the SVG data plus a special "download" attribute. Example: <svg id="svg">...</svg> <div id="download" class="container"></div> <script> (function() { var a = document.createElement("a"); a.href = "data:image/svg;base64," + btoa(document.getElementById("svg").outerHTML); a.download = "segment.svg"; document.getElementById("download").appendChild(a); })(); </script>

There's a lot here that can be involved so you'll need to do some learning on your own. The main things to learn about are: the <video> element and the basics about how HTML and CSS work together. Can you create a page that has just the video in it and playable?

Once you send that information to my browser, I can screw around with it however I want. It may have started off as data from your database, but it's not in your database anymore. It's in an HTML form. What's redundant is the fact that your receiving page is going to have to look up the ID in the database anyways, which is the same place the category name is being stored. You are looking up the ID in the database, right? How else would you know that the ID you're receiving in the form is valid? It sounds like you might not be doing that. Exactly: the price is not something that should be in the form, and when you want it, you look up the price in your database according to the ID. Because putting it into the form means someone could go change the value however they see fit. Actually you're trying to do the opposite: put something in the form and then not look it up in the database later.

Promoted properties are also arguments to the constructor. Your constructor has no arguments. The rest isn't important.

When in doubt, a good first step would be to check if the online documentation has anything to say on the subject. In this case, it does.

Fortunately your question has nothing to do with PHP, which is why the thread is now located in the HTML forum. It is fairly straightforward to use HTML to (1) put the video inside some markup container and (2) put an image in that container that will overlap on top of the video. Try that. If you have problems, post the HTML you've written and perhaps even a screenshot. Bonus points for using something like jsfiddle.net that will let you test what you need to do in a way that you can share it with other people.

So you'd be cool with me going into the page (which is in my browser so I can do whatever the hell I want) and change the value of the name only to be anything I wanted? Let's try another example. You're making a checkout page for some online shopping thing. You put into the form the product ID and quantity, because obviously you need to know that. You also tell me the product price, because obviously I need to know that. Do you put the product price into the form as well?