requinix

Have you fixed your HTML yet? After you have done that, What do you see in your browser's address bar?

Fix your HTML. Attributes need quotes. Your href does not have one. Add them. Regarding your problem, are you clicking that link in your browser? Are you talking about getting that ID from within details.php?

Not if they guessed where the file is. I'm about 99% sure that you don't need to be creating files on the server. Not if you're just going to turn around and send it to the user. You don't need actual files to do that. Do whatever you're doing to create the file, but instead of putting it in a file you output it.

Which is what my first post addressed.

Know that it really doesn't make any difference. The same code in one file is just as good (or bad) as the same code in another file.

You have some sort of output happening. Make it not happen before the download portion. Possibly by moving that code closer to the top of the file.

Check the documentation for setcookie().

Are you able to change the markup of the page? Not much: to use multiple tbody elements, one for each group of rows. Visually it'll probably look the same as before, and reorganizing the rows like that would make this much easier.

The first step is to learn about getting data from the query string (aka $_GET). The URL to the page would be "script.php?specialty=whatever". One file handles everything, like mac_gyver said. The second step is to take the value from the query string and use it with a prepared statement.

Planning for the future is definitely good, but the thing is that localization can be a real pain to set up. How much time will you be spending working on something that you don't need right now? It's okay to do part of something now and the rest of it later. Delaying parts you don't need now also gives you time to learn about what your requirements will really be, instead of assuming now what you'll need in the future. So I suggest you focus on just the message part for now. String messages are pretty easy to solve in a rather generic way by using formatting and placeholders. You're gearing up for this really powerful but complicated solution when there are easier means available. Not everything has to be handled by this system. Consider "you have X unread messages": - Localized it will always look about the same - a simple sentence - The "messages" word could be singular or plural, but there are languages where singular vs. plural is not as simple as adding a letter, or even as simple as designating a "singular" and "plural" form for a word - Using %d as a placeholder works - unless you decide that you want to do something like write "you have no unread messages" There are varying degrees of complexity to a possible implementation but you don't have to cater to the least common denominator for every single thing. You can do an 80/20 solution: make it simple for 80% of the use cases, more complicated for the other 20%. <?php // messages/en.php return [ // a simple string template that will support a lot of different messages "You have %d foo thing(s)" => "You have %d foo thing(s)", // not good enough? use a function "You have %d bar thing%s" => function($n) { if ($n == 0) { return "You have no bar things"; } else if ($n == 1) { return "You have 1 bar thing"; } else { return sprintf("You have %d bar things"); } } ]; function translate($template, ...$args) { $messages = get_translation_table(); $template = $messages[$template] ?? $template; if ($template instanceof \Closure) { return $template(...$args); } else { return vsprintf($template, $args); } } And done.

First, as someone who hasn't seen your other threads: How good does this need to be? Do you just want messages changed? Do you care about numbers? Currencies? Dates?

Essentially. You need to be calling the getUserIpAddr function (and assigning the result to a local $ip variable), $session_id is a function not a variable, and there's no need for a $session array if you're just sticking variables into the array and then pulling the values right back out again.

Yes. You could store it as a number, because technically they are numbers (kinda), but you don't need the advantages that storing as numbers gives - let alone the hassle of converting those numbers back into their pretty, human-readable forms.

Ah, but what if more than one person downloads the same file? Looking at just the URL won't work. Are you using sessions yet? It's another thing to throw at you, but it does give you a particular benefit here: a unique identifier for each visitor. While you can store data in the session, you don't actually need to here. With sessions in place, you can store the visitor's session ID in the database. That will let you key in to what individual people do - whether they visit and download, visit and don't download, browse around, and so on. You may not be particularly interested in implementing this just yet, but like I said: if you don't store the data now while you don't want it, you won't be able to fill it in later when you do want it. If you aren't familiar with sessions, they're easy: call session_start at the beginning of every page on your site that you want to use sessions, and do it before you output anything. When you store information in your database, you get the session ID with session_id.

Moving this to the PHP forum, even though it'll be SQL stuff for a bit. By website hits are you talking about something other than this download stuff? Then yes, you would have two separate tables for the two separate events. For the counter, don't use an actual counter in the database. Track individual downloads instead. You can get a counter by doing a count of matching records in the table - don't worry, it's fast. Also means you can do more than just total downloads, like downloads per month. Because as a rule of thumb, Data Is Good. Get as much as you can. I don't mean tracking users or anything sketchy like that. I mean, if you have information (like a download happening) then you should store everything you can about it. Even if it doesn't seem useful now. Because if you decide later that, say, you'd like to get an overview of where in the world people are downloading your stuff, you can't go back in time and fill in data for event that have already happened. So for downloads, create a table with: 1. An AUTO_INCREMENTing ID, because these sorts of things are handy to have around 2. The name of the downloaded file 3. The DATETIME of the download 4. The visitor's IP address, which can also help you deal with abuse problems (that hopefully won't happen) For best performance, create a UNIQUE index on the filename. You can also create a regular INDEX on the filename and the download time (both fields), which will allow you to run fast queries when looking at both fields in the same query. Tracking website hits will look very similar to that. If you want a counter for a specific file, and just that file, you do a query to SELECT COUNT(1) from the downloads table WHERE the name of the file is whatever file you want to check. But more often you'll want counters for all files, in which case you can do one query to get all of them at once by SELECTing the name of the file with its COUNT(1) and having the query GROUP BY the file name; pull that information out into a PHP array and you can reference it when creating your HTML markup.

You want text files for every single file? What happens when two people try to do a download at the same time? If you have a database available to you and just want to avoid using it, that's not really a good enough reason and you might as well use it. If you don't have a database available, think about it. It's one of those things where you'll probably discover that having a database turns out to be surprisingly useful. If you really, really don't want a database, (a) I'd like to know why you're so firm on it, but (b) yes, there are alternatives.

Got bad news: you have some data you need to store and a database is the best place for it. Especially when you consider problems like concurrency.

andSelf was deprecated back in 1.8. That was a number of years ago. Your book may be slightly out of date. As for this thread, leave it. It's fine. Maybe someone else will find it on Google and your follow-up will answer their problem.

The problem is you're copying elements' innerHTML, which does not carry along the current state of the elements. State like whether a checkbox is checked. Work with everything as DOM elements. Create your basic list structure and then move the existing elements into it as they are, ie. with jQuery functions like append(). But the best solution would be to write markup that can switch between the two presentation styles on the fly. Ideally you shouldn't have to change the structure of the HTML at all to change how it appears to the user.

Can you try explaining that with a few more words? Exactly what is it supposed to do and what is it currently doing?

I'm sure it was not malicious, but most people don't appreciate it when someone has homework and uses forums like ours to get the answers. Next time, please remind us that you're learning and let us know that your tutor asked you to do something. That way we can help you get to the right answer without accidentally writing all the code for you.

So you got us to write the code for you. Well done. It won't happen again.

Farming StackOverflow content to your forum is a really good way to piss off StackOverflow.

I hope you've learned a lesson from that: don't use unattended or otherwise automatic software upgrades on production systems. Have you checked if dpkg needed to update configuration files? Hopefully it created backups of the originals - check if the changes are relevant. Anyway, the curl output looks right. Next step would be writing proper WSS headers and seeing what happens.

array() can be used to create something that looks like an object (with keys) and something that looks like a list of things (no keys). The result part has two opening symbols: [ and a {. The first one is a list, the second is an object. Two symbols, two array()s. One inside the other.