maxxd

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).

It's not a typo. Steveinid is pretty much correct in the assumption that the query will match either a city or a zip code. If you enter a zip code, the city obviously won't return a result and vice-versa. You're searching the contents of two columns using one criteria and returning anything that matches.

You can use prepared queries for all query types, and if the SQL itself contains any values not hard-coded in the SQL string you absolutely should. That having been said, if you're doing a straight select without external input of any sort, don't bother. It'll just add an (admittedly small) amount of overhead. From your posted code it looks like you're actually doing that already. As mac_gyver pointed out, you should be seeing additional PHP errors - I see several missing semicolons in what you posted. I haven't used atom, but it should be pointing out those types of errors for you.

As this has moved to a new issue, please start a fresh thread with your latest question.

It still seems weird that even having to hard reboot the system would wipe out a file that clearly had been saved. Admittedly, if Windows was already having trouble it has been known to happen; it totally sucks, but yeah - computers barf sometimes. As to your second question; no idea, dude. I do however look askance at the `$stmt->close();` line as I'm not sure one really ever needs to close a DB connection in PHP, it handles that pretty well on its own. Somebody here will I hope speak up if I'm mistaken on that. What you've posted will overwrite variables of the same name if the code you've posted is nested. For instance, if you're looping through a result set defined as `$result` and you have the code you've posted, then yeah - `$result` will change as of the first iteration of the internal loop (the code you posted) and you'll get unexpected results. I will also say that if you're running a query within a loop based on the result of another query, there's probably a bigger issue with the code. Post what you've got.

Not really sure how my post was the answer - did you recover your file?

That is really strange; try opening the file in a plain text editor. It almost looks like it could be an issue with your editor (atom? i don't recognize the icon).

Not sure how that would have happened, but dude I feel ya' - losing WIP sucks. Check to see if your editor created a temp file somewhere or if there's an automated backup. Obviously, this is one of the benefits of using git but if you're not or you didn't commit or push, it may be rough. How exactly were you running the script that an infinite loop could have wiped your file?

U+2002 is a space. Is there a reason you're encoding it? I'm sorry, I don't trust 'invisiblecharacter.net' so I won't be visiting your link; perhaps you can explain further?

From what I can see 'inded' is a typo for index. What that means is that the URL you passed in to the function doesn't include a URL query. Use the null coalescing assignment operator instead of directly assigning the value.

Just getting back to this. According to the ThemeForest page the last update to this theme was in 2018. A lot has happened in both PHP and WordPress since then - it might be time to start shopping for a new theme. I can almost guarantee that if you're seeing these issues now you're going to see worse issues with the code in the future.

Nothing in the vast amounts of code you've posted has to do with creating the output in your screengrab. Post that output function and we can help.

Seeing as $subcategories is the common variable on both lines, I'd assume that is the problem. As of 7.2, php starting emitting a warning if the variable passed to count() isn't an array or another type that actually can be counted. I don't know what the 'knowledge template' is, but I'd bet it was developed before php7, and that sometimes there are no subcategories - this is probably leaving $subcategories null or 0, which isn't countable. Check to see if there's an updated version of the theme; if not you'll need to find where $subcategories is defined and make sure it's an array even if there aren't any subcategories to be found.

Ah, well that would explain it. I forgot about the Chrome extension bit...