Magictallguy

Yes, a desktop PC

Relatively certain his statement was directed to me - similar sentiment from me though

Lol @ you @Sim Not only the wrong word for the intended meaning, but a word from Old and Middle English; suggesting it's simply not in use anymore. That's the trouble with using older language - contexts are different. How about stop being a young me and drop the attitude; it ain't gonna help you in this world

To add on to SRB's statement; in some setups, it may be necessary to parse the JSON string into an object before JS will let you use it as such. let scavengeData = JSON.parse(data); alert(scavengeData[0].amount);

Ah, they use cPanel. Also, welcome to the forum. I'll message you directly and prevent derailing your intro thread 🙂

"Scheduled Jobs"? Are you running on Plesk?

If I'm reading that right, you should be able to access the `amount` key (presumably repurposed to a context of "days" if applicable) like a standard array. data[0].amount Edit; which I see you've tried. In what format is `data`? Is it a JSON string, or something else?

Your setTimeout call. If memory serves correctly, you don't need to add the parenthesis for the callable function setTimeout('showScavageResults', 1000);

Debugging is too old skool! Dubuging shall rise!

"dubuging" is my favourite developer's pasttime

Ya know; if you used the code tags built into the forum, you'd see your markup was broken.

I remember experiencing this issue before in multiple other engines and almost every case came down to sessions. There was one or two cases where a token was being set before it was processed (invalidating the expected key before we could touch it) - check for duplicate calls to MCCv2's CSRF token generation function

I work for a small number of sites on the same host and have not experienced this issue. Check your session handling

ID DON'T NEED #! AAAAAAAAAA

Put id="php__container" back into the div from which you removed it. Change the <a> tag id attributes - they don't need an octothorpe and they must be unique

Restore the php__container ID to that div and alter your anchor IDs

The .com was unavailable at the time

Which kinda negates the point of a database.

Ah, I see. Thinking scalability now; a simple boolean flag for "in use" is fine if you only have 1 non-standard use for an item. But what if, in the future, you decide to add something else that could also make use of the "in use" boolean? I can see that getting confusing to manage and potentially giving unexpected/unwanted results with the conflict. So, to keep with logic, you'd just add another bool, right? How many booleans are you going to be ultimately adding until moving data to a separate table just makes more sense? I'm not knocking your approach, in fact I quite like it. I merely wish to point out a potential flaw to future designs

What about higher quantities? Your idea of setting a bool directly on inventory would work for single items, but quantities would be much harder to handle

Could add checkboxes to your creation form, along with relevant columns to the items table - select, on item creation, where the item can be listed (if at all)

No. Prepared Statements do not secure your data any more than a standard query would. It is on the developer (namely you) to use the functionality as intended. The most obvious difference (when coding) between PDO and, say, MySQLi is that using Prepared Statements negates the requirement for escaping data. Another benefit of PDO is that it isn't limited to the MySQL(i) driver; it can support 12 different DB drivers (at the time of writing) - which makes it highly adaptable and extensible. Use either properly and you should be good to go.

I believe last month's top player would disagree with your speculation

There's very little point in using prepared statements if you're not preparing them. I'm definitely against this method