mac_gyver

if you don't close the connection in your code, php closes it when php finishes processing the page. when php finishes running the code on a page, either normally (reached the end of the page or an exit/die/return statement) or abnormally (a fatal error occurs) it runs a 'clean up' routine that destroys all the resources used by the code on the page, which would close the database connection. inline html, that's outside of any php tags, is still actually php code. there's an inline html php token it gets converted to (T_INLINE_HTML), which simply outputs the inline html when that token is interpreted when the php code runs on the page.

it's a deprecated alias -

you would write the information about each error to a log file. you would then scan the log file and only send an email when you want. you would normally use a cron job to trigger the scanning of the log file.

you are correct, each database connection is only open for a fraction of a second. by the time the browser renders the page and someone actually starts playing a video, the instance of your script that output that page has long since ended, closing any database connection that was open on that page request. 25 concurrent connections is fairly low. large sites handle this problem by not using shared web hosting. your page could be partially at fault if it is opening more than one database connection per each invocation of your script or of opening/closing a connection for each database operation on the page. you would need to look at the web server access log to see if there really are 25+ concurrent requests to your page and where they are coming from.

you are going to need to debug what your code IS doing in order to find out what is causing the problem. some value(s) are either not being set (given the number of html errors on the page, this is a possibility, the browsers it works in may be more forgiving of the errors) or are being set to an value that the code isn't expecting (different browsers send different things in the same situation that code needs to take into account.) i did notice that the form is setting a hidden field, that hopefully is being tested in the php code to determine if the form has been submitted, so the php code should at least be able to detect that a form was submitted. unless there's an obvious problem or a specific error message that points to the problem, there's isn't a single answer to 'Contact form not sending in IE or Safari'. you must track down what is happening to reduce the possibilities to just one or two that can be investigated further. if your site receives a lot of visitors, it would be best if you logged all the data values that get submitted when the contact form is submitted, along with the browser's user agent string. you can then look at the logged data and determine why the code isn't doing what you expect it to do.

the first parameter of the date() function is a string. when you don't quote it, it is first tested as a defined constant, which throws a php error because it doesn't exist, then php assumes you meant a string and tries the value a second time as a string.

things you display on a web page are just for display purposes. if you need the total on the server, you should calculate it from the original source data values so that someone cannot alter the DOM in the browser and submit any value they want to your server-side code.

we cannot tell you why your code is not working without feedback from you. there's a dozen different possible reasons your code is not logging you in. you must do some debugging to find out what your code and data are doing on your server to narrow down the possibilities. the suggestions i made about php's error_reporting/display_errors and PDO's error mode were a starting place to get some information about what might be going on, since you have provided no information other than 'it doesn't work'.

don't hijack threads for your problem. topic locked.

@blacknight, it's not that people don't like it, it's that it produces bad code that's harder to maintain because it requires that the programmer keep track of a greater amount of information, making his job harder and making it harder for anyone in the future to make use of the code or make changes to the code. using global to being a value into a function breaks the black-box model of writing functions. the only interaction a function should have with the calling code is at the point where the function gets called.

when you use OOP mysqli syntax, the connection (new mysqli(...)) will always return an object. you must specifically test for connection errors using one of the two methods shown in the php.net documentation - /* * This is the "official" OO way to do it, * BUT $connect_error was broken until PHP 5.2.9 and 5.3.0. */ if ($mysqli->connect_error) { // your error handling code here... } /* * Use this instead of $connect_error if you need to ensure * compatibility with PHP versions prior to 5.2.9 and 5.3.0. */ if (mysqli_connect_error()) { // your error handling code here.... } had you used the procedural mysqli_connect() syntax, your testing of the $db value would have worked. i recommend skipping mysqli and use PDO as it has far fewer consistency problems like this, especially if you are going to use prepared queries.

your code has no apparent error checking logic in it and any of the pdo statements could be failing due to errors. after you make the pdo connection, you should set the error mode to exception and you should set emulated prepares to off/false. you should also have php's error_reporting set to E_ALL and display_errors set to ON when debugging any code problems to get php to help you. you also need to use the same password hashing method in the login code that was used when the user's account was created. what exactly is your user registration password hashing code?

the answer is similar to one of your previous threads, you pass the instance of the database into your function as a call time parameter.

he's already getting a php error message, but apparently didn't read it or look at the line in his code that's triggering it.

it would help if you provided some context for the last error message. what exactly were you doing when you got that error?

the page you linked to has a ton of html and css errors and warnings (check at validator.w3.org) i even see an external javascript file being referenced before the <!DOCTYPE tag, meaning the the browsers cannot find the doctype and there are also several external javascript files being referenced twice. there's even a couple of form input fields that aren't within a form. you need to correct ALL of the html, css, and javacript problems first, since different browsers will behave differently when errors are present in the page you send them. i also notice that the forms don't have any action='...' attribute. i don't know if you are submitting the forms using javscript or counting on a nonexistent action to submit to the same page, but in either case, the variation of the url may be changing (the host-name/subdomain), relative to the session id cookie, and this may be causing the code to not behave as expected. what exact indication/output do you receive, in the case where it doesn't work? this would at least tell us what it is you see when you try it when it doesn't work, in order to narrow down some of the possibilities.

we are not here to fix or change your code for you. we are here to help you when you try to fix or change your code. since you didn't write this code, moving thread to the 3rd party forum section.

the error message is referring to this line - $db->free(); there is no mysqli free() method. there is however a mysql_result free() method, which for your code would be $result->free();

in general, to delete information you would - 1) make a post method form (you are modifying data on the server, so by definition, post method should be used.) the form should submit the id of the row you want to delete. 2) your form processing code would first make sure that there is a currently logged in user, then make sure that a form was submitted, take the submitted id value, validate that it is of an expected type/value, then use it in the WHERE clause in a delete query. 3) the delete query would include a condition in the WHERE clause to make sure that the current logged in user OWNS the row that's being deleted to prevent anyone from deleting rows that are not their own. without seeing your code, it's not directly possible to help you with what it might or might not be doing.

if would help if you told us or showed us what output you are getting. just telling us you are getting no result can mean a number of different things. what output are you getting from the code? as to the mysqli code, your connection and connection error checking is a mix of procedural and oop usage that isn't correct. it also looks like it had a trigger_error() statement in it at one point that got removed. the php.net documentation contains examples of using procedural code to make a connection and testing if the connection worked. you should start by reading the documentation.

if the code is going to be redone using PDO, why did you or someone else take the time to switch to mysqli first? just because the mysql functions are depreciated does't mean that they still don't work. you could have safely ignored/suppressed the depreciated error on the mysql_connect() statement.

another thing to add to your list of to-do's. you should style the elements on the page using css. the <font> tag is obsolete along with most of the inline styling in your markup.

the suggestion to use http_build_query() was to produce general purpose code for your pagination links that doesn't need to be changed every time you change something else about your urls. what happens if you change the field you are searching, add a dynamic number of results per page, or add the ability to change the sort order? are you going to go into your pagination code and edit the links to add each of these possibilities? the answer to that question should be a no. using http_build_query() to use any existing get parameters, just set the pagination parameter to what you want, and use the combined result to build links would mean that you don't ever need to change the pagination code should anything else about your urls get changed.

because you are using a post method form for your category, the submitted $cat_name value is only present on the one page request that the form submitted to. on all other page requests, there is no $cat_name value and the where clause becomes WHERE category='', which is likely a false value and doesn't match any rows in your database table. so, two things - 1) you should ALWAYS validate inputs and take an appropriate action if they are not an expected value. if there is no $cat_name value, your code should do something predictable. either output a message that no category was selected and don't even attempt to run the database query or form the database query without the category in the WHERE clause and match all categories. 2) you must propagate the $cat_name value (which should actually be the category id, not the name) in your pagination/sort links. the easiest way of doing this is to make your category form a get method form (or just use links for the categories) and build your pagination links using http_build_query(). btw - your code needs some help. some of these things are causing the code to not do what you expect. also, fixing these things will organize and reduce the amount of code, making it easier for you and for us to see what it is your code is trying to do. 1) you are using both mysql and pdo database statements. you should use only one type and since mysql is obsolete, use pdo throughout all your code. 2) you are including config.php twice. once is enough. 3) you are running code setting variables that don't ever get used, such as the $num variable. unused code should be removed. 4) you should enable exceptions for your PDO database connection so that any errors that occur with the query statements will throw an exception. you should also disable emulated prepared queries. 5) you should NOT use any @ error suppressors in your code. for variables that might not exist, use isset() to test for them and take an appropriate action if they are not set. 6) your pagination is actually 'rowination' you are specifying the starting row in the links. you should be specifying a logical page number. 7) to get a total row count, you should use a COUNT(*) query. selecting all the rows from your table just to get a count of the rows is not efficient. you are using a prepared() query when there's nothing in the query that requires it to be prepared, then you are running a non-prepared query when you do have external data being put directly into the query. these should be the other way around. 9a) the query that gets a total row count and the query that gets the actual data to display on the page MUST have the same WHERE clause. the WHERE clause should be built in a php variable and used in both of the sql query statements. 9b) the vis='yes' condition must also be in the WHERE clause for the two queries (or you could create a database 'view' that contains this condition.) if you do item #11 in this list, of reorganizing your code, having all the main php code together, without it being mixed in with and cluttered up by the html markup will make it easier to see problems like this. 10) the $sort value that's coming from the visitor's browser MUST be validated to insure it is ONLY an expected value in order to prevent sql injection. the ORDER BY $sort term in the query cannot be protected by escaping the value or using a prepared query placeholder. if you make an array of the permitted sort values, you can loop over this array to build the sort links and use the array to validate the submitted sort value. 11) lastly, your code needs a general reorganization that will help clean it up. the php logic that determines what to do on the page, based on inputs the page receives (controller logic), and any database retrieval code (model logic) should all come first at the start of the file. this is referred to as the 'business logic'. the 'presentation logic' that contains all the html/css/javascript markup should come at the end. the business logic should set variables as it's output that contains the data that the presentation logic needs. the presentation logic should contain no database specific instructions, it should only receive variables from the business logic that contain data. edit: 12) you should use the cat_id to relate your tables, not the category name.

yes, you will need to alter the code that makes each pagination link so that it includes the search term. my post above contains search instructions (this forum software doesn't pass search terms in the url, so i cannot post a search result for you to use, you will need to actually perform the search yourself) that will find several examples showing a general purpose way of building links using php http_build_query() that does this.