Selling Maniapets...

**Toongears** · 06-16-2012

$130 -

**MichaelCrystal** · 06-16-2012

1. Yes, but there's no security issues with it, and it works, PHP does have to read 2 more lines for each "cleansing" but in the end it isnt enough to really have any effect on the actual load time.
2. As far as I know it does, it cleans it from anything from coding - SQL injections.
3. Again, if the new site owner adds on to this area, and it starts to lag, they might want to proceed to optimize it.
4. $user can be found in the header.php master script, but isn't shown here.
5. Select isn't the best, but it works, and as long as you limit it so it doesn't keep running it won't lag the site to the point where you can even notice.
6. Didn't know that, but doesn't really effect the load time either.
7. Okay, it works, but the new owner's might want to consider that.
8. Same as 7.
9. In the fuctions script (A include file), there are different functions for different things on the site. Nothing wrong with that.
10. This is actually something I thought of, but all you would have to do in the script is put "/chat/mail/?action=2" instead, so it would take on whatever domain it's on.

As I posted before, this site is in development, it hasn't even came to it's beta tested, now as all programmers know, there are usually always bugs. I didn't finish everything so I never got around to fine-tuning the coding. So you can expect bugs, but none of the ones here are really bad, they just call for maybe a line or two being changed. And actually doesn't have to done. It works perfectly, it just might slow down your overall load time. Which in fact it doesn't in the result, because there isn't enough to slow anything down.

That right there was fine-tuning. It was a site being developed, not a finished product.

It works, the only issue that *needs* to be done with up their is the SQL Injection (Not a hard fix) and the deleting part (not that hard either, you just set it so that only the user that it was mean't for in the database, could delete it.)

***judda*** · 06-16-2012

1 - Never said this was a security issue. This issue is a memory one. You are grabbing more memory than you actually need.

2 - This script proves otherwise (run it via command line with arguments):

PHP Code:



<?php
$bar = htmlentities(strip_tags($argv[1]));

$query = "SELECT * FROM foo WHERE bar = '$bar'";

echo $query;

Code:

$ php test.php "asdf' OR 1=1"
SELECT * FROM foo WHERE bar = 'asdf' OR 1=1

SQL injection in it's simplest form.

3. "Deal with it when it comes up, instead of now while still in development"? In a development environment, you will never have half as many posts or anything as you do in a production environment. So you would never be able to reproduce it there. Why not just do it right the first time especially in stuff which could be such core functionality. Going in later on to optimize is just asking for new bugs.

4. Then why are you overwriting it in your while loop later on.

PHP Code:


user3 = $row['user']; 
$user2 = strip_tags($user3); 
$user = htmlentities($user2);

This will just cause a headache when debugging anything.

5. The first query you run isn't limited. So yes it would have to go through everything (assuming that the table is properly indexed), it would have to go and do an index scan to grab all relevant rows. And then you are selecting the data right out of it, so forcing it to not only find the data, but actually grab the values for it. Whereas if you just did a COUNT on the key column on the table, then it could happen a whole heck of a lot faster.

6. No matter how miniscule things may look / seem in execution time, they add up. Just say you have 3 things that slow down execution of a script by even 5 milliseconds (you have some that do it by more). Each time that snippet of code is executed, you are essentially throwing away 15 milliseconds of execution time. It may seem small, but every millisecond counts when optimizing websites.

9 - Never said anything was wrong, but just more clear for any developer going in there.

10 - But yet you decided to go with the less efficient route. http://maniapets.com/ = 22 characters = 22 * 1 byte (if ASCII (VARCHAR)) or = 22 * 2 bytes (if UNICODE (NVARCHAR)). This adds up. And quickly! Especially for such a frequently used table such as 'player updates'.

These ones here don't call for huge changes ... but multiply that through each and every one of the scripts that you currently have on the site. And remember, I had only gone through 39% of the code when I stopped. There are likely more. So the "one or two lines that need to be changed" is actually a lot higher than that.

"Which in fact it doesn't in the result, because there isn't enough to slow anything down." - Key words here ... ."isn't enough to slow anything down" ... meaning you are anticipating at one point in time yes, it WILL slow down when there is enough 'stuff'.

That right there is how application are made. Not fine tuning. If you consider optimizations, readability and poor decisions fine tuning there are bigger issues.

~judda

**MichaelCrystal** · 06-16-2012

Okay, I'm going to make it AutoBuy $130, with the knowing that there are a few bugs that will needed sorta out, but nothing that can't be fixed. If anyone is interested, the artwork alone is worth the price, please PM me.

Thanks,
MC