requinix

It could be a settings problem, sure, but it could just as easily not be a settings problem. Add error_reporting(-1); ini_set("display_errors", true); at the top of the file and see what happens.

Okay, that's what I thought. You cannot read registry settings from the client browsing the website. You can only access the registry from the server PHP is itself running on. And obviously only if it's a Windows machine.

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.