Leaderboard

Short answer: it's safe. Longer answer: it's as safe as any other PHP file on your server. It's a common practice to put this script, or at least a script that defines variables/constants with database credentials, in a PHP file that is not located inside the web root (eg, outside of your public_html or www or whatever directory that your site is based in) because if it's not an actual page then it really shouldn't be in the root; this practice is easy to achieve when you get larger sites that have a single public_html/index.php that runs an "application" or some similar concept whose files are all outside the root.

Removing the battery from a fire alarm does not make the fire go away.

Seems to me that the best approach would be to fix the problem instead of disabling the warning.

Very interesting. That seems like something to look into but I do move at a pretty slow pace. I really do appreciate the ideas.

If $cat_id contains "" then the query will fail with a syntax error. But we don't know what's in it, nor do we know what's in your table - and we certainly have no idea what "don't work" means unless you tell us. Check if your query gave an error message.

Welcome to the community. It is designed for those interested in learning and developing systems based on PHP and related technologies. We do not allow for advertisements. Members in good standing are allowed to place promotional links in their signatures. Messages created solely for the purpose of advertisements will be edited or removed.

You do it in the same way you have in your get_post($pid) function, only this time pass the category id get_posts($cat_id)

You can't put functions inside strings like variables. <?php $x = date('Y'); $y = 1989; $description = "In this classic lecture which was delivered over " . ($x - $y) . " years ago, etc etc....."; echo $description; // ==> In this classic lecture which was delivered over 31 years ago, etc etc..... ?>

Have you tried putting a WHERE clause in your query, for example WHERE blog.cat_id = 4

No you don't. You have a function perfectly capable of giving you the current session ID. Why do you think you have to take that value, which is going to be the same value every time you call the function so long as the session is active, and put it into $_SESSION for you to get it? If you want the session ID then call the function. Stop overthinking this. No. You see two session files. Containing session data. For two different sessions. How did you run those queries? That's a rhetorical question. You aren't supposed to tell me the answer. You're supposed to consider what the answer is and then continue thinking about the implications of that answer in order to find the answer to your question.

I suggest you start your hunt for an answer over here.

Is granting the ability for your web user to run any command as root without a password unsafe? Absolutely, you might as well just run your web server as root if your going to do that. If you're going to use sudo, then you want to limit the commands that can be run to exactly what is necessary. For example, at one point I had a page that would allow resetting an email password and the process to do so required root. I created a shell script with all steps necessary and I added this to my sudoers file: www-data ALL = NOPASSWD: /root/bin/reset-mailbox-password That allowed my public-facing web page to execute that command and only that command as root with sudo. That way if there were ever a security issue in the future that gave someone shell access as www-data they couldn't just run whatever they wanted to sudo and further compromise the machine.

No, you should change the sudoers file to allow user apache to run that command. However, before you get yourself in trouble, please explain why you need web users to run restricted commands. Perhaps we can come up with a safer alternative.

"Outside a class"? Screenshot #1: grve-wrapper selected below, bounding box shown above is too low, highlighted CSS on the right shows a few rules Screenshot #2: with the position:relative and top:50% rules disabled, the bounding box is in the correct location but the image is too high Screenshot #3: img selected (the one that's visible), bounding box shows it's too high on the page, highlighted CSS shows a few rules Screenshot #4: with the top:-50% rule disabled, the bounding box is in the correct location

It's just a normal HTTP request, just like anything else. Forms really are not anything special. It's just like a link using an <a> tag, except you can send more data by using method="post". So if your trial page outputs the form <form method="post" action="checkout.php"> <input type="email" name="Email" value="example@example.com"> <button type="submit" name="ProductId" value="1">Get trial</button> </form> When you click the button the browser will Open a connection to example.com Submit the http request POST /checkout.php HTTP/1.1 Host: example.com Content-type: application/x-www-form-urlencoded Email=example%40example.com&ProductId=1 If you don't understand the above, you should do some research on the HTTP protocol and learn how it works. As you can see though, your trial page is not referenced at all in those steps. The request is for checkout.php and the data is sent in the body of the request in the same format as a query string. This is not at all true. POST data is just as visible and open to manipulation as GET data. The only difference is where it's located in the request. This is why I said you need to get over your trust issue with $_GET. $_SESSION is the only thing you can generally trust as that data never leaves the server and cannot be manipulated directly by someone, they would have to exploit some vulnerability in your server or your code. It's a little bit of a semantics / being pedantic thing. Big picture, sure you are passing some data. Your not passing the trial pages $_POST array though. The trial page doesn't have a $_POST array unless your posting data to it in some way. By adding the action attribute pointing to checkout.php you're no longer posting any data to the trial page, your posting it to the checkout page. There's nothing wrong with using terminology like "pass the ProductId to the checkout.php page", but you should have the understanding of how that actually works. The language in your posts implied that you did not as you seemed to think that PHP was either sharing one $_POST between scripts (misunderstanding "global" I think) or somehow moving the $_POST array from one script to another which is not how it works.

Based on your last post it sounds to me like you still don't really understand the process, or maybe you do but just don't articulate it well. It sounds to me like you're thinking you are defining $_POST['ProductID'] on your trial page then have to somehow transfer that variable over to the checkout page. That's not really how things work though. Your trial page doesn't have a $_POST['ProductID'] variable. It generates a form as it's output. That form is submitted to the checkout page, and that form's data contains a ProductID field which makes it so that your checkout script will have a $_POST['ProductID'] variable. Taking a step back to basics again, every request you have to look at in complete isolation. The request has to contain whatever data your script needs to get stuff done, and there are a variety of places in a request that the script can look at for data. $_GET - Data from the requested URL's query string (side note, you should get over your trust issues, $_GET is fine for something like a product ID). $_POST - Data from the request's body content, assuming the body is form data. $_COOKIE - Data from any Cookie: headers $_SESSION - Session data is handled via a slightly more complex process. When your script ends, the data stored in $_SESSION is saved to the web server somewhere and a unique identifier is then passed to the client. The client passes that identifier back to PHP on the next request (usually as a $_COOKIE value) and then the data is looked up on the server and restored. Whether you use a database or not doesn't really matter. You'd give your checkout.php page an identifier of some sort via one of the above mentioned input options. Your checkout page would then use that input to do whatever it needs to do. You can provide your identifier via $_POST if you want to checkout.php, but you're not "transferring $_POST['ProductID']" from the trial offer script to your checkout script, at least not in the way it sounds to me like you are thinking. Your trial offer script does nothing more than generate a form with whatever data you need. Once that is generated and sent to the client the trial offer script is done and is no longer relevant. When the user submits that form then the browser would take the form's data and send it directly to checkout.php, no other script is involved in the process. Now, going back to your original question, you mention having a shopping cart, so you need to split your process into two parts. Add the item to your cart. Display the items in your cart. Whether you want to do that via two separate scripts or all in your checkout.php doesn't matter too much. You could have your trial offer page post back to itself like your normally do and add the item to the cart then just redirect. In that case your checkout doesn't need to do anything other than look at the contents of the cart and display them. Otherwise you could have an input to your checkout page that identifies an item to add to the cart. You'd then just have your trial page create a form that posts directly to the checkout page with the necessary data. Your checkout page should still logically treat this as two steps and add the item to the cart, then look at the contents of the cart and display it.

Sorry but no, it is not what you thought. Seems a quick primer is in order. PHP handles exactly one page request at a time. When it finishes with a page, it completely forgets everything that happened. You can't set a variable on one page and get it in another page. Obviously that would be a huge limitation to making a website work, and that is why things like databases and cookies and sessions exist. That means there is no transfer of "control" between pages. PHP doesn't remember that the user was on trial-offer.php and is now going to checkout.php. All it knows is that someone is trying to request checkout.php, and they may or may not be sending data too. $_POST is not a database or cookie or session. It's a variable. A variable that you can reference from anywhere in your code, but just like every other variable, it's only usable for that one page. If you made any changes to it (which is a bad practice so don't do that) then you could see those changes for the rest of the page, but whatever you do will not be available on another page. Same for $_GET. $_GET gets its information from the query string - the stuff after the question mark in the URL. PHP looks at the query string, parses it, and shoves the data into $_GET for your convenience. $_POST gets its information from POSTed form data. The most common way to send POSTed form data is with a <form> whose method=POST. PHP looks at the data sent to the server, parses it, and shoves the data into $_POST for your convenience. If you have a form with an action="" then the browser will be nice and assume you meant action="(the current URL)". That's how form data goes back to your page: because the browser told your server that it wanted the same URL with some POSTed data. If you have a form with an action="checkout.php" then the browser doesn't have to assume anything, and it will tell the server that it wants checkout.php with some POSTed data.

A meta-refresh will do what you want <?php echo "Your pizza is ready<br>"; echo "<meta http-equiv=\"refresh\" content=\"5; url='url-to-go-to'\" />" ?>

a. the echoed time values should have been correct. are you sure about the posted code and the output that you got? b. browsers and web servers don't interact in real-time. even if you try to flush() the output, you are not very likely to get the result you want (see the php.net documentation for the flush() statement to see all the problems with trying to do it this way.) c. people don't like to wait on web pages to display things for x amount out time (it's either too long of a value or too short of one to suit the current visitor) or to redirect around on your site. the only redirect you have upon successful completion of post method form processing code should be to the exact same url of the current page to cause a get request for that page. if you want to display a one-time success message, store it in a session variable, then test/display/clear that session variable at the appropriate place in the html document. any navigation to other pages should be handled using navigation links where the visitor can choose where they want to go to next.

If you have a SQL injection vulnerability, separate tables will not necessarily help you. Depending on the kind of vulnerability / setup you have the attacker may be able to run queries against arbitrary tables, or just drop the entire database. Aside from that, separate tables will become a maintenance nightmare when next year you need to add a few extra fields to the schema for all 10,000+ tables or whatever. Or you decide you want to be able to aggregate the data for a report and have to query every table and combine the results. Multiple tables with the same schema is the wrong solution 99.999% of the time, and you're not in that small 0.001%. Your wrong. Databases are designed to process data. They are designed to deal with tables that have many rows quickly and efficiently so long as you set them up properly. As an example, I have a table that records every login attempt to a website. It currently has about 2.2 million rows in it. I just queried it to find all my login attempts. It came back with 2976 rows. Guess how long it took the database to find those records out of the 2.2 million total records? 0.271 seconds. Yes, less than a second. If they can inject a DROP TABLE command, they can probably inject a SHOW TABLES command to get a list of all your tables then loop that list and drop each one. Your approach buys you nothing. You need to make sure you're not vulnerable to an injection attack in the first place, and then have solid backups to restore from just in case something does happen.

the username is a value that originally came from external submitted data. depending on your registration code's validation logic, it could contain anything, such as a hexadecimal encoded string, consisting of just letters and numbers (a hexadecimal encoded string, in a non-string context, will be decoded into whatever string it actually contains), or it could contain single-quotes, that if put directly into an sql query will allow sql injection. it sounds like you think that using a prepared query ONCE, when the data was first submitted and stored makes the value safe to use in all future queries. it does not. it only made that first query safe. any value that ever came from external, unknown, or dynamic data (recently, a year ago, or a year from now, when your application gets updated to get usernames via a call to an external api, where you don't know what type of characters it might contain) must treat the value as unsafe in whatever context the value is being used in (sql, html/css/javascript, email header, filename, system/shell, ...)

It's not just about user input. It's about not knowing right there at that moment whether the value is safe. Can you guarantee that there is no possible way a username could have anything wrong with it? Not just in the database but also the value stored in the session? Modern day "hacks" are not about finding a single problem that gives someone complete access. They're about finding a series of small vulnerabilities that combine to form something large. In your case, perhaps there's a way to get a username that's kinda invalid into the database, and then maybe there's a flaw in some code that loads the username into the session, and then maybe there's a flaw in this particular script where the bad username in the session can turn into SQL injection. That's why application security is so difficult: to protect yourself you have to make sure that everything is covered, but for a malicious user all they have to do is find one or two problems.

You're putting the entire table in there. The only thing you need you need to repeat is the data row (that being the second <tr> and what's inside it). You'll also have a bit of a problem with where your code is. The loop is before your <html> so you can't put the table row in there. Instead you need to move the loop itself. That also means moving the mysqli_close, since you can't very well read the query results once you've closed the connection. The good news is that you don't need to close the connection in the first place. PHP will do it for you when the script ends.

your table header also has an extra <th> before user name

That's true, as far as I can tell what you're talking about. But that loop you have only uses some variables. Every time through the loop it updates those same five variables to have five new values. By the time the loop ends, all you have left is whatever the five latest values were - everything that happened before is lost. You've got a loop that can go through all the results. You've got some HTML for a table row. Instead of using the loop for some variables, use the loop for the table row.

This could be a language barrier thing, but I'm a bit confused.It sounds like the user will select a material from the second drop-down then scan a QR code that identifies the material they're scanning and that scan should match the selection from the second drop-down? If so, why? What's the thought behind making the user select a material from the second drop-down and then match that to the QR scan? Also, because the problem isn't clear at this point show the code you have, as well as any error messages or unexpected results you're getting. Assuming there's no error message and the results are unexpected, give us the results you were expecting.

Again, you haven't gone into any sort of detail about anything regarding these dropdowns so I have no idea what it is you need to do. Besides... use Javascript? If you want more detailed advice then you'll have to start posting code and markup and whatever you have, along with a complete description of what sort of "data matching/comparison" you're talking about.

It's not like the experience is entirely unusable... Make the scanner so it gets the data from the QR code. Use Javascript to do whatever it takes to validate with the dropdowns - I have no idea what this part is since you didn't go into much detail about it. Then either you submit a form or you send an AJAX request to the server to store "the timestamp" (what timestamp?) in the database. Break the whole thing down into discrete steps: scanning the QR code is one, validating with the dropdowns is another, scanning the second QR code is a third, and so on. Work on each step in turn.

I am not familiar with vagrant, but when I setup my virtual box VM's if I want the VM accessible from the rest of the network it needs to be configured with a Bridged Adapter for the network and have an IP on the same subnet (that'd be 192.168.1.x for you presumably, unless your using a /16).

As given, the code loops through each line in the file, looks to see if that line contains the entered word and, if so, displays that line on screen, effectively creating the HTML link (because that's what each line of the file is!). It's a really clumsy way of doing this, because The links are hard-coded in the file, making them difficult to maintain, and The test (strpos) will find the given word anywhere in line, so if you were to enter the value "target", it would match each and every line! A simpler and safer way might be to hold just the words in the file, without all the HTML stuff, and search that, then create the HTML for the selected line: . . . $found = false; foreach ($lines as $line) { if ($line === $search) { $found = true; printf( '<a href="https://blabla.com/blablabla/blablablabla/%s" target="_blank" rel="noopener noreferrer">%s</a><br/>', $line, $line ); break; } } // If the text was not found, show a message if (!$found) . . . Regards, Phill W.

... For one, percent and weight are not interchangeable units. I can't imagine why a thing is being labelled with a "kg" unit when it's supposed to be a percentage. It doesn't make any sense. It isn't the sort of problem that should exist. For two, I can't imagine why someone has a thing in a (shopping?) cart that is measured in percentages. Sweeping this problem under the rug is not the answer. You need to deal with the fact that WP or whatever is attaching incorrect units to the items. Because there's a really, really good chance that the wrong units are a symptom of a larger problem.

Your column headers are being generated inside the while loop. Move them to outside the loop so they only generate once. The <td> <inputs> should be left in the loop.

Sessions are for sharing data between pages. This does not involve sharing data between pages. Sessions are not appropriate. Don't get ahead of yourself. You're imagining stuff that does not need to exist. Breadcrumbs for a user CP page? You don't need anything "universal" to do that. It's Forum -> User CP. That's it. There's nothing fancy there: just a link, an arrow, and some text. You can write exactly that on your page. Breadcrumbs for things like threads and lists are potentially trickier because you don't always know the hierarchy. Threads are in subforums, but what are subforums in? Other subforums? You don't have that information ahead of time. Don't bother with anything universal. You don't need it. Just get breadcrumbs on thread pages working.

Your breadcrumb is based on browsing history. Are you sure that's what you want? Because I really doubt it is. And if it is then you should really reconsider because that's not how they're supposed to work. Unlike the kind you hear about in stories, page breadcrumbs are not history but about location. For example, look at the breadcrumbs for this page (just above the page header): this page is located in PHP Coding Help, which is a subforum of PHP Coding, which is one of the main categories for the whole site.

Ah, there's no feeling in the world quite the same as receiving a reply that says "thank you for the advice on what I should be doing right but I really don't give a damn".

To run a web application you require a webserver. To run a web application with php you also require some support for php integrated into the webserver. There are a number of different webservers, the two most popular being apache and nginx. There are a number of different ways of integrating php with the webserver. With Apache you can choose to use mod_php which is an apache module that integrates php or you can use apache with php-fpm (fastcgi process manager). With Nginx, your option is to use php-fpm. Eventually people typically also will need a database or data persistence server like mongodb, and often will have a caching server like Redis. On your local machine you can install the webserver and everything else you will need and run those. There are popular installation and configuration setups like WAMP and MAMP that have been around for a long time, and many people use. I have mixed feelings about these. The problem is that they install all these things on your workstation, some of which you might not want or need, and then they are running typically even when you don't need them because you aren't developing. They also have to be upgraded and managed as time goes on. In recent years there was a move by most developers and teams to using virtualization. With virtualization, you can run a virtualized server on your workstation and interact with that server in the same way you might interact with a hosted server. The great thing about virtualization is that you can start an environment when you want it and stop/pause it when you don't. It's also isolated from your workstation. This has many advantage including the ability to develop on the the same platform you will deploy to, as most servers are running some sort of linux, with the vast majority being either RHEL/Centos or Debian/Debian based distributions. Installing a virtualization manager like Virtualbox or Vmware facilitates the use of a provisioning manager like Vagrant. With Vagrant you can use vagrant "boxes" which will download and start up a full virtualized server environment with all the server processes you might want or need. This is how lots of people were doing development even a few years ago, and there are many people who probably still use Vagrant. More recently many developers have moved to Docker. Docker supports "containers" which are small environments that can run anything from a full server, to a single process. I won't go into all the details, but with Docker you can start up the things you need (for example apache/mod_php in one container, mysql in a 2nd container) and allow you to run your application locally while also allowing you the same iterative development process you might use with the php server. To understand all of this, you also have to understand a fair amount about networking, dns, linux distros, package managers and shell scripting, as well as the support and configuration of a webserver. If you want to proceed, then I'd recommend learning about Docker. There are some projects that have pre-built docker environments you can look at. https://laradock.io/ is a popular one that is focused on laravel projects, but can be used for other php projects. I've also heard good things about https://lando.dev/ although I haven't had a chance to experiment with it, and then there is the massive but generic LAMP http://devilbox.org/ Any of these will help you get a jump start on using Docker as an alternative to installing everything locally. At the end of the day, going to localhost:8000 vs localhost is not a sufficient reason to spend all the time going down the rabbit hole of all this stuff as you are still learning the basics of web development and php coding.

You're still trying to paddle upstream without a paddle. My suggestion would to be look at a CURRENT tutorial on adding, updating, and deleting data to a database table. I would also suggest PDO instead of mysqli as I feel it's more robust, but that is a personal preference. I like this PDO tutorial as they do a nice job explaining how PDO works : https://phpdelusions.net/pdo

Use JOINs with a single query to get the information you want instead of running multiple queries If you are only retrieving a single record, don't use a while loop - a single fetch will suffice Use prepared statements - don't put variables directly into the SQL string <?php /* MK_users MK_role_access MK_baccounts +-----+---------------+ +----------+----------+ +-----+------------------------+ | uid | fullname | | role_uid | role_bid | | bid | businessname | +-----+---------------+ +----------+----------+ +-----+------------------------+ | 1 | Laura Norder | | 1 | 10 | | 10 | Amazon | | 2 | Peter Dowt | | 2 | 20 | | 20 | Apple | | 3 | Tom Di Canari | | 3 | 30 | | 30 | Paula's Poodle Parlour | +-----+---------------+ +----------+----------+ +-----+------------------------+ */ $_SESSION['id'] = 2; // provide a value $res = $conn->prepare("SELECT ba.bid , ba.businessname FROM MK_role_access ra JOIN MK_baccounts ba ON ra.role_bid = ba.bid WHERE ra.role_uid = ? "); $res->bind_param('i', $_SESSION['id']); $res->execute(); $res->bind_result($bid, $business); $res->fetch(); echo "$bid - $business <br>"; //==> 20 - Apple ?>

$query = 'SELECT * FROM convoy_part WHERE user_convoy= :I'; $start = $bdd->prepare($query); $start->execute(array(':I' => $_GET['id'])); $rows = $start->fetchAll(PDO::FETCH_ASSOC); foreach ($rows as $row) { // Zählung der Datensätze echo "<pre>"; print_r($row); echo "</pre>"; }

Find a better way to store the ids than a comma-separated list.

If you had used a data model like the one I suggested to you in May 2019 ... ... the coached_from and coached_until dates would give you who the coach was/is at any point in time.

try $temp = []; foreach ($cars as $car) { $qty = intval($car); $key = trim(strstr($car, ','), ','); if (!isset($temp[$key])) $temp[$key] = 0; $temp[$key] += $qty; } foreach ($temp as $k => $t) { $newcars[] = "$t,$k"; }

You could roll your own. function twoColorCircle($a, $b, $sz) { $out = "<svg width='$sz' height='$sz' viewBox='0 0 1000 1000'> <linearGradient id='grad2' x1='0' y1='0' x2='1' y2='0'> <stop offset='0%' style='stop-color:$a'/> <stop offset='50%' style='stop-color:$a'/> <stop offset='50%' style='stop-color:$b'/> <stop offset='100%' style='stop-color:$b'/> </linearGradient> "; $c = 500; $r = 499; $out .= "<circle cx='$c' cy='$c' r='$r' fill='url(#grad2)' stroke='#000' /> </svg>"; return $out; } foreach ([16,32,64,128,256] as $sz) echo twoColorCircle('#5fc75d' , '#f19e2d' , $sz); echo '<br>'; foreach (['16em','8em','4em','2em','1em'] as $sz) echo twoColorCircle('#5fc75d' , '#f19e2d' , $sz);

Alternatively, define your monetary amount columns as decimal(). This gives fixed number of decimal places. Here's an example DATA CREATE TABLE `income` ( CREATE TABLE `expense` ( `income_id` int(11) NOT NULL AUTO_INCREMENT, `expense_id` int(11) NOT NULL AUTO_INCREMENT, `userid` int(11) DEFAULT NULL, `userid` int(11) DEFAULT NULL, `pay_date` date DEFAULT NULL, `expend_date` date DEFAULT NULL, `amount` decimal(10,2) DEFAULT NULL, `expamount` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`income_id`), PRIMARY KEY (`expense_id`), KEY `idx_income_userid` (`userid`) KEY `idx_expense_userid` (`userid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; ) ENGINE=InnoDB DEFAULT CHARSET=utf8; income expense +-----------+--------+------------+---------+ +------------+--------+-------------+-----------+ | income_id | userid | pay_date | amount | | expense_id | userid | expend_date | expamount | +-----------+--------+------------+---------+ +------------+--------+-------------+-----------+ | 1 | 1 | 2020-01-01 | 2500.00 | | 1 | 1 | 2020-01-15 | 800.00 | | 2 | 1 | 2020-02-01 | 2650.00 | | 2 | 1 | 2020-01-25 | 250.00 | | 3 | 1 | 2020-03-01 | 2400.00 | | 3 | 2 | 2020-01-21 | 1500.00 | | 4 | 2 | 2020-01-01 | 3000.00 | | 4 | 2 | 2020-02-10 | 500.00 | | 5 | 2 | 2020-02-01 | 3100.00 | | 5 | 2 | 2020-03-15 | 1800.00 | | 6 | 2 | 2020-03-01 | 2800.00 | | 6 | 2 | 2020-03-20 | 1600.00 | +-----------+--------+------------+---------+ +------------+--------+-------------+-----------+ QUERY SELECT i.userid , mname , income , expense , income - expense as diff FROM ( SELECT userid , EXTRACT(YEAR_MONTH from pay_date) as month , MONTHNAME(pay_date) as mname , SUM(amount) as income FROM income GROUP BY userid, month ) i LEFT JOIN ( SELECT userid , EXTRACT(YEAR_MONTH from expend_date) as month , SUM(expamount) as expense FROM expense GROUP BY userid, month ) e USING (userid, month); +--------+----------+---------+---------+---------+ | userid | mname | income | expense | diff | +--------+----------+---------+---------+---------+ | 1 | January | 2500.00 | 1050.00 | 1450.00 | | 1 | February | 2650.00 | NULL | NULL | | 1 | March | 2400.00 | NULL | NULL | | 2 | January | 3000.00 | 1500.00 | 1500.00 | | 2 | February | 3100.00 | 500.00 | 2600.00 | | 2 | March | 2800.00 | 3400.00 | -600.00 | +--------+----------+---------+---------+---------+

Use $diff->days. $dt1 = new DateTime('2020-05-01'); $diff = $dt1->diff(new DateTime())->d; //--> 14; $diff = $dt1->diff(new DateTime())->days; //--> 44; ->d gives the days as in "1 month 14 days" ->days gives the total days Using SQL: select datediff(curdate(), '2020-05-01') as days; +------+ | days | +------+ | 44 | +------+

foreach ($global_array as $k => $v) { foreach ($global_array as $k1 => $v1) { if ($k==$k1) continue; if (array_values(array_intersect($v, $v1)) == array_values($v1)) { unset($global_array[$k1]); } } }

Assign role to users Have an access table to define which roles can access which files (As requested, all tables are accessible via PDO) +-------------+ +---------------+ +--------------+ | user | | role | | file | +-------------+ +---------------+ +--------------+ | user_id | +------| role_id |-+ +---| file_no | | username | | | description | | | | filename | | password | | +---------------+ | | +--------------+ | role_id |>-----+ | | +-------------+ | | | +-------------+ | | | access | | | +-------------+ | +--<| role_id | | | file_no |>-+ +-------------+

Hi Barand, Amazing code and you only read a description of my bookmark profile. You are a 'helluva' coder. Your expertise and mastery shows in your replies. I don't really need to change anything that you have posted other than names but i didn't post to get free code. I am trying to learn from your example. I'm reading about sql now so that i can think better about these problems and approprite solutions. I'd like to come to the same conclusions as you oneday. I really learn alot from you and i thank you for that. Meantime, i've changed the last login code and it works well. I was actuly just inserting your login into lastlogin then inserting the current login into current login. I guess it is easier to say that login becomes your last login before i update the login. I guess i was thinking wrong here. Your idea is better. I don't have time to add the book mark code today. I have alot of things to do and i am behind schedule. I'll read more about sql before i go to bed, then tomorrow i will tackle this topic. I finished adding the bookmark profile to each page, so all i have to do now is submit it to the dbase. This code example is a great start! I also have to read the data from the db before i can display the bookmarks. I do not have so much coding experience as you do, so i am a bit slow. I'll update the post when i can finish this feature. I'll let you see the final code here so you can offer an opinion if you want to do so. Thank you, Barand, i have learned alot about sql today. You are steeringme in the right direction!

Yeah, sure, it sounds all very possible. What do you need recommended? Sounds like you already know what you need to do.