KevinM1

What stack? HTTP is stateless, meaning each time you visit the script it's a new script.

well that doesn't seem to be what he's doing here... True, but I figured the caveat should still be mentioned. It's one of those gotchas that often gets people asking "It worked there, why doesn't it work here?"

The document.write() version is dangerous, as any document.write() invoked after the page is finished loading will create a new document in place of the loaded page, thereby nuking what you had.

Could be due to a JavaScript race condition. JavaScript loads fast, faster than the generated HTML. Placing the buttons above the gallery could be causing the error as your showgallery() functions are being hooked up to divs that may not exist when the script first loads. Element position does matter to JavaScript. That's why the first step for good script writing is to always wait for the entire DOM to load first. Try placing your script at the bottom of your markup. Barring that, show your generated HTML. Also, as a general tip, I strongly suggest you clean up your overall code structure. Mashing PHP processing with output and JavaScript generation is the road to heartbreak. Well-formed PHP apps follow the general pattern of: All PHP processing first, where results are stored in variables -> Markup, with a minimal amount of PHP to display those results (if/else statements and loops should be the extent of the logic used for display). JavaScript should be written in an unobtrusive manner. By separating back end logic from markup from presentation logic, you make your code easier to work with, maintain, edit, and debug. It's how the pros do it. It will certainly make the lives of those you ask for help from easier.

Over to what? I think you're confusing variables in the global namespace (which was, until very recently, the de facto namespace for everything in PHP) and the use of the 'global' keyword. Pass variables into functions through their argument lists, and take care that they are defined (read: have a value) before attempting to use them.

Shouldn't it be "SELECT ... `Password`... " ?? Your db columns are lowercase in your query, but you capitalize it in your if-conditional. Looks like a simple typo to me.

Not so weird. Think about it - there's more than one of these viruses in the wild, right? Depending on how they do their job (simple keylogger? something more sophisticated?), they're all going to be sending back a not insignificant amount of data. Sifting through and testing the accumulated data takes time.

Don't call the function unless you have an error. A simple if-conditional should do the trick: if (isset($errorId)) { displayError($errorId); }

Yup. You should have: $phone = $_POST['phone']; You should validate it as well. A regex should do the trick. EDIT: Just a quick word about form inputs and how they work with PHP - Input values are stored in one of two superglobal arrays - $_GET or $_POST (there's also a catch-all $_REQUEST, but that's sloppy and potentially dangerous to use). Which array is used depends on what method your HTML form will use. $_GET for get, $_POST for post. When you want to access a form value, you do it by accessing the superglobal array with the name of the form input you want to retrieve. So, $_POST['phone'] assumes that your form used the post method and had an input with the name of phone.

Replace your first code snippet with the following. Take note of what I do to $message, and how that matches what I said two posts ago. <?php error_reporting(E_ALL ^ E_NOTICE); include 'config.php'; $post = (!empty($_POST)) ? true : false; if($post) { include 'functions.php'; $name = stripslashes($_POST['contactname']); $email = trim($_POST['email']); $error = ''; // Check name if(!name) { $error .= 'Please enter your name.<br />'; } // Check email if(!$email) { $error .= 'Please enter an e-mail address.<br />'; } if($email && !ValidateEmail($email)) { $error .= 'Please enter a valid e-mail address.<br />'; } // Check message (length) if(!$message || strlen($message) < 15) { $error .= "Please enter your message. It should have at least 15 characters.<br />"; } if(!$error) { $subject = "New Message"; $message = stripslashes($_POST['message']); $message .= "\n\n"; $message .= "Customer Phone Number is " . $phone; $mail = mail(WEBMASTER_EMAIL, $subject, $message, "From: ".$name." <".$email.">\r\n" ."Reply-To: ".$email."\r\n" ."X-Mailer: PHP/" . phpversion()); if($mail) { echo 'OK'; } } else { echo '<div class="notification_error">'.$error.'</div>'; } } ?> Also, where does $phone come from? Right now, you don't have any values being placed in that variable. Do you have a corresponding HTML form field for the phone number? If so, you need to grab a hold of that value in your script.

Show all of your current code.

$message = "Customer Phone Number is:" .phone; Should be: $message .= "Customer Phone Number is: " . $phone; Why? 1. The '$' denotes a variable. Without it, PHP thinks that you have a named constant titled 'phone' that you're trying to add to your $message string. 2. The '.' is the string concatenation operator. It simply adds whatever value is to the right to the string on the left. Think of it like addition. 3. The '=' is the assignment operator. It takes the value on the right of it and assigns it to the variable on the left. 4. '.=' is a shorthand concatenation and assignment operator. You could rewrite your statement as: $message = $message . "Customer Phone Number is " . $phone; They're equivalent statements. The shorthand is used because, well, it's shorter. EDIT: So, what was the bad statement I corrected doing? Since you were using the normal assignment operator rather than the shorthand, you were simply overwriting your $message with that statement. However, your message still won't validate as you add your own strings to it before checking to see if a message exists at all, or if it's the right length. Do the check first, then add your text.

To be honest, your site needs a lot of work. First, there's no visual structure to it. I don't know if it's intentional, or if you just haven't gotten around to it, but it looks incomplete at the moment. Visitors will want more than just text and unordered lists. If someone registers with your site, why should they need to login with both their username and email address? Pick one or the other. If someone logs into the system, don't bring them immediately to an order page. Instead, return them to the page they were on when they signed in. Users don't want to be forced into purchasing something just for signing in. Your products should have images. Your entire commerce logic needs work. You should have a cart where customers can add and remove items. This cart should persist even if they log out. Realistically, a dropdown list of products to choose from is too limiting. First, you're likely going to have an unwieldy number of products to choose from once the site is done. Second, you're going to have customers who will want to order several different products at once. You need to look at how real e-commerce sites get it done. A small thing - your order form has an "Agree to terms" check box. What terms? Like I said before, take a look at how other sites do things, and really sit down and plan how to do it yourself. It's a lot of work, but necessary if you want paying customers. As it stands now, I can't imagine anyone willing to spend money on your site.

I assume so, given the forum he's on.

http://lmgtfy.com/?q=php+user+accounts

You'll need multiple tables. At least one for users and one for job listings. The job listings table would have the users table's id column as a foreign key value, thereby allowing any number of job listings per user.

I just wanted to say that this thread is great as a "My first professional web app" case study. It should be stickied and pointed to whenever someone asks about what to consider in terms of db construction, project management, and the like. Also: jQuery is a JavaScript framework that has absolutely nothing to do with database queries, or the database at all, for that matter. It's a minor thing, but I didn't see anyone correct it.

Your greatest amount of focus should be spent on figuring out the various info you'll need to store and manipulate in your system, and how your users would expect to interact with that info. So, your back end - database design and business logic - should be your highest priority. I'd start by writing down what you need. The easiest way to do this is to examine all of the data points you may want to store. What is a facility? Street address? Room(s)? Floor(s)? What is a valid booking? Dates? Times? Location(s)? Once you have an idea of what you need to store, start writing your db tables, using the following link as a beginner's guide: http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html When you feel your db design is solid, then you can start working on the PHP you'll use to access and manipulate the data stored within. There's not a lot of advice I can give here, as what you'll need is dependent on how you need the system to run. It may be a good idea at this point to turn the project on its head and think about how an end user would interact with your system. To think about the kinds and quantity of data a user would need, and how they'd set up new bookings, edit existing ones, add and/or edit other data, etc. The pretty bits tend to come last, as HTML, CSS, and JavaScript don't typically have much, if anything, to do with the way underlying systems actually work. You may be able to find a 3rd party system that will do what you want, but those suffer from not being custom to your needs, and, ultimately, you wouldn't really learn anything that way. There's no magic bullet or easy button when it comes to learning this stuff and doing it right.

I'd just start out with C# 4.0. The O'Reilly book I mentioned will say which features were added to the language in each version, so you'll already be set. Most of what you'll encounter will likely be C# 3.0/4.0 stuff anyway, unless you need to do work on a legacy system. For setting up your work environment, all you really need is Visual Studio Express. It's an IDE/compiler with SQL Server 2008 Express built in, so you'll be good to go out of the box. One caveat - SQL Express files are not compatible with the full-fledged SQL Server 2008/SQL Server 2008 R2 db servers. So, you'll need to install the Express version on IIS when you deploy. Also be aware that ASP.NET MVC and pure ASP.NET are two very different things. You can mix and match, as MVC is built on top of regular ASP.NET, but it's a bit of a PITA to do so, and, really, not all that worth it aside from using something like a calendar control. If you're curious about source control, you can get Subversion to work. I use a combo of VisualSVN server (Google it, the server is free) and TortoiseSVN client (also free). I agree with Thorpe about IIS. 7.0/7.5 is better than previous versions, but still pretty confusing and counter-intuitive. Windows permissions suck, and there are a lot of hoops to jump through to get things like FTP to work. MSDN is hit-or-miss with its documentation, too. That's probably where the biggest stumbling block will be.

The code wasn't tested because I don't have access to your database, and wasn't entirely sure of how your db was structured. How can I test db functionality in that manner, short of going through a lot of hoops that are outside the scope of something like this? Further, you keep changing the details - first, you have one option that can be changed, now you have three? Your form doesn't even address your 'banner' setting, let alone the second of the three options you refer to. Did you even read the comments I wrote in the code? Probably not. In my years here, I've learned that the quality of answer received is directly proportional to the quality of the question asked. You're going to have to learn how to communicate your problem(s) much more effectively. How is your settings table structured? What do you mean by "it's not working?" Do you have a test page we can access? Have you tried basic debugging techniques, like echoing out the values of the $_POST array? Is the code you provided your actual code or a rough example/sketch of what you're trying to do? It doesn't matter where you go for help, everyone will say the same thing: be crystal clear about what you want. Personally, I could care less if you decide to stick around here. Your attitude sucks, and, frankly, this community is better off without people like that.

I tried cleaning it up a bit for you. Not tested, obviously. Be sure to read my comments. <?php error_reporting(-1); ini_set("display_errors", 1); require_once '../config.php'; $db = new DbConnector(); if (isset($_POST['submit'])) { $db->query("UPDATE " . SETTING_TABLE . "SET option = {$_POST['banner']} WHERE setname = ''"); // <-- Are you sure your WHERE clause is correct? Also, where does banner come from? echo "Process complete."; } $settings = $db->query("SELECT * FROM " . SETTING_TABLE); while($row = $db->fetchArray($settings)) { $selectOption = '<td>' . $row['setname'] . '</td><td><select size="1" name="' . $row['setname'] . '">'; if ($row['option'] == 'on') { $selectOption .= '<option value="on" selected>on</option><option value="off">off</option></select></td>'; } else { $selectOption .= '<option value="on">on</option><option value="off" selected>off</option></select></td>'; } } ?> <!doctype html> <html lang="en-us"> <head> <title>Form</title> <link href="mainframe.css" rel="stylesheet" type="text/css"> </head> <body> <!-- You should really make sure your table is formatted properly --> <table border="1"> <tr> <form action="settings.php" methed="post"> <tr> <?php echo $selectOption; ?> </tr> <tr> <td><input type="submit" value="Submit" name="submit" /></td> </tr> </form> </tr> </table> <h2>Settings</h2> <a href = "admin.php">Admin Panel</a> </body> </html>

I think at a fundamental level your design is flawed. Like Thorpe and phpfreak said, CMS' don't tend to store their views in a db. Rather, they're saved as simple .php files in the filesystem itself. These view files are constructed in such a way to expect certain data, which they parse and display. Views are supposed to be very simple. This is slightly different than templating as the code used to display the data is pure PHP, so there's no text replacement necessary. In other words, you'd have something like: <?php include('somemodel.php'); // your data ?> <!doctype html> <html lang="en-us"> <head> <title>Example</title> </head> <body> <table> <?php foreach ($model->data as $value) { echo "<tr><td>$value</td></tr>"; } ?> </table> </body> </html> Keep in mind, this is a very simple and canned example. What you should do is take a look at how the pros do it. Learn some MVC frameworks (Code Igniter, Kohana, Zend Framework), or a CMS or two (Joomla) to see how it's actually done.

1) I don't know how to do that At the top of your script, put: <?php error_reporting(-1); ini_set("display_errors", 1); ?> Also, Google and the PHP manual are your friends. If you don't know something, always search there. You seem to be very confused about what your form contains and how to pass that info along to the db. You should probably show us the form itself so we can see exactly what your db query should be. Also, since you're using a DbConnector object, you most likely don't have to write: $db->DbConnector(); An object's constructor is called automatically when one asks for a new object (e.g. $db = new DbConnector(); ).

C# is a great language. VB sucks, but C# is really, really nice. And I agree with requinix - you already know a non-Microsoft language. If you want to maximize your own profitability, you should have a Microsoft language in your toolbox. So, get the C# 4.0 In a Nutshell book from O'Reilly Press, and download the free Visual Studio Express. If you're looking to do web programming, look into ASP.NET MVC. Version 3 was just released. Much better than the old ASP.NET web forms way of doing things. If you're interested in Python for the web, look into Django.

Private makes the data member or method accessible only to an instance of the class in which it was defined. Protected makes the data member or method accessible only to an instance of the class in which it was defined AND any child classes/objects. Neither can be invoked from the outside, so something like $obj->invokePrivateMethod(); will fail. So, in essence, yes, things marked as private or protected are for internal (to the class/object) use only. As far as uses go, well, data members should be as restricted as possible in most cases. You don't want to give the outside world direct write access to your data fields, which is what you have with public members (note that both var and no access modifier at all default to public). This is why most well-written code examples show fields marked as either private or protected. For methods, chances are you'll have classes that have functionality you don't want other objects to get their hands on, like routine db visits. Private and protected keep these parts hidden since the rest of the system really doesn't need to know how things are done in a particular object. You were on the right track with thinking it's about encapsulation. Objects should be seen as black boxes. Their outside has a public interface (public methods, not necessarily the interface language construct) which tells the world how to use it properly. The actual mechanisms that do the work are hidden to protect them. It's not like you need to know how things work inside the box to get it to fit in with others.