KevinM1

It means pretty much what it says. OAuthStoragePDO contains 4 abstract methods. The class that inherits from it must either provide concrete functionality for every one of them, or the child class itself must be declared as abstract. A non-abstract class cannot have abstract methods within it, even if those methods come from inheritance.

Also, put all your code in tags when posting on the forums.

The history of programming is embedded in laziness. Look at the names of just about every *nix command.

That sounds incredibly convoluted, and really not thinking in OO terms. Your menu class needs to represent a menu. It shouldn't necessarily represent all kinds of menus, or every menu on your site. A menu needs to be a discrete thing, in and of itself. What a particular menu represents can be implemented in a variety of ways. You could pass in options through its constructor. You could subclass. The point is, you're trying to jam all of your site's particular menu functionality into one object, instead of thinking in more abstract terms. OO is all about abstraction. That's one of the reasons why it's a popular paradigm. If you can abstract your code, and write code that interacts via interfaces (meaning the public members of other classes, and not necessarily the interface language construct), you'll have modular code. What you're currently doing is the classic mistake of jamming code into classes because of some nebulous idea that "it's how the pro's do it." Without actually understanding the how or why, you're simply making everything harder for yourself. I understand that your finances are tight, but you should really try to save ~$30 and get Zandstra's book. You're not going to be able to get a job at a development studio with your current quality of code, and for freelance projects, editing/debugging/maintenance would be a nightmare with what you have. This is really one of those "spend money to make money" moments. Far more efficient than writing some code and seeing if we can make heads or tails of it.

Your code is very scattered, and pretty much gibberish. 1. You never declare $menu_array before using it. 2. You have $i for no reason, and don't do anything with it after incrementing it. 3. You use array_values for no reason, and never use $link_option in that loop (your other methods won't be able to 'see'/use $link_option due to scope). 4. You try appending $this->menu to $this->newmenu when $this->menu has no value. --- Right now, it looks like you're panicking because the code isn't working right, and you're making random incremental changes hoping that somehow it'll fix the problem(s). Your first three posts - written in the span of 30 minutes - highlight this. You need to stop, take a deep breath, and really run through what you've already written. None of it currently makes any kind of sense. Do it with pen and paper, and map out the process. Then, compare what you want to happen with what your current code is doing.

In PHP, when you have an argument that is equal to something, like: example($x = "hello") { // blah } That value is that argument's default value. So, if you invoke the function like so: example(); It will use that default value (the string "hello" in this case). If you supply a different value, like: example("bonjour"); It will use that instead. So, in your case, you don't need two constructors as your second constructor can take parameters, but if no parameters are supplied, it will just use the specified default values, which are empty strings in your case.

And, here's a good (and cute/funny) explanation as to why you shouldn't use the comic sans font: http://www.comicsanscriminal.com/

When I do hourly work, I just create an invoice at the end. It's itemized, so each component is listed. For contract work, the client and I negotiate a total price. I require 1/3rd up front, another 1/3rd after an agreed upon milestone, and the last 1/3rd at the end.

that doesn't account for <BR> <BR /> <br/> <BR /> etc... lots of other ugly formats that browsers will render properly Good point.

I'd ditch the regex completely and go with: public function br2nl($string) { return str_replace(array("<br />", "<br>"), "\n ", $string); }

That would be a horrible use of classes. Again, john_doemoor, show the code you're having issues with.

Your submit button is named 'Register', but you check for $_POST['submit'] in your code.

1. Are you getting any errors/warnings? 2. Are you actually connecting to the db? 3. Have you manually tested your queries?

No, don't do this. In fact, never use the 'global' keyword at all, for anything. OP, why don't you show us what you're trying to do (in code)?

Are you looking for something like the following (took a guess with the $userLogLines field): public function getUserLogLines($logLines, $householdId) { $this->userLogLines .= $this->parseUserLogLines($logLines, $householdId); return $userLogLines; } ??

OOP is notoriously difficult to learn, and really shouldn't be used for production apps until: 1. You know what you're doing 2. You know why you're doing it OOP isn't just about slapping code in objects and calling it a day. It's about knowing when/where/why/how to use classes and objects to make clean, modular, reusable code. If you're not at that level, then don't force it in a full blown app. There's nothing wrong with procedural programming, and if that's what you're comfortable with, use it. Learn OOP on the side.

So I'm basically going to have to recreate every single method used by MySQLi? Cause that's where this is headed. At that point screw OOP. I thought once I established a connection I'd be able to use the built in functions of php. A query method would essentially be this correct: public function query($query){ return $this-DBconnect->query($query); } Yes, that's what your query method should look like. Listen, when you create a wrapper object (which is what you're doing, since your object merely contains an instance of a MySQLi or PDO object), in order to get at the methods associated with the internal object, you'll need to delegate, which is what that code does above. That said, you don't necessarily need to create a wrapper object. You have a mutant Factory (it's an OOP pattern) on your hands here. Instead of selecting a particular type of DB to use and then wrapping it in a custom object, which would require you to write a delegate method for everything you want to do, just return the correct type of DB object. class DBFactory { public static function connect($mysqlipdo, $persistcoe, $dbname, $user = 'dbo418598519') { if($mysqlipdo=="pdo" && $persistcoe=="persist") { return new SafePDO_errordisplay("mysql:host=db.1and1.com;dbname=$dbname", $user, "pass", array(PDO::ATTR_PERSISTENT => true)); } elseif($mysqlipdo=="pdo" && $persistcoe=="coe") { return new SafePDO_errordisplay("mysql:host=db.1and1.com;dbname=$dbname", $user, "pass"); } elseif($mysqlipdo=="mysqli" && $persistcoe=="persist") { return new mysqli_errordisplay('p:db.1and1.com', $user, "pass", $dbname); } elseif($mysqlipdo=="mysqli" && $persistcoe=="coe") { return new mysqli_errordisplay('db.1and1.com', $user, "pass", $dbname); } } } // Usage $DB = DBFactory::connect(/* args */); All that said, I strongly urge you to stop where you're at and get a good resource on OOP in PHP (I'm partial to PHP Objects, Patterns, and Practice). You're writing very convoluted code with your _errordisplay variants, the kind of thing that will inevitably create headaches and heartbreak down the road.

The error is pretty self-explanatory. Your DBConnection class doesn't have a query() method. You need to write one.

You monster!

Questions about the availability of a website do not belong in PHP Coding Help. This topic has been moved to Miscellaneous. http://www.phpfreaks.com/forums/index.php?topic=360700.0

*shudder* Yeah, that question quickly leads to the realm of nightmares.

This topic has been moved to Application Design. http://www.phpfreaks.com/forums/index.php?topic=360658.0

Sounds good. Play with it to get a feel for it, and don't be afraid to ask more questions if you need to tweak the design.

The biggest thing is figuring out how to both constrain and direct the player. You need to make parts of your grid inaccessible (like mountains), and you also need to tell the player where to go. That's how the classic, 2D RPGs worked. With games that rely on a map grid, you're never going to be able to guarantee that a player will hit a certain point on the map unless you force them there. If exploration/freedom of movement is what you're aiming for, the best you can do is limit where they can go and make the next step of the journey obvious.