mac_gyver

you can get a count of how many correct matches there are directly in the sql query, without writing out all that code. also, once you have the $arr with the 6 numbers, you don't need the foreach() and for() loops. however, all of this will require that you set up your database table correctly, with the data normalized. you need to store each number that the user has selected as a separate row in your table. your table would have columns for - draw, user, and num. yes, there will be 6 rows for each user for each draw. the query to get the count of correct matches will look like this (untested) - $query = "SELECT user, COUNT(*) as num_correct FROM your_table WHERE draw='$draw' AND num IN (".implode(',',$arr).") GROUP BY user"; if you only want the users that have matched all 6 numbers, the query would look like this - $query = "SELECT user, COUNT(*) as num_correct FROM your_table WHERE draw='$draw' AND num IN (".implode(',',$arr).") GROUP BY user HAVING num_correct = 6";

are you getting a header error due to outputting something (or even your file having been saved with a byte order mark character) before the setcookie() statement? having php's error_reporting/display_errors set to report and display all php errors, when debugging code problems, will help.

what debugging steps have you taken to try and find the problem? is the data being submitted from the browser to the server? is the code where the insert statement at being ran? is the insert statement correctly formed? is the insert statement producing an error? since the code is using ajax to post the data, does it have the ability to display any message that the php code might be producing if there is an error on the server?

you would output a selected='selected' attribute inside the correct <option ...> tag that corresponds to the previously submitted value, if any. however, by making the select menu available during the edit phase, you create a situation where a user can retrieve the data from one record and easy (fumble-fingers) submit/overwrite a different record. to prevent any possibility of accidental/intentional miss use, at the point of editing the actual data, you should store the id of the record being edited in a session variable, out of the hands of the person involved, and don't display the select menu (or display it for reference, but ignore the input value from it.)

your select menu is not persistent (doesn't pre-select the existing value), so, on the update form submission, $_POST['view'] has the value from the first option - <option value="">Select</option>

web servers are stateless. each request for a page is completely separate from all other requests to the server. except for session variables, the only way any variable can exist is if it was supplied with a value on that particular request. if $_POST['view'] was set as the result of one form being submitted, it will only be present on that one page request. a different form submitting data will only supply the data corresponding to the fields in that form.

does the form that sets/submits $_POST['update'], also have a field named 'view', so that $_POST['view'] would have a value on that particular page request?

you need to debug what your code is doing, in order to find out at what point the program and data are correct and at what point they are not, in order to narrow down the problem. also, using call_user_func() with user supplied parameters, without validating those parameters, will let a hacker run any php function. you need to validate that $actionfunction contain only and exactly one of the permitted function names.

what does the following debugging code, added immediately after the line with the <?php tag in the insert3.php file, show - echo "<pre>"; echo "POST:"; print_r($_POST); echo "FILES:"; var_dump($_FILES); echo "</pre>";

you didn't state what sort of problem occurs at that point. is it a memory error or a timeout/maximum execution error? how many id's do you need to retrieve information for? does the site/api you are reading have a way of getting data for multiple id's in one request?

i'm going to go with this was caused by some specific content in a notification tripping up the code (hackers are known to put things in posts, hopping that the content gets viewed in the back-end by member's with elevated privileges or that the content gets sent via emails to staff/members to try and infect computers via the email client.) afaik, (i should have checked this while i was logged in as you), nothing has been changed permission wise that would have removed your ability to see and use the flag as spammer button. if you are referring to the previously reported post by you, perhaps someone else hit the button before you and it was no longer present when you tried?

just a minor point, but your search form is specifying what will be displayed/gotten on the page and should use the get method. this will make it easier to propagate and combine the search/keyword term in url's since it will already be a $_GET parameter.

i pruned all your notification records except for the 5 latest, after the spam-y one, and logging in as you (hopefully this didn't log you out) shows me them in the drop down. does this work for you now? if not, do you get just the circular spinning arrow ajax activity indicator or does it go on and display the notification box with only the heading information and none of the 5 remaining current notifications?

and did you add the two error_reporting/display_errors setting lines to the profile.php page?

i pruned your records down to ~150. see if the notification list is being displayed now? there also is a recent record triggered by a spammer posting in one of your followed forum sections and something about the characters/content from the post being put into the notification could be causing this. if notifications are still not being displayed after the pruning of records, i will delete that specific notification to see if it has an affect.

have you been receiving notifications since you started this thread? the ipb database table shows recent 'followed forum' notifications for things like the 'Whats the big deal on converting to mysqli" thread. I suspect that you reached some limit that the programmers (term used loosely) never considered. you have approx 400 notification records. reply back if this still isn't working, and i will prune some of the older notifications to see if it has an affect.

single quotes aren't operated on by default. see the list of flag parameters in the php.net documentation - http://php.net/htmlspecialchars

the most likely causes of the problem with the code is that your file(s) are outputting something to the browser before the session_start() statement (your localhost development system may have a setting turned on that allows the code to work under this condition) or that sessions are not configured correctly on the server. please post the first few lines of your code showing where and how you added the two lines that i suggested.

the code is way out of date (about 13 years out of date) and is dependent on register_globals being on. rather than to patch it up by emulating register_globals, which introduces a huge security hole, by allowing any session variable to be set from any $_POST/$_GET data a hacker feeds your script, you should access the correct $_POST, $_GET and $_FILES data that is being submitted to the code. while you are updating things, the mysql_ and ereg_ functions are obsolete and will be removed from php in the future and should be upgraded to equivalent PDO/mysqli and preg_ functions. i also see a bunch of stripslashes() statements, indicating that php's magic quotes settings were messing up your data. the magic_quotes and register_globals both have been removed as of php 5.4. you will also want to properly escape (using the database library's escape string function) string data (addslashes(), which is what the magic quotes used internally, is not sufficient) being put into sql queries or use prepared queries to prevent sql injection and errors when string data contains sql special characters. edit: another thing the code is using that will cause you problems moving between server configurations is the short opening php <? tag. you should always use a full opening php <?php tag so that your php code will always be seen as being php code, regardless of the php configuration. and in general, to clean up the code, you should have the php 'business logic' that controls what happens on the page, processes form data, and retrieves data displayed on the page, grouped together near the start of the file and the 'presentation logic' that is producing the html/css/javascript on the page near the end of the file. the only php code in the presentation logic should be simple loops/echo statements that makes use of the data from the business logic. and even more, the htmlentities() and nl2br() functions are OUTPUT functions, used when displaying information on a web page. they should not be used when inputting data into a database table.

if you were previously getting the - Você não está autorizado a acessar essa página, favor fazer o login. message from your code, but now you are getting a http 500 error after adding the two error_reporting/display_error lines, that would indicate that you messed up the php source code somehow and it's likely producing a php syntax error. review where and how you added those two lines of code to make sure the php syntax is not broken.

are the << links present in the 'view source' of the page? i'm guessing that when you are outputting the content on the page, you have some broken html that's eating the links and they are not being rendered correctly. also, according to the program logic, those links don't appear on page 1. do they show up when not on page one?

you are likely having an error with the session_start(). for debugging purposes, add the following two lines of code immediately after the first opening <?php tag in your main files, i.e. the files that are being requested via a url, and see what sort of php errors there may be - ini_set("display_errors", "1"); error_reporting(-1);

i recommend creating an array that holds your form definition (the display/legend text, field type, field name, and validation type information), then loop over this defining array, to produce the html of the form, and use the array data when processing and validating the submitted form data. here is a recent thread showing the basic layout of a form/form processing code - http://forums.phpfreaks.com/topic/294898-required-fields/?do=findComment&comment=1506734 my suggestion of using this defining array would be in addition that what is shown in that thread and would replace the writing out of the html for the form fields and the writing out of the validation logic for each form field with code making use of the array data instead to control what happens.

the settings all look okay. at this point i would suspect either a coding problem (code is running that clears the session) or the host-name/sub-domain name is changing in the url's (with no session.cookie_domain setting, the session id cookie will only match the variation of the domain name where it was set at, so if you are switching around between url's that have and don't have the www. as part of them, the session will alternate and only appear when the requested domain matches where the session was started.) other than obvious coding problems (like missing exit; statements after header() redirects that lets code run that modify session variables or logout code that gets ran just because a page on your site got visited) you will need to debug what's actually going on. you will need to look at the session id cookie in your browser to make sure it is set and what the session id is, echo the session id in your php code, to make sure it matches what's in the session id cookie, and even look at the contents of the session data file, that has the same name as the session id, to see when the data in it gets deleted. also, do you have any sort of session regenerate or session destroy statements in your code that could be messing with the session data? does your login code check if someone is already logged in and skips processing the request and does it check if a form has been submitted? it may be that the browser is requesting the login page, without any form data, thereby not matching any user and clearing the session variables. do you have any sort of ajax based requests going on that could be doing this in the background? edit: btw - the session cookie lifetime only matters if you expect the session cookie to be remembered by the browser when all instances of your browser are closed. the session gc_maxlifetime is the setting that could be causing the problem, in which case the session data file itself will be missing (looking for the actual session data file will help to pin down if the file's being deleted or if code is clearing the session variables.)

if the information you posted above is a control panel that's modifying the master php.ini, the settings won't take affect until you stop/start the web server. and you still must check what settings php is actually using by using a phpinfo() statement, as things like syntax errors in the php.ini and the wrong php.ini being used, will cause default php settings to be used, not the ones you have set.