Jump to content
#StayAtHome ×


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About phppup

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Any other opinions? PS: there are TWO questions that I inquired about.
  2. I am setting up a new form with more updated PHP code and seek some opinions: Is using FILTER_VALIDATE_EMAIL FILTER_SANITIZE_EMAIL just as good or better than the predisposed methods of the acceptable Regular Expression Pattern ie: '/^\ [A-Za-z0-9_]([\.-]?\w+)*@\ [A-Za-z0-9_]([\.-]?\ [A-Za-z0-9_])*(\.\w{2,3})+$/' On a slightly related topic, during testing I used PHP to create a SQL table and discovered that if the table already exists, an error message stating that the "table already exists" will be produced and the existing table will stay in tact. Does this eliminate the need to use code that would state if($exists !== FALSE) { echo("This table already exists"); } or is it suggested as a "best practice" as either a safeguard or coding approach?
  3. An order would ONLY be placed on webpage_2 (along with pricing). So, the distinction isn't the status of the order, but rather the classification of the visitor (ie: browser or customer). Does that change your thinking? If I get 100 visitors and only 20 become customers (on their first visit) do I want one single table of all visitors, or two distinctly different tables [BasicInfo with 80 rows, CustInfo with 20 and an association to their placed orders]?
  4. @Requinix.... Sorry, I'm just so used to posting in the coding section and the question arose while I was considering the code that needed to be written. I will be more careful in the future. As for my concern, I'm more interested in how to structure the USER data accumulated from visitors that enter partial information versus those that provide additional information (and an order). The idea being that if webpage_1 gathers basic information, then a visitor that declines providing more data on webpage_2 (after seeing cost/pricing) can be contacted with a survey to determine what discouraged him. Obviously, a visitor that DID provide additional information and became a customer would NOT be sent the same survey. So, from a coding perspective, do I insert all webpage_1 data into a table BasicInfo and then move it OR duplicate it into a table CustomerInfo if the customer completes webpage_2 ? Or do I simply lump everyone into a table of BasicInfo (for ALL visitors), perhaps with a column indicating whether they were only a visitor or an actual customer?
  5. I am considering a two step order form. The first webpage would require basic information such as name and email. The second webpage would include pricing and submission. The reason for the two step separation is so that the basic data can be inserted into a table. In the event that an order is not submitted, these people can be solicited separately (perhaps with discounted pricing or a survey). The real question pertains to the best architecture for such a database. My initial thought is that I need a table for data [BasicInfo] generated from webpage_1, and another table for people that actually place orders [CustomerTable] with an associated table for the actual order and pricing [OrderTable]. Does every completion of webpage_1 go into the BasicInfo table, with a repeat of basic info and order info being directed to CustomerTable and OrderTable, respectively?(This seems unnecessarily redundant where BasicInfo is really a list of both costumers and visitors) So what is the best way to trim the fat? Put everyone in BasicInfo and then move the row if they place an order? Put everyone in BasicInfo with a column named 'order' that is updated for future referencing? Some other method that I haven't thought of yet? Advice please.
  6. Last line should read: make sure your $ret is positoned correctly to avoid sending multiple emails with the same content.
  7. It sounds like you've got something working. (which is a plus) and now just need to tweak it to for your specifications. There are many more qualified coders here than me, but here's my opinion. If I understand your dilemma, you are receiving one email per student but would prefer receive a single email with the information of all the students. I would suggest adding an IF statement that surrounds the entirety of your applicable code. You can either ADD another column (maybe MEMBER) and sort through with the IF statement. Or, analyze an existing column that is applicant (maybe attendanc_date). So, if attendence_date is March 1 [2020-03-01] THEN put the six lines of $msg into the body of the email, otherwise, skip the row. You will want to add an additional \n at the end of your $msg to make the email body more presentable and break up the information. Also, in this instance, make sure your$ret is pristine correctly to avoid sending multiple emails with the same content. Good luck.
  8. I created scripting to upload multiple images simultaneously. The files sizes allowed for upload are 2 MB (or larger) and are then resized to approx 300kb each. In testing, I have discovered that the uploading terminated after 20 images. Is there a variable that needs to be re-defined in order to easily allow uploads of several hundred images? PS: I've seen several conflicting examples for defining max_file_size. What is the correct math to define this parameter?
  9. I'm trying to create a series of web pages that will lead to a FINAL SALE page. At that point, I require TWO things to happen. First, the customer must pay the displayed total. Second, some kind of automated receipt needs to be generated so that a script can allow the customer to progress further. An applicable example would be a customer navigating through web pages of paintings by different artists and then choosing to see Alfred's latest unreleased paintings for a $2 fee. After paying the $2, the next web page would validate receipt of the payment, and now allow the customer to access Alfred's gallery. Is there a template for this sort of thing? Obviously, an online payment would require a credit card. Any recommendations for service providers would be appreciated. I have contacted Pay Pal, but they seem trained to encourage Ebay type sales and insist that the email I receive as confirmation would be sufficient. However, that would require me to check my email and manually grant access to galleries without ever sleeping. LOL. I'm sure there is a more viable solution, but need some advice and guidance from those that have already traversed this obstacle.
  10. Got it working. Cleared up my error messages. Even re-wrote it in Procedural style for my clarity. Thank you all for your input. Thank you, <strong> sensei </strong>
  11. select max(id) as maxid resulted in: ERROR: Could not able to execute select max(id) as maxid. Unknown column 'id' in 'field list' $sql ="select max(id) FROM persons as maxid"; still provided NO result
  12. $sql = "SELECT MAX(id) FROM persons" ; if($result = mysqli_query($conn, $sql)){ if(mysqli_num_rows($result) > 0){ echo "<br /><br />ROW ".$row['id']."<br /><br />"; } } gives me: ROW and an ERROR message of "Notice: Undefined index: id"
  13. Field Type Null Key Default Extra id int(11) NO PRI NULL auto_increment first_name varchar(30) NO NULL last_name varchar(24) NO NULL email varchar(70) NO UNI NULL sum int(11) NO NULL Persons is a simple table made up of some simple columns: id, first_name, last_name, email, sum.
  14. Yes, MCONTE, both of those seem to work, but apparently mysqli_insert_id($link); works ONLY during an INSERT and not as a method to SELECT (independent of an INSERT in the same script). Barand, I have a simple table being displayed row by row that is giving me results from other script efforts. Didn't want to waste space by posting it. echo "</tr>"; while($row = mysqli_fetch_array($result)){ echo "<tr>"; echo "<td>" . $row['id'] . "</td>"; echo "<td>" . $row['first_name'] . "</td>"; echo "<td>" . $row['last_name'] . "</td>"; echo "<td>" . $row['email'] . "</td>";
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.