KevinM1

PHP will work for you, but I suggest finding a host with version 5+. Version 4 is outdated, and no longer supported by Zend. Moreover, if you're looking to write some OO code, PHP 4 is a joke in that regard.

This is slightly more difficult, but not by much. First, all of your stored hyperlinks should have an id associated with them. The most typical type of id is a simple number. So, you should have something like: link_id link_address --- --- 1 http://www.google.com 2 http://www.cnn.com Each DELETE button is then associated with that hyperlink's id. When the button is pushed, that id value is then passed to the script that handles the actual deletion, and is used in finding the hyperlink itself.

Do you know of any small businesses in the area that want a website? Or a local non-profit? Or school?

You need to store the file names in a database. Then, on the page that's supposed to display the links, loop through the database and construct the links. It's a pretty simple process, really.

Did the guy try using the computer before purchasing? Are his issues with it things you knew about before selling it? If you live in the US, the worst that could happen is the guy taking you to small claims court to get his money back. There wouldn't be any extra fines, and certainly no criminal prosecution. The question at the heart of the matter is whether or not you were truthful about the capabilities and functionality of the computer. If the buyer was misled into believing it was a better product than it actually is, you should refund his money to avoid going to court. You should do this even if you didn't explicitly lie about it. Lies of omission count in court, and will count against you. Whenever I do a private sale, I always draw up a simple contract. It says that I'm selling the product for a certain agreed price, and that the product is being sold as-is, with no warranty. I allow them to examine/demo the product right there before signing the contract. There are two copies of this contract - one for me, one for the buyer, and we both sign each one.

As stated... it's a personal site. My php playground... I know that the delete doesn't work, and I am currently working on that, and as to the inability to tell what commands area available, I am modifying that now... If it's a personal, i.e., not for public consumption site, then what does it matter what we think? I mean, if you want us to critique your code, then post it. Otherwise, like others have said, what's the point? I will say this - the 'design' reminds me of the worst of the Flash-based sites I've seen (yes, yes, I know yours is PHP). Despite what some developers think, most users don't like to interact with a mysterious, limited CLI. It's not clever, it's not exciting. When I first saw your site, my immediate instinct was to close the tab. As a learning exercise it may have value, but it's not something most users would want.

Hmm...I'm not sure if there's a JavaScript-only solution. Have you tried looking at website text editors like TinyMCE? You can embed it into your site (with a bit of work), and it should do what you want.

The color combination is a bit harsh, especially the green. I felt like squinting. I don't like the green links at the top. Their font is a bit squished, and they don't really fit in with the bulk of the site. Your navigation pane could use a bit of work. I'd move the search box to the bottom, then move the 'Home' link to be the first item of your unordered list. That would make it look a bit more tidy and flow better. I think, in general, you either need to increase the graphical load, or strip it down even further. Right now, the site is in this weird in-between look that doesn't quite gel. Imagine a Wiki with 3D buttons for its tabs only ('Revision History', 'Discussion', etc)...that's the same kind of disjointed feeling I'm getting here.

I actually learned most of PHP by coming here. It's one thing to read a book and the canned examples they have, but it's another to see real problems, real solutions, and various ideas on how to properly build a system. I figure I owe it to the community to give back in some way. I tend to ignore the vanilla "Help, I'm getting a 'headers already sent' error!" posts and go for the ones that are either more difficult, or ones that will allow me to steer the greenest of the newbies in the proper direction before w3schools rot their brains. I actually tend to hang around the JavaScript board more than the others because JS gave me the largest amount of trouble for years, so I figure I'll try to help others avoid the headaches I had.

You seem to be on the right track. One thing caught my eye: You don't actually have a variable named $credits that you're assigning to, due to the fact that you don't set the findCredits return value to a variable. Instead, you should do something like: $idiot = new User('bubba'); $idiotCredits = userFind::findCredits($user->getName()); $idiot->setCredits($idiotCredits); There were some additional minor syntactical errors, but again, you are on the right track. Something to keep in mind is that OOP deals with objects. That sounds dumb and obvious, but it's something that many people trying to learn OOP tend to forget. Objects are supposed to be simple in concept, if not in execution. They're supposed to represent one concrete thing, and not much else. Keeping things simple is what fuels the 'magic' of OOP. It allows the programmer to combine objects at runtime in order to create larger system components. For example, look at what you've broken your system down into. You now have a User class that can be used in any other part of your system. Even better, that User class may also be useful in other sites. You can possibly distill your verification classes into something more universal as well. Using them in concert doesn't affect their own innate usefulness, either. User objects aren't damaged or irrevocably changed by passing them into the other classes' methods. So, as a general rule of thumb, it's better to have a host of simple objects that you can pass around and combine with other objects than one really big, complicated object that attempts to do more than one thing well.

Right off the bat, a lot of the properties you have in your user_checker class should be a part of each user. The mechanism that checks the user shouldn't store that kind of information. Instead, it should check to see if the user is able to perform a certain action based on the user's current state. If so, continue processing. If not, abort and display the error. I'm also weary about your idea to pass in database table info directly into the object constructor. Again, this kind of information should be part of the user, and there should be a membership system in place with your DB structure that can inform the user object where it belongs. So, something like: class User { private $userName; private $userLevel; //new member? gold member? admin? private $credits; public function __construct($name, $level, $credits) { $this->userName = $name; $this->userLevel = $level; $this->credits = $credits; } public function getCredits() { return $this->credits; } } User info should be pulled from the DB upon login. If the query succeeds, build the object and log it into sessions class UserCheck { private static $adPrice; public static function setAdPrice($price) { self::$adPrice = $price; } public static function checkUserCredits($user) { if($user->getCredits() < self::$adPrice) { return false; } else { return true; } } } We use static here because we're not interested in having an actual object, only the methods it provides for checking the user. So, after you user object is created upon a successful login, you'd only need to do something like: $userState = UserCheck::checkUserCredits($user); if($userState) { /* continue processing */ } else { /* error, not enough money to place the ad */ } It might not be 100% inline with your system, but you should get the idea.

The administration portion looks and feels more professional than the rest of the site. The biggest problem I have is the homepage. Users are there to shop, not read about shopping. The store itself is incredibly bland. You have a wonderful looking site, but in the middle of the page are a few categories/products that just don't have any life to them. Try playing around with the font, or overall layout, because right now it looks like a data dump with very little effort used in trying to make it presentable. You have background image tiling issues. You need to fix this. If you're wondering what I'm talking about, look at the description of the first item you have for sale. the Baby BanZ sunglasses.

Well, without seeing those external files, there's no way anyone can offer a suggestion. All I see are function calls at the bottom of the code, but there's no context.

I like it, with the exception of the header and footer blocks. They're too tall, and are just wasting a lot of space as is. It's especially noticeable when looking at your 'About Me' page. It feels as though I'm reading the info through a narrow slit. Also, not related to your project, but is the audio on your employer's page loud enough? I have my speakers set pretty low, and it still startled me.

That should work. You could also give each unit their own Move method and pass into it an object representing the game world/level, which could then return the unit's new position.

I hate this design. There's way, way too much wasted space. Do you really need two huge headers for each sub-section? Do you need so much Flash that, aside from a couple areas, doesn't really do anything? Do you need those pretentious 'MF Tips' boxes that don't really say anything important or informative? I dislike the sliding menu. I dislike the link that goes to your forum. Are those numbers supposed to be your phone number? I dislike those as well, given their lack of context and size/positioning. The whole thing looks cluttered, and has very little real content. It doesn't look professional to me at all.

Without knowing what you want your game to be and how it should run, then yes, in a general sense, you're on the right track. The key, like with everything else, is to try to have a good idea of all the system's participants before diving into coding. Changes to your design will inevitably happen, but you should still know what you want to do even if how it is actually done is not in line with your original setup. Also, keep in mind that the first 'O' in OOP is 'Object.' A lot of new OOP learners try to stuff as much functionality into as few objects as possible, which runs counter to the entire point of OOP. It's better to have many simple objects than one big, complex object. Why? Because objects can (and should) be used in combination to create larger system components. This grants us flexibility. So, objects can (and should) be used as properties of other objects. And objects can (and should) be passed to another object's methods. And, simple data structures (like arrays) can contain objects as well. That's about all I can say without knowing anything else about your project. I hope it helps somewhat.

The original ASP (sometimes termed ASP Classic) was pretty much equivalent to PHP. ASP.NET is very different.

ASP.NET is a completely different beast than PHP. Essentially, the process that loads the site reads what browser the user is using, and serves up the right HTML to make the page look correct. So, someone using IE and someone using Safari will (in theory) get the same visual experience, although the actual HTML may be different. The process knows what to do because most of ASP.NET is written using server controls. These are written much like regular HTML tags, but they're all 'aimed' at the server. Something like: <asp:Button ID="Button 1" OnClick="Button1_OnClick" Text="Submit" runat="server"></asp:Button> So, when the user encounters that button, it may be a form's submit input or a generic HTML button. You can also point most generic HTML tags to the server as well, simply by using the runat attribute. There are a host of controls that automatically obtain and output database query results, so there's no need to loop through the results and echo them out manually. There's also a great calendar control. ASP.NET is, therefore, primarily a tag language like HTML. The 'magic' occurs with using a processing language, in this case either VB.NET or C#. The code here can be written in an inline style inside the .aspx file itself, much like how PHP can be used with HTML in the same file. More importantly, it can also be used in a code-behind style, where the processing is stored in a separate file from the markup. ASP.NET isn't without its flaws (like all languages/platforms). I wouldn't recommend it for small sites, given its overhead. It tends to have some issues when it comes to using CSS to format things. And .NET itself is a pain to learn. The libraries are nice, but there's a steep learning curve. Still, it's another tool to put in the toolbox.

I never really understood the point of doing it server-side. Then again, I never tried it, either.

You're kidding, right? Idk...it seems there are an increasing number of ".jsp" pages floating around. Would ajax based sites be counted as javascript? First, Java != JavaScript. The former (Java) is a full-fledged Object Oriented programming language which is run by a virtual machine. It was developed by Sun Microsystems. JavaScript is a client-side scripting language which is interpreted by a web browser. It was developed by Netscape (now Mozilla). So, Java Server Pages, by themselves, are not JavaScript. Most likely, JavaScript can be incorporated with them (much like how PHP can be used in conjunction with JavaScript). AJAX, on the other hand, is JavaScript (the 'J' in AJAX is JavaScript), so yes, those count. JavaScript is most likely the most widely used scripting language in the world. Virtually all modern sites employ JavaScript to do something. It is a cornerstone technology of the world wide web.

You're kidding, right?

Regardless of whether you use push or the brackets, you need to put the new data into an array itself, then add that array as a new element of your main array.

Remember: sessions use cookies to maintain state unless you specifically tell them not to.

Hmm...maybe a locking mechanism of some kind? Have a temporary name file/db that stores these in-use (but not fully registered) names so that when someone else tries to register on the site, the script checks both the member db and temp db?