KevinM1

A message stating that you're leaving does not belong in the sub-forum whose sole purpose is for new members to introduce themselves. This topic has been moved to PHPFreaks.com Questions, Comments, & Suggestions. http://www.phpfreaks.com/forums/index.php?topic=347813.0

Why would Facebook using GET variables preclude them from using Ajax?

Negligible difference between the two. Such micro-optimization is usually a waste of time. Focus on the real bottlenecks (read: database), and cache when you can. Look into memcache and APC for examples.

Your while has a syntax error. Should be: while($query_row = mysql_fetch_assoc($query_run) && $counter <= 2) Also, as an aside, you don't need to assign your columns to a variable only to echo them. There's nothing wrong with simply writing: echo $query_row['title'];

To be honest, I think you should start with basic OO methodology before trying to move further. Knowing the syntax of objects does nothing to prepare one to use them properly. Right now, I have the feeling that if you tried to adapt the code in the tutorial, you would just blindly slap on parts that relate to the particular problem you're trying to solve rather than something more universally useful. In short, you need to learn how to crawl before you can walk. You should get two books before progressing much further: PHP 5: Objects, Patterns, and Practice by Matt Zandstra [Link] Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four [Link]

Not a fan of that tutorial because it claims to be a real world example, but has the following flaws: No error handling. In fact the author squelches errors by using the '@' symbol liberally through his code. A true real world example would have exception handling. No escaping of values or anything else to combat an injection attack. An incredibly egregious omission for a tutorial aimed at newbies. A complete lack of ability to handle complex queries. Unless you have an embarrassingly simple domain, chances are you'll want to JOIN tables at some point. It's just a bad tutorial all around. Looks like the author wanted to make something that mimics a generic ORM, but neglected to build any of the functionality that makes them worthwhile to use.

Not really OOP. OOP is more than just stuffing what would simply go in a function inside a class. Your best bet is to use an existing OO solution (MySQLi or PDO) and figure out a way to incorporate your specific needs with it.

If you only want to refresh/update some content on your page without having the entire thing reload, then AJAX is your only option.

What's stopping you from posting back to the same form and simply having a message display at the top for each successful submission?

Maybe the professor should teach to not use the 'global' keyword, and how to properly structure a PHP script as well.

The PHP Coding Help section is not the place to recruit someone to work on your project. It's for answering specific questions about specific code. This topic has been moved to PHP Freelancing. http://www.phpfreaks.com/forums/index.php?topic=347446.0

Calling session_start in login.php isn't enough to send the value to empty.php. You need to explicitly assign it to a session variable: $_SESSION['id'] = $id;

POST ideally shouldn't be used for simply retrieving information anyway. While POST and GET behave similarly (aside from GET data always being visible in the address bar), they have different meanings, and should be used accordingly. Besides, one of the benefits of GET is that the results can be bookmarked. That said, you can make your links look more pretty by using .htaccess. So, instead of something like example.com?user=1138 you could have example.com/users/1138.

Uh, yeah, since that's how you defined your function. Quick and dirty function lesson: Functions have signatures. These signatures are a function's name and the arguments listed in its argument list. If you define a function with a certain signature (such as your function which requires four arguments), it will only work if you actually pass in four arguments. It is possible to have a function that can take an arbitrary number of arguments. That said, since you're struggling with the PHP 101 basics, it's best if you try to gain a solid understanding of the fundamentals first. Start with the PHP online manual and move on from there.

Yes, || is the logical 'or' operator.

It's easier to do what thorpe suggests than what you want to do. Think about it: With thorpe's suggestion, you need to check if the link is valid; that it fits the format you're looking for. But, you can ensure that the iframe the link goes in is correctly formed as you'd be creating it programmatically. With your idea, you'd need to verify that the iframe is correctly formed AND verify that the link within is also valid. It's more work for no real gain. Regarding output, well, how were you going to output these iframes originally? Just take the (hopefully well-formed) iframes from the db and echo them, right? If that's the case, then why can't you simply echo a premade iframe with the particular link variable as its source? EDIT: see thorpe's code above.

What amounts to small navigation links in your footer shouldn't be your main navigation. If it's below the fold, and not obvious, users won't see it.

I like the idea, I just think the execution needs a lot more polish. There are some odd language choices that are a bit confusing, and some design issues as well. The main problem is that a 'permanent gift list' is an odd phrase. Is it a list of gifts you want to give other people? A wish list for yourself (which, after reading, it is, but it could be clearer). A lot of your 'About This Site' info should be on the main page. Hell, you could have the first couple sentences as: "Tired of receiving tube socks and bright neon green shag sweaters as gifts? Make a Quick Gift List to let others know what you like!" Simple, to the point, and explains the site immediately. The 'About This Site' page is just a mess in terms of formatting. I count three different indentation levels. Also, the fourth question is, again, phrased oddly, and could easily be removed without harming the overall point you're trying to make. On the login page, the "forgot your password?" link is out of place. It's the only thing centered on the page, and doesn't line up with the register link. The "How to use this site" box is also a mess. Why use a small serif font here? Wouldn't you want the instructions to be as easy to read as possible? Also, why have it push the navigation menu down? It should be the main content of the page, with your navigation menu to the left of it. Regarding navigation, you need a "Create new gift" button. One shouldn't have to look at their list before creating a new item. Also, navigation needs to be on every page. Relying on the browser's 'Back' button is a surefire sign of amateur design. I'm a bit weary about you using BBCode for the comments and whatnot. What you should do is integrate a text editor of some kind that will do the formatting for you - TinyMCE, CKEditor, etc. Now, to the sample list. Just more of the same kind of questionable design choices. Why is the name of the gift so small? Why is the body of each request indented so far to the right? The "Buy Item" button implies that one can actually purchase the item in question directly from your site. It really needs to be changed to something more obvious, like "Mark as Purchased." Not to mention, the buttons don't toggle anyway, at least not in Firefox 7.01. The list should also be automatically sorted by priority, rather than date. If a user has a bunch of items on their list, but the one they want the most is way down at the bottom, what are the odds that it will be bought? Again, a good idea, but very little thought went into useability.

You're switching on $grade, yet trying to make cases for $markGrade. Further, cases cannot be used as normal conditionals. You can only use them when you anticipate that your variable will equal a certain value, such as: switch($i) { case 0: echo $i; break; case 1: echo "\$i = 1"; break; } switch So, just use normal if/elseif/else clauses.

This topic has been moved to JavaScript Help. http://www.phpfreaks.com/forums/index.php?topic=347058.0

Uh, no. You shouldn't require people to give you their email address for site testing purposes.

Do you have a test account for us to use?

That's still a sloppy way to do it. GET and POST, despite working similarly, have different meanings. GET is for retrieving data, and since parameters can be passed in via address bar, the results of the request can be bookmarked. POST is for inserting/updating data. Keeping them separate like this will greatly simplify what you need to do. For example, you could have an edit.php file which accepts the id and code as hidden inputs. Similarly, you could have a reply.php file that accepts the threadid as a hidden input as well. There's also the matter of PRG (POST/REDIRECT/GET) issues: http://en.wikipedia.org/wiki/Post/Redirect/Get http://stackoverflow.com/questions/2146431/back-button-re-submit-form-data-post

How are you accessing this page? Your mixing of POST and GET should be setting off alarms in your head....

You don't need a Singleton for that.