requinix

You can't tell us where the problem is or what function is causing it, and you haven't given us what we need to reproduce the problem on our ends. It should not be surprising that we can't tell you what the solution is.

jQuery's click() adds event handlers. Every time you call that you add a new event handler. When onclick happens every one of those will be executed.

So this isn't resolved then? What version of PHP are you using? Oh, and find out where the problem is exactly.

The problem is you keep adding onclick handlers. Yes, adding. You aren't replacing the one set previously. Add the handler only once and do so outside of whose_turn(). Don't have to do anything else with it.

Right. I just focused on the user input side of things. Still have to escape it for the query, still have to escape it during output - same as always.

preg_replace() isn't doing it. Have you checked what $template is before this tag replacing runs? What are the various $keys and $values?

A partial upload. There's an error code for that.

Which function is causing the problem? getimagesize()? Historically it's had a couple problems dealing with very tiny files.

No security reason. Valid reasons could include length (don't want 1000-character-long tooltips) and cleanliness (HTML tags wouldn't look pretty).

parse_url followed by parse_str. No regex needed.

Are you basically just counting characters? We need to know more.

Anything in Apache's error logs?

I'm saying that the minimizing will break code like function update(v) { document.getElementById('id').value = v document.getElementById('other').value = v } as well as styles like body p { text-decoration: blink; } style="border: 2px solid blue"

Your $sql assumes that there should be quotes around $isin (the general case). Remove those. $isin may need quotes around its value (the specific case). Add them if it should have them. As in $isin = "'" . $user_isin . "'"; But $user_isin is a string, right? Not a number? If it is a number then it shouldn't have quotes at all.

Two different errors. 1. What's at the very beginning of the themes/news/functions.php file? There's something that PHP is outputting - perhaps a UTF-8 bom, or perhaps whitespace before the <?php tag. 2. Does that tmp folder exist on the new machine? If not then create it and set 0777 permissions on it.

Use DOM to rewrite the HTML. It's not just textareas you have to treat specially: there's scripts, styles, and PREs for starters. And inline CSS is worth mentioning. Oh, and you're removing \s\s+? So if I type two spaces and/or newlines somewhere they're both lost?

Remove the quotes from the general case, add them in the specific case.

It's not permissions. You're mixing up two different but related concepts: file paths and URL paths. Quick primer: File paths are paths to actual files as they are on your computer. Using Windows as the best example of their differences, C:\Windows is a file path. In PHP you use file paths whenever you deal with include()ing scripts. URL paths are in URLs. Like right now I'm at /forums/index.php on the www.phpfreaks.com website. The relationship is about how the web server turns a URL into a file. "/forums/index.php" might translate into "C:\inetpub\phpfreaks\forums\index.php". You also can't confuse the two: I couldn't go to "www.phpfreaks.com/C:/inetpub/phpfreaks/forums/index.php", and in the code I couldn't include "http://www.phpfreaks.com/forums/index.php"; With that out of the way do you understand the problem? Because the DOCUMENT_ROOT is a file path, not a URL path.

Er yeah, expense. It depends what validateUploadedPhoto() actually does. Query the database? Since you have to do a query to get the photos in the first place, why not check then? Re: Unprofessional: This is the Internet. Shit happens. As long as you deal with it appropriately (right response soon enough) and had implemented something sufficient to do so then you're forgiven. Of course that's just the general case. Overkill: You implement this pre-moderation system only to find out that 99.99% of images uploaded are safe. Sure you catch one bad image in 10,000 but how much time did you spend approving the other 9,999? Alienate: If I'm using your site and discover that not only my photos have to be approved but it takes hours to do so then I probably won't use it. There are plenty of other sites I can go to instead. Flag: How else will you know if a photo is approved? In the time between the upload and the approval the image has to be stored somewhere, and since the only difference between "new" and "approved" is, well, whether it's approved, why not reuse the same mechanism and extend it just a little bit to have that flag?

Easiest change: Add an "approved" flag to the photos table which indicates what it sounds like it indicates. You might want one on the users table too: if a user is approved then their uploads are automatically approved (lets you skip moderation of people who have shown themselves to be trustworthy). But then you'd need some kind of "report" functionality. Then do the uploads like normal. When it comes time to show an image, if approved then you do as normal, and if not then you handle it differently. Personally I would just deny that the image exists in the first place, but otherwise you could use a placeholder image and some brief "Awaiting approval" message. But before you go on with this, consider what is actually necessary. How worried are you that people will upload inappropriate images? If they do, what happens? If there's little chance or little fallout then a pre-moderation system might be overkill and a reporting system would be all you'd need. How many photos will be uploaded in an hour? Do you have enough people to handle the approval process? Quickly enough to not alienate your users? If not then you can let users find the bad ones. How about user moderation? Basically every site driven by a community includes some form of user moderation system, ranging from simple user/superuser flags to multi-level hierarchies.

Just to be sure, what's the code around that call to file_exists()?

Have you considered setting up VirtualHosts for each of those sites? Then you wouldn't have to worry about paths.

First step is finding out who is saying where the site is. On an affected machine, 1. Who are the DNS servers? 2. If you do an nslookup -type=all www.sitename.com, what results do you get? 3. If you clear the cache (and verify that it's been cleared) and ping www.sitename.com, what IP address does it use?

It should prevent many forms, but there are some it won't. It depends where you output the strings. Pretty much all you need is htmlentities() or htmlspecialchars().

So no on a billion lines of code. How about just two? UPDATE friend SET requestor_approved = 1 WHERE requestor = current user AND requestee = other user UPDATE friend SET requestee_approved = 1 WHERE requestor = other user AND requestee = current user