requinix

With just ->item, SimpleXML will always get the first element named "item". Use $xmlappend->addChild to create a new item each time, put that in a variable, and add the title and URL to that.

Go for an MP4 (which is just a "container" for stuff) using H.264 video and AAC or MP3 audio. Not sure how you did the conversion but make sure you're converting to those formats. Could be you converted without audio, or to an audio codec not supported by WMP or the browser. Is the MOV (preferably) or MP4 (to see what's wrong) online somewhere we can see? Very wrong.

Is this not something you can just do manually? Not many good reasons why you should be able to execute arbitrary SQL files on a regular basis. Fewer that require you to use PHP instead of, say, a cronjob.

The firstColor is inside the color array which is inside the $m_array array. $m_array["color"]["firstColor"]

There is an easier way: make sure the tag column is unique and do an INSERT IGNORE with all the tags at once. INSERT IGNORE INTO blogTags (tag) VALUES ("tag1", "tag2", "tag3")which will be easier to do without prepared statements.

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

mysqli_query("$conn, $deleteQuery, ");Not sure why those quotes are there, but they shouldn't be.

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

Simply accessing a non-existent property will not fatal code unless (a) access goes through __get which fatals by itself or (b) you try to do certain types of actions with that value, such as call a method on it. Your live website should keep those 500 errors in place: displaying error messages to the user is not a good thing. Instead, check your error log, be that the Apache log or a dedicated PHP error log.

I was saying that because of: (your application doesn't know the columns in the table so it has to query the metadata for them) (you say you're copying tables) (creating tables) ("many tables" and you're copying them around) (tables are changing schema on a regular basis)

My first reaction is "Why are you creating so many tables?", followed by "Why doesn't your application know the table structures already?"

Like a regular user. It is impossible to tell if a request comes from a real person.

1. You can start at $i=3 and skip even numbers. 2. You can stop at sqrt($num). 3. Make your function return true/false instead of outputting a string. 4. There's absolutely no need to keep track of all those $numbers: if it's divisible by $i then false, and make it return true after the loop finishes. 5. Research other methods of determining primes.