Jacques1

Does Edge accept any cookies from the site at all? Run a separate test script with a simple setcookie(), then check your current cookies in the browser UI and with PHP. <?php if (setcookie('cookie_test', 'test')) { echo 'Cookie set. Run again to see if the cookie is sent back.<br>'; } echo 'Cookies sent by the browser:<br>'; var_dump($_COOKIE);

Trying to “sanitize” MP3 files (or any other file type) is pointless, because the meaning of data depends on the context, and there are infinitely many possible contexts. For example, the exact same PNG file can both be a perfectly valid image and a dangerous PHP. The “<?php” tag is eventually just a sequence of bytes (3c 3f 70 68 70), and those bytes may very well appear in a legitimate PNG file, be it in the metadata or the actual payload. If you remove those bytes, you'll damage the image, and you still haven't done anything about other contexts. What about the other scripting languages on your server? What about client-side scripts? Also note that some browsers like IE will actively work against you and switch contexts through all kinds of weird heuristics. The only chance is a defense-in-depth approach: Check the file extension with a whitelist (you'll probably only want “.mp3”), then generate a random filename and append this extension. Store the original filename in the database. Store the uploaded files outside of the document root and make them available through a proxy script. This script may either do a simple readfile() or use advanced techniques like X-Sendfile. Make sure the files are served with the correct Content-Type header. Use a separate (sub)domain for the proxy script, e. g. tainted.yoursite.com. The same-origin policy will isolate this domain from your main domain, which greatly limits the effects of many attacks against your users. Use Content Security Policy to tell the browser that script execution, form submissions etc. should be disabled for tainted.yoursite.com. Note that this only works in modern browsers, and IE needs special treatment. Those are just the most basic steps. When you're more experienced, I strongly recommend you also look into more advanced security topics like SELinux or virtualization.

You're also terminating the session with session_destroy() and then try to write data to it. This of course makes no sense. Get rid of the statement. I guess what you actually want is session_regenerate_id(true).

Your session cookie is created for the domain www.cunninghamwebdd.com, but you're redirecting to cunninghamwebdd.com. Those are, in fact, two different domains. While the subdomain can theoretically create a cookie which is valid for the superdomain as well (but not the other way round), I strongly recommend you pick a single canonical domain (preferrably www.cunninghamwebdd.com) and use that exclusively. Configure your webserver to redirect all other domains to the canonical one. This will save you a lot of trouble now and in the future.

Use mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); on top of your script to make mysqli report all query problems.

Why do you ask? In reality, a database without professional management is not safe, even if can only be accessed locally. There are simply too many ways to screw up: SQL injection vulnerabilities, configuration errors, inappropriate permissions, weak passwords etc. Of course you have to make your database as safe as possible, but do prepare for the case that an attacker manages to bypass your security nonetheless. That means: Don't store any sensitive data unless you absolutely need it. Make sure all passwords are hashed with a strong algorithm like bcrypt. Also encourage your users to generate purely random passwords with a password manager. Consider using encryption.

The password does get hashed with password_hash(). The code above is copied and pasted from wikiHow. Personally, I'd get rid of all the JavaScript magic and use a plain old form. I have no idea what the client-side hashing is supposed to do. Maybe it's some kind of poor man's HTTPS, in which case you should replace it with the actual HTTPS protocol. Maybe it's supposed to obfuscate the original password, in which case SHA-512 is far too weak. Either way, it only bloats the code and leads to problems (as you can see).

Forget about “validating” human names. You somehow seem to think that there are no characters outside of the latin alphabet and that people are named either “Joe” or “Jane”, but that's not the case. There's a large variety of different languages and names. There's José de San Martín, Bjørn Kjos, Jürgen Kleine-Frauns and Bhārat kē Pradhānmantrī. Who are you to say that those names are “invalid”? Yes, you could force everybody to transliterate their names to make your PHP script happy, but this is user-hostile, distriminating, confusing and completely unnecessary. We have Unicode now, there's no reason to artificially limit your users to 7-bit ASCII. If at all, you'd only check for basic features like “There must be at least one graphic symbol”: <?php const HUMAN_NAME_REGEX = '/[[:graph:]]/u'; $test_name = 'Bjørn Kjos'; var_dump( preg_match(HUMAN_NAME_REGEX, $test_name) );

The first code fragment doesn't do anything (useful). It decodes $complete_json, throws away the result and then dumps the original JSON-encoded data. The second fragment attempts to actually display the decoded content. Are you sure $complete_json is valid JSON? Like I already said, concatening individual JSON documents doesn't work, it was just a demonstration of loop logic.

If you're dealing with JSON arrays, yes. In case of objects, you need to be careful with conflicting keys. It might make more sense to keep each object in a separate “namespace”. For example, { "x": 1, "y": 3 } and { "x": 2 } would become { "a-meaningful-name-for-the-first-dataset" : { "x": 1, "y": 3 }, "a-meaningful-name-for-the-second-dataset" : { "x": 2 } } But I don't know your data, so this is a decision you'll have to make.

You can merge JSON documents, but you can't just concatenate them. If all documents have an object as their toplevel structure, you need to put the key/value pairs into a common object, possibly resolving key conflicts. If all documents are arrays, you can concatenate the individual elements. In both cases, array_merge() should be useful. But if you already have a better approach, that's of course preferrable.

If some scripts cannot be parsed at all and function definitions aren't found, this sounds a lot more serious than an error reporting issue. You should try to create a minimal example of a script which works in one environment but not the other. Also do a full comparison of the two php.ini files (e. g. with diff). Besides that, it's not ideal to have a version mismatch between the development machine and the production server. You should consider going back to 5.5.7, possibly in a virtual machine. There's also the changelog, but I doubt that it's actually a version issue.

If you want to do something with each $filename, you have to do it inside the loop. Doing it after the loop only gets you the last filename as a leftover. <?php $complete_json = ''; foreach (glob(__DIR__.'/../json/*.json') as $json_path) { $complete_json .= file_get_contents($json_path); } echo $complete_json; Note that a JSON document has a specific structure (it must be either an array or an object), so you probably can't just concatenate all individual files. You'll need to wrap them in a common structure.

Let's get some things straight: You got plenty of help and a large variety of solutions to choose from. You rejected all of them, merely telling us that they are not an option or “don't work”. This is entirely unproductive and, obviously, doesn't get you anywhere. Maybe you thought that eventually somebody would write the code for you, but that's not what this forum is about. We expect people to actively work on the problem. Your code doesn't work? Show the code. Maybe you should concentrate less on complaining and more on getting things done.

Since you seem to struggle a lot with syntax errors, I recommend you grab a proper IDE (integrated development environment) like Netbeans or Eclipse. This will analyze your code as you write it and notify you immediately when things go wrong. Then you don't end up with 100 lines of broken code. It's also helpful to write code step-by-step and top-down. That is, you start with the basic structure of the script and then slowly add new statements, testing each stage. As to your code: The terminators of heredocs must not be indented (they need to start in column zero), and you're missing the closing brace for the test2_2 function. Besides that, your code is a complete mess full of security vulnerabilities…

Consider using a template engine like Twig instead of prehistorical PHPHTML spaghetti code with dozens of security vulnerabilities. This allows you to render your HTML in a sane way: <select id="ret_teamname" name="ret_teamname" tabindex="4"> <option value="" selected>-- Select Returning Team --</option> {% for member in team_members %} <option value="{{ member.l_id }}">{{ member.season }} {{ member.leaguename }} {{ member.rteamname|truncate(25) }} {{ member.firstname|first }}. {{ member.lastname }}</option> {% endfor %} </select> (the truncate() filter requires the Text extension) Unlike your code, this can actually be understood by human beings, not just the PHP interpreter it's secure, because all input is automatically HTML-escaped it separates the business logic from the visual presentation, making it a lot more readable and extensible

You assign null to $response in line 35, but then you try to assign an array to $response->data in line 41 as if null was an object. This is of course nonsensical. Either make $response an array and use the $response['data'] syntax, or make it an actual object.

In your first post, you actually said it's /webroot/etc/php.ini, which sounds like you're running PHP in some kind of jail. So what's going on here?

As to your original question: No, it's not OK to use potentially undefined variables, even if PHP still runs the code. Using undefined variables triggers notices. Of course you may suppress or ignore notices, but then you're likely to miss actual bugs. It's a security risk. If a variable isn't defined, an attacker may be able to inject their own value and manipulate the control flow of the program. This has happened with the infamous register_globals misfeature, and it's still happening with the extract() function. It's extremely confusing and can lead to errors. For example, it's sometimes desirable or even necessary to do type-safe comparisons with the === operator. If the value is just “kinda false”, this comparison will fail. Yes, PHP accepts and even encourages sloppy programming. But that doesn't mean you should do it.

What does php -i | grep 'Loaded Configuration File' say? Is this the exact file you're editing?

INSERT IGNORE with Link being a primary or unique key.

Do not create duplicate topics (how ironic). Your thread is here: Deleting Duplicate Error

Are you sure you've edited the right php.ini? What does phpinfo() say about the “Loaded Configuration File”?

“Apache 2.0 Handler” means that you're not using FastCGI, so ProxyErrorOverride is not available. That leaves you with only two options: Either you change the webserver setup and switch to FastCGI, or you give up and use the shutdown function hack to render the error pages. The webserver itself cannot do that in your current setup (as far as I'm aware).

The code makes no sense whatsoever. I recommend you start with the basics of PHP before you jump to more advanced topics like form processing. How to write valid HTML markup. How to escape data for HTML contexts. How to access a MySQL database with PHP. How to make PHP show errors. $row['id'] is a string, so $row['id'][$i] is technically valid -- until you hit the string limit.