mac_gyver

you need a user/permission system. see the following basic example - // roles define('BUYER',0); define('SELLER',1); // other roles would go here... // permissions define('CREATE_LISTING',1); define('POST_REPLY',2); // other permissions would go here.... class user { private $permissions = array(); public function __construct($user_id){ // this code retrieves the user's permissions based on their assigned role // define permissions to roles. this would normally be in a database table // for demo purposes, these are just assigned here... $permissions[BUYER][] = POST_REPLY; $permissions[SELLER][] = CREATE_LISTING; $permissions[SELLER][] = POST_REPLY; // fake code to assign a role based on dummy user id's // actual code would retrieve the role from wherever it is stored if($user_id == 123){ // a dummy buyer $role = BUYER; } if($user_id == 456){ // a dummy seller $role = SELLER; } $this->permissions = $permissions[$role]; // store this user's permissions } public function has_permission($var) { return in_array($var,$this->permissions); } } $_SESSION['USERID'] = 123; // a fake user - with role of buyer // example usage - $user = new user($_SESSION['USERID']); // get this user's permissions if($user->has_permission(CREATE_LISTING)){ // code for creating or processing a listing... echo 'you can create a listing'; } if(!$user->has_permission(CREATE_LISTING)){ // note the ! (not) echo 'you cannot access this page'; } if($user->has_permission(POST_REPLY)){ echo 'you can post a reply'; }

what you are currently doing, lets the player attack other people by clicking on a link. if they change the value in the url and can accomplish the same thing as clicking on one of the other links, what difference does it make? what specifically about being able to submit a value in the url to attack other people vs clicking on a link to attack other people is a problem? edit: submitting data that changes something on the server should be handled using a post method form. url get parameters should control what is displayed, i.e. gotten, on the page. this won't prevent someone from submitting any value they want, because anyone can submit any data via post or get that they want.

we cannot help you with what you tried unless you post what you tried. your task is simple, change each place that is producing a pagination link, of which there are several, so writing a user function may be helpful, so that it also has the id=value in the link. the method i suggested makes this general purpose and future proof. it also url-encodes the values for you in case they have any characters that are not allowed in links. the code in the linked to forum reply shows how to do this.

each different form processing code needs to test for a unique field name in the form, such as a hidden field, so that only the form processing code that corresponds to the submitted form will run. // post method form processing code if($_SERVER['REQUEST_METHOD'] == 'POST'){ if(isset($_POST['a_field_that_uniquely_identifies_form_1'])){ // all the form processing code for form 1 } if(isset($_POST['a_field_that_uniquely_identifies_form_2'])){ // all the form processing code for form 2 } // any other form processing code // if there are no errors, you should do a header() redirect to the exact same url of this page so that the browser won't try to resubmit the form data // to pass any 'success'/'thank you' message to be displayed when the page gets displayed after this redirect, pass it/them in $_SESSION variables // you should also exit;/die; after any header redirect to prevent the remainder of the code on the page from running // if there are errors, don't redirect and let the code on this page display the error messages and redisplay the form } // end of post method form processing code // any get request - display code starts here... the above code should set error messages in an array - $errors['form1_name'][] = 'some message'; or $errors['form2_name'][] = 'some message'; at any point to detect if there are errors, you can just test if the $errors array is empty or not. to display the errors for any form, just test for and loop over the $errors['form1_name'] array elements.

your pagination links need to include the $_GET['id'] value (and any future possible items you add to links.) if you build the query string part of the pagination links using http_build_query(), this will happen 'automatically'. if you do an advanced search on the forum for http_build_query() and my user name, you will find a page worth of examples showing how to use http_build_query() to combine any existing $_GET variables with your pagination values when you build the links. edit: here's one showing the phpfreaks pagination script, modified to use http_build_query() - http://forums.phpfreaks.com/topic/291074-php-mysli-pagination-with-items-per-page-select-option/?hl=%2Bhttp_build_query&do=findComment&comment=1491152

Lines 120-125 are probably inside of a conditional statement, so that they don't become defined until that conditional statement is true. function definitions should all be grouped together and come near the start of your code or even be in a separate file that gets included near the start of your code.

the WHERE clause would be - WHERE YEAR(LastVisit) = whatever_year_value_you_want i'm pretty sure this would have the same level of performance as your Last 6 months query.

and the multi-value update can be implemented as the following without having to dynamically produce case logic in the query (assuming that id is a unique index) - INSERT INTO tablename (id,col2) VALUES (1,'AAA'),(2,'BBB'),(3,'CCC') ON DUPLICATE KEY UPDATE col2=VALUES(col2)

no. you have to find what''s causing the problem, before you can fix it. the javascript would apply to the client-side rendering time, which isn't much, compared to the time waiting for the server to send the response.

i just checked the http://www.compareandchoose.com.au/adventure_activities page at both http://developers.google.com/speed/pagespeed/insights/ and http://tools.pingdom.com/fpt/ and the large amount of time taken, ~2 seconds, is waiting for the response back from your server, rather than things the browser must do to render the the page. the amount of time is fairly consistent, over about a 5 minute period i checked. you will need to profile what the code is doing in order pin down where it is spending this amount of time.

you need to determine the page generation time, by taking the microtime(true) value at the start of the code on a page and again at the end of the code on the page, and calculate the difference. this will tell you if the problem is with the generation of the page or elsewhere, such as in the web server taking a long time to actually invoke php after the http request was received. if it turns out the problem is in the page generation, you need to calculate the time taken at different points in the code, around database activity, around calls to external api's, ... to narrow down where the time is being consumed.

have you done any debugging to make sure that the $_FILES data is what you expect? also, there are at least three problems with what you are showing use in that code - 1) you should validate that input data exists and is what you expect before using that data. your code should never get to the point of running a query unless you know you should be running that query. 2) isset($_FILES["fileField"]) that $_FILES element will be set, even if there is no valid uploaded file. if a user doesn't select a file and likely for some of the possible upload errors, what you are testing in the isset() statement can be true, but the ['name'] element that you are using can be empty. this is actually related to the above item. you shouldn't be testing for data at the point of using it in a query. by the time you get to the point of forming and running the query, you should have already determined if there's data present. 3) "all other text fields update fine". unless you removed lines of code from what you posted, that implies you are repeating similar code for each field and are running a separate query for each field. that is a database killer. you should update all the fields using one query (note: if none of the values being updated have changed, mysql doesn't actually update the record.)

in programming, a simple typo in a variable name, can cause your program logic to loop forever, because the code is no longer testing the correct variable. if you cannot find the problem in your code that is causing this, you will need to post the code that reproduces the problem.

any particular web hosting may have restrictions on how to send email through their mail server (and may not even supply a sending mail server, your friend that can send emails may be sending them through some other mail server.) what is your free web host's name and have you checked their FAQ section on sending emails? common problems would be a mail server that's set up to require smtp authentication or problems with the From: address (or lack of) being used in the email headers.

some comments - 1) ALL the form processing code needs to be inside of a logic test that has checked if a form was submitted. if a form was submitted, all the form fields (except for unchecked checkboxes and un-selected radio-buttons) will be set, even if they are empty. 2) you should trim() all inputs before validating them. 3) you should validate all inputs to insure that required fields are not empty and that anything in a field is of an expected format and is not nefarious. 4) any user input that's put into the message body should be passed through htmlentities() (even if you are sending a plain text email, since email clients can be configured to view the email as html even if it is not) so that should you be using a browser as the email client to view the email, any javascript that was in the submitted message won't be rendered. 5) the email address that's being put into the mail header MUST be validated to insure in only contains an email address and nothing else that could be used to inject other headers into the email. 6) you should produce a specific error messages for each input that didn't match the expected format to tell the visitor what they did that was wrong, so that they can correct the problem. validation errors should be added as elements to a php array variable. 7) you should re-populate the form fields with any previously entered data so that the visitor doesn't have to re-type the values. doing this and displaying any validation errors is easiest if you have one page that contains the form and the form processing code. the email is not being sent from the person who submitted the form. it is being sent from a mail server at the web host where the form was submitted to. the From: address in the mail header is either an email address with a domain name that can be matched to the ip address where the sending mail server is at or if the domain doesn't match where the sending mail server is at, that there's an SPF DNS zone record at the domain being used in the from email address that says your sending mail server is authorized to send email for that domain. 9) you must test the value returned by the mail() function to determine if the sending mail server even accepted the email (it still may not be sent and the receiving mail server may not accept it) before displaying any sort of success message. 10) and because getting email to actually be sent is something of a problem due to all the spam abuse, you should log the relevant information about each form submission so that you know what's going on.

web servers can handle several 100's of requests per minute. just using the timer/ajax-request method will work for a casual chat system. you would want to make each request/response as brief as possible and make the server side code as efficient as possible, off loading as much formatting/processing onto the client as possible. the client side request, which should be a GET request btw, would include the id of the last message that has been displayed for that user. the server would just query for and retrieve any new messages with id's greater than that id. at a minimum, the message id column in the database table would be indexed. if there's no new messages, the server should return a simple status value to tell the client side code it doesn't need to do anything, perhaps just an empty json encoded array. if there are new messages, just return the raw message data, leave any formatting/display to the client side code. make sure that the database server has query caching turned on as well. when data in the database table hasn't changed, the same database query being made from multiple clients will return data from the cache rather than retrieving it from the database table. you can have 100's of clients all waiting for a new message and they will keep getting the result from the cache that there's no new messages until there actually is one that was stored into the database table, altering it, which causes the cache to be cleared so that it will then cache the new message(s) for the next series of update requests.

in the context of a monthly calendar, what do you want to display? displaying every open time slot for even one trainer (what if you have 20 trainers) would not be piratical. your monthly calendar could at best show a clickable 'event' on the days that have available bookings (and a non-clickable, 'full' listing for days that have no open time slots), either just one event total, if any of the selected/filtered trainers have an opening, or one event for each selected/filtered trainer that has an opening on that date, with a hoover/pop-open tool or a link that gives you a view/page that consists of the booking grid with the open time slots for the clicked on date. a monthly calender could be used for the appointment confirmation. you could display an 'event' on any days that have any un-confirmed appointment(s), for the currently logged in trainer. clicking on the 'event' would take that trainer to a grid of un-confirmed appointments that can then be reviewed and approved. assuming that a trainer would have the need to cancel an appointment, you would instead display an 'event' for all days that the trainer is available. clicking on any day would take the trainer to a grid that shows un-approved and approved appointments on that day with choices to approve/cancel each appointment.

there are existing resource availability/resource reservation scripts that probably do this in some fashion (likely for reserving/booking rooms, rather than a trainer, but the logic is the same.) you would need a table to hold the resource (trainer) availability schedule, all resources in stored in the same table, using a resource id to identify which rows are for each resource. for reoccurring schedules, you would need to store the definition of the schedule (Mike is available on Mondays-Friday from 8am-5pm) and evaluate it, storing the resulting dates and times in the availability schedule table, as needed (any query displaying data with a date higher than the latest stored date would evaluate the definition to populate dates up to at least the latest display date.) you would have a second table to hold resource reservations, with the resource id, the id of who is requesting the resource, the date, start time, end time, and a status. the status would indicate if the resource has been requested (someone selected a date/time slot, but it has not been confirmed) or booked (if the trainer has reviewed and confirmed the reservation.) any resource reservation with either of those status values would not be available for selection. if there is a preference for a particular resource or type of resource, you would get and apply a filter in the query that determines which resource id(s) you match in the resource schedule table and for just the date(s) you are trying to display. you would then join the rows from that table with the resource reservation table, using the resource id and date columns, to get the row(s) and therefore the start/end times the resource is (is not) available for selection. that should get you the data you need to display a grid of appointment slots that are (are not) available for selection.

besides listing what you want, do you have a specific programming question or a problem you need help with?

and, even if the session variable are being set as expected in the login() function, if the session start on that page has failed (there would be php errors), the login isn't actually working because the session variables will only exist as local variables and won't be propagated between pages. did you set the error_reporting/display_errors settings on each page or better yet those should be set in your php.ini on your development system so you don't need to remember to put them into code for debugging and remove them when you put your code onto a live server.

the suggestion to use a bootable linux cd wasn't to install linux, it was to boot to an environment where windows isn't running so that you can delete the file without it being locked by the windows operating system.