phppup

I have a script that ends with mysqli_close($connection); [which I've been told is a "proper" methodology, although not a requirement] I've now decided to add an option of } else { header("Location: https://example.com"); } if conditions force the code to take this route, is the mysqli_close($connection); ever implemented? Is there a Best Practice for addressing this instance?

I'm getting closer, I suppose. Using @kicken suggestion is giving me a separate window that processes and displays the desired information. But apparently the target="xyz" forces the xyz-page to refresh with each click to submit. As I mentioned to ginerjm, so I want a new window [that would need to be physically closed by the user] with every individual click event.

@ginerjm Yes, absolutely. For example: a form with a drop-down of employee names that will provide data on a totally separate new window. If data for a second employee was requested, a second new window would open to provide that data. Theoretically, these windows could now be placed side by side for comparison and the main form would still be available and unchanged.

I want to have the results of a SQL query appear in a newly launched browser window. As I am aware that this is a JS function, I have managed to accomplish that portion of the task by having the processing script become the new window. action="processing.php" onclick="windowScript()" function windowScript(){ window.open("processing.php"); } but at this point, the $_POST data is NOT interacting. I suspected that this is because the PHP processing script is no longer directly receiving the submitted data. What is the best way to proceed?

I would think that if the code was successful on PC then the issue causing the problem is NOT the code. Although altering the code and checking for other errors might help. Have you tested the upload process on mobile with different size images? Perhaps the movie has internal settings to limit duration and size of transfers. Is the mobile giving the same results when used through your service provider as it does it connected to WiFi? (Be sure to clear cache BEFORE testing out you may get unreliable results.)

@requinix I understand what you're saying, but at the same time, isn't allowing every keyboard symbol in an input field also offering a skeleton key to a hacker-wannabe. Yes, I expect a person's name to contain only letters (unless you're Elon Musk's kid). But aren't there certain symbols that effectively take the challenge away from a malicious effort if they are accessible (ie: opening tags for code), especially when that code is headed for a database. Or should my question be: what's the best way to secure a db?

Well, there's that. But also the degree of security to thwart malicious efforts and hacking attempts. Let's say for a comment text area to be stored in a db.

While on the subject of being paranoid, what characters are safe to use [or totally unsafe] for usernames and other text inputs? Is a Reg Ex excluding < > ? adequate? (probably not, but is there a basic template to use all around?)

How paranoid should I be? I've never actually dealt with a hacker threat. Is there a Best Practices for recovery?

Better than checking the schema?

Suppose a file contains a form with action="" The HTML form self evaluates with PHP that is in the same file. Perhaps the HTML includes PHP tags for error messages to be displayed (which I've seen in HTML files). Does it matter whether the file itself is stored as a PHP file versus an HTML file?

What is the most efficient way to determine whether a table exists? I've seen statements that using CREATE TABLE IF NOT EXIST is an indication that one is not properly maintaining a database. But it seems to me that part of a proper maintenance plan would include an immediate response if a table that should be in the db was to suddenly vanish. How can I code to alert (and repair) for a possible hack/compromising of data. I've seen information that explains to SELECT record 1 with the understanding that if there are records, then the table MUST exist. But to the contrary, just because there are NO RECORDS would not indicate that the table is non-existent, only that there are no records. Am I being too nitt-picky?

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