PFMaBiSmAd

So, you did not actually provide us with any information about how these sites are hosted. Are they hosted at the same web host and do they have access to the same database server?

A DATE data type in your table is formated yyyy-dd-mm (for several reasons.) The data values you put into the table must be formatted that way (for several reasons.) If you want to retrieve the data with a different format, you use the msyql DATE_FORMAT() function in your query or you write some slow php code to do the same after you retrieve the data.

And APC can be found here - http://downloads.php.net/pierre/

The GD and curl extension .dll files COME with the Windows binary distribution. There is no need to compile them or php in order to use them. You must simple make sure that php can find the ext folder and enable them in the php.ini. Edit: Likewise for openssl.

Seriously, did you bother to read the error message. The first parameter ($conn) in your code (mysqli_query() expects parameter 1 to be mysqli) is a null (null given). You must pass the $conn variable (assuming that is what your mysqli connection is in) into your function as a parameter when you call the function.

Seriously, that error message is blatantly self explanatory. Did you bother to read it - In your database: transtar_07LhCwo, there is no table wp_posts. You either have the wrong database selected or the table wp_posts does not exist with that spelling and capitalization (assuming you are on an operating system that is case-sensitive.)

^^^ you apparently already have a table of user information in a database, why are you even messing around with a file? If you are just verifying acceptance of some condition, you would just add a 'verification' or a 'status' column to your user table.

The error message is fairly self explanatory, $result->fetch_object() is on a non-object. Therefore, $result is a non-object. Since $result is being set in your code by $result = $mysqli->query($sql), doesn't that suggest that the code failed to return an object and you would need to debug why a call to the ->query() function was failing? If you echo $mysqli->error it will tell you why your query is failing.

You are opening and closing the file, but not writing to it. Did you proof-read your code to make sure it was attempting to write anything to the file?

Problems with php code breaking due to upgrades are usually due to php.ini configuration differences and php code that is relying on outdated php functions and non-recommended php.ini settings. You did not state if the php version was changed, however, there are very few incompatible differences when going up to a higher php version. If you have the previous php.ini, I would use a program like Winmerge ( http://winmerge.org/ ) to check for differences with the current php.ini. I would also check using a phpinfo(); statement that the php.ini that is actually being used (the Loaded Configuration File value) is the one that you think it is. Setting error_reporting to E_ALL and display_errors to ON would also likely point out anything like session errors (perhaps the session.save_path no longer points to a valid folder or one with the correct permissions.)

array_slice is probably the best bet to get the 8th - 15th elements of the array you want for further processing.

Only if the function returned a URL of the resulting image. The src="..." attribute must contain a URL since the browser fetches that URL and expects an image to be returned at that URL.

Yes, but you did not provide any information in your post as to what result you ARE getting vs what you expect. For all we can tell, you are then storing this information in a database and using DB query functions that are using the database's timezone setting and not matching the correct information.

If you use <pre> </pre> tags around your print_r() statement, it will make it much easier for you and others to see what your data actually is - echo "<pre>",print_r($Features,true),"</pre>";

Coming up with the to x value is rather straight-forward, simply take the starting number and add the mysql_num_rows() value to it. On full pages, where you queried for 20 results, mysql_num_rows() will be 20. On the last page, mysql_num_rows() will be just the number that was actually retrieved.

In case you have not made any progress on this, the actual problem is because mysql_ASSOC that you are using in mysql_fetch_array() is incorrect. It should be MYSQL_ASSOC Due to this error, you are not actually fetching anything and assigning it to the $_SESSION variables. I determined this rather quickly (it has taken me longer to compose this reply than it took to find the problem) by executing the code on a development system that has the error_reporting and display_errors set in the master php.ini as previously suggested and doing a little debugging (commenting out the header() and ob_end_clean() statements) so that I could see what is happening in the login code. Now, please remove all the ob_start();, ob_end_clean();, and ob_end_flush(); statements from your code. You should only use output buffering if you want to buffer output for capturing it, not to fix problems in your code. The ob_end_clean() function in particular in your code is hiding/cleaning the php error message you would get about the mysql_ASSOC problem. If your MYSQL file (which I assume contains your msyql_connect() and mysql_select_db() code) also happens to contain your database connection username and password, please change this file so that it has a .php extension so that if someone discovers it and browses to it that they cannot see the username/password (without an extension, the contents of the file will be output as is, with a .php extension, the php code in the file will be parsed as php code and only any output it sends will be seen, which is likely nothing.)

Yes, read and follow the last advice you were given to troubleshoot why your query is producing an error.

By using the correct variable that is holding the file name, like someone told you above ...

The error is likely because of the short open tag <? - http://www.phpfreaks.com/forums/index.php/topic,303067.msg1433865.html#msg1433865

It wasn't until reply #5 in this thread that you posted actual code that exhibited the symptom you were claiming. What a waste of time.

There are several all in one - Apache/php/mysql triads that can be installed on almost any personal computer - http://www.apachefriends.org/en/xampp.html Yes, those two error_reporting/display_errors setting should work. You should only put them into the file you are trying to debug (assuming you can identify which one) so that it is easy to remember to take them out later. They should generally be put right after the first opening <?php tag in a main file so that any runtime (they won't help with parse errors) errors produced by any of the actual code are reported and displayed. By having a local development system, you can set those settings in the master php.ini and you won't ever need to worry about where they are at in your code or remember to remove them when you put your code onto a live server.

And is this page being requested using a URL, like http://localhost/handle_reg2.php

You should NOT be attempting to learn php or develop php code on a live server. You are literally wasting hours of your time uploading code just to see one result and until code is completely tested and debugged, it often has security holes that would allow a hacker to exploit a live server. Actually, since you are including the .html file into (hopefully) a .php file, what I wrote concerning the .html files does not matter. Except that does not report or display anything unless you have error_reporting/display_errors set to report and display correctly.

What file extension are you using on that page? All you are seeing is the raw un-parsed php code being output on your page (do a 'view source' in your browser.)

A) Have you configured your server so that .html files get parsed as php code so that the php code in header.html is being seen as php code? B) Are you developing and debugging your code on a system with error_reporting set to E_ALL and display_errors set to ON in your php.ini so that all the errors php detects will be reported and displayed? C) global_variables? There is no such setting and if you were actually writing about register_globals, C-1) Don't turn them on (ever), C-2) They don't have anything to do with why your code does not work.