maxxd

I'm curious as to why you have to drop a table and recreate it after each round. Explain that, please - it smells off.

Famous last words... 😆

What does the JavaScript function myFunction() look like?

No idea what your css looks like, but the second snippet is a form within a form, and all the fields are inside the inner form. Depending on how your element selectors are set up, that could cause a problem. Either way, if I'm not mistaken it'll almost certainly effect your form function.

OK, so places to start researching in order to understand Barand's reply: https://www.php.net/manual/en/book.pdo.php https://www.php.net/manual/en/ref.pdo-mysql.php https://www.lifewire.com/database-normalization-basics-1019735 Full disclosure, I've not read the final link fully but from what I've scanned it looks decent. Your data structure looks simple enough right now, just know that as it grows the need for normalization will grow.

Problem is, you're talking about very different ways of getting the data. In the grand scheme of things the problem is as easy as ginerjm says - you get the data and output it while building the response. However, if you're using a CSV you'll need to research fopen() and fgetcsv(). If you're using a JSON string it'll be fopen() and decode_json(). If it's a database, research PDO and MySQL. And if it's an Excel file, that's a whole other can of worms that's going to entail third-party libraries. Each potential path has it's own ups and downs; you'll need to decide how you want to store and retrieve the data. Outputting said data is easy - in every case it's a simple echo statement.

Float's a but quaint these days, but I can't recall off the top of my head any major updates in browser interpretation of it recently. I also don't recall hearing of anything removed from browser parsing of older standards. Sorry for the not terribly useful post, but unless there's some browser-prefixed or experimental definitions or functions I can't think of anything in the past year or so that would break CSS backwards compatibility. Maybe somebody else remembers something?

OK, looking closer you've got more problems than just not using the correct definition. Your HTML is invalid - your h2 elements are I think supposed to be class title2 and aa or bb, but right now that's two separate string so "title2" is ignored entirely. Your CSS is repetitive and nested incorrectly - if you look at the blocks you've marked as making the text glow, they're all wrong. The first block will only target a div or span with a class of 'aa' inside and H1 element, the second will only target a div or span classed 'bb' inside an H2 element, and the third a div or span classed 'cc' inside an H3 element. So none of your markup matches those selectors. Get rid of the H1, H2, and H3 and define .aa, .bb, and .cc. Or, better yet, just define a 'glow' block and use that class on every text block you want to be styled that way. The .title1, .title2, and .title3 classes have nothing to do with the effect you're trying to achieve so remove that comment and stop confusing yourself. There's also at least one typo in your CSS that your IDE should warn you about.

Did you try actually applying `background-clip: text`?

What's it doing now? Showing us what it should do doesn't really help. One thing that I see off the at is that you're not actually calling background-clip; you're doing the webkit- prefix and a moz- prefix (as far as I can find this prefix doesn't actually exist), but never actually calling `background-clip: text`. That may be the issue, but again it's hard to tell without and example of what it's actually doing now.

I can almost guarantee that yes, yes it will. 5.6 to 7.4 is quite a leap. For the other question, I'm not entirely sure what a rota is - let alone what 'addressing from the menu' is - but it's tough for anyone to tell if it'll be affected by upgrading WordPress without knowing what the integration is. If it's a WP plugin (and an old one at that as it runs on 5.6) then yes, it'll probably break. Honestly, even as a coalition of volunteers if the site is that important to your organization and the work it's doing, it's going to be worth it to hire a professional to upgrade it for you - a good pro will spin up the site locally and test all the upgrades before they even touch the live site and can more than likely fix any issues they come across. Maybe a GoFundMe drive can help? Unless you're in the mood to learn a lot rather quickly. At that point there are plenty of people here ready and willing to help you out when what you tried on your local version of the site explodes for random reasons.

Not gonna lie, in my experience Android browsers are more standard than iOS; certainly moreso than Safari. Are you using anything tricky in your styling? A lot has happened in the last year with CSS.

As requinix says Captcha is definitely the standard, but there's also the concept of a honeypot which is a hidden field that a bot will fill in but a human won't. So if the honeypot is filled, your script can ditch the submission.

I agree completely with gizmola's point about fluid design - the link I gave comes in handy for reference and when hard stops are necessary.

This is a good resource for screen resolution (among other things).