the182guy

There is no way to know for sure where the call was initiated from because an AJAX request is just the same as any other page request. If you add any sort of variable to check, it will always be breakable by just copying the AJAX HTTP request. Have you considered securing it with a login system? So only give access if a user is authenticated.

Exactly correct, it's just a pointer or reference to a MySQL result set. If you're generally writing OOP then fetch_object() is preferred or more appropriate. Array functions on objects? What have you got in mind?

Show the menu PHP code. Also show the relevant code from the page that includes the menu, so we can see how you identify a page.

You haven't given enough information for someone to be able to help you. Describe what the script does currently and give more info on what you want to achieve.

There's a few ways to do that then. One is to create a db table that stores page file names and keywords that relate to the content. You could even store the actual content for a more comprehensive search. Other than that youll have to read the page files and look for the search term, you would need to exclude any php code whilst searching each page.

The getItems() method would be more appropriate in the ItemsAbstraction class. You could have it return an array of objects using mysql_fetch_object() for example. Unless you need methods from the Item class there would be no need to create an Item object for every record in a list, especially if the stdClass returned by fetch_object() has the same properties as your Item class. When working with a single item in the application, it may be more suitable to instantiate your Item class for it.

Search facilities are entirely dependant on the way your content is stored. Do you store page content in the database or is it hard coded into scripts? A simple search function is easy to do with PHP if you're searching MySQL stored content, just use a LIKE query.

It won't be a problem to have all the process code together. I would add a hidden input element to each form to give it a name e.g. <input type="hidden" name="form_name" value="contactus" /> Then in your PHP process code I would handle it like if($_SERVER['REQUEST_METHOD'] == 'POST') { $formName = isset($_POST['form_name']) ? $_POST['form_name'] : ''; switch($formName) { case 'contactus': // handle contact form break; case 'search': // handle search form break; default: // unknown form } } If there is a lot of process code then it could be better to create for example a base class form handler, then extend it for each form, to keep the code organised etc.

On this line you're using a space in item id instead of an underscore: $_SESSION["cart_array"] = array(1 => array("item id" => $pid, "quantity" => 1));

The one you have can be used like foreach($userPost as $p){ $postTime = ago($p['postTime']); echo "Post: ".$p['postTitle'].", ".$postTime."<br/>"; } There is another one here: http://www.php.net/manual/en/function.time.php#91864

OP, show us all of the relevant code, including the part which is calling your upload function.

I don't like lots of returning like that within a function. It should have as few exit paths as possible, preferably just one, making it easier to read, maintain and debug. I would instead create a return object which has a success (true/false) property and a message property to indicate the reason for failure. Even better would be if the message was a pointer rather than a user friendly message, e.g. TOO_LARGE, where you'd let the front end or view handle the actual turning it into the user friendly message if you needed different languages or want a more MVC style system.

Nothing difficult there, just use common sense. Like in the example if you have a dropdown with certain values that are acceptable, make sure that when the form is submitted, your PHP only accepts the same possible values. In that case I would have an array of possible values, then use in_array() to test if the input is valid, if it isn't either default to a valid value or throw out a validation error.

This should be solved. You haven't taken any notice of thorpe's suggestion.

Use it on your user input like $cname = mysql_real_escape_string(strip_tags($_POST['cname']));

Try to keep your logic and output separate if possible. For example in that uploadFile function, passing it a file you'd expect it to return something like success/fail instead of printing out messages.

There are a few issues with your code: See SQL Injection See why isset post is bad PHP_SELF has an XSS vulnerability when used in that way

You're passing the result of mysql_query() to your function which in turn passes it to explode() which is causing the error. You need to get the datetime string from the query result and pass that.

haris, are you getting any error messages, either MySQL errors or anything in your error log file? $file is just the argument name. The variable given as the argument is $image which is set as: $image = $_FILES['image'];

That part is not sent to the server so you would need to add it to the value with a delimeter for example: <option value="user:This is a user">This is a user</option></select> Then in your PHP when it's submitted, parse the value with something like explode() to get both pieces. Another option is to use Javascript to send the display text to the server as well.

Well unless you have some real visitors (as most websites aim to attract), of course it will only be you sending the data.

Storing include locations in the session could be a bad idea. What happens if the session expires or doesn't exist and a user views a page that doesn't have the vars being set? If there's a script that all of the others are including, such as a database connection script then you could put your constants and other includes there, so they'll be present on all pages that include that script.

Looks like your just not including the script that has the define() stamement, into adminpage.php Constants won't persist across page requests like session variables do. They need to be included into every script that accesses them.

They aren't editable by clients unless your code allows them to be, e.g. by a bug/vulnerability or a vulnerability in the web server for example in a shared hosting environment. If someone got their hands on the admin's session ID cookie then they may be able to peform a session hijack and login as the admin.

Actually when will you not know ? In rare cases when you want to accept input from more than one source, normally get and post rather than cookie.