requinix

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?

It would be a lot of data to store in a session, that's true. However it doesn't have to be lost when the browser closes - the cookie that supports sessions can be given a lifetime just like any other cookie. But still, no sessions. What else do you have access to?

Well, just think about it. Can't use cookies. What else is there available for you to use?

The whole auto-submit thing doesn't make any sense.

What is the name of the page this form is on? Is the form submitting to itself?

The right direction for what, exactly? Databases? Application design? User experience? You have an idea for something but we're going to need more than just that.

Yeah. It's a distinction between an original amount and an effective amount. It's $10 originally and +$1 for the time-based fee thing I don't know for an effective amount of $11. Now, this should all be handled in a single place, so it's not like the page itself is doing this work, but yes: the code starts with the original $10 and then recognizes that it should +$1 because of the time.