Leaderboard

do not store any user information in cookies. anyone can set cookies to any value and can impersonate a user. to do what you are asking, generate a unique token, store the token in a cookie and store it in a row in a 'remember me' database table, along with the user's id and things like when the remember me was set and when you want it to expire if not regenerated. if you receive a cookie containing a token, query to get the user's id and the expire datetime to determine if the token is valid. if it is, set the normal session user_id variable to indicate who the logged in user is. you should only store the user id in a session variable, then query on each page request to get any other user information, such as the username, permissions,... this will insure that an change/edit in this user information will take effect on the very next page request.

Good morning everyone! Newbie living in the northwest corner of Louisiana. I'm not a developer, I am a student (at 50 y/o). Just wanted to say HI --Exco

Because you're asking for the number of rows, not the actual data. You want to fetch the row data and use that. Some searching suggests that you'd do that using this code: return $query->row()->total_paid_amount Also, if you're trying to get a sum of all payments, you probably don't want to be using GROUP BY, and should remove p_id from your select list.

The query you ran in PHPMyAdmin appears to be the only one above that has correct syntax.

You can tell composer to pull a specific commit by adding #hash after version. "api-platform/core": "3.0.x-dev#14c7cba" Normally just doing 3.0.x-dev would pull the latest version, but I think because both the main branch and 3.0 branch use this alias it causes an issue and for some reason composer prefers the main branch.

Problem is, you're talking about very different ways of getting the data. In the grand scheme of things the problem is as easy as ginerjm says - you get the data and output it while building the response. However, if you're using a CSV you'll need to research fopen() and fgetcsv(). If you're using a JSON string it'll be fopen() and decode_json(). If it's a database, research PDO and MySQL. And if it's an Excel file, that's a whole other can of worms that's going to entail third-party libraries. Each potential path has it's own ups and downs; you'll need to decide how you want to store and retrieve the data. Outputting said data is easy - in every case it's a simple echo statement.

No it is not. Look at the query in your code: $query = "SELECT krs.id_thn_ak ,krs.kode_matakuliah ,matakuliah.nama_matakuliah ,matakuliah.sks ,krs.nilai FROM krs INNER JOIN matakuliah ON (krs.kode_matakuliah = matakuliah.kode_matakuliah) WHERE krs.nim = $nim AND krs.id_thn_ak = $thn_ak"; Look at the query in the error message: SELECT krs.id_thn_ak ,krs.kode_matakuliah ,matakuliah.nama_matakuliah ,matakuliah.sks ,krs.nilai FROM krs WHERE krs.nim = 18024114 AND krs.id_thn_ak = INNER JOIN matakuliah ON (krs.kode_matakuliah = matakuliah.kode_matakuliah) They are not the same query. Now look at this part of the query that was shown in the error message: ...FROM krs WHERE krs.nim = 18024114 AND krs.id_thn_ak = INNER JOIN matakuliah... See why the query does not work? Now look at this part of your code: $this->input->post('$id_thn_ak', TRUE); Look carefully. Are you sure that is correct?

The following w3school page talks about collapsing a website navigation for smaller/mobile screens: https://www.w3schools.com/howto/howto_js_mobile_navbar.asp

So, if I'm comprehending this correctly, it not do much about determining whether the unique element is available (which the SELECT will accomplish) but MORE about determining whether the value is INSERTable (which is defined in absolute terms by the field being unique).

Sounds like you're talking about doing this in Javascript? If you're implementing your own bot check then it can't be in Javascript because the bots can just ignore that. It has to be in PHP. Doing that means you need to "remember" $entry from before. If you put that as a hidden input in the form then guess what the bots will do. There's a really simple way to solve this, though. Don't remember $entry but a hash of it, then check the hashes. $hash = sha1(__FILE__ . $entry); <input type="hidden" name="hash" value="<?= $hash ?>"> Then your PHP does the hash the same way but using the number the user put in the form, and it checks that the result matches the hash from the form. Bots can't figure out what value generated the hash, which also means they can't successfully substitute their own hash value. But know that bots are capable of solving math problems like this...

I'd probably just do that if it were me. Regenerating the user on every request isn't really going to be an issue I think, and might be necessary anyway more often than you'd think. I think what this error means is that you're trying to persist the App\Security\TokenUser object, but that object does not correspond to any known entity. Likewise for the other class. I've never used this library so really don't know anything about it. My initial comment was based on a quick look at the class where it seemed like it just extracted a string value from a user object. Doing a little more googling, I'm thinking maybe doctrine's reference proxies might be a solution for you. Since I don't know how things are structured, I can't really provide a good example but whever you were passing a fully hydrated user before, you'd change to just passing a reference, something like: $reference=$em->getReference(User::class, $jwt->getUserIdentifier()); $blamable->setUser($reference);

that doesn't matter. the main point of using prepared queries is to prevent any sql special characters in a value from breaking the sql query syntax (which is how sql injection is accomplished.) currently, a value that contains a ' (singe-quote) will break the sql query syntax and produce an error, rather than to allow the UPDATE query to execute. what if the user on your site has a name that contains a ' or wants to use one in their username? using a prepared query also simplifies the sql query syntax, making it easier to write a query that doesn't contain typos. a header() statement doesn't stop php code execution. you must use an exit/die statement with/after a header() redirect to stop php code execution. currently (before the last posted code), all the rest of the code on the page executes every time it gets requested, even if the user isn't logged in. it's not about using them only one time (you can use them any number of times.) this is about writing code that doesn't contain a lot of unnecessary clutter that you want someone else to look at and help you with. when you post code that contains as much as 2x the amount of typing in it that is necessity, it makes it harder for the people who would help you. it also takes your time typing and fixing mistakes in all the unnecessary typing. the points that were made about the php code are coding practices that will help make the code secure, simplify it, help reduce mistakes, ... here are some more points about just the posted php code - error_reporting should always be set to E_ALL and the setting should be in the php.ini on your system, so that you can change it in a single place. don't use output buffering to make bad code work. find and fix whatever is preventing your code from working. using output buffering also makes debugging harder because it hides non-fatal php errors and any debugging echo output you use, when you execute a header() redirect. the only value you should store in a session when the user logs in is the user_id. query on each page request to get any other user information (which you are doing) such as the username, permissions, ... this insures that any changes made to the other user information will take effect on the next page request. don't copy variables to other variables for nothing. this is a waste of typing time. just use the original variables. don't unconditionally destroy the session. the session can hold things other then the logged in user_id. the session user_id will either be set or it won't. you don't need to create a bunch of variables and logic to detect if there is a logged in user or not. your should build the sql query statements in a php variable. this makes testing easier and help prevent typo mistakes by separate the sql query syntax as much as possible from the php code. don't use variables ending in numbers. this just makes more work for you keeping track of what you are doing in your code. you should list the columns you are selecting in queries. this help make your code self-documenting and helps prevent mistakes. outside of the log in code, you should NOT select and fetch passwords. don't use a loop to fetch data from a query that will match at most one row of data. just fetch the data. don't store passwords in plain text. use php's password_hash() and password_verify(). don't attempt to detect if a form submit button is set. there are cases where it won't be. instead detect if a post method form was submitted. one case where the submit button won't be set is if you upload a file that exceeds the post_max_size setting. in this case, both the $_POST and $_FILES arrays will be empty. your post method form processing code must detect this and setup a message for the user that the size of the post data was too large and could not be processed. after you have detected that there is $_FILES data, you must test the ['error'] element and only use the uploaded file information if there was not an upload error (the errors are listed in the php documentation.) your post method form processing code should trim then validate all $_POST inputs before using them. apply htmlentities() to any dynamic value when you output it on a web page to help prevent cross site scripting. finally, these points just apply to the php code. your makeup is not working due to the mistakes in the html document. you need to clean up the html document so that it only loads each external element once and is valid markup.

How long do you want this 'session' to go on for? You are setting up for a post session to send the input to your script and then you apparently send the screen to be re-displayed, but after doing what? Are you planning on saving the input in a table or in a text file? Plus your current code seems out of order since you are displaying the form before you have retrieved the "name" contents so it won't be displayed, if it even executes. PS - don't use 'name' as your name field. Give the text are an actual name - not what is possibl a reserved word. Question - what are all of the BLB lines about? And your statement about "it is a simple thing to do". Where did you learn that to be true? Obviously it is not since you're here, no? Let's start with a decision on my first question. Where are you keeping this data to be re-used?

Yea, I usually just do something like this: $storageDir = '/wherever/you/want'; do { $name = bin2hex(random_bytes(16)); } while (file_exists($storageDir.'/'.$name)); The loop probably isn't really necessary, the chance of a collision is statistically insignificant I think, but I throw it in anyway just in case. I'll usually create a few sub-directories as well rather than literally have everything in one directory. Take the first few characters of the name and make a sub-directory based on that. For example, if the result were c6c1ce8c2bcf000daea561cbcca4a671 then I'd end up saving the file to: /wherever/you/want/c6/c1/c6c1ce8c2bcf000daea561cbcca4a671. Keeps the directory sizes more manageable just in case you need to manually browse to some file.

or you could just convert to the much simpler, better designed, and more modern pdo extension. in your previous thread, i posted an example showing what your SELECT query would look like using the pdo extension. here's what the UPDATE query in this thread would look like - $stmt = $pdo->prepare("UPDATE accounts SET userbalance = ?, totaldonationdc = ?, userlevel = ?, userexperience = ?, totaleventjoined = ? WHERE id = ?"); $stmt->execute([ $userbalance, $totaldonationdc, $userlevel, $userexperience, $totaleventjoined, $_SESSION['id'] ]); after you have made a connection using the pdo extension, converting existing msyqli based code to pdo mainly involves removing statements, copy/pasting the list of variables being bound into an array in the ->execute([...]) call, changing fetch statements (see pdo's fetch(), fetchAll() and sometimes fetchColumn()), and using differently spelled methods for things like last insert id and affected rows.

the most common cause is executing a query that returns a result set but not fetching all the data from that result set. this ties up the connection so you cannot run another query. therefore, if a query returns a result set, simply fetch all the data from the query in to an appropriately named php variable, freeing up the connection for use by other queries, then test/use that variable throughout the rest of the code.

PDO is more streamlined mysqli has result objects and statement objects depending on whether you used query() or prepare(). The methods for handling the results of these two objects are completely different. This mean two confusing sets of methods to learn. On the other hand, PDO produces objects with exactly the same methods to process the results of query() or prepare(), and usage of prepare() is itself much simpler. Some mysqli methods are only available depending on your implementation of MySql. PDO works with multiple varieties of DBMS (mysql, postgres etc). The SQL dialects may be different but your php code remains the same if you change. Having used the old mysql_* for years I originally changed to mysqli (how different could it be?) After a long while I decided I had to learn PDO in order to support others who were using it. I really wished I'd switched to it originally instead of mysqli.

You can simplify things by always ensuring categories have at least one subcategory, and always linking images to the subcategories then you have so that mysql> SELECT c1.cat_name -> , count(i.id) as total -> FROM prefix_channels c1 -> JOIN prefix_channels c2 ON c2.child_of = c1.cat_id -> JOIN prefix_images i ON i.category = c2.cat_id -> GROUP BY c1.cat_name; +-------------------+-------+ | cat_name | total | +-------------------+-------+ | parent_category_1 | 4 | | parent_category_2 | 2 | | parent_category_3 | 1 | +-------------------+-------+

I think you hit a nerve there gizmola and you too maxxd. I feel it as soon as you say it that I'm stuck in terms of considering max and min scaling, viewport and having a fluid design (as maxxd calls it) that has no limitations in terms of scaling up or down. It's what you're talking about that I'm interested in, but which I can't express or describe. It has nothing to do with poor English or language limitations. This only has to do with too little knowledge. I live too much in the past and fail to see that it has evolved. This is like banging your head against the wall. I read, ask for advice, get answers and understand it then and there. I constantly see what I'm doing wrong, and what I should have done differently. Not mine; I see and understand how it should be, recognize and understand what will be done if I do/write like this. When I sit down again, I'm just as clueless. I have too much tunnel vision in many areas. I have to get out of that tunnel. It only leads in one track. I thank you for the answers you give and will read through what is linked to. You keep trying to push me in the right direction. I absorb all the knowledge you give me, but.... 🤔😠I get irritated and frustrated with myself. Thank you for the knowledge you spread and give me. (Barand, Gizmola, Maxxd, Kicken, Requinix, Benamen, Ginerjm and everybody else).

I agree completely with gizmola's point about fluid design - the link I gave comes in handy for reference and when hard stops are necessary.

In my opinion, you want to build a "responsive" site, where you have certain thresholds you use for mobile devices. Rather than start with the idea that you have a max, allow the site to grow and shrink based on the device specific (viewport) attributes like vh and vw, as well as using the flexbox properties that allow for growth and shrinkage. So for example let's say that you have a fixed height for a header, and below that you have a flexbox that should fill available vertical height and width. You might have a style like this: .app { font-size: 15px; color: #fff; height: 100vh; width: 100vw; } .header { background-image: linear-gradient(to right, #18a0BE, #622db9); height: 55px; display: flex; } .app__container { height: calc(100vh - 55px); display: flex; } .main { background-color: #edf1f3; flex: 1; } And your markup might be something like: <body class="app"> <header class="header "> </header> <div class="app__container"> <main class="main"> <div class="cards"> </div> </main> </div> </body>

mysqli_query uses an SQL query (string) for its second argument. You are passing $stmt which is a prepared statement object. There is nothing in that query that needs preparing so just use mysqli_query with the query string.

I don't use mysqli so I can't answer that. You will have to read the php manual to see how a prepared statement is used. https://www.php.net/manual/en/mysqli-stmt.prepare.php Read the example for 'Procedural style' BTW - since you are not using any user-supplied arguments in your query, you really don't need to 'prepare' the query.

This can be a frequent issue, which is why it's important to test on multiple browser. You can also reference caniuse.com to get an idea of what is supported on which browser versions. If you look up position: sticky there for example, it says for chrome (up to 90, which is your version) it's partially supported with the note: Modern chrome fully supports it.

Dangling can refer to perhaps a thread hanging off of a new shirt or a strand of hair hanging on your forehead.

Your code can be simplified in many ways. See the comments in the refactored code below. <?php function setRememberMeToken($pdo, $user_id) { //$length wasn't a great name and is an unnecessary variable. $token = bin2hex(random_bytes('25')); $expirationDate = time() + (86400 * 7); // <-- 7 days later (make sure your comments are accurate) setcookie("token", $token, $expirationDate, "/"); $_COOKIE["token"] = $token; //$_COOKIE['remember'] is unnecessary, just get rid of it //--deleted //You calculated your expiration timestamp above already, no need to do it again. $to = date('Y-m-d', $expirationDate); //Assuming token_id is an auto increment column, you can just omit it from the insert. $sql = "INSERT INTO `user_token` (`user_id`, `expires`, `tokenHash`) VALUES (?, ?, ?);"; $stmt= $pdo->prepare($sql); $stmt->execute([$user_id, $to, sha1($token)]); } function getRememberMeCheck($pdo) { //I find spacing out your queries makes them easier to read and understand. $stmt = $pdo->prepare(" SELECT users.name, users.user_id FROM user_token, users WHERE tokenHash = ? AND expires > NOW() AND users.user_id = user_token.user_id "); $stmt->execute([sha1($_COOKIE["token"])]); $db_query = $stmt->fetch(); //Your token and expiration date are validated as part of the query //All you need to do is check if you got a result or not. if (!$db_query){ //If you didn't get a result, either the token is invalid or it has expired. //header("location: login.php"); return false; } //Otherwise, if you did get a result, the token is valid. $_SESSION["loggedin"] = true; $_SESSION["username"] = $db_query['name']; $_SESSION['the_usr_id'] = $db_query['user_id']; return true; } //This method seems to just be a copy of the method above, why does it exist? //The only difference is $_SESSION["loggedin"] = true; which you could just do above. //function setSessionVarables($pdo) { //... //} //--deleted function isRemembered() { //Instead of a separate remember cookie, just check if the token cookie exists. //if ($whatever){ return true; } else { return false} can be simplified to just return $whatever return isset($_COOKIE['token']); }

Every class you create that extends your dbconnect class will be creating it's own separate connection to the database. If you're using several of these classes in a page load then that would mean several separate connections. What you should do is have those classes accept an instance of your dbconnect class as a parameter to their constructor. class secondClass { private $db; public function __construct(dbconnect $db){ $this->db=$db; } } $db=new dbconnect(); $sc = new secondClass($db);

Flexbox and/or grid should handle everything you want. I would start with using flexbox for all of the layout pieces you have already described, so certainly you want a container div for those so that you can use display: flex. At that point it's just a matter of applying the appropriate parent/container properties or child div properties you desire. This article might help if you need a refresher: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

The point of storing the expiration date is so that you can check it when you lookup the token later and reject expired tokens. You cannot rely on the cookie being deleted by the browser at the requested time, so you must check for yourself if the token is expired or not. $stmt = $pdo->prepare(" SELECT users.name, users.user_id, tokenHash FROM user_token, users WHERE tokenHash = ? AND expires > NOW() AND users.user_id = user_token.user_id "); $stmt->execute([sha1($_COOKIE["token"])]); $db_query = $stmt->fetch();

i suspect you are asking this because your code and variables aren't behaving the way you expect? the reason most of your conditional tests are not working and variables are being changed, is because one = is an assignment operator and two == is a comparison operator. when you have a statement like - if($donationclash = false), this assigns false to the variable, then tests the result, which will be a false value. all these conditional tests against variables should use two ==. if($donationclash == false), this tests if the variable is equal to a false value and leaves the value in the variable as is. a comment about the use of the $donationclash variable throughout this code. since your program logic is halting execution if the $DONATIONCLASHTIME is false, there's no point in the $donationclash variable at all. all the rest of the code on the page after the $DONATIONCLASHTIME test and its message won't be executed. here's a list of issues with the current code - there are no helpful comments in the code describing what the goal of each section is. this makes it almost impossible for anyone to help with your code. switch to the much simpler and more consistent PDO database extension. it treats the result of a non-prepared and a prepared query identically. this alone will eliminate about half of the code dealing with database queries. don't copy variables to other variables for nothing. just use the original variables. this accounts for close to half of the existing lines of code. this is just a waste of typing and is making more work for you in keeping track of everything and makes it almost impossible for anyone to help. don't use multiple names for the same thing. this requires you to keep track of which name you are using and makes it next to impossible for someone to help. use under scores _ to separate the words making up names of things. make the database connection in an initialization section at the top of your code and don't repeatedly require (once) the connection file. only store the user's id in session variable, named user_id or similar, to indicate who the logged in user is. this will either be set or it won't. query on each page request to get any other user information, such as the username, permissions, ... you have mistakes in most of the if() comparisons. one = is an assignment operator. two == is a comparison operator. there are other logic mistakes with what the else and else if logic is doing, that would be easier to see if you consistently indent your code. use 'require' for things that your code must have for it to work. include/require are not functions. the () around the value does nothing but clutter up your code with unnecessary typing. be consistent. you are using include/require_once and echo/print at different points. don't use a loop to fetch data from a query that will match at most one row of data. just fetch the single row of data. why do you have an if() around the prepare() calls? you don't do anything if they fail and since the execute() calls can fail, why don't you have conditional tests for them too? instead of writing out conditional logic for each database statement that can fail, use exceptions for errors and in most cases simply let php catch and handle any database exception, simplifying the code. the only time your code should catch and handle a database statement error/exception is for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted data. in all other cases, don't put any logic in your code and simply let php catch and handle the error/exception. build sql query statements in php variables. this will make testing easier and help to eliminate typo mistakes by separating the sql query syntax as much as possible from the php syntax. you should always fetch all the data that a query returns, which is why you went to the trouble of executing a query in the first place, so there should not be any case where you need to close a prepared query. don't store redundant data in multiple locations. you are storing the user's id in the donationclashdetails. that's all the user information you need. you can get any other user information via the user's id. any one conditional test can either be true or false. you don't need test for the false case after you have tested for the true case. if a test is not true, it must be false. the $stmt->store_result() and $stmt->bind_result() after the INSERT query don't belong there and may be producing errors. do you have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your system, so that php will help you by reporting and displaying all the errors it detects? the SELECT ... FROM donationclashdetails WHERE participationid = ? query, right after the INSERT query, and the associated repetitive logic, is unnecessary. the php code for any page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document post method form processing should - detect if a post method form was submitted, which you are doing. however, all the form processing code goes inside this conditional block of code. yours isn't. keep the form data as a set, in an array variable, then operate on elements in this array throughout the rest of the code trim all the inputs at once validate all inputs, storing validation errors in an array using the field name as the array index after the end of the validation logic, if there are no errors (the array holding the errors will be empty), use the submitted form data after the end of the form processing logic, if there are no errors, perform a redirect to the exact same url of the current page to cause a get request. this will prevent the browser from trying to resubmit the form data to display a one-time success message, store it in a session variable, then test, display, and clear the variable at the appropriate location in the html document. if there are errors at step #5, the code will continue on to (re)display the html document. you would test/display any errors and redisplay the form, populating the field value(s) with any existing data. apply htmlentities() to any dynamic value when you output it in a html context

Not sure how that would have happened, but dude I feel ya' - losing WIP sucks. Check to see if your editor created a temp file somewhere or if there's an automated backup. Obviously, this is one of the benefits of using git but if you're not or you didn't commit or push, it may be rough. How exactly were you running the script that an infinite loop could have wiped your file?

So it looks like you are using your own tokens for login. That is not a good idea. You should be relying on the session instead. If you expect to have a cluster of app servers, you might need to change session storage so that it uses your database, or redis/memcached instead of files, or you can use a load balancer that supports the configuration of a "sticky" session, but otherwise, you don't want to be creating and managing your own session/authentication token for anything other than the remember me feature. Sessions already, when properly configured, utilize a cookie. You also want to make liberal use of session_regenerate_id. From what you posted, this has DRY/ logic issues: if (isset($_POST['remember-me'])){ $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; echo "<hr>"; echo setRememberMeToken($pdo, $user['user_id']); echo "<hr>"; header("location: dashboard.php"); } if (!isset($_POST['remember-me'])) { $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; echo "<hr>"; echo "<hr>"; header("location: dashboard.php"); } Again, I don't have your code, but you have a repetition of code, and worse yet that code is actually not relevant to the variable you are checking (!isset($_POST['remember-me']). What you want to do is avoid blocks like this, which are also mutually exclusive. So again, assuming that this is part of a block where you already established successfull login previously, you can rewrite your code like this, to separate the remember-me check so that it only does what is relevant to the existence of that flag. I will also point out that if the user logs in without the remember me checkbox, you should remove the remember me token, but your code doesn't do that. Something like this would be better, and also fix your current hole. // Assumes authentication succeeded above this code $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; $_SESSION['the_usr_id'] = $user['user_id']; // Not sure why you need this? if (isset($_POST['remember-me'])) { setRememberMeToken($pdo, $user['user_id']); } else if (!$_SESSION['rememberMeLogin']) { // Was not a "remember me" authentication AND remember me was unchecked. So should remove the remember me token & Delete the cookie. unsetRememberMeToken($pdo, $user['user_id']); } header("location: dashboard.php"); exit; Another thing I would suggest is not to use md5, but used sha1 instead. md5 has a smaller collision space. I would also add something to the random input to the hash (md5,sha1). So perhaps add something like username + random bytes. People can generate a large table from random byte input (a rainbow table) and look for matches. By doing so they might figure out you are just using random byte combinations of a certain size. It's not a major security hole, but one you can protect against by not just hashing random characters of the exact same size from a routine. This is similar to the idea of using a "salt".

You could make the opening page check for the screen width (JS) of the device making the call and re-direct the process to the page you want if the size is < 800px or whatever size you want to check for.

What does this mean? I really don't know what you are trying to tell me/us.

I have no idea what your question is. I do see some html code that is very difficult to interpret.

HOw about posting some code that we can read and play with should we need to? Images are not really appreciated.

You should not be putting user's input directly into your query. Doing so opens you up to SQL Injection attacks. Use parameter binding to create a safe query with the user's input.

Websafe colors is an artifact of the days when memory constrained graphic cards only had support for single byte ( 256 colors) per pixel. Those days are long gone, and you should not be concerned with the 216 websafe colors unless you are going for some sort of retro color palette.

It sounds like you are trying to access your scripts from different levels of your website hierarchy. For example, you want to access the nav.php script from your main root folder, as well as for the pages under the "models" and "john" folders. Is that correct? If that's the case, I would modify those include statements so that they are root relative. <?php include "{$_SERVER['DOCUMENT_ROOT']}/include/nav.php" ?>

You can use include function "<?php include 'header.php'; ?>" to achieve the same.

If you are still using that monitor that you bought in 1990, stick with websafe colours.

The web is a complicated and confusing interdependent set of technologies, and is often underestimated. Most people get confused as to how specific things actually work. There are better tools now, like the chrome web tools for example, which are great aids to figuring out how a web application actually works. Javascript with its frameworks and SPA's continues to add to the complexity and role of client side code running in the browser, but I do believe that if you really understand the fundamentals, like where code actually runs, and the overall architecture of the various processes involved, you have a better chance of avoiding confusion. HTTP is very important to understand. Using the dev tools Network tab is a great way to explore this. A lot of times people just assume that something described in abstract, like cookies for example, are obvious, but if you don't understand where cookie data lives, and in what circumstances the server has access to cookie data, and what restrictions might exist for that data, it can just seem like magic, which leads to confusion. A good understanding of HTTP helps demystify things. When you look at HTTP it then helps to understand that HTTP is built on top of TCP protocol. So you can continue to delve into the intricacies of how things work, and gain a deeper understanding as you see fit.

Thanks, you helped a lot, I really appreciate it, and now I have some direction. It's funny, tho, how I can get stuck in some seemingly simple things.

There is no reason to be writing obsolete/insecure php mysql code in 2022. Literally every veteran member of this forum will offer you the same advice: The mysqli_ interface to mysql is annoying to use. Learn/use PDO instead! There is a fast easy to read guide to using PDO that will teach you everything you need to know, as well as offer best practices. Whether it be mysqli_ or PDO, all variables should be prepared/bound, as Barand advised. It's just cleaner/easier to use PDO to write your code. Now every single person like yourself that is learning, when they receive this suggestion, has the same reaction which is "thanks, I will have to learn PDO ... sometime in the future (aka never) because they will have to learn PDO and rewrite some of their existing code. I understand that this is a natural reaction to a learning curve and the unknown. With that said, aside from understanding how to set up a PDO connection, you really will thank us all later, if you make the change now.

You already have some useful answers, but I'll throw in my 2 cents which includes a bit of history. When the world wide web was first evolving, all HTML pages were static. The HTTP protocol, which enables the WWW, describes how a client (browser) can use a URL to reach a server, and request a resource (html document). I would hope that at this point you are familiar with the HTTP methods available -- GET, POST, PUT, PATCH & DELETE. So a browser made a get request via HTTP, and the first servers would resolve the location of a static html document and return that to the client. Again, somewhat obviously, an html document can specify a number of pieces, which again in the early days were images, as Javascript and css had not been invented/formalized yet. The job of the browser is to parse and assemble the html document and display it to the user, and handle hyperlinks. Eventually, people wanted to provide a more interactive experience. A simple example, would be a page that showed all the latest news stories of the day. Either someone had to manually update the index page, and add static html pages for all the stories, or a program running on the server could be enlisted to create html on the fly. Sophisticated software existed for a long time to do all of this, and in many ways the WWW was a huge step backwards. Client/Server and terminal applications had existed for years prior to the first browser and web server, and people were used to using online services like Compuserve and AOL, which had their own client/server protocol and content rendering client software. The WWW was an attempt to democratize this and provide standards that anyone could use. HTTP itself came from scientific organizations who wanted a way to easily share research papers. Much of what we know as the Internet also came from this process, where people would publish standards in the form of "Request for comment" ie RFC's. A few groups that had been involved in the creation of the first web servers got a working group together and published RFC 3875 which describes the "common gateway interface" (CGI) which standardized the way a web server could invoke a program, accepting input from the web server in the form of environment variables with specific names and purposes, and then return the results (in the form of html) to the web server, which would then return that "computed" html to the user. This was the birth of "server side" web programming, and the basic structure of that continues to this day. Web Server accepts an HTTP request with a URL If Web server detects that the URL requires a "CGI program" be run, it passes variables (user input and standardized CGI web server variables) to the program through the Operating system environment Local server program runs, returns a "response type" data structure + the actual data to the web server Web server returns html (or any other valid resource type) to the client I mention this, because the URL might have been an image, which could be generated on the fly by a server side program as in the case of a computed graph image So this brings us to the various popular server side languages. In the early days of the web, people would often write their CGI programs in C, as the primary server operating system of choice by most people involved in running servers in the early days of the WWW was Unix. As C is terse, and requires compilation, early web developers started looking for ways to simplify coding. CGI allowed any "program" to be used, which meant that early developers could use something as simple as a bash script which chained together various unix commands. The Perl scripting language was extremely popular at the time, due to its interpreted nature, advanced data structures and many available libraries. For example it had a relational database client interface (DBI/DBD) that allowed a developer to write simple code to make SQL calls to a relational database. Commercial databases like Sybase SQL server and Oracle were popular at the time, and the open source MySQL database was seeing a lot of adoption, as the commercial databases were expensive and hard to obtain. Perl, like other interpreted languages, is evaluated when the script is run (at runtime). Most developers found this highly preferable to developing in a compiled language like c or c++, which required a compilation/build process anytime you changed so much as a single line of code. It was in this time, when PHP first appeared, and it was intended to be a language/toolkit specifically aimed at making the development of serverside web scripting simpler. So one of its features as the ability to intermix HTML and php scripting blocks in an html script. This is somewhat in the spirit of a competing standard at the time, called "Server Side Includes" which had a similar objective of taking something that was mostly pure HTML and augmenting it with some markup that the server would act upon when the page was requested. With that said, PHP like Perl, is interpreted, and thus required a runtime process to parse the PHP code and execute it at runtime. Java also has a runtime, although the main difference in the case of Java is that the Runtime engine (the JVM) was designed to be a persistent server process/daemon. In the case of Perl & PHP, a web server running a Perl or PHP script needed to invoke the perl or php runtime program, which would then load the script code and run it. This script code could of course also load/include perl or PHP libraries, and do all sorts of things while running, but unlike java, it was not intended to have any persistence. This is very different from java where you can create objects and have them persist in the JVM (or in the case of Java EE, a Java application server). PHP programs are run when requested, and when the PHP script is done running, all the variables and objects that might have been created are disposed of when the script ends and has returned the response data to the web server. As PHP became popular, people wanting more performance and less overhead began to look for ways to reduce the overhead of starting up the PHP process each time. By this time, the open source Apache web server had become hugely popular, and apache was designed to be a collection of modules, with a specification for anyone who wanted to add a new feature to the server via development of a custom module. Developers within the PHP project community created an apache module (mod_php) which essentially made PHP a part of the Apache Web server. This meant that instead of the web server having to fork a child program and pass all the variables through the environment, a PHP script could receive that data and access web server variables directly from Apache's shared memory structures. The problem with this idea is complicated and has to do with how Apache services requests. I wrote about this issue on my blog if you want to read more about the underlying issues. Around this same time servers had appeared to challenge Apache, most notably the NGINX web server. NGINX has a fundamentally different architecture to Apache, and had no support for mod_php or something similar. NGINX was designed to be a highly performant proxy server, so it supports a variety of ways to proxy a request to a server process for handling. NGINX implements "Fastcgi" which was developed as an alternative to CGI. Essentially, fastcgi sought to get around the same problems that apache modules were designed to get around -- the overhead of having to create and destroy an os program for every request to a server side script. NGINX and other servers that support fastcgi (which even includes apache now, via an optional fastcgi module) assumes that there is a persistent operating system process that supports the fastcgi protocol. This was ideal for languages with a persistent runtime application server process like java. In order to make this work for php, a persistent php application server was developed within the PHP project, that supports fastcgi. This php application server is called php-fpm. Internally php-fpm maintains a number of persistent php processes which can be used to run a php script. A proxy web server like Nginx can be configured to send requests for php script to php-fpm via fastcgi protocol, and return the results to the client. I hope this somewhat long and verbose history of web servers helps answer your question and give you some background to clarify how PHP works. At the end of the day, a PHP script is a PHP script. There aren't a lot of different types of PHP files -- there is only .php. Frameworks have introduced template languages, and PHP can parse files of various flavors, but in all cases the end result is the execution of PHP code. Unlike Java, there was never an effort to define specific file formats to do different things as in the case of Java servlets/vs JSP vs JSTL. PHP was designed with the intention of being a language that would work with and be integrated with a web server via CGI. It has many design features focused on that, and is not generally considered a generic scripting language like perl or Ruby or Java, Nodejs or more recently, Python. Any one of those languages (including PHP) could be used to create a "socket server" that can run on a server and handle HTTP requests. There are other types of protocol servers (Websockets in particular) that have become popular as the web has evolved. The performance of PHP interpretation has been improved in recent years, and there are also projects that add some valuable features like "event driven non-blocking IO" which are beneficial if you are developing a server process in PHP, but that is not the typical reason people use PHP. For the most part they are using it to create server-side web applications.

All languages that power websites, including PHP and Java and Node.js/Javascript, share the same two aspects: that there is code running on the server which creates some output, and (typically) that there is code running on the client to perform additional actions. That duality is a lot more apparent with PHP than it is, say, Node.js and React, but only because that's the more traditional (and easier) style of mixing your server-side code with your output. If you wanted to use React to handle the interface instead then you could do that with PHP too, even if the approach would be different.

the code for any php page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document the code for any particular section can all be in the main file or divided between the main file and any number of separate files that get 'required' when needed. the html document should only contain simple php code, acting like a template engine, that operates on the input data supplied to the html document from the other sections of code OR more simply just use a 3rd party template engine.

cannot possibly help you without having all the code needed to reproduce the problem. i'm going to guess session data is involved and you are switching between http and https requests, which will result in two separate sessions.

You should be using prepared statements. They have the added benefit that you then dont have to worry about data values like "O'Reilly" or "The Bull's Head"

OK - I've added the sort usort($test, fn($a, $b) => $b['itemCount']<=>$a['itemCount']); // sort descending itemCount $seen = []; foreach ($test as $k => &$rec) { $rec['rolanID'] = array_diff($rec['rolanID'], $seen); // find new ids if ($rec['rolanID']) { // if there are some new ones ... $rec['itemCount'] = count($rec['rolanID']); // count them $seen = array_merge($seen, $rec['rolanID']); // add the new ones to those already seen } else unset($test[$k]); // if no ids, remove the array item } and I now get this (no duplicate 123)... Array ( [0] => Array ( [supplier] => TEST2 DEPO [rolanID] => Array ( [0] => 456 [1] => 188 [2] => 200 [3] => 123 ) [itemCount] => 4 ) [1] => Array ( [supplier] => TEST DEPO [rolanID] => Array ( [1] => 234 ) [itemCount] => 1 ) [2] => Array ( [supplier] => DIFFERENT DEPO [rolanID] => Array ( [0] => 897 [1] => 487 [2] => 100 ) [itemCount] => 3 ) )