requinix

->fetch() only gives you one row at a time. If you look at what's available to use you'll probably find something more like what you're expecting.

You're much more likely to get some help if you can show some initiative on your part first. Like, if you've tried writing the code yourself. Or if you have something partially done to show and don't know how to continue with it.

You'll have to do that. Educated guess says the image has to be a monochrome (B&W) bitmap.

All you have in that array is the firstname. That's not unique. You need the first and last names. Also, don't add them as array values. When it comes time to look up a value in there with in_array(), PHP will have to scan potentially the whole array to find a match. A faster method is to use array keys; put the whole $row as the value. Well, for starters, I don't see anything trying to use $names in there. Since you're going with the approach I said before about having the first and last names be the array key, you can use isset() to tell if there is an entry according to the name parts from $item.

How does that work, exactly? Does the USB show up as a file device you can just copy files to? What does that process require you to do?

Check what I said again. Your query on the database (1) needs to set up an array that holds all the records in it so you can look in there for a match easily, and therefore (2) it has to happen before the foreach.

Putting a database query into a loop is almost always a bad idea. Do one query ahead of time that looks up every record, then stuffs it into an array. You can use the firstname + lastname (that being the only unique (?) piece of information you can work with) as the array key, and for fun the entire row of data as the array value. Then your foreach loop checks that array for a match.

Removing the battery from a fire alarm does not make the fire go away.

Use number_format.

You're saying you can open a popup window, handle clicking on a radio button, and update the parent window's form data, using only HTML and CSS? I'd love to see that.

Yes.

I'm sorry but it sounds like you're saying that your application is letting in bad data: invalid items in a non-member's shopping cart. That's the problem, isn't it? So how about fixing that problem?

Is there any particular need to have every step on different pages? The first couple about location, sure, but after that, wouldn't it be easier to have everything at once? It also helps the user see just how much they'll have to do, instead of one more page after one more page after one more page... If you need multiple pages, what about simulating multiple pages? Put everything into the one HTML response, then use Javascript to show/hide chunks of it as the user progresses. On that note, is there a need for this to be PHP at all? Javascript is quite capable of doing math. You may be able to do all of this on the client side.

Javascript to open the window, Javascript to handle the radio button selection event, then window.parent will give the popup's code a way to reach the parent window's form and textbox.

Short answer: it's safe. Longer answer: it's as safe as any other PHP file on your server. It's a common practice to put this script, or at least a script that defines variables/constants with database credentials, in a PHP file that is not located inside the web root (eg, outside of your public_html or www or whatever directory that your site is based in) because if it's not an actual page then it really shouldn't be in the root; this practice is easy to achieve when you get larger sites that have a single public_html/index.php that runs an "application" or some similar concept whose files are all outside the root.

That doesn't look too unusual: periodic requests to look for new posts. Hopefully IPB will switch to websockets in the future... Windows, right? Can you run TCPView, sort by one of the Sent/Rcvd Packets/Bytes columns, and see if maybe that helps explain what's going on?

I'm not sure how that's even possible... Like, there's no way a site should be able to cripple traffic like that without being totally obvious about lots of ongoing traffic.

"More than expected" is for people who strain the servers. You won't be doing that, right? Store the inputs in a database table and have the data associated with the user. You haven't described anything more about your application or what those inputs are all about so it's hard to give more specific advice...

Correct. Also correct.

No you don't. You have a function perfectly capable of giving you the current session ID. Why do you think you have to take that value, which is going to be the same value every time you call the function so long as the session is active, and put it into $_SESSION for you to get it? If you want the session ID then call the function. Stop overthinking this. No. You see two session files. Containing session data. For two different sessions. How did you run those queries? That's a rhetorical question. You aren't supposed to tell me the answer. You're supposed to consider what the answer is and then continue thinking about the implications of that answer in order to find the answer to your question.

Why should it be? What good would that do?

I don't know what you saw in those Google results, but the first result in what I saw was a link to the session_id() function. Oh. By the way. If you go this approach then you'll need to take additional measures to deal with sessions that are cleaned up after inactivity. Because the more of these IDs you hold onto, the more likely you'll eventually run into a conflict.

I suggest you start your hunt for an answer over here.

This "sessMemberID" is from your application. PHP isn't making it for you. It's probably the member.id value, but I suggest looking at your login code to be sure. The "session ID" is something else. It's a unique identifier that PHP does create for you. It is highly unlikely that you will ever need to care about it.

You said shared hosting. Does that include a database?