curtis

moejoe22 hit the nail on the head. Get rid of your last elseif, and test if $error contains anything separately: Indenting statements inside blocks helps improve readability... <?php $error = ''; if(!$username) { $error = "Please enter a username!"; } elseif(!$password) { $error = "Please enter a password!"; } elseif($username != $row['username']) { $error = "Please enter a valid username!"; } elseif($encrypted_password != $row['password']) { $error = "That password is incorrect!"; } // now check for errors if (!empty($error)) echo $error; ?> Like mojoe22 said, only one branch will execute, this is not a switch statement (without a break). Therefore, there is no reason to concatenate. The first branch found to be true will be executed, and then execution moves past the rest of the branches. An alternative approach would be setting up some error flags that hold bit masks, which would be a pretty easy way to test for multiple errors.

Sorry, it seems the permissions are set up to allow reg. users to edit posts for a limited time.

No, it was my mistake, you're absolutely right. The only times I've tried this, I happened to be working with standards conforming documents. Obviously, that's a rare luxury with (X)HTML. Sorry about that. There are a couple possibilities here, in order to prevent reinventing the wheel. One is to use the PEAR package, HTML_Common2, which utilizes PHP 5 OOP. The PHP 4 version is available, but not recommended. I briefly looked at some of the class members, and they seem to be using regex as well. At the very least, when writing complicated regexes, I prefer to use the /x modifier to allow whitespace and comments, because they are much easier to maintain that way. Also, there's a PECL extension called html_parse, which seems a better solution for handling HTML, but at the cost of some portability.

Showing your absolute path shouldn't be too big a security issue. Presumably, you aren't going to keep it there permanently, but in any case, I edited it out. As for what's next, I'm quite tired at the moment, so I think I'm going to turn in for now. I just saw you posted the "old" version. I like it much better, for the simple fact that it doesn't use frames. It still has problems that gevans mentioned about your original posting, though. Also, you define the variable for output, but it never does get echo'd later in the script. To be honest, all this seems to be the tip of the ice berg, IMO. If you have the time and desire, you'll want to absorb a lot of tutorials and practice coding. Otherwise, maybe consider contracting a PHP developer. Good luck.

I edited my previous post with a suggestion to try phpinfo(). It seems $sidebar is undefined when you try and echo it out in the frame tag. It doesn't seem like that should be the case, from your code. Did you post the exact code with which you're working? Also, did you make all the changes suggested in gevans' initial post? It contains some important improvements, one of the most important being the use of mysql_real_escape_string() to prevent SQL injection attacks. Since the variable is undefined, you're not getting a valid resource. OT here, but configure your server to serve error pages for the various HTTP errors. There is an Apache forum for specifically dealing with Apache configuration issues.

Your error is my fault (sorry, been a while since I've used that function). It should be "ini_set". Edit: also, to find out more about your server's PHP installation, create a file somewhere not obvious, and in it, put only this: <?php phpinfo(); ?> Run the script, and carefully look it over. It should also tell you which php.ini you are using, and where it is.

If PHP is not logging or displaying errors, you will need access to php.ini (preferred), or try to change the settings during runtime: <?php // at the top of your script - this may not work, depending on how PHP's configured set_ini('display_errors', 'On'); error_reporting(E_ALL | E_STRICT); ... ?> Try running script and see if you get any errors. If you are trying to debug on a live server, either test locally, or make a copy of your necessary files (the script and those included) and move them to an alternate directory; make sure the paths point to the proper files.

There are no syntax errors in the code you showed (doing a lint check). However, there may be errors during run-time and/or errors in your included files. Make sure to check your PHP error logs, and that PHP is indeed logging errors. In your development environment, it's helpful to use these settings in php.ini: display_errors = On error_reporting = E_ALL | E_STRICT

If you want to parse HTML, use the DOM, not regex. PHP DOM Manual DOM XPath docs

That shouldn't be necessary, unless the need arises to handle things like authentication, cookies, or SSL.

You might try breaking the problem down into smaller parts to get a better idea of where to start. Here's an idea for a specific spec. [*]Get a URL to search from the user. [*]Search data at the URL. [*]Search for URI patterns. [*]Store each URI. A tip: at this point, you should check if an entry already exists.

What you're asking isn't quite making sense to me, but if I think I understand you right: <?php $list = array('Jeff', 6, 6); // strings equal 6 if ($string1 == '6' && $string2 == '6') { // do stuff with array } ?> You might want to consult some basic programming tutorials to learn things like boolean comparisons, among other things...

Using the responseXML property can be useful for data (usually a larger amount than when using responseText) that needs to maintain its structure. You could always get the swiss army knife out on the string, but it's can be less efficient programming. In many cases, using responseXML is just more readable as well. 448191, it'd save you some typing if you stopped using the item method. Concerning the updates var you used in your loop, you could've just used [b]updates[ i ][/b] rather than [b]updates.item(i)[/b]. The latter method is deprecated, if I'm not mistaken. It's just my style to save space, especially in JavaScript, so feel free to disregard. ;)