phppup

Additional info: At the same time that these issues occurred, I visited the webpage on my cellphone (different WiFi network, different anti-virus/firewall/security) and got the same ODDBALL occurrences. UPDATE: This morning I was working from a different location on a different webpage (same website) and all was fine. Then, suddenly, changes to HTML and PHP echos were ineffective. Am I correct in assuming that these clues are pointing me in the direction of the hosting server? Is this likely an internal problem that they need to resolve, or is there a way that I can help PUSH my updated code so that it becomes active? NOTE: although code is not being displayed to reflect changes, the files are being saved and can be recalled with the latest info retained.

The TIMESTAMP that you have is a countdown of seconds that can be converted to "human" readability by reformatting it. This should get you on the correct path $date = date('d-m-Y H:i:s', 1565600000); echo "The date is $date."; Note that 1565600000 is a test TIMESTAMP. You can research DATE formatting for a variety of effects to organize the date information in a way that you prefer. ie year- month- date or otherwise. You can even spell out the names of months etc.

An HTML file was getting too large so I decided to attach some JavaScript as a src="add.js" rather than sitting the JS directly in the HTML file. When add.js was stored in the same folder as the HTML, the connection worked. But when moved up in the h hierarchy by one level, I couldn't find a connection. I thought ../thisLevel/add.js would work (and I tried every variation) but got nothing. Suspiciously, after settling on leaving the JS in the same folder as the HTML, I discover that the response I was getting was outdated - as if cached. [I changed an alert("hello") to "HELLO 2" but was alerted hello on screen) After emptying the cache, I got variations of effectiveness from the script. This made it impossible to review since I didn't know if errors were caused by the script, a malfunction of cache, or otherwise. Is this a browser, server, or computer issue? What is the remedy? Is it a common occurrence when JS is outside of the HTML code?

@maxxd it works because the ECHO is 'printing' the HTML commands that are to be used. In this format, the PHP had to be interrupted by closing the quotes and adding a dot around a non-HTML item, which is a PHP variable, and then reopening the connection if more concatenation is required.

@ginerjm This particular item caught my attention. $secretcode = ['nospam']; Looks like a piece from @kicken in yesterday's post on "sudden influx of spam"

You don't have to literally SPAM yourself. But you DEFINITELY should TEST to make certain that the code you create works as expected. Add one new piece at a time. Then, try to send yourself a message that would be INVALID. if it gets through, try harder. If it is successful, then move to another feature and test again. PS: I find it effective to create a message to myself for definite confirmation. echo "This worked great"; } else { echo "no luck this time"; After enjoying success, you can comment them out or remove them.

Not that type of environment. And that is why I'm more concerned regarding the example I outlined in my analogy.

Our seems that the previous response are pointing out two items: 1) Your page is subject to not attacks. One solution to that is to create a method that would require human intervention to assure that the girls are being populated by a real person. You can create an text input that requires a phrase ("yes I'm human") or a random number and validate it before the form will be allowed to submit. 2) Your entire method of validating the return email is whether a dot and @ exist in the email address. There are loads of viewpoints p online. Do a search for "PHP email validation". Then, test what you code by trying to spam yourself.

I know this may seem trivial, but it's like to handle this correctly from a load bearing and a db rules standpoint. My scenario: a user has several buttons that can access information IF the user is authorized. There is a good chance that the user will click (and come back) several buttons during a session. Does it make sense to put the entire set $AUTH1, AUTH2, etc. into $_SESSION when running the initial SELECT statement in order to save trips to the database? Our should a separate SELECT be introduced each time? Analogy: I went to the basement and brought up soda, fruit juice, and bottled water. I only needed water, but there was a good chance I'd need another option later, and wanted to avoid the trip up and down the stairs. I don't suppose my code gets tired, LOL, but traffic is traffic. Recommendations?

@gizmola Thanks for the helpful information.

@Barand Ran a new test with ENGINE=INNODB; and had SUCCESS. Thank you. Oddly, after ALTERing the table to INNODB, the problem persisted. But recreating the tables worked

@benanamen That's what I thought. But if you READ my opening entry, you'll understand that when I deleted a particular student, the particular student was deleted from the PRIMARY table ONLY. The child table did NOT get affected at all. And that's a problem.

CREATE TABLE student_details ( student_id INT PRIMARY KEY, Student_name varchar(8), student_year varchar(8) ); CREATE TABLE student_exam ( exam_id INT PRIMARY KEY, exam_name varchar(8), student_id INT, FOREIGN KEY(student_id) REFERENCES student_details(student_id) ON DELETE CASCADE );

I felt fairly confident of my understanding and code for a second table with a foreign key, yet in testing, when I deleted a record in Table1, it did NOT get deleted in Table2 (which holds the foreign key that references Table1) I even went so far as to replicate the steps from https://www.geeksforgeeks.org/mysql-deleting-rows-when-there-is-a-foreign-key/ but the final steps for After Deleting did not match up ( as I continued to have 4 records in the subordinate table) because the record that should have been removed was still there. I have tried to troubleshoot and ran SHOW GLOBAL VARIABLES LIKE 'foreign_key_checks'; directly in MySQL at phpMyAdmin and received Variable_name Value foreign_key_checks ON as my result. Guidance, please.

@schwim I was conflicted because I've heard that $_SESSION might be easily compromised, however, I would think reposting the same data in HTML through a hidden input as suggested by @requinix suggested, could be even more vulnerable. How would I do it securely? I found it interesting that the next post after this one titled login user only one device at a time seemed to align with a similar vagueness regarding the implementation of whether a SESSION or a TABLE would be more effective as a Best Practice to handle movement of information. Remarks?

Within the quiz that I am assembling (which does NOT allow a user to return backwards), there are answers to previous questions For example, #1 ....what color was John's coat. #3.... what was the problem with John's blue coat? #4.... After Mary fixed John's torn coat pocket, where did they go? etc. At the end, the person will be asked, "Do you want to submit these answers or take the test again"? If they decide to re-take the test, then no answers will be evaluated. If they submit their responses, then the replies will be saved in the database. I see two approaches: either I can save each answer in $_SESSION and INSERT them ALL if the user clicks the "SUBMIT my answers" button OR, I can INSERT and UPDATE to the table after each question is answered and either DELETE the record or overwrite it as the quiz progresses, until they decide to choose SUBMIT. Which is the best approach? Why? Are there any other realistic options to consider?

I'm guessing that yes, it's the number of queries that at to load, and retrieving extra days is still better than an extra query. As for the diagrams, awesome of you. I thought there was a sql clause like SHOW (which I have not gotten to work) that could be used.

No problem. I just wanted to confirm that hopscotching through the tables regularly was the right way to go (versus a single table with so the necessary data parked and available). Perhaps I'm just thinking too "humanly" for setting up an "automated" system. So it's the number of queries that actually cause extra load? Is it preferable to gather all my data and then evaluate sql = "SELECT X FROM TABLE.... JOIN... JOIN.... JOIN if ( evaluate results to determine action... Or cascade through IFs that essentially create extra query trips $sql = "SELECT x from table1 WHERE if ( $x .... condition TRUE $sql2 = SELECT.. JOIN.. another condition... but has the potential to reduce the bed to access resources. Or does it not matter at all? PS: how do I extract the diagram of my db structure similar to what I've seen posted in this forum? _____ | | ----- ? Thanks.

No problem. I just wanted to confirm that hopscotching through the tables regularly was the right way to go (versus a single table with so the necessary data parked and available). Perhaps I'm just thinking too "humanly" for setting up an "automated" system. PS: how do I extract the diagram of my db structure similar to what I've seen posted in this forum? _____ | | ----- ? Thanks.

I'm getting accustomed to spreading my data over multiple tables, and trying to do it right. Assuming that several small tables i are more optimum than one big table (since there are less rows to touch - even if they are being ignored), is touching a table for a single column advisable? I know repetition is a no-no, but should oft needed data be stored together (even if unrelated)? Example: On login there is a check for user and password (from USERS). But then I want to make sure the account is active (it will expire after 30 days and days is stored with other timestamps) so check ACCOUNT activity. And that the user logged in within the last 5 days (check INFO) or used a PROMO table code etc, etc. Each of these tables needs to be visited to compare data. Is this the correct/best approach? Or is there an alternative way to make 'regularly required info' more accessible?

Thanks @Barand. I seem to have had it right, but obviously there is a wrinkle somewhere that I'll need to iron out while creating the PHP code. Along these lines, once the FK connections are established, will they enable a more direct INSERT of data from a form? Or do I need an INSERT statement for each table independently? Are JOINS only for data retrieval?

I think it's Maria DB, if that makes any difference. I don't have access to now, but when putting the code directly in as SQL through the admin access, I got a red dot and an "unrecognized expecting... " balloon message. I tried several variations to resolve the issue, but thought I'd better check my structure here (since everything else to establish the FK send pretty straight forward. Table1 id PK auto increment - users personal info - Table2 id PK auto increment favorite car year, make, model, color linkID FK references Table1(id) Table3 id PK auto increment favorite vacation location, hotel, duration linkID FK references Table1(id) My approach is that while tables 2 & 3 are separate from each other they are both connected to the individual user, and would connect to the respective ID. Is my approach valid, or do I need to connect the tables like a set of trains on a track rather than a motor boat with several water skiers?

It was so much simpler when I stored all my collected data on one big table (well, not really too big, actually) Now I am attempting to be more efficient by learning the proper use of foreign keys. Table1 id PK auto increment Table2 id PK auto increment linkID FK references Table1(id) Table3 id PK auto increment linkID FK references Table1(id) When I tried to implement this table structure, MySql would not allow me to create Table3. What am I doing wrong? Is my approach/understanding flawed? Do tables 2 & 3 need a primary key? Why?

@Phi11W A n EXTREMELY valid point. ABSOLUTELY!!!... but it's always a fair reminder to see. I believe this is why I ran into trouble initially, as I was not so keen on re-directing my data. It's been a few days since I had a chance to work on my code, but I think I'm going to try a hybrid that tests the code on the current page (so that PHP error messages could be visible on the same paged form) and passing the values for usage through $_SESSION. To your point, Phi11W, then someone sending data directly would hit a dead end because $email=$_SESSION['email'] and NOT the value of $_POST['email'] Any comments are welcome.

Does a user have to begin the form from the beginning if a field is invalid? If it passes as valid, then you redirect to another page?