scootstah

I may be wrong but I think the more information that exists in your session, the more memory you use for every page load. Generally, I only store the user ID in the session and then run a query for that ID to get their info.

I don't think there is much you can do to prevent errors in that scenario. There will obviously be uncontrollable errors if profile.php relies on constants or a database connection created in a script that include'd it. What most CMS and frameworks do is check to make sure if the pages have been include'd or not by checking for a constant. For example in CodeIgniter, everything is routed through the index.php file (which is pretty common). The index.php file defines a BASEPATH constant, so all subsequent files in the framework check that the constant is defined, because that means it was not accessed directly but through the framework as expected. Another thing you could do is use an .htaccess file to deny users from viewing those files.

Don't set a maximum limit on the password. There is literally no reason to do that, and you're just going to annoy people. The hash will always be the same size regardless of the input.

You could probably do a sub-select to get the total rows couldn't you? Seems a little weird though.

Uh... http://www.php.net/manual/en/pdostatement.rowcount.php You can also just do count($result->fetchAll());

Well, that's scary.

If you find a cheap/free theme that you can modify to make it a little more unique, it might help to drive the price down. 30 minutes to an hour of tweaking an already made theme is easier than creating a brand new design from nothing.

That means the query failed and returned FALSE instead of a resource. You will need to display the query error with something like: $query = "SELECT * FROM boom_likes WHERE user_id=$the_user_id"; $result = mysql_query($query) or die("Query failed!<br />Query: $query<br />Error: " . mysql_error()); On a side note - if $the_user_id is not an integer it needs to be wrapped in quotes. WHERE user_id='$the_user_id'

This is why Python and RoR dev's hate us.

I don't see anything syntactically wrong. Is it showing up in the page source? Maybe you have malformed HTML somewhere (speaking of which, you need to close those two font tags (actually you should really be using CSS instead of font tags, but I digress)). Also, this &&($row['user_id']==$loggedinuserid) is unnecessary since you are only selecting rows with that user id to start with.

I don't know much about the Zend framework but, after briefly looking at their documentation, it looks like you need to be doing other things in your controller before you can use variables in your view. Here is the two articles I was looking at: Controllers Views

I like the idea of using hooks, so that plugins don't have to modify any part of the application. To see what I mean, compare something like Wordpress to SMF or phpBB.

The only way you could do that is by storing it as something like varchar, which is just not a good idea. Instead, simply remove the 0 when you need to display it.

You don't need another query, you just need to use different data when you bind it.

Yeah, sometimes you gotta factor in the headache multiplier into the hourly rate formula....hehe.

I don't think any of us can answer that for you. Is it a system that interests you? Would you like to work with it again? Would you pick that system for future clients based on some of the features of the system, or because of how the system handles certain things vs other CMS?

At the very least you are learning a new tool. The next time someone comes up and wants a site built with TYPO3, you know you can do it. I guess you have to ask yourself if you feel that you will ever use TYPO3 again after this job. If the answer is yes, then I think learning TYPO3 is beneficial to you.

All pages need to have session_start() at the top in order to work with sessions (unless of course the pages are being include'd from a page that does call session_start()).

Really? If I was a client and found out I was being charged more because the developer was going to need to spend time learning the technology I would be looking for another developer. there are plenty of developers around who do know typo3, why pay someone who doesn't? You don't necessarily have to increase rates if you don't want to. Maybe attach a small fee, or just bill them for the extra time it would take to learn the platform. The point is, if the client is insistent on using a specific platform that the developer isn't familiar with, why should the developer have to eat the time? It is in the developer's best interest to work with a platform which they are very comfortable with because it would take less time to finish the task; which favors both parties in that the developer will have time for more projects and the client pays less.

Do all of the pages have session_start(); at the top?

Create a random string when the user signs up to use as a salt.

That's not going to prevent SQL injection with PDO either. PDO has its own escape method ($PDO->quote()) if you aren't using prepared statements.

If it is not something you are familiar with or can learn quickly (less than a day), I would charge more than normal rates (if you can) for having to take the time to learn the system. If that fails you could always try to convince them why X framework (which would be one that you are more comfortable with) would be better or work just as well.

No. That doesn't even sort-of prevent SQL injection. What you need to be doing is escaping the string (see Pikachu's response above) or using prepared statements (with the MySQLi or PDO drivers).

You can't get the client's time with just PHP. DateTime (and other date functions) use the server's date/time.