requinix

Okay, let's go back a step. Who will own the server that this code will be running on? The client? Is it their server? Or is the code hosted somewhere the client cannot control and they use their browser (or some other means) to access/use/whatever it?

Keep in mind that PHP code is open-source, so if somebody wanted to circumvent your registry key licensing checks, they could do it really easily. Like, in the time it takes me to microwave last night's leftovers. win32std It looks pretty old, though, so you might have to find an alternative. Like a shell command.

Go with the second code. So you have that code in a place that receives the form data and (tries to) output the file. What's the code for the entire script?

And exactly who is the "client" here? Are they the one running this PHP code? Or are they browsing the website or whatever?

What's the code to generate the file?

Okay. Are you still getting the undefined index warning from that details.php?id=20597 page?

Perhaps you've been looking at this for too long and so can't see it. class, equals sign, single quote, the various classes, single quote Your first change to href was: single quote, href, equals sign, the URL, single quote Compare where the quotes were. Your second attempt was the same except you put in double quotes, something which the class attribute was not using, which is no more correct than it was with single quotes except the double quotes conflict with the ones you were using in PHP. One more time. And then, after you've clicked then link, tell me what the URL in the address bar is.

Take another look at how the class attribute is set up.

Do you see how the quotes work with the class attribute? That's the correct usage. Compare with what you did for the href... Can't get values from the URL if there are no values in the URL. Have you been clicking the Details links?

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.