maxxd
-
Posts
1,655 -
Joined
-
Last visited
-
Days Won
51
Posts posted by maxxd
-
-
Am I wrong in thinking I read somewhere that it's pretty easy to spoof the request method header? I'm assuming now that I am, but I've always avoided checking it for that very reason.
What I will typically do is insert a hidden value in the form (which can easily be changed, but there are stops to avoid that) and check for that hidden value in the superglobal of choice. For instance,
<?php public method handleIt(){ if(isset($_POST['axn']) && isset($_POST['nonce'])){ $method = "action".ucfirst($_POST['axn']); if(method_exists($this, $method)){ $this->_something = $this->$method($_POST); } } } private function actionAnAction(array $vars){ if(!$this->_nonceObject->checkNonce($vars['nonce'])){ return false; } return $this->doStuff(); } ?> <form name='doIt' method='post'> <input type='hidden' name='axn' value='anAction' /> <input type='hidden' name='nonce' value='generatedNonce' /> <input type='text' name='lah' value='deDah' /> <button type='submit' name='whatever' value='Do It' /> </form>Please excuse the obviously inane code (it's been a rather long day), but hopefully it's enough to illustrate the point, and it seems to me this is safe and thorough enough to make sure you're dealing with a legit form submission, exactly how you intended the form to be submitted.
Either way, $_REQUEST needs to be retired immediately. Then we can all just sit back and watch WordPress burn.
-
Theoretically, yes, you can combine arrays in nested foreach() loops, but I'm not sure I understand what your end goal is, which makes it difficult to advise how one would possibly go about doing that. What's the correlation between the array values? Right now it seems utterly random.
-
If it's a Debian flavor of Linux, you should be able to run
sudo apt-get update sudo apt-get upgrade
and that'll update everything except the operating system itself. Honestly, if you're already thinking about wiping the system and starting over, there's nothing to lose by giving it a shot. And you may end up saving yourself some time and headache.
-
This may be a dumb question, but why not just update PHP? I'm not a server jockey by any stretch, but I don't remember hearing anything about PHP updates that would cause it to not compile on even old equipment. I've got a severely under-powered 7-year old eMachines box sitting in my office that I use as my development LAMP stack and it works wonders for developing and testing. Granted, it's not directly connected to the Internet, and it's not up to version 7 yet, but it does work well.
-
1
-
-
Hunh.
I thought 'visibility: hidden' behaved more like 'display: none' - good to know. Thanks for running the tests and posting your findings!
-
No disrespect taken - it was a quick and dirty answer, honestly.
I almost went so far as to use .toggle() instead of .css(), but had a meeting to go to. The only thing about using opacity instead of toggle(), hide(), show(), or display/visibility is that opacity will leave the element in the DOM. Which can be a pain for form processing (there will be extra variables in there that you don't really care about), but it will still at least take up the physical space in the DOM so that anything beneath the second select element won't suddenly reflow upwards.
At any rate, thanks for fleshing out the example and pointing out the omissions!
-
$('#location').on('change',function(){ if($(this).val() == 'loc5'){ $('#second').css({ opacity: 1 }); } });Of course, you'll need to set the secondary element to 0 opacity in the stylesheet.
-
There's no way for us to tell why it's failing right now as the SQL looks fine. What you need to do is check the results of the query. See if the query failed; if it did check the error using mysqli_error().
if(!mysqli_query($con, "UPDATE news SET news_title='$news_title', news_content='$news_content', publish='$publish', facebook='$facebook' WHERE news_id='$news_id'")){ print("<p>Don't print the error to screen in a real application; but for testing purposes the error is ".mysqli_error($con)."</p>"); }Also, please note that you're inviting SQL injection by putting suspect data ($_POST values) directly into the SQL. Look into prepared statements - honestly, here's where you're going to find PDO much easier to deal with.
-
Not entirely sure I'm following what you're asking (been a long week, sorry) but this article on Active Record and Data Mapper patterns may be a good read.
-
Is this not an option you can set from the WordPress dashboard? Admittedly I've not used it, but I assume WooCommerce PayPal plugin would have a settings or option page accessible to the site administrator.
-
You should be getting a good number of errors using this code, because quite honestly it doesn't make any sense at all. Add the error reporting code in ginerjm's signature to the top of your file.
First and foremost, that's not how you use a ternary statement. You want something more along the lines of this:
$friend[] = ($r['friend_one'] == $_SESSION['uname']) ? $r['friend_two'] : $r['friend_one'];
Second, you're creating an empty string called $project, then attempting to access the totalids() method of that empty string, which obviously doesn't exist. If $project is supposed to be an object with the valid method totalids(), you'll need to pass that object in to the function in order to use it. Even if you do pass in the correct object, you're overwriting the value of $totalids on every loop iteration, which may not be what you intend to do.
$project = ""; ... $totalids = $project->totalids($_SESSION['uname'], $friend);
Third, you're assigning a value ($r['friend_one'] or $r['friend_two']) to the next numeric index in the $friend array, then immediately trying to access that data at a specific numeric index, which may or may not exist. If the specified index does exist, it looks like it would be completely accidental.
The print_r() statement shouldn't be printing anything at all right now.
-
You need to drill into the outer array in order to get to the inner ones. So, if you're actually going to ignore any data other than the contents of the first array index, you'd use
$parsed_json[0]->name;
to get the value of 'name' in that first array value.
I don't know the business logic behind the feed you're parsing, so I'm not sure if just checking the existence of the name value will work, but the implication is that if the name field contains data, that user is online, right? If so, wouldn't it be possible to assume that if there's a record, there's an online user? Seems like it'd be a bit wasteful to populate a feed stream with empty data. At any rate, you could do something like
$status = !empty($parsed_json[0]->name) ? true : false;
-
That's not really how a race condition happens. A race condition is going to be a concern mostly when considering something using controlled, unique indices - consider user signup where you've got a system that runs a select query with the requested username supplied by a user, then inserts that username if the select query doesn't return a result. Basically, in this case user A and user B request the same username at almost the same time, both select queries will report that the username is available (ie, not already in the database table). Then user A's insert query is run and suddenly that username isn't available to user B despite the select query - quite correctly - reporting that is was available just a second ago. Or, if there's not a unique constraint on the username field in the database, suddenly you have the same username associated with two distinct records.
What you're describing is a simple insert query. There's no select to check the availability of any index, so no race condition can occur. As everyone has said in this thread, if user A and user B insert a new record at the same time, the worst that's going to happen is that both records will be inserted, which is honestly kind of the point of the thing to begin with. There's no unique constraint (either defined or implied by the business logic) to make this an issue.
-
A variable in double quotes will be parsed, whereas a variable in single quotes will not be parsed, but rather treated as a string literal - it doesn't matter where or how the variables are declared.
-
You may want to look into a routing system where this is done for you. You can spin your own using PHP and .htaccess, but there are several available online that can take care of it for you and have the benefit of being widely tested and publicly developed. The biggest thing for this is it's easier for your users to remember, it's more search engine friendly, you don't have to write and test it, and you know exactly what you are getting and where it's coming from.
In addition to the things @ginerjm pointed out, I'd highly recommend switching from mysli to PDO. Prepared statements are much easier to deal with in PDO, and you should never, ever inject user-submitted data (such as $_POST variables, let alone $_GET) into a database call. Seriously, don't do it.
You're also declaring $con as a global variable. Although there's nothing technically wrong with doing this, it's not a good idea. Things get very confusing very quickly when you declare a variable to be global; where is that variable declared? What was in it when it was declared? What was put into it later, either by accident or intention? Passing the variable to the function leaves a clear trail of accountability that you can trace when things - as they inevitably do - go south.
I also just noticed that you seem to be running the exact same query twice. Why?
-
Before you start trying to answer your initial query, you need to look at the underlying database structure - what you've told us about it certainly sounds like it's going to make life more difficult for you moving forward. If you restructure your data as Barand and benanamen have suggested, you'll find your SQL joins to be much more self-explanatory and the data you do receive much more usable. It'll then be two simple joins - one from player_shirt to player and one from player_shirt to shirt to get any number of shirts per player. As it stands now, you're locked in to one shirt per player, and you can't have a player on multiple teams, let alone a user that's a player on one team but captain of another. In order to satisfy your initial request to count the number of shirts, that then becomes a simple COUNT(*) AS num_shirts from the player_shirt table - no joins needed at all.
-
var_dump $result and see what's coming back. And this is one of those dumb questions that has to be asked, but you are using different email addresses or deleting any inserted data between rounds of testing, yes?
-
Thanks, Barand - I meant to link that...
@ohno - There are plenty of people on this board that can. Post in the Job Offerings forum and I'm sure you'll get replies. And depending on your server setup, no, you may not have to upgrade; however, running outdated, unsupported versions of PHP is dangerous to your company and to your company's clients, so you'll want to.
-
It all works right now - it won't work in the very near future. PHP7 has removed the mysql_* functions that are used all over this code. So at some point in the near future (depending on how quickly your host updates their servers), this one section of code will be the absolute least of your worries. As benanamen and mac_gyver said, you're going to need to have this code rewritten using PDO (or do it yourself).
-
It's been a long day and I'm tired, but I think your prepared statement is malformed. When using a prepared statement, you only have to actually prepare it once. Try:
if(isset($_POST['defid'])){ $sql = $conn->prepare("INSERT INTO modified_adjustments (default_id) VALUES (:did)"; foreach($_POST['defid'] as $did){ $sql->execute(array('did'=>$did)); } }Of course, you'll want to check for errors and may want to wrap the whole thing in a transaction, but (assuming my brain hasn't broken), that should be the basic idea.
-
Personally, I'd use DateTime objects.
Right now you're comparing strings which technically does work thanks to PHP's loose typing, but it can lead to hard-to-pinpoint bugs and odd behavior. Not sure what responses your API gives, but if you try to compare "INVALID_ACCESS_TOKEN:INVALID_ACCESS_TOKEN PM" to "12:53 PM", it's going to give weird results. Obviously. However, an incorrectly formatted time string in the constructor of a DateTime object will throw an error that you can handle. Plus, I just find the DateTime objects easier to work with when it comes to comparisons and any mathematical operations.
-
1
-
-
No offense, but this is a hot mess. As benanamen points out, you're using code that is about a decade out of date for dealing with the database calls. Not only that, you're attempting to use the $all variable before it's defined and you're not associating any of the 'add to cart' buttons to a specific product so how is your processing script supposed to know which product is meant to be added to the user's cart? I'm not going to go in to the output of raw variables into HTML but you're going to want to look into escaping output, and just the mishmash combination of php and HTML is going to make this a bit of a nightmare to maintain or extend as you move forward. Ideally, you'd use a separate php file to gather your data and a templating system (twig is great, btw) for display.
If you continue forward with the code you've posted, first thing's first - use PDO instead of mysql_* functions. This will allow your site to still be functional later this year. You'll want to gather all the product data into an array at the top of your script, then print out the line items later on in the body of the page. You can do this is one of two ways: create a separate form for each item listed that contains a hidden field with the product ID as mac_gyver suggests, or change the name of the submit button to an array where the key is the product ID as such:
<input type="submit" class="..." name="my-add-button[product][<?= htmlspecialchars($all['id']); ?>]" value="add to cart" />
That way, when the form is submitted, you know what product the customer actually wants. There shouldn't be a need for the product name or price to be stored in the form as your processing script can grab that data from the database.
-
1
-
-
You're not actually validating any of the submitted fields. Just because a value is set in $_POST doesn't mean it's not empty or a blank string, nor does it mean that the field doesn't contain additional mail headers (allowing an unscrupulous user to use your contact form the send spam). I suggest you do some research into data validation, sanitizing, and escaping - it'll make life better for everyone involved.
-
Check out PHPMailer.
How do you show php foreach loop results as ajax mousehover?
in PHP Coding Help
Posted
You'll have to target each 'show-details' class individually. Put that div inside the 'product' div and target it specifically. This is untested, but should theoretically work:
$(document).ready(function(){ $('.product').mouseover(function(){ $(this).find('.show-details').css({ display: 'block' }); }); $('.product').mouseout(function(){ $(this).find('.show-details').css({ display: 'none' }); }); });