requinix

Purple?

What's your full code so far? What have you tried? How did it not work?

You can't put BRs between table cells like that. The browser has to try to deal with the invalid markup you've given it, and it apparently does so by interpreting those as being placed before the table.

Just because it uses the same = symbol doesn't mean it works the same way. That does not make sense. Rewrite the expression in terms of X alone. Meaning you have to end up at X = ....

GoDaddy has nothing to do with that, and if you move then you'll still have that same problem. It has to do with your stuff. Two different things. Can't have a CDN without a backend host, in one form or another. CDNs are about distributing static content by using lots of servers scattered around the world, each with a copy of the files you're trying to serve. With servers closer to the users, yes that means lower latency. A place like the PHP Freaks forums cannot use a CDN for the threads and posts and such because that isn't static, but it can use one for the CSS and images and other files that its pages need that don't change often. No one guarantees 100% uptime. What they will guarantee, if anything, is a certain number of "9s". For example, "five 9s" means 99.999% (which is about 25 seconds of downtime per month, on average).

They do have permissions, it seems you're just not able to see them. (Must be that the FTP server or client just doesn't want to show you.) Unless you're saying they have permissions 0000, which is a very bad thing. PHP is running as a different user than you, meaning when it creates files and folders they will have a different owner (but likely still 0644/0755). That's something for you to keep in mind: - If the uploads folder was created by PHP then you (via FTP) will not be able to delete or rename or otherwise affect files within that folder... unless you modify the permissions of the files/folder within PHP. But you probably don't need to do that. - If you created the uploads folder then it'll need to be 0777 so that PHP (which is subject to the "other" permission set) can put files in there.

Not really. If you wanted better security then you should actually move to a dedicated box - so there aren't other, untrusted users on the same machine. But you probably don't need the added security. As a test of something, do a file upload through PHP and place the file wherever. This can just be a little test script you write quickly. When you look at the file through FTP, what user and group does it belong to?

It should already be set up so that everything you create via FTP is owned by you and your group, files are created 0644, and folders are 0755. If you create things via PHP, which includes doing file uploads, then it will be a little different.

If it's a shared server, as in shared hosting that you get from some company online, then you don't do anything. The hosting company manages it.

Don't make it more complicated than it needs to be. Add a column to whatever table you're using to hold the HTML-ready version, alongside the raw BBCode version. Yes, it doubles disk space, but disk space is cheap and plentiful while your time is not.

Your taught your computer that application/force-download type is a "Wave Sound". The thing that triggers the download is the Content-Disposition header, so leave the Content-Type with the right value. Unfortunately that varies by file, and you probably aren't recording it anywhere accessible. You should install something like fileinfo in order to get the type based on the file contents (your only recourse), but if that's not an option, header("Content-Type: application/octet-stream");the application/octet-stream type is your best option because it has an official meaning, unlike application/force-download (which someone simply made up).

Why go through GD? 1. Make a 1x1 transparent pixel in MS Paint or whatever, save as GIF for the small size. 2. Do echo base64_encode(file_get_contents("/path/to/pixel.gif")) and copy that. 3. Paste it in code as header("Content-Type: image/gif"); echo base64_decode("base64 encoded stuff here");

Not sure what to say. Looks like you're doing everything right and IE is pulling the underscore out of nowhere... It still has the underscore when you save the file, right? Tried another browser?

$_GET won't do that. Which is an array, by the way, not a function. You need two functions: rawurlencode and htmlspecialchars(). Applied to $file in that order. And htmlspecialchars() alone for the second $file. echo " ", htmlspecialchars($file, ENT_QUOTES), " ";That's because the filename is going into a URL, and you're putting that URL within HTML. When the browser figures out what to do when you click the link, it will HTML-decode the URL first (because it's in HTML) and then verify it is an acceptable URL (and if not, URL-encode it automatically because it's nice like that). In download.php you only look in $_GET: there will be no HTML encoding and the URL decoding happened earlier (since, being in a URL, PHP knew it must necessarily happen at some point anyways).

PHP_SELF contains a portion of the URL that is pretty much exactly as the user entered it in their browser. Most of the time someone can enter in something you didn't expect and still execute your script. For example, "script.php" may be triggered with "script/foo/bar": the web server sees "script", realizes there's a matching file "script.php", and then executes it.

Nah, I sighed because this question comes up a lot but it's not the easiest thing to Google for. Problem is the symptoms vary, like broken links or losing form data. And just given those symptoms it's not necessarily obvious what's wrong, and the first place you'd check (the PHP code) isn't actually where the true problem is. Just one of those things where you know the answer from experience, not from raw PHP knowledge.

(sigh) You should always put quotes around attributes in HTML. If you don't do that then spaces will mess it up and you'll lose stuff. Also, PHP_SELF is not safe to use unless you wrap it in a function like htmlspecialchars(). echo "<form method='post' action='"?><?php echo htmlspecialchars($_SERVER['PHP_SELF']).'?delete=true&recordid='.$doc_folder.'&deletefile='.$file;?> <?php echo"' ><a href='/pages/download.php?file=$file'> $file </a> <input type='submit' value='delete'></form>";And what's with your opening and closing tags? You've gone crazy with them.

It's not that simple. What type of applications? Employment in what field? Java is a little more flexible than C++ in that regard (at least not without using assorted frameworks) but people don't use it for "normal" programs anymore.

Why do you want to learn it? Java is more common for web development and helps for Android, C/C++ teaches you a lot about how software works at a lower level.

The site you PMed me is behaving exactly like your original rewriting rules are still in place. What's in your .htaccess now?

You'd have to change the first RewriteCond to check if the HTTPS flag is off, but otherwise yes. Only a couple more days? Might as well wait. And when you do the switch you can enable HSTS too. - HTTP Strict Transport Security - OWASP

RewriteCond %{HTTP_HOST} !^https://www.example.com.au$ [NC]That will never match. The HTTP_HOST is literally just the hostname. You need to check the "HTTPS" flag separately. Redirect https to http, for some crazy reason, as well as no-www to www? RewriteCond %{HTTPS} =on [OR] RewriteCond %{HTTP_HOST} !=www.example.com.au RewriteRule ^ http://www.example.com.au%{REQUEST_URI} [L,R]

So now either you find a new hosting company, upgrade to dedicated hosting (where you can control the server and install your own software on it), or don't convert files.

ffmpeg has nothing to do with PHP or GD, the latter of which is a library and not an application, but your conclusion is correct.

You can get ffmpeg as a PHP extension to bridge the gap, but you aren't going to find something purely PHP to do this.