maxxd

That's still not making a whole ton of sense. The original code you've posted is using fetch to call to a php script, which I assume is pulling data from a database. It's presenting that data as an array - there's really no getting around that. One way or another you'll need an iterable interface in order to loop through the dataset to present the data. An array is the most convenient way; you could json-encode the data before php outputs it so that it comes across as an object in javascript, but really the way it's being used here that's mostly semantic. It sounds like there's something else going on that we don't know; is there caching involved? Like Redis or Memcached? Explain what goal you're trying to achieve, not how you want to achieve it.

You can also switch to PDO and get the benefits of not having go through extra steps like explicitly binding parameters (you can pass an array to PDOStatement::execute). Granted you'll still have to pass it an array that matches the parameters in the query, but it's less typing. There are also other reasons to move to PDO; the simplified interface and much easier readability, for example.

Not gonna lie, I have no idea how they do it. In my experience though, even large corporate entities that are respected in the field like MC or CC the results are just kind of assumed to be legit. An agency I recently worked with was adamant about pointing out to clients that it couldn't guarantee specific numbers on email opens, reads, or deletions because the numbers were at best kinda reliable... I assume the big players have some sort of sway with major email providers, but I have no proof of that. Obviously tracking results of clicks from the email to the website are more reliable as you simply append the tracking parameters to the end site from the email to the URL in the email itself. Doesn't help with opens, though - sorry. I have to assume someone here is more knowledgeable than I on the subject.

Your best bet here is to use an email service. SugarCRM, Constant Contact, MailChimp, etc. all provide the tracking you're looking for - how reliable it is is always kind of a debate, but they are the standards.

Honestly, if you want fancy tooltips I'd recommend using Tippy - super easy and powerful.

Things you'll need to do to get help: Describe what the code should be doing Describe what the code is doing instead Show us any errors you're getting in your browser Show your relevant code If it seems like the error could be a database problem, describe the data and its structure Explain what you've done so far to fix the issue(s)

Do you have a question?

To elaborate on requinix's point, JavaScript is client-side. That means it runs in the browser, so - for example - if the user clicks on something JavaScript can catch that action and do things to the elements currently on the loaded page without reloading that page in the browser. PHP on the other hand runs on the server, so the page needs to be refreshed so the data gets back to the server and can be acted upon. If you want to run a server-side process from the client, you'll need to use AJAX (today, the fetch() JavaScript function) to send the client-side information to the server for processing.

I should hope you hash the password value before putting it into the database - right now you're doing a plain-text compare. Also, is the name of your submit button actually 'submit ' (note the space at the end). Are you getting an error message or is the script just always showing the login form? Perhaps using a few words to describe what's happening would help us to help you.

What error are you getting? Your flow looks pretty standard and mostly correct, so post some code - please use the <> button to do that.

The height and width on .update-card is just there to see the effect. You can remove them and add some padding to the div to make it dynamic.

Using the markup in the thread and this CSS .update_card{ width: 300px; height: 100px; background-color: red; } .update-list{ margin: 20px; border-radius: 10px; overflow: hidden; width: fit-content; display: flex; flex-direction: column; row-gap: 20px; } give me this It looks like that's what you want?

Echo it out and see. echo __DIR__;

Then it's quite possible you're going to need to revisit the markup. What it comes down to is that whatever element(s) you want to have the rounded borders is where you need to put the background color. Or you might be able to put the rounded borders on the parent element with an overflow set to hidden, but it's late on a Friday night for me so please don't quote me on that...

.update-card has the background color. Use border-radius on that.

Several things - some are minor, some not so much. First and foremost, you're concatenating strings in places you don't need to - it'll get confusing and bite you in the end. Secondly, magic quotes have been deprecated (I thought they were removed, tbh) for quite a long time, and add_slashes() is pointless. Use prepared statements in PDO and actually be secure. Finally, as to your reported problem - php's mail() function is ... not great. Use PHPMailer or (as kicken suggested) Symfony/mailer. Either will make your life much, much easier, and you can debug the transaction much more easily.

Have you tried outputting $search to make sure it equates to Fred Smith? Beyond the basic issue requinix is alluding to, we're gonna need to see more code and you're gonna need to do some debugging.

What does "comes back after a blink" mean? First thing I notice is that you're missing a closing brace in your function.

Yeah, your markup is a mess. Sorry to be blunt about it, but it's certainly not the first time it's been brought up. Apart from that, I highly recommend reading up on flexbox and grid. As kicken pointed out, you're missing a closing tag and it's difficult to say exactly which closing tag you're missing, but the layout as I read it simply won't work in the way you want with flex. I'm not quite sure I understand the layout you want - it looks like 2 divs side by side with a single div underneath that goes full width, maybe? This is achievable using flex, but could potentially be easier to do using grid. Either way, I'm belaboring a point because I'm a bit tired. Your markup is borked. Fix it, post it, and tell us what it is currently doing and what you want it to do.

Take a look at this: https://uselessdivs.com/blog/a-short-guide-to-help-you-pick-the-correct-html-tag/ I haven't read through the full article, but the image toward the top is correct and could be helpful.

Also, you're opening a <nav> element but closing it as a <main> element, so the structure is broken from the get-go.

There's always $_SERVER['REQUEST_TIME'] - you could do a diff with the previous value (that you'd stored in session). Replace the value once you've done what you need to do with the value of the diff and move on to the next page.

That only works for you in your timezone, because you're adding the offset specific to your timezone. You have a choice here - either ask the user what timezone they're in and offset to that, or display in one timezone and let your users know you're doing that. Either way, convert all dates and times to GMT before saving it in the database and convert it on output. Either way, the code you've posted is clearly not the code you're using - that last block closes PHP and then continues to use PHP. You're also checking to see if magic quotes are enabled - I believe those were removed in version 5 or so? They're gone, ignore them and the add_slashes() function. Use PDO with prepared statements. Your Javascript is manually doing a whole lot of what the Date object does natively, and I'm not honestly sure why you're even bothering with the Javascript in this case. Finally, your form markup tags don't match - you open a text input and then close a textarea. In addition, you're using the field as an output - there's no need for it to be a form field, just output the value. Basically, you're beyond the point where you can acknowledge that the code is a mess that needs to be cleaned up; you need to clean up the code before you can proceed.

If that's the actual html you're using it's a mess. You open a <nav> element twice but only close it once and nest it incorrectly. If main is actually a semantic main element it's also nested incorrectly, and you open big_div and nav_div divs but only close one of those. In the CSS both your nested divs are position fixed, which really doesn't serve a purpose; beyond that neither of the fixed divs have a top value, so the fixed won't take effect. And it's a small thing but lowercase has been recommended for html tags for quite some time now.

If there's a reasonable or good chance that there will be multiple images per question, then yes make a joining table. However, if it's most likely that there's only going to be one image per question then keep the data where it is. The thing about db normalization is that it's kind of relative; one appropriately normalized database won't look like an appropriately normalized database for a different project. I personally think first normal form is a pipe dream, and from what I've read third normal form is kinda the ideal. It has all the logical hallmarks of a well-designed database and is easy to read and reason about, but it's also true to the business logic and functional specifications for the specific project.