Phi11W

This is almost always the wrong way to do things. You cannot guarantee that this update process will run every, single day. This is Technology - stuff happens. Updating every record is a lot of [unnecessary] work for your database to do and will, almost certainly, lock the entire table, causing other issues. Showing stuff to Users is not the database's job. You'll write an Application that the Users interact with and that will show them your "remaining time". I'm sorry, but why? Users these days want instant responses, not arbitrary and artificially-enforced delays. If you are interested in a particular date & time, then work out when that is and store that. You never need to change it, "in bulk" or at all, Your application can calculate how long it is until "Real Time" catches up with it and show that duration to the User, no matter what they do in the meantime (refreshing, logging off-and-on again, etc. ), and You can easily tell once you have reached it in a SQL query. Keep it Simple ... Regards, Phill W.

I would go further and say you must not "select data in order to decide to insert or update it". That road leads to Race Conditions. Whist "on duplicate update" exists and works well, I would suggest making a conscious decision about which is the more likely condition to occur. In this case, I would say that updates are far more likely that inserts (with new pages only being added occasionally) so I would code the update first, and check to see whether zero rows were updated by it and, if so, insert the new row. Regards, Phill Ward.

The path is relative to where it starts from. Without any qualification ("inc/header.php"), it starts from the current directory, i.e. where the file doing the including is. With a leading slash ("/inc/header.php"), it will start at the root of the site. You might also be able to navigate "upwards", e.g. "../inc/header.php", but that's actively barred in some systems and will drive you mad if you have to refactor the site significantly. Regards, Phill W.

Hi Barand, If only for completeness, shouldn't you have a "group by Branch" in there? Regards, Phill Ward.

Five of your queries use "SELECT *". Do not do this in Production code. Databases are intrinsically shared entities and table structures can be changed [by anyone] at any time. Retrieving more fields than you actually need leaves you open to expected slow-downs, not of your making. Your remaining four queries could be combined into two. Taking the first pair, you can retrieve both aggregated values in one query: SELECT date_format(Date,'%Y') as month, COUNT(*) COUNT FROM calibrationdata WHERE Branch = '$userbranch' group by year(Date) order by year(Date) SELECT date_format(Date,'%Y') as month, sum(amount) FROM calibrationdata WHERE Branch = '$userbranch' group by year(Date) order by year(Date) // Can be combined into SELECT DATE_FORMAT( `Date`,'%Y' ) as month , COUNT( * ) as tally , SUM( amount ) as total FROM calibrationdata WHERE Branch = '$userbranch' GROUP BY year( `Date` ) ORDER BY year( `Date` ) Execute the query once, retrieve the values into an intermediate variable, then display that at the relevant point on the page. Also,. make sure that you have a database index supporting querying this table by Branch. Also, take a look at Parameterised Queries (Prepared Statements) to protect against SQL Injection Attacks. Obligatory XKCD Reference: Little Bobby Tables. Regards, Phill W.

Or, perhaps better (i.e. safer) ... switch( $_POST[ 'siti' ] ) { case: 'FIUMI' : case: 'MOLINI' : case: 'VITA' : $category = $_POST[ 'siti' ] ; break; default: throw new \Exception( 'Invalid category!' ); } Why? Just because you send the User an HTML SELECT list to use does not guarantee that the value you receive comes from that list! Regards, Phill W.

How does the User tell your code which "category" a file belongs to? Presumably, that would be another Form field, passed at the same time as the uploaded file itself. [Validate and then] Use that value to construct the target path for the file and pass that value to move_uploaded_file(). // pseudo-code if ( isset( $_POST[ 'btn-upload' ] ) ) { if ( validatePostArguments( $_POST ) ) { $targetFile = buildTargetPath( $_POST[ 'category' ], $_FILES[ 'file' ] ); move_uploaded_file( $file_loc, $targetFile ); } } Regards, Phill W.

You'll also note that my function returns a string which is then displayed by echo(). It's a subtle distinction but means that you can send that string result anywhere you want. You should retrieve the data up front and pass it to the templating "system", not the other way around. Having the templating "system" reaching out to get its own data whenever it needs it will cripple the application. You could wind up running dozens (or hundreds!) of queries where one would do just as well. The principle I'm trying to demonstrate here is that data retrieval (from the database) and creation of content (based on a "template") need to be separate functions and you use PHP code to get the data you want from one into the other. The "front-end" must be parameterised to take the data you pass it and apply those values to the template HTML. The "back-end" must retrieve the required data and put it in a form that you can pass to the "front-end". In my example, I used individual parameters, mainly for clarity. It sounds like you'd be better off passing an array, with key-value pairs containing the data. This allows the templating "system" to take whichever values it wants and use them and "ignore" any that it doesn't need. (This is the classic "XML" principle; a great idea, as long as you don't have to worry about security!). Regards, Phill W.

I think this is something like what you're after: function data () { //Abbrieviated code.... SELECT title, category, description, image_link FROM TABLE1 WHERE product_id=1; return $row ; } function template( string $title, string $category, string $description, string $image_link ) : string { $tmp = '<div class="t">TITLE %s</div>' . '<div class="l">CATEGORY %s</div>' . '<div class="m">DESCRIPTION %s</div>' . '<div class="r">IMAGE LINK <img src="%s"/></div>' ; return sprintf( $tmp, $title, $category, $description, $image_link ); } function go() { $row = data(); echo template( $row['title'] , $row['category'] , $row['description'] , $row['image_link'] ); } Regards, Phill W.

MySQL should be able to cope with loading 31000 rows with ease. What error(s) are you getting when try to load it? I would suggest loading the whole file into a "staging" table and then transferring data from that into your "proper" tables. Regards, Phill W.

In your login page, you need to extract the data from the data record you've retrieved and store it into the session, as you do for the username. $query = 'SELECT username, phone FROM users WHERE username=? AND password=?'; // bind parameters $result = mysqli_query($con, $query) or die(mysql_error()); $rows = mysqli_num_rows($result); if ($rows >= 1) { $_SESSION['username'] = $username; $_SESSION['phone'] = $result[ 'phone' ]; . . . Learn to use parameterised queries (which is much easier with PDO) to protect against SQL Injection attacks. Obligatory XKCD reference: Little Bobby Tables Never use "select *" in Production code. If somebody [else] adds some multi-Giga-byte columns holding the User's life story in video form, your super-quick login page suddenly slows to a crawl, having to read those massive fields that you've absolutely no interest in. Kudos for storing hashed passwords. Regards, Phill W.

You should be checking every single input value that comes from the client because you cannot trust anything that it sends to you! You have no control over the client's machine so you must regard it as completely untrusted. Just sending particular HTML to it does not count as control - just fire up the [free, installed-as-standard] "Developer Tools" in your web browser if you don't believe me. You must validate everything server-side and that means checking and cleansing every single input datum as it arrives. Would that not turn them on for every single User? Cue wide-spread confusion, complaints and bug reports! Yes, upgrades can be disruptive but I'd be surprised if every upgrade causes you problems. Or, perhaps, your codebase is simply older - the more versions you have to "jump" across, the more likely you're going to have problems. Sadly, software upgrading is like a diesel-powered hamster wheel - once you climb onto it and start running, it's very very hard to stop. (Unless you use VB6, of course - abandoned by "Our Friends in Redmond" in 2002 but still going strong today. 😉 ). To me, this sounds like you're either working with highly volatile data structures that change a lot or you have a lot of "dead" code handling data items that no longer exist. All the more reason to guard against missing elements properly. Regards, Phill W.

Not sure about best, but this should do the trick: <?php sacconicase_post_thumbnail(); $am = get_the_author_meta( 'discount', $post->post_author ); if ( $am ) printf( '<div class="mostrasconto">&nbsp;-%s%%</div>', $am ); ?> Regards, Phill W.

I don't think you need password_verify() at all here. When saving the password, hash the entered, plaintext, password and store the hashed value. When logging in, hash the entered, plaintext, password and compare that to what's in the database table. Saving password (as you currently have): $hashed_password = password_hash($password, PASSWORD_DEFAULT); . . . $sql = "INSERT INTO users (first_name, last_name, email, password_hash) VALUES (:first_name, :last_name, :email, :password_hash)"; . . . $stmt->bindParam(':password_hash', $hashed_password); Logging in: $email = $_POST['email']; $password = $_POST['password']; $hashed_password = password_hash( $password, PASSWORD_DEFAULT ); $sql = "SELECT a, b, c FROM users WHERE email = :email and password_hash = :hashed_password"; . . . $stmt = $pdo->prepare($sql); $stmt->bindParam(':email', $email); $stmt->bindParam(':hashed_password', $hashed_password ); $stmt->execute(); $user = $stmt->fetch(); If you get no rows back, either the username or entered password is wrong. Regards, Phill W.

Does your application know what to do with raw SQL passed as a QueryString argument? (If it does then I'd suggest that's a pretty poor design). if it doesn't then I see no point in defending against this. Hackers can throw this (and lots of other) stuff at your application, but it won't get them anywhere if your code doesn't try to do anything with it. Of course, you should vigorously validate and clean any inputs you do receive and that you do intend to do things with. Regards, Phill W.