Leaderboard

If you can get the quantity you could use a simple if statement. Something like <?php echo ($quantity>50)?'Secret':$order->get_formatted_line_subtotal($item);?> I'm not familiar with WooCommerce so I don't know how to determine $quantity, but if you look at the part of the template that shows the quantity you can probably figure it out.

When I said leave the action off I meant that literally. Don't put that in at all but I don't think that is the real problem. Start debugging by putting print statements after each mysqli to follow your logic so you can tell where it is failing. If you are getting a blank page then make sure there is no logic path where there is no output. Also check the page source to see if there is anything there that the browser is not displaying.

If your query is only intended to return one row, then you just fetch the row and check with a simple if statement whether data was fetched or not. $row = $result->fetch_assoc(); if ($row){ //Yep, got data } or $row = $result->fetch_assoc(); if (!$row){ //Nope, no data available. } depending on whether a positive or negative test fits best with your situation.

Don't feel bad, neither did I.

One day I decided to check out my own Shared Hosting website, typed in the URL, and instead of a page appearing, a "file" downloaded to my computer desktop. Turns out that the hosting provider did a mass "upgrade" which broke the custom code in my .htaccess file, which in turn caused all my PHP pages to be considered as "files," which all got downloaded to anyone who visited any of my pages. I learned 2 lessons: a.) Don't have poorly written .htaccess code which can be 'broken' b.) Don't have any sensitive data (like your mySQL "conn.php" username password, etc.) in any public directories. Either put them up one level, or, like Barand said, define them in your php.ini so that later, even you won't be able to find them 😀

$_SERVER['PHP_SELF'] is vulnerable to an XSS Attack. Just delete the action completely. Yes, it is, but it is a Security problem and shouldn't be used. You "could" use it if you enclosed it in htmlspecialchars but that is just sloppy. Cleaner to leave the action out completely.

i just noticed the cause of the problem. you have a stray semi-colon ; on the end of the while() statement. this short-circuits the loop, so that it loops over all of the data first, then your code that you think is part of the loop, inside the {}, is actually after the end of the loop, where there is nothing in $row. this is the the correct syntax for a while() loop when using { } around the conditionally executed statements - while (some condition is true) { code to execute inside the loop } // or even better, put the opening { on the next line so that it is alighned with the matching } while (some condition is true) { code to execute inside the loop } - you shouldn't even be using a loop to fetch the data from a query that will at most match one row. just directly fetch the row of data. btw - since you are comparing the user number in the query, if the query matched a row of data, you know that the user number was found. you don't need to compare it again in the php code. also, your comparison in the php code, because you are using an exact, not equal !== match, will always fail. by definition all form data are strings, regardless of what value they hold and the fetched data from a mysqli query (if using the default settings) is the actual data type of the column in the table. a string data type (the variable with the form data) will always be not equal to an integer data type (the variable holding the fetched user number from the query.)

PHP is getting confused about the single quotes in the SESSION variable. You could add curly brackets around the variable: $query = "SELECT page_url,link_anchor_text,page_description,keyphrases,keywords FROM links WHERE {$_SESSION['search_column']} = ?"; Or you could utilize string concatenation: $query = "SELECT page_url,link_anchor_text,page_description,keyphrases,keywords FROM links WHERE " . $_SESSION['search_column'] . " = ?"; Note that you want to validate the "search_column" variable. That way you prevent the query from potentially breaking if the column name is a reserved word or if the column name doesn't exist in the database table. You will also want to prevent things like SQL injection attacks.

@2020, good, you have PHP error reporting turned on.... but where is your mySQL error reporting? Just yesterday there is a whole important thread here on this (I think if you implement it, you'll find what's going wrong): p.s. Okay, let's do a PDO race. But I should be given a head start, considering my old age 😀

Google is my friend: https://stackoverflow.com/questions/6080022/php-self-and-xss I read about that last night, very interesting. I also read this article. Whenever I see two or more ways to do something, I'll google search using "vs" as a search term. For example I'll type into google: mysqli_stmt_init vs ...and then I get to read articles where people argue about which way is best. Another thing I do (for fun) is speedtest my whole PHP page ($startime at beginning of page, $endtime at bottom of page), and figure out where the slow points are. I remember spending a whole week getting my page load time from 885ms down to 665ms. That was exciting. And, yes, from this you can infer that I don't do real PHP work, I just like learning and messing with PHP. Regarding mySQLi, Barand is the forum expert here.... (his code is a work of art; he writes code that even the PHP inventors haven't invented yet), and he uses PDO. I'd like to learn PDO. PDO does seem to benchmark a tad bit slower, but it looks way cooler! One of these days....

Oh, I learned something again. I used to do it this way: <?php require("../my_secret_file.php"); ?> (The ../ part tells PHP to go up to the directory just above the viewable public_html directory). But I like Barand's answer: by defining these hidden directories in your php.ini file, it's a bit more secure. Again, if some idiot switches off PHP at your Shared Hosting provider, everyone will be able to see the require("../my_secret_file.php") in plain text. Of course, they still won't see what's in the secret file, but they will know where it's at :-) You know those interviews they do on TV where the interviewee does not want to be seen.... so they have all the lights out. It's totally dark, and his voice is disguised. During the interview, someone accidentally comes in the room and switches on the light hahahaha. THAT can happen with PHP. And, of course, stuff like that happens while you are on a vacation, or in the middle of the night. So when you log into your site, all of a sudden you see your PHP code everywhere. Or.... worse, you go to your "www.my_supposedly_secure_page.com" and it DOWNLOADS to your desktop as a downloaded file.......THATS always fun. 😀

...Yes. You know how you have your RewriteRule that sends a particular URL pattern to index.php? You do not have one for the new URL pattern. That means it won't go to index.php. And PHP cannot do anything if it doesn't get the request. You don't need any PHP for this. All you need is a new RewriteRule for the new URL, and it can still use your index.php with controller and action and id by simply specifying a default value for the one that's missing.

By referencing the file system path to the file or by defining an included files folder in your php.ini file.

Yeah, must be tough. I was only in my 50s when I started learning PHP.

Yes If the drop down was malfunctioning, there was something else wrong with the code. Perhaps one of the tags was missing or coded incorrectly. All the above "Select here" code does is create a new option in the drop down so that neither "Yes" or "No" is the default selection, which is a good way to make sure the user actually makes a selection. They have to actually to interact with the drop down to answer the question. That depends on the tutorial. Most tutorials don't talk about everything a reader needs to know in order to do something. Otherwise too much time will be spent on trying to explain the basics before they can get to the topic the tutorial was designed for. Or maybe this was beyond the scope of the tutorial. If the tutorial was about creating a simple form, for example, they are not going to go into ever facet of an HTML form. There would be too many things to discuss for a single tutorial.

@2020, my long lost twin 😀 It sounds like you're just like me, but quite a bit more advanced than what I know. I learned PHP code back in the late 90's... right after I learned how to fix people's broken Sony Walkmans. I'm still good at both: 90's PHP code, and fixing broken walkmans :-) Debugging code is the fun part. Just make sure you have ALL error reporting turned on, both PHP and mySQL, then start at the top few lines and comment everything out below and keep echoing stuff. When you uncomment the next block of code and you get errors, or a blank page, then that's where your first error is. This is a no-no, by the way: <?php echo $_SERVER['PHP_SELF']; ?>" (injection issues) And for your require('conn.php'), at least keep your conn.php up one level above public_html, like this: require("../conn.php"); And for housekeeping sake, I wouldn't have my form named the same as my button (both named "submit_link"). What the heck is mysqli_stmt_init.... I gotta look that one up. I'll learn something new today.