requinix

allow_url_include is unsafe and should never be used; allow_url_fopen is the "safe" one that should be enabled. Just to put that out there. Using something to automatically update (via FTP or whatever) is the best option, but it can take a while to set up a good system. Short of that, my suggestion is to "copy" the CMS for each client, but for the files that you want shared what you actually copy are a bunch of links* pointing back to the originals. Thus you can keep include()ing the same files. When you need to customize files you remove the links, copy the files, and make your changes. You need to make sure file permissions are set up on the originals so that anybody can read them - that could be the problem you have now. 0644 on regular files, 0755 on directories. * Symbolic. There's a chance that PHP will realize they're symbolic and take special actions (I don't know but I wouldn't expect it); those actions may screw up the whole idea, in which case you'd need hardlinks instead.

What do you get if you print out $query?

With PHP there are many, many ways of doing something. Narrow it down to the methods that actually work and are safe (feel free to ask for help on that part) then pick the one you like best.

dirname() will only work in some of the situations. For example, it won't work with URLs like "/path/to/file.php?query_string". strtok(), or some similar method, will work on every URL.

So update $nwhatever every time it gets adjusted in the database. That way you don't have to keep looking it up.

bin2hex Spoiler: "octet" was the right term.

Maybe a description of the problem you're having?

Maybe all you want to do is round the number?

Don't use gmdate() - just the regular date(). gmdate() formats time according to the GMT timezone. strtotime() parses time according to the current timezone. If they aren't the same then you might end up going backwards in time...

Maybe. Does it do what you want? If not then what URL are you redirecting to what URL?

$naqahdah = $naqahdah - $cost_homes;

Use strtok on the REQUEST_URI: strtok($_SERVER["REQUEST_URI"], "?")

1. Does your server have mod_rewrite enabled? 2a. How do you know it doesn't work? Are admin.php and index.php not running at all, or are they not running correctly? 2b. Could it be that admin.php wants the page name without the "a/" path?

To keep the original httpd.conf as "clean" as possible, create another .conf file for settings that you add. Near the end of httpd.conf is a bunch of Include directives: put another one at the end for your new .conf. Inside that new file put the ProxyPass I posted, then reload/restart Apache.

Just use INI files and parse_ini_file. Don't do any PHP-code nonsense when there's a much simpler solution that's actually geared towards this exact use case anyways.

RewriteConds and (a single) RewriteRule go together as a set. If you want a more specific rule than "everything goes through index.php" then add another set of Conds+Rule before the generic rule.

GIMP can't open websites. Your question doesn't make sense.

SELECT 1 FROM pm WHERE id = user ID AND read = "unread" LIMIT 1 If you get any rows back at all then there is at least one unread message.

The arrays wouldn't be empty - there would be no arrays at all. $lat and $long are only defined if the loop runs, and if there aren't any matching $ids in the database then the loop will not run...

1. That's hashing, not encryption. 2. Actually it would hash "1234password1234". Remove the ",0" in the second call to substr() to fix that.

You can use iconv() or the mbstring extension to convert between text encodings. Get the strings from the RSS feed, as you normally would, but convert them to UTF-8 before you do anything else.

That output you posted looks like it was UTF-8 encoded twice. Okay. The RSS feed is probably in UTF-8 form. As long as your HTML output is also UTF-8, whether that's through a header header("Content-Type: text/html; charset=utf-8"); or a META tag you shouldn't need to do anything else with the text. Problems arise when the input and output aren't in the same encoding, or something tries to change the encoding of the data while it's in transit (such as a utf8_encode() when it's not needed). So theoretically, all you need is to have the RSS's encoding match the HTML page's encoding. Separately, don't use htmlentities() for that STORE_XML_RSS_FILE. It's only needed when outputting to HTML. It's unlikely that the URL would contain anything that would be entity-ized (as it would be an invalid URL to begin with) but still, isn't needed. And a slight correction to something Dan said earlier. ...Kinda. The whole thing was a bit vague. When putting text into RSS use htmlspecialchars, not htmlentities(). The difference is that the latter will try to encode some characters into HTML entities, but XML does not support those same entities. That is, things like "é" in XML are generally invalid. The former will only encode the characters that are strictly necessary: ampersands, less-thans, greater-thans, and double quotes. Plain XML only supports those four and numeric entities (like {). After that's right, if you have problems then you need to deal with character encoding. That's specified in the

Try LEFT...

Drop that extra equals sign and add a "url=": echo ""; Also know that it's entirely up to the browser whether it'll refresh the page or not (but most do).

You didn't put any quotes around the email.