phppup

@cyberRobotThanks for removing a heavy burden. *not sure what emoji would be appropriate* LOL

OK, yes. @cyberRobotThat is in the realm of what I was planning

I haven't begun to write the actual code yet. Only began to formulate the concept. How would echo implode($meta); work?

@cyberRobot Yes, I do consider the description tag as one of the "usual." I discovered a meta for security and refresh that I am unfamiliar with and uncertain about. As for you saying Yes, that was me from way back when. I suppose I owe an apology to everyone that I effected. (although I never got too crazy and NEVER used irrelevant terms)

@gizmola With all due respect, I don't think google is the ONLY search engine on earth. (Sorry, not a fan of theirs, but still fond of you. LOL) Are there any less popular meta tags that I should use (beyond the usual list) or recommended settings to be aware of?

I'm not sure whether I'm becoming overindulgent or a real developer, so please advise me. I have several webpages for a new website. I am well acquainted with them and their content. As I began planning to publish these pages, I realized I could probably utilize an array to include meta data for bots and search engines. My thinking was something like: for ($I=0; $I<count($meta); $I++){ if ($page.I){ echo $meta[I] } } I'm concerned with the effectiveness of doing this. Will bots and crawlers see it as legitimate and valid the same as if each page had "hand written" meta data? Or will it flag it as illegitimate or miss it, thereby hurting the pages placement in search results? Not much more to provide since I'm asking the question BEFORE attempting the code. Thanks

Get back to the withing script. Add the $gname association in the SAME loop and create $sql_2 to ADD a token. Don't forget to also call $sql_2 Gotta go for now.

If the second UPDATE is to ADD, then it CANNOT be $sql_1 ALSO because you already have a variable of $sql_1. So, perhaps that should be variable $sql_add throughout the second UPDATE. Revert to the code that was working with the subtraction and then work out the kinks for the addition.

It's very possible, but this is a clumsy methodology. Mac_gyver has the right idea. I'm also running out of free time. Have you tried replacing user_updated_token with a hardcoded number (like 20) just to validate that addition will occur?

OOPS! Just realized the code error I made. I made $gname = 20 which is WRONG. $gname is a user name, I meant to add an increase of value by 20 for easy verification. Sorry.

I like to test one item at a time. This let's you know where problems originate. If the subtraction is working, then now get the addition to adhere. I would think the two updates should be in the same loop, this way all criteria is the same.

I'd try this for starters: ////$gname = $row["fname"]; $gname = 20; //this will give you an easy way to spot the added value and see that it increases $user_updated_token = ($user_token) + 1; $sql_l = "UPDATE users SET token='$user_updated_token' WHERE id=$gname"; I don't use PDO, some in not sure about if ($conn_l->query($sql_l) === TRUE) //would == be more accurate than === And are you repeating this query? You already have it once, don't you?

I guess the first question is what exact code you added and where to trigger these errors. You are getting no errors prior to these added lines?

Did you get it working? (If it's good please mark the solution) PS: you may want to review and consolidate your tables to eliminate redundancy. Streamlining is good.

Looks like it would. Why not give it a shot?

It seems to me that you may want to restructure your process (especially if your learning) because it's easier to learn to code correctly than to learn bad habits. And it's easier to find and resolve issues on smaller projects than large. What @mac_gyver is providing you may be advanced information, but it is accurate. If a user of your small group tells you that their balance is incorrect, you currently have no recourse but to shrug your shoulders and respond that your code is full-proof (not very reassuring to a disgruntled user). Mac's method would offer an additional table for transactions that would allow you to say, " You had this many tokens on DATE and you received X many on these dates from user 1, use 2, etc. You also gave to these people on these dates, and this is my evidence to support the inquiry." More advanced, but much more useful.

Well, you cannot ADD to a column that does not exist, right? So at some point, you need to tell the SQL statement that $gname = fname so that the correct for value is increased by 1.

Does the row have a column for gname?? Or does gname = fname at that point? After you get out working, I would suggest a review of @mac_gyver comments.

I only see ONE statement for UPDATE. You need one for ADDING and ANOTHER to subtract.

If I'm following this, it seems that as long as the fname donor has > 0 tokens, you would UPDATE the row WHERE fname is found and decrease the number of tokens by 1. Then, do the same for the gname to increase the token quantity by 1

You should not use the asterisk * to select EVERYTHING unless you NEED everything pulled from each row of the table. Only SELECT what is required for reaching your goal. SELECT merely pulls data. UPDATE will overwrite columns. WHERE will tell the table which SPECIFIC cells should be effected. You can search for helpful tutorials for SELECT, UPDATE and WHERE online.

Legal advice is not provided here, but you can always contact an attorney or do you own research with an emphasis on your LOL locality. Beyond my disclaimer, I do not think that gathering the information should cause a problem. How you use it could be a different issue. In other words, collecting email addresses to use to contact your customers/users would be a reasonable business activity. Collecting the information to coordinate malicious activity would likely be frowned upon. Divulging the personal data on a billboard by a highway would probably be unwise. But again, this would be a good reason to have some kind of notification that informs users of what you are doing and your intentions. If the do not agree with the terms, then they can decline.

I think requinix was trying to point out, in a sarcastic tone, that any protection is better than none. Also, I don't see why it would be illegal to collect email addresses. If you are in a region that does not permit this, perhaps a notice or terms of service stating: "This website saves all applicable data during usage" will be beneficial (but I cannot provide legal advice on this).

You did not ask a question. You didn't post your code within the designated coding < > template. Nonetheless, it appears your mail function mail($to,$subject,$email_body, $headers); is directing your outbound emails to the variable $to (which appears to be equated to xyz@gmail.com) Either check the inbox of xyz@gmail.com or change the email address connected to $to

I just discovered that my domain's built-in email will no longer be included in my hosting package. Any recommendations for code solution or third party providers for an inbox with useful options?