Jacques1

First of all, “doesn't work” tells us absolutely nothing. It could mean anything from “When I execute the script, my PC catches fire” to “There's a tiny issue with the HTML markup I get back”. If you want a good answer, you need to ask a good question. So what is the problem? What happens? Are you getting any errors? If not, are you sure your error reporting is on and up? In general, you can't just read a remote file like you read a local file. This is a special feature which is often turned off for security reasons. If it actually is turned off on your server, then PHP will tell you. But only if your error reporting is turned on and up.

Age is irrelevant. I started programming in my mid-twenties without any previous experience whatsoever. I didn't even know how to write HTML. But I loved writing code, so I learned, practiced and played around. And after a few years, I was eventually able to turn my hobby into a profession. Web programming is no rocket science. Of course every programmer likes to think that they're a genius who performs magic, but in reality, the average web application is actually fairly simple. You don't need to be Einstein or have tens of years of experience. You just have to be able and willing to learn. I see absolutely no reason why you should switch to Java at this point. Why give up the PHP knowledge you already have? Java also won't magically improve your code. If you have the tendency to write messy, unorganized programs, then this will be a problem in all languages. So you might as well stick to PHP (unless you no longer like it). I'd rather analyze the underlying problem: Why did you end up writing code which you're not satisfied with? Is it a problem of bad resources? Is there something wrong with the way you learn? Is it a matter of attitude? Since I don't know you, I cannot give an answer. But my impression is that you're too hesitant. You talk about learning PDO as if that was a matter of many years. Why not learn it now? Open the PHP manual, grab your favorite editor and start playing around. Try to establish a database connection. Try to make a simple query and fetch the result. Try out prepared statements. It's really not that hard. When you find out that a certain technique is bad, stop using it. Don't come up with excuses or make plans for solving the problem in the distant future. Solve it now. The only way to become better is to constantly eliminate mistakes and replace them with good practices.

Since you didn't say anything about the character encoding of the database connection, my guess is that this is your problem. When you send data from the browser to some database, there are at least 3 encodings involved: The encoding of the user input in the HTTP request. The encoding of the database connection (MySQL must know how to interpret the incoming data). The encoding of the MySQL table. You've appearently covered the first and the last stage. No, you don't need an accept-charset attribute; it's enough to declare the encoding of the entire document. If you've forgotten the second stage, then MySQL might misunderstand the incoming UTF-8 data (the default encoding is Latin-1) and store nonsense in your table. How to declare the encoding of the connection depends on the database interface you use. If you're still using the old mysql_* functions, then it's mysql_set_charset(): mysql_set_charset('utf8'); Do not use a SET NAMES query. While this also changes the encoding, it doesn't update the encoding information in the MySQL API and can break important functions like mysql_real_escape_string() entirely.

While you may have satisfied the PHP parser, the code still makes absolutely no sense. Do you realize that you let any visitor overwrite any file on your server as long as PHP as access to it? All they have to do is manipulate the file path through the POST parameters. They can leave the upload directory by injecting a “..” string through the fuser parameter, and then they can freely travel around on your server via the create parameter. This is a disaster. Never, I repeat, never insert raw user input into critical contexts like file paths. The Internet is not your living room where everybody is your friend and plays by your rules. When you give people the chance to screw up your application or your entire server, they may very well do that, if only for the “fun” of it. So please think before you write code. If you want fname and create to be simple alphernumerical strings, you need to actually validate that.

You somehow assume that the referrer only contains the base URL without the query part, but it contains the full URL including all parameters. So you can't just append your own parameters. Using the referrer generally isn't a good idea, because it's not reliable at all. It may be missing entirely (depending on the client's browser), or it may point to some unknown site (if that's where the request comes from). Why not simply submit the form to the same script that renders the form? Then you can skip all the complicated message passing and redirecting. What do you practice then? Writing bad, obsolete code?

Well, just think about it. If you have, say, 210 results, how many pages are there? How do you calculate this number? When you know that, all you need is a for loop and a way to include the page number in the URL. The latter can be as simple as adding a page parameter: https://yoursite.com/list.php?page=123

Yes, this is hideous code, because your dynamic parameters are neither URL-encoded nor HTML-escaped (what if they contain special characters?), and the parts you did escape are escaped by hand instead of using the appropriate PHP function. Every dynamic value that goes into your HTML markup must be HTML-escaped. If you don't do that, then you're begging for syntax errors and cross-site scripting attacks. Depending on the context, you may need additional preparation. For example, URL parameters must be URL-encoded. It's very important to understand this: You can't just dump a PHP string into an arbitrary context. Many PHP developers struggle with this simple truth, but it's crucial for writing correct and secure applications. In your case, you would encode the parameters with urlencode() and then escape the entire URL with htmlspecialchars(). You can also let PHP do the URL-encoding if you use http_build_query(): $parameters = array( 'cname' => $cname, 'pcaption' => $caption_array[$next], ); $result_final .= '<a href="' . html_escape('viewgallery.php?' . http_build_query($parameters), 'UTF-8') . '"><img src="/photos/assets/left.png" alt="left navigation"></a>'; Mixing small snippets of HTML markup into your PHP code (aka spaghetti code) also isn't the best idea, but that's another story.

What does this have to do with HTML? This is clearly a PHP problem. You said you don't retrieve the $username variable. My guess is that the code was written a long time ago when the register_globals setting was still around. Back in those days, the PHP core developers thought it's a good idea to automatically create variables from input parameters. For example, if the script was executed with a form parameter called “username”, then PHP would automatically create a $username variable. This quickly turned out to be a major security vulnerability (see the link), so the whole feature was deprecated in 2009 and removed in 2012. But appearently it lives on in your code. Define your variables properly, and the problem will go away.

Who said that? Whether or not short tags can be used depends on the short_open_tag setting. Appearently it's activated on your Mac, but it's not activated on your Windows PC. So either activate it on Windows as well, or simply remove all short tags to solve this problem once and for all.

You have to quote the entire attribute. Like this: <a href="https://yoursite.com/foo">some link</a> Using unquoted attributes is generally a very bad idea. Apart from the syntax errors, you'll also run into security issues as soon as you start using dynamic parameters. So always quote your attributes. What the W3C validator actually complained about were the ampersand (&) characters. Since the ampersand is also used to start an HTML entity like ", the parser does not always know if you mean a literal ampersand or an ampersand as part of an HTML entity. The general recommendation is encode all literal ampersands with the & entity: <a href="https://yoursite.com/foo?x=1&y=2">some link</a>

PHP 4? Are you serious? Then appearently you haven't updated your XAMPP since 10 years. It's about time.

So? Does that mean you should take the wrong approach? Of course you're free to spend the next few weeks on an incorrect concept and then throw everything away and start from scratch. If you think that's a useful learning experience, go ahead. But if you want to save time, you should fix your mistakes now and not build a whole application on top of them.

That mysql class is no standard PHP functionality. It's a custom class which you need to include in your code.

Of course it does. If you want to allow p elements outside of tables, you need to do more work: You have to actually parse the markup and then accept or reject tags depending on the context. But what's the point of this complicated logic?

The author himself actually warns you that the code is full of security issues, the comments make it very clear that the whole tutorial is bullshit, and the text is more than 5 years old. Why on earth would you pick that tutorial? What do you expect to learn? How to write crap code?

Do not use strip_tags(). This function mangles the user input based on a very primitive mechanism. If you're lucky, it will only remove the parts you want to remove. But chances are it will cut off the input somewhere, either because the markup is invalid, or because the function is simply too stupid to understand the markup. Why strip_tags() is still around and gets recommended is beyond me. Do yourself a favor and use a proper filter like HTML Purifier.

It's great that you're using a proper database, but it's not really a good idea to copy and paste random code you found somewhere on the Internet. The code is pretty much the worst you can get; it's out of date since at least a decade, and now you indeed have no security whatsoever. Write your own code. I know it's tedious and time-consuming, but that's simply how programming works. Create a table for all the information you need, and then use PDO to insert your data. It's no rocket science. The “funny” thing is that it's actually fairly easy to attack a local application without direct access to the network itself. It's enough that you have access and use the Internet on the same machine. For example, the local user interface of many routers used to be vulnerable to cross-site request forgery: The attackers didn't need access to the interface, they simply made the victim (or the victim's browser) take action on their behalf. I don't know whether or not this applies in your case as well, and that's not the topic. My point is simply that secure and robust code is not only about protecting some public website from evil hackers. You may very well need it on your local network as well. The only theoretical exception is when you have an entirely isolated network which isn't connected to the Internet in any way.

I'm not talking about a multi-user upload. You have the exact same problem if you upload multiple files, use tabbed browsing or whatever. Any situation which results in two uploads in quick succession can break your system. The belief that private applications don't need any security is also somewhat problematic. First of all, who says the application is actually private? Is it online? Are you sure that your authentication layer is absolutely perfect? Secondly, a lot of the things which people call “security” is much more than that. It's about making sure that the application works correctly under all circumstances. This is needed in any case, regardless of whether the application is used by you, your friends or the whole world. So we have no database and no ambition? Then I'd use a synchronized counter: <?php ini_set('display_errors', 1); $filename = null; $counter_path = '/path/to/counter'; $counter_fp = fopen($counter_path, 'r+'); if ($counter_fp) { if (flock($counter_fp, LOCK_EX)) { // read current value $current_index = fread($counter_fp, filesize($counter_path)); // increment counter ftruncate($counter_fp, 0); rewind($counter_fp); if (fwrite($counter_fp, $current_index + 1)) { $filename = $current_index; } else { trigger_error('Failed to increment counter.'); } flock($counter_fp, LOCK_UN); } else { trigger_error('Failed to lock counter file.'); } fclose($counter_fp); } else { trigger_error('Failed to open counter file.'); } if ($filename) { // now we can use the counter value } Like I said, it's a PITA. And if anything goes wrong when the counter is incremented, we lose the value entirely.

That's no excuse for bad code, is it? Like I said: random numbers. This is a PITA if done correctly. It's not enough to simply increment some counter. You also have to synchronize file access to that simultaneous uploads don't read the same counter value and overwrite each other.

We've already discussed this problem dozens of times, the last thread is just a few items below yours. I generally recommend random filenames, because they're foolproof and don't expose the upload behaviour of your users. However, if you insist on numbering the files, you should use an AUTO_INCREMENT column in your database. You'll have to store the original filename, anyway. So insert the metadata of the file into your database, retrieve the ID of the inserted row and use that as the filename. Besides this, your code has some major security issues. You check the MIME type in the $_FILES array, but this information comes from the user and can be anything they want. For example, I could upload a malicious PHP script, declare it as a JPEG image, and you would happily accept it. Checking the file type actually doesn't protect you at all, because even a perfectly valid image may very well contain malicious code. What matters is how the file is interpreted. As long as your webserver treats the file as an image, you're safe, no matter what the actual file content is. However, if that same file is treated as a script (due to a “.php” extension, for example), it may suddenly turn into malware and attack your server. So that's what you need to worry about. Never accept the user-provided file extension. Always set the extension yourself. Make sure there's only one extension. Turn off script execution in the upload folder.

Not really. There's a reason why I specifically advised against this approach. Printing the raw MySQL error message on the screen is a very bad idea. Not only does this leak internal information about your database system; it's also completely pointless, because the user cannot do anything useful with the information. I mean, what is an end user supposed to do with some internal MySQL error? They cannot fix it, can they? The MySQL messages are meant for you, the database administrator. When I take a closer look at your code, this all looks very dubious. So you hand out database admin accounts to other people and let them create their own database? Why would you do that? This is a major security risk and, again, absolutely pointless. You need one database. It seems you're repeating the same mistake that you already made at the beginning of the project: At first, you wanted to literally create a new folder for each user. When that turned out to be a bad idea, you've somehow decided to try the same thing with databases. That's just not how web applications work. You have one application with one database which holds all the user data. Your application may then render personalized content to create the illusion of separate user pages. But physically, it's just one application with one database. It might be a good idea to start with a smaller project and get familiar with the basics before you jump to the advanced stuff. For example, create a simple registration system which allows people to register, log-in and then view their personal information of a profile page.

Whatever caused this, the point is that you need to add some kind of error reporting to your code. There are two options: You can use the old way of manually checking the return value of every single function call. This is tedious as hell and will bloat your code beyond recognition. MySQLi can do the error reporting itself. I strongly recommend the second solution. All you need to do is activate error reporting in the MySQLi driver: $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; This makes MySQLi throw an exception whenever a query fails. So instead of getting some cryptic error message when you try to fetch from a failed query, you now get the actual MySQL error, and the script terminates immediately.

What's a “raw symbol”? Anyway, my guess is that you forgot to declare the character encoding of the database connection. In that case, MySQL will use the default encoding from the configuration which can differ accross systems. How the encoding is declared depends on the database interface you use. If you're still using the ancient mysql_* functions, it's mysql_set_charset(). If you're using MySQLi, it's mysqli_set_charset(). If you're using PDO, it's the charset parameter of the DSN string. Do not change the encoding with a SET NAMES query. While many people suggest this, it's very wrong, because it doesn't update the encoding information of the MySQL API and can break critical functions like mysql_real_escape_string().

What's the purpose of this log? I mean, what's the information you're trying to get out of it? You won't find a lot of users who have turned off JavaScript altogether, because large parts of the WWW simply require JavaScript. What's much more common is to specifically choose the domains that are allowed to provide JavaScript code (using a browser plug-in like NoScript, for example). So while JavaScript is generally turned on, some scripts on your site may still be blocked. How do you deal with that? For example, if I were to visit your site, all scripts would be disabled by default. However, I might then whitelist your main domain so that I can use the site properly. Does this count as “no JavaScript” or not? Also note that NoScript can block iframes as well.

This is neither a special feature nor does it have anything to do with inheritance. The code simply stores a Battery object in a property of a Device object. In other words, a device has a battery and may interact with it (draw energy from it etc.). This is very different from inheritance. If you make Device a subclass of Battery, then you're saying that a device is a battery. That obviously doesn't make a lot of sense. A device may have a battery as one of its components, but it certainly doesn't have the behaviour and purpose of a battery. Since this isn't inheritance, it certainly won't help you implement inheritance with multiple parent classes. If that's your goal, you should have a look at Traits.