PFMaBiSmAd

Try this - http://www.phpfreaks.com/forums/index.php/topic,271402.msg1281020.html#msg1281020

Is the hostname correct? On most shared web hosting, it is not 'localhost'

That's not that much data. Adding a cache won't help fix problems in your code or problems between your code and the database. You would need to post the code for your page that is experiencing the problem for anyone to have a chance at helping find what the actual problem is.

You have no database connection present at the point where the UPDATE query is being executed. The mysqli connection is being made later in the code and the mysql connection is right before a SELECT query near the bottom of the code. Are you developing and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON so that php would help you by displaying all the errors it detects? Edit: And remove the error_reporting(0); line that is in the code now as that just hides errors that would help you find why your code is not working. Attempting to learn php, develop php code, and debug php code without using full php error_reporting/display_errors and without using mysql/mysqli error reporting on query statements is like a blind guy trying to drive down the highway. You might eventually get where you are going (produce code that works) but it will take you a very long time and when you get there you will be in a world of hurt.

You need to change your code so that the UPDATE query string is being built in a variable (then just put that variable into the mysql_query() statement) so that you can echo out the actual query after it has been populated with the variables so that you can see exactly what it contains. Your code produced the expected query when I tried it, however I faked the values from the database. It might be that your actual values contain something that is preventing them from working after they have been passed through two different forms... You also need to use mysql_real_escape_string() on each piece of string data being put into every query to prevent any special characters in the data from breaking the syntax of the query and to help prevent sql injection.

Most applications include/require a configuration file and any functions/classes as the first thing they do. You would put any global application settings like session.gc_maxlifetime and session.save_path into an "initialization" function and call that before the session_start() statement.

Also, if you do a "view source" of the edit form in your browser, you will find that in the following line, $_POST[comment_id] did not get replaced with the actual value because the overall string is using single-quotes and variables are not parsed when in a single-quoted string - echo'<input type="hidden" name="commentid" value="$_POST[comment_id]" />';

.htaccess files are specific to Apache and php settings can only be put into a .htaccess file when php is running as an Apache Module and as you found out, only when the web host has permitted php settings to be changed using a .htaccess file. A local php.ini is specific to php running as a CGI application and only when the web host has permitted php settings to be changed using a local php.ini The only universal solution for the session.gc_maxlifetime setting is to put it into the code before every session_start() statement. You would also need to set the session.save_path before every session_start() so that it points to a private folder so that only your session settings apply to your session data files.

A session consists of the session id from the browser and the matching session data files on the server. To prevent the session data files from being deleted on the server you must set session.gc_maxlifetime to a longer value. You apparently have root access to your web server. Why not just change that value in the master php.ini?

That's correct. That's because browsers don't pass any cookies back and forth between HTTP and HTTPS protocols. They maintain separate cookie caches to prevent the HTTPS session from being hijacked once it has been accessed through HTTP. If you have something important enough to use HTTPS, you need to establish the session using HTTPS. You would need to post the actual settings for someone to help with them. Also, examine you web server error log for more information about what is causing the error. Also, is php actually running as an Apache Module or is it running as a CGI application?

Does that mean it worked on the same server where the modified one does not work? We know that because you would not be writing a post on a help forum. Just telling us that something does not work is pointlees. What exactly is it doing when you try it? Unless you provide the symptoms to narrow down the dozen possible things that could cause a script to not work on any particular server, no one can directly help you with the problem. What did you see in front of you the leads you to belove it is not working? Please tell us which ones or at least which fields are the originals so the we would have a clue about which areas in the code you touched.

Adding these header statements to your pages should prevent the browser/proxy/server from caching the content - <?php header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1 header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past ?>

If you are concerned about security or someone cheating in a game, you need to remember the answer on the server and pass it between page requests using a session variable.

The third setting would cause any switching back and forth between www.yourdomain.com and yourdomain.com to give two different sessions. Are you redirecting or have links that would cause pages to be reached both with and without a www. on the URL? Beyond that, perhaps pages are being cached on one system and not the other so that visiting a dynamically updated page shows the previous contents instead of the changed value. If you force your browser to refresh the page, do the values show up correctly?

Yes, if you actually have two separate sessions. This could occur if when you go between pages where the PATH or DOMAIN (host name/subdomain) changes in the URL and the session cookie settings are not setup to permit different path/domain values. You can also get variables that seem to change values when there is nothing in your code that causes it if register_globals are on and you have other POST/GET/COOKIE/program variables with the same name as the session variable. What does a phpinfo() statement show for the following settings - register_globals session.cookie_path session.cookie_domain

I did some testing and the reason php.net probably put the 'bug compat' warning message in is because when register_globals are OFF and session.bug_compat_42 is ON (i.e. make the bug still work), session_register() still associates the named program variable with the session. It does not actually cause the value in the $_SESSION variable to change in the script, but when the session data file is saved, the value in the program variable is what is written to the session data file if you don't have an assignment statement setting the $_SESSION variable in the script. session_register() acts like a 'mini' register_globals for the one specific variable. This also means that the php documentation for session_register() incorrectly states it does not work when register_globals are OFF.

Is the link present in the HTML "view source" of the page in your browser? If it is, then you have a CSS problem.

Edit: never mind, I see you did post what I asked for.

It is likely that the web server is setup to prevent you from overridding settings in a .htaccess file. There needs to be an appropriate Apache AllowOverride setting in order for you to be able change settings through a .htaccess file. Any instructions stating you can put php settings into a .htaccess file when php is running as an Apache Module, come with an implied "and your web host permits it."

It would take seeing your actual code to help with what is wrong with it.

Because FILTER_SANITIZE_SPECIAL_CHARS is only to protect HTML, not mysql - single and double quotes have ASCII values greater than 32, so FILTER_SANITIZE_SPECIAL_CHARS does nothing for them. You should only use mysql_real_escape_string() to escape string data put into a mysql query, that is what it is for.

session.bug_compat_42 and session.bug_compat_warn can be set anywhere. .htaccess file (if php is running as an Apache Module) local php.ini (if php is running as a CGI appliction) in your script (though I doubt this will actually turn the warning off.) Edit: and you should contact your web host to get them to turn those settings off in the master php.ini, because there is ABSOLUTELY NO reason for those settings to be ON.

One check you can do for yourself is to create a .php script with a phpinfo(); statement, then browse to this script and search on the resulting page for any settings containing the word suhosin. The setting in question, if it is present and if it shows up in the phpinfo() output, would be suhosin.post.max_vars Edit: actually your .php code is only slightly helpful because we don't have access to all the parts necessary to test it, like your database, include files... What would be helpful though, assuming that the problem is in the form and not the server, is if you attached the html "view source" of a form page that doesn't work. That would let someone examine and/or test if it contains a valid form with all the 300+ fields correctly represented and if they do post correctly. Make sure you xxxxx out any sensitive information, but don't alter the html on the page.

One of the columns you are inserting must be defined as a key and you are attempting to insert a value that already exists.

Both from and to are mysql reserved keywords - http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html If you were using mysql_error() to troubleshoot why your query is failing, you would be getting sql syntax errors at those keywords where they are being used as column names. You should rename your columns to something else.