requinix

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.

You don't have to change anything. Whatever your code is that looks up the amount, update it so that it takes the time into account and adds $1 if it's after 3:30.

They are stupid and wrong. Perhaps it worked once long ago, but right now it's clearly not the right behavior.

If this is coming from some theme then your first course of action would be to contact the author. Not just to see if there's a fix, but also to see if there was a particular reason it was done this way (not that I can think of one). And once fixed, anybody else using it would be able to benefit from your investigation. If you can't contact the author, or the theme is old and unmaintained, or whatever, then edit the theme.

Remember when I said that the first rule of thumb when dealing with CSS problems is to remove rules?

"Outside a class"? Screenshot #1: grve-wrapper selected below, bounding box shown above is too low, highlighted CSS on the right shows a few rules Screenshot #2: with the position:relative and top:50% rules disabled, the bounding box is in the correct location but the image is too high Screenshot #3: img selected (the one that's visible), bounding box shows it's too high on the page, highlighted CSS shows a few rules Screenshot #4: with the top:-50% rule disabled, the bounding box is in the correct location

Look at my second and fourth screenshots.

First rule of thumb with CSS problems is to try removing stuff instead of throwing more at it.

Did you take a look at the parent .grve-wrapper?

GDPR only applies to residents of the EU.