mac_gyver
-
Posts
5,451 -
Joined
-
Days Won
175
Everything posted by mac_gyver
-
Inserting data into 3 tables at same time.
mac_gyver replied to knoxinator's topic in PHP Coding Help
1) you need to review the last post in your previous thread on this forum. 2) you should NOT have separate database tables for each location/venue. you should have one result table with a column that holds a location id that the data belongs to, with a separate table that defines the locations and assigns the id value via an autoincrement column. 3) once you have the raw data stored properly, you can query for anything you need anytime you need it. -
in addition to that, it's $_GET not $GET, and you are concatenating incorrectly. btw - your cart definition is overly complicated, requiring a huge amount of code to maintain. all you should store in the cart is the productcode as an array index and the quantity as the value. you can do this directly in a session variable - $_SESSION['cart']. there's no need to copy it to another php variable, then copy it back. once you simplify your cart definition, to get a count of the different items in the cart, you can just use count($_SESSION['cart']). to get the total quantity of items, you can just use array_sum($_SESSION['cart']). when you need to display the cart, by retrieving the information for all the productcodes that are in the cart, you can just use array_keys($_SESSION['cart']) to get all the productcodes.
-
a) does your C_URL value have a trailing / b) are both the allow_url_fopen and allow_url_include settings turned on so that you can use a URL in an include statement? c) are you sure you want to use a URL? see reply #3
-
you could always make the change you have theorized will correct the problem, perform a test, and observe the results to see if the experiment proves or disproves your theory about the cause of the problem - https://en.wikipedia.org/wiki/Scientific_method
-
everything that is in your header.php file is output that's being sent to the browser. line 21 is just the end of all the output. the best way of correcting this is to layout your page with any php code that determines what your page will do (the control logic), first. then put any php code that gets/produces the content on the page and the actual html/css/javascrpt markup at the end. your form processing code is part of the control logic that determines what your page will do and it should come before the <!DOCTYPE html> tag.
-
function definitions should go near the start of your code or be in a separate file that you include near the start of your code.
-
you need to determine why your login code isn't matching a row in your database table by actually investigating what is happening in your code and in your data. is the registration code doing anything to the email address? when you look directly at the data in your database table (using phpmyadmin or a similar tool) what is stored for the email in the case where it doesn't match? any chance you accidentally entered a space or other white-space character before or after the email address when you registered it, but not when trying to log in?
-
do you have php's error_reporting set to E_ALL and display_errors set to ON so that php will help you by reporting and displaying the errors it detects?
-
^^^ that's not it. based on this - $res = $__db->query($query, $buffered ? MYSQLI_STORE_RESULT : MYSQLI_USE_RESULT);, the code is using the mysqli database extension and the query method is the mysqli->query() method. the value being returned is a mysqli result object. using count() on it isn't relevant to the number of rows in the result set (the ->num_rows property would be.) you need to loop over the result set in order to process all the rows. what is your code that's trying to process the result set?
-
unfortunately, for things like dates of birth, the abomination leftover from the 1970's, known as a unix timestamp, is not appropriate. under mysql, any date earlier than 1970-01-01 00:00:00 results in a zero (all current mysql versions) and depending on your php version and operating system, php date()/strototime() are either limited to 1970-01-01 00:00:00 or 1901-12-13 20:45:54. also, using a unix timestamp requires a conversion that is time zone dependent and is lossy because the mapping is not one-to-one in both directions due to DST. using the mysql DATE_FORMAT() however only involves changing the format of the value, not converting it to/from a different number system and avoids all these problems. the php date/time class doesn't have these problems either.
-
Trouble converting user id into variable
mac_gyver replied to CloudBreaker's topic in PHP Coding Help
^^^ you may be setting session variables using the result from the above two lines of code, but they are not the values that you think they are. $conn in those two lines of code is your database connection. both of those lines of code should be throwing php errors, because there is no id or user_firstName values having anything to do with $conn. in order to retrieve the row from your database table, you need to execute a mysqli_fetch_assoc() statement. and in looking at the sql query statement, you have now added some conditions in it that will never be true. your login should always be failing. you are also (apparently) storing passwords in your database table in plain text. this is not safe as it will allow anyone that gains access to your data to have the raw passwords. php has password_hash() and password_verify() functions that you should be using. there are examples of how to use them in the php.net documentation. -
and after you fix those things, you will still be getting an undefined variable error inside your function, since you have a variable scope problem. you need to pass the $db variable as a call time parameter into your SignIn() function.
-
if you are doing a header() or javascript or meta tag redirect/refresh of the page, you could still be modifying the host-name/sub-domain (or the path) in the url, which can cause the session to not match, since the default session 'domain' setting causes a session to only match the variation of the host-name/sub-domain where it was set at. if you are on a shared web server, using the database is actually less secure, since there's no limit/flood checking for login attempts against the database server. shared accounts can sit there 24/7 trying database usernames/passwords until they break in to your database. using the default file handling for session data (assuming that the web server permissions are set up correctly) would mean that your session data files are owned by your account and cannot be read by the other accounts. if you are on a vps or dedicated web server, the session data files or database would be equally secure (assuming you don't have any database code that allows sql injection and you are using the same database connection for the session data and the web based data.) i recommend that until you have a proven need to use a database for session data, to stick with the default file based session data. edit: and if you are displaying the php errors, are you (in your code) or php (in the php.ini) using output buffering so that you won't actually see any displayed errors if your page is doing a redirect/refresh?
-
Trouble converting user id into variable
mac_gyver replied to CloudBreaker's topic in PHP Coding Help
when the user logs in, retrieve the user id from the database table and store it in a session variable - $_SESSION['user_id'] = $row['whatever_your_id_column_name_is']; // assuming that you have executed a database fetch statement and assigned the row to $row then, just use $_SESSION['user_id'] at the point where you need to reference the currently logged in user's id. -
extensions located in ext not loading
mac_gyver replied to Ginnnga's topic in PHP Installation and Configuration
yes, the loaded extensions should appear in the phpinfo() output. also, are you browsing to the .php file that contains the phpinfo() statement, rather than invoking it via the command line? i would check your web server error log for relevant error messages. there could be a permission problem, invalid syntax for a path, ... syntax errors in the php.ini, cause all lines after the point of the syntax error to be ignored and i'm pretty sure that php doesn't provide any sort of php.ini syntax error output to alert you to such problems. have you made any other prior changes to the php.ini? how did you obtain and install php? if it's part of an all in one xAMP package, you often need to install extensions using the package's control panel. -
extensions located in ext not loading
mac_gyver replied to Ginnnga's topic in PHP Installation and Configuration
is the php.ini that you are changing the one that php is using and are you restarting your web server to get any changes made to the php.ini to take effect. the php.ini that php is using can be found in the phpinfo() output for the Loaded Configuration File line. phpmyadmin uses muti-byte string functions and insists on the extension being loaded. -
1) do your database functions have error checking logic in them so that you would know if there are any database errors? 2) do you have php's error_reporting set to E_ALL and either display_errors set to ON or log_errors set to ON so that any php detected errors would be displayed/logged? 3) when you change pages, are you changing the host-name/sub-domain part of the url and/or the path in the url and your session cookie parameters are not set up to match variations of these that are different from where the session was originally started? it may be that sessions are not working between pages, regardless of the session save handler, due to how you are getting between pages and the session cookie settings (see item #5 in this list.) 4) are you calling a database function to close the database connection anywhere in your main php code? this would prevent php from saving the session data during the shut-down process since there wouldn't be a database connection for your session write handler to use. upon the next session_start() you would be getting a new empty session. 5) for debugging purposes, temporarily comment out the session_set_save_handler(...) statement so that php will use file based session data handling. this will help pin down the problem to either your main program logic or your session handler code. 6) why are you or why do you think you should be using a database session save handler? there's very few reasons for doing so and since the code must be 100% correct and is dependent on there being a database connection (see item #4 in this list) it has restrictions that you must take into account when writing your main code or you must set up a second dedicated database connection that is only used by the session handler and not your main code (or you can remember to always call session_write_close() before calling any database connection close function.)
-
further to the above, as of php5.5.4, you can specify that php uses standard serialization for the data. as to the serialization, here's the read handler documentation - the write callback doc is similarly worded.
-
php internally serializes and unserializes the session data it passes to and retrieves from the write and read session data handlers, though it's not (according to the documentation) the same serialization that the serialize() and unserialize() functions do.
-
you need to pick a script that has the features you want, and if it doesn't work, troubleshoot what's going on, because whatever reason one script doesn't work, may affect all similar scripts. in short, in order to fix a problem, you need to find the cause of the problem, otherwise you are just trying to fix symptoms, and the actual problem will remain.
-
here's the form you posted in your other thread, modified to work for either registering a new user or editing/updating an existing user - <form method="post" action="<?=htmlentities($_SERVER['PHP_SELF']);?>" enctype="multipart/form-data"> <?php if(!isset($row) || !$row){ // not set at all or false (no row fetched) ?> <label>Username:</label> <input type="text" name="username" required="required" placeholder="Please Enter your chosen username"/> <br /> <label>Password:</label> <input type="password" name="password" required="required" placeholder="Please Enter your chosen password"/> <br /> <?php } else { ?> <input type="hidden" name="id" value="<?php echo $row['id']; ?>"> <?php } ?> <label>Company Name: </label> <input type="text" name="companyname" required="required" placeholder="Please Enter your company name" value="<?php echo isset($row['companyname']) ? $row['companyname'] : ''; ?>" /> <br /> <label>Email: </label> <input type="email" name="email" required="required" placeholder="Please Enter your email" value="<?php echo isset($row['email']) ? $row['email'] : ''; ?>" /> <br /> <label>Address Line 1: </label> <input type="text" name="address1" required="required" placeholder="Please Enter the first line of your address" value="<?php echo isset($row['address1']) ? $row['address1'] : '';?>" /> <br /> <label>Address Line 2: </label> <input type="text" name="address2" required="required" placeholder="Please Enter the second line of you address" value="<?php echo isset($row['address2']) ? $row['address2'] : '';?>" /> <br /> <label>Town: </label> <input type="text" name="town" required="required" placeholder="Please Enter your town" value="<?php echo isset($row['town']) ? $row['town'] : '';?>" /> <br /> <label>County: </label> <input type="text" name="county" required="required" placeholder="Please Enter your county" value="<?php echo isset($row['county']) ? $row['county'] : '';?>" /> <br /> <label>Postcode: </label> <input type="text" name="postcode" required="required" placeholder="Please Enter your postcode" value="<?php echo isset($row['postcode']) ? $row['postcode'] : '';?>" /> <br /> <label>Telephone Number: </label> <input type="text" name="telnumber" required="required" placeholder="Please Enter your landline number" value="<?php echo isset($row['telnumber']) ? $row['telnumber'] : '';?>" /> <br /> <label>Category: </label> <input type="text" name="category" required="required" placeholder="Please Enter your chosen category" value="<?php echo isset($row['category']) ? $row['category'] : '';?>" /> <br /> <label>Upload Image: </label> <input type="hidden" name="size" value="350000"> <input type="file" name="photo" /> <br /><br /> <?php if(!isset($row) || !$row){ // not set at all or false (no row fetched) ?> <div class="box"> <label>I agree to the <a href="#" target="_blank">terms</a></label> </div> <input type="checkbox" class="checkbox" id="the-terms" value="I Agree"> <input type="submit" name="submit" value="Register" disabled="disabled" id="submitBtn" /> <a class="haveaccount" href="login.php">I already have an account...</a> <?php } else { ?> <input type="submit" name="submit" value="Update"> <?php } ?> </form> if you made any changes to the form in the other thread after you posted it, you will need to make those same changes in order to use this. note: my post above this one contains a typo, the query would be an INSERT ... ON DUPLICATE KEY UPDATE...
-
editing a profile and creating/inserting a profile (your last thread) only differ in the following - 1) retrieve an existing database recored to populate the form fields (you can unconditionally do this. if there is existing data, populate the form fields, if there isn't existing data, don't populate the form fields.) 2) update, rather than insert a database record (there's a single UPDATE ... ON DUPLICATE KEY UPDATE ... query that can do this for you without using any different php logic.) 3) not sending a signup email your form and php code should be be almost identical (you can in fact use the same code for both, with a small amount of logic, to handle not sending the signup email when updating). so, from what you learned from doing the last thread, why are you having basic problems with form field names not matching, a <form ... tag that won't allow an upload to work, and undefined index errors? learning actually requires that you look at and think about what you are doing. just repeatedly dumping a list of errors and code on a help forum for someone to tell you where to put your fingers on the keyboard and what to type to fix them isn't you learning anything. it's us doing your work via a proxy.
-
changing the session save path could only cause this problem if your setting was only in effect for some of the files, not all of them. the problem could be anyplace in your code, from the login not actually working (i can devise an example that contains an incorrectly coded 'test' of a session variable that makes it appear that the user is logged in, with a second correctly coded test that finds that the user is isn't logged in) to things like header() redirects (already mentioned above), url rewriting (that's changing the sub-domain/host name for only some files), pages getting requested twice by your browser (where the code isn't detecting if there is actually data and ends up clearing session variables), older version of php where register globals are still in effect and you are overwriting the session variables, ... there's just too many possibilities and hitting the correct one based on pot-shot guessing isn't going to find the cause any time soon. if you are not able to troubleshoot your code to find the problem, you will need to post enough of your code that reproduces the problem.
-
similarly - no it won't. applying an escape string function to the password doesn't strip out any characters and therefore doesn't affect the security of the value in any way. in the OP's code it would be necessary to escape the password value, since the hashing location (which is also not recommend, in addition to hash method) is in the sql query statement.
-
i'm assuming that means the page that's giving you the symptom of the session expiring/of being logged out. if so, it sounds like the session_start() on that page isn't actually working (there would be php errors) or a logic error in your code is clearing the session variables. and that even brought another suggestion to mind, of a header() redirect that doesn't have an exit/die statement after it and your php that continues to run, after the header() statement, is clearing the session variables. at this point, it's going to take seeing all the actual code involved that reproduces the problem, from start (the login code) to the end.
