requinix

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.

Sorry but no. The slash affects the URL, naturally, but it is by no means necessary for the form to work. Nor does it have anything to do with GET vs. POST.

Put both the image and the caption inside the container DIV and use CSS to make them both somewhat block-ish. Give the container DIV an equal negative left margin so that it looks like there's no margin on the first image.

curlCall is some function defined somewhere in your application. Look at it to see how it is supposed to be called and then update your code accordingly.

Forget "common" and think about "purpose". A session cookie lasts potentially forever, but it disappears when the browser closes. Is "forever" a problem? User authentication should not last forever. A regular cookie lasts until some particular time, assuming it does not get refreshed. But once that time passes, the data contained by the cookie is lost. Is losing that data a problem? User tracking data should not disappear or else you'll mistakenly count too many users.

SQL statements are like a recipe: there are a variety of things you can combine together to get the desired end result, but you have to do them in a certain order for it to work. For example, WHERE clauses have to come before ORDER BY clauses.

<form action="multi.php" action="post" class="py-4 px-5" id="form"> Take a closer look at that. If you don't see a problem, try reading each piece of it aloud to yourself.

You can see the expiration time of the cookie. Five minutes is really short, though, so I doubt the timeout is coming from an expired cookie. Which means it's server-side and there's nothing you can do about it.

I don't know why "config/config.json" and "./config/config.json" would work any differently. Are you sure that's happening? You have some code with the former that works fine, you add the leading ./ with no other changes, and it stops working?

That is not PHPMailer. That is regular mail. Find, download, and use PHPMailer. Read the manual and they will tell you how to send HTML emails.

Sorry but no, it is not what you thought. Seems a quick primer is in order. PHP handles exactly one page request at a time. When it finishes with a page, it completely forgets everything that happened. You can't set a variable on one page and get it in another page. Obviously that would be a huge limitation to making a website work, and that is why things like databases and cookies and sessions exist. That means there is no transfer of "control" between pages. PHP doesn't remember that the user was on trial-offer.php and is now going to checkout.php. All it knows is that someone is trying to request checkout.php, and they may or may not be sending data too. $_POST is not a database or cookie or session. It's a variable. A variable that you can reference from anywhere in your code, but just like every other variable, it's only usable for that one page. If you made any changes to it (which is a bad practice so don't do that) then you could see those changes for the rest of the page, but whatever you do will not be available on another page. Same for $_GET. $_GET gets its information from the query string - the stuff after the question mark in the URL. PHP looks at the query string, parses it, and shoves the data into $_GET for your convenience. $_POST gets its information from POSTed form data. The most common way to send POSTed form data is with a <form> whose method=POST. PHP looks at the data sent to the server, parses it, and shoves the data into $_POST for your convenience. If you have a form with an action="" then the browser will be nice and assume you meant action="(the current URL)". That's how form data goes back to your page: because the browser told your server that it wanted the same URL with some POSTed data. If you have a form with an action="checkout.php" then the browser doesn't have to assume anything, and it will tell the server that it wants checkout.php with some POSTed data.