Jump to content

Phi11W

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by Phi11W

  1. I'm guessing that's because you told it to? while( $r = mysqli_fetch_row( $result ) ) { echo "<option data-location_name='$r[1]' data-location_phone='$r[2]' value='$r[0]' selected> $r[0] </option>"; // ^ ^ ^ ID!! // | | ID // | Phone // Name // } Trying putting the name ($r['location_id']) inside the option element, not the id or, rather, whatever happens to be the first column that your query retrieves ($r[0]). Regards, Phill W.
  2. Taking these statements in order: $rec = mysqli_query( $db, "SELECT FROM joborder WHERE id=$id" ); This tries to execute a SQL query and puts the result - hopefully a set of results - into $rec. The function can also return false if its execution fails - which it will because your SQL in invalid. (What were you hoping to get from the joborder table?). I'll gloss over your SQL Injection Attack vulnerability for now. $record = mysqli_fetch_array( $rec ); Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, boolean given in line 8 So now PHP is complaining that you're passing a Boolean value (false) as the first parameter to this function. Fix your SQL and try again. 🙂 Regards, Phill W.
  3. You have an array containing the field names that were passed into the function. That array is used to build the SQL statement so those columns will be returned in each row. Now, for each row in the returned data, you need to loop through your fields array and pull out each value from the row, by field name, something like this: while( $row = $results->fetch_assoc() ){ $dlm = ''; foreach( $fields as $field ){ echo $dlm . $row[ $field ]; $dlm = "\t"; } } Regards, Phill W.
  4. Personally, I prefer to have my SQL clean and self-contained but then I don't have to work with WordPress. YMMV. Here's one way: public function wpquery_select($conn,$sql,$fields){ $sql = replace($sql,'*',implode(',',$fields); <-- Assumes your query has "select * ..." $results = $conn->query($sql); . . . Regards, Phill W.
  5. Thank you for posting your database's root password for the whole world to read. Go and change it right now. Stop using the root user in your Application code. Create dedicated accounts for each of your Applications and grant these accounts appropriate permissions. Always keep the biggest and best tools to yourself (so that you can sort out the mess made by other people or programs). Stop using Reserved Words as table / column names (e.g. "user" & "password"). Doing so will come back to bite you, at some point. Don't store the user's actual password. Instead, take the entered password, put it through your favourite, one-way, hashing algorithm and store the result of that. (When the user is logging in, take the entered password, hash it and check that value against what's in the database. Read up about Prepared Statements as a way to protect yourself against SQL Injection Attacks. Obligatory XKCD Reference: Little Bobby Tables. Regards, Phill W.
  6. Which file? Would you expect both the load() and save() method [of this subclass] to all the work to find out which file they needed to work with? No. What might be more "normal" would be to tell the object which file is should "save" itself to, i.e. you would pass the load() and save() methods the path to the target file. But then you have another problem ... This is a Box. A Musical Box, wound up and ready to ... no; that's a different story. This is a Box. It will be one of many Boxes and each of these will need to load() and save() themselves to/from somewhere (having one file per box might be OK, but could make for a lot of files!) A typical pattern I've seen to handle this is to pass each method something that it can read from or write to - a file stream is commonplace, but it really depends on how you intend to store your data ab out each box. Regards, Phill W.
  7. You structure looks wrong to me. You have multiple form elements, each of which contains one select element with two option elements. I would expect there to be one form element, which contains one select element, which contains one or more option elements. echo( '<form method="POST">' ); echo( '<select name="inv">' ); if( mysqli_num_rows($result) ) { echo( '<option>' . $row["rizikos_lygis"] . '</option>' ); while( $row = mysqli_fetch_array($result) ) { printf( '<option value=\'%s\'>%s&nbsp;%s</option>' , $row["sugeneruoja"] , $row["pavadinimas"] , $row["sugeneruoja"] ); } } echo( '</select>' ); echo( '<input type="submit" name="submit" value="Apskaičiuoti">' ); echo( '</form>' ); Regards, Phill W.
  8. As Brand says, try the assembled SQL manually and see what the database is objecting to. Some other thoughts: 1. You're wide open to an SQL Injection Attack. Obligatory XKCD Reference - Little Bobby Tables. Less severely, you're effectively excluding anybody with an apostrophe in their name, e.g. "Peter O'Toole", from registering with your site! Not that you'd be the only one, according to IrishCentral. Why is this? Because in your PHP code you're building a String value that just happens to contain some text that your database should be able to make sense of. By blindly bolting things together in this way - easy though it might be - you're not following the Rules that SQL expects. Look into Prepared Statements as a way to correct this. 2. Never use "Select *" in Production code. Both of your checks are pulling every field in the username table. That might be fine now, when you only have a handful of small fields to worry about but sooner or later, someone [else] is going to think it's a "great idea" to add a BLOB field into this table that contains terabytes of video profile for each user. Suddenly, your user check, which used to be really quick, is having to haul all of that data back across the network, even though its not interested in a single byte of it! Always specify the fields that you want to work with explicitly. All that said, I wouldn't perform the check this way at all. What you have here is a potential Race Condition. Computers are fast. Really fast. It's possible that, after checking for duplicate username and email but before doing the actual insert, someone else could get in and insert the same values into the database. Now you have duplicate user records or two people using the same account. Nightmare. Instead, get the database to do the heavy lifting for you: Add a unique index on username.email. Add a unique index on username.username. Remove both the check queries and just attempt the insert. If the user tries to reuse an existing username or email address, you'll get an error that you can handle in your code. Finally, your PHP code, as given, is difficult to read. You'll spend far more time reading code than writing it so start to think about readability now. (I very nearly "went off" on one because you were building a SQL string instead of executing it. I found the execution, eventually, way over to the right, off the edge of my screen!) Think about code readability, not least of which "one statement per line" and "indenting". With that in mind, let's take another look at your code: /* Register and check username and email is exist or not */ if (isset($_POST['submitted'])) { $username = $_POST['user']; $email = $_POST['email']; $first = $_POST['first']; $last = $_POST['last']; $password = $_POST['password']; $check_user = "SELECT * FROM username where Username = '".$username."'"; $check_email = "SELECT * FROM username where Email = '".$email."'"; $check_user2 = mysqli_query($GaryDB, $check_user); $check_email2 = mysqli_query($GaryDB, $check_email); if(mysqli_num_rows($check_user2) > 0) { $taken_user = "&#8594; Sorry, Username is taken"; } elseif (mysqli_num_rows($check_email2) > 0) { $taken_email = "&#8594; Sorry, E-mail is taken"; } else { $register = "INSERT INTO username (Username, Password, FirstName, LastName, Email) VALUES ('$username','$password','$first','$last','$email')"; $insert = mysqli_query($GaryDB, $register); /* } --- Closing brace - wrong place! */ if ($insert) { $insert1 = "successfully added"; } else { $insert1 = "Failed to added"; } } /* --- Closing brace SHOULD be here */ Note that, because of the misplaced braces (which are far easier to see with the code nicely laid out) the code is always passing through the "if($insert)" test, regardless of what else it does. It should only go through that bit if it's tried to do an insert, which it will with the closing brace moved as I've described. Regards, Phill W.
  9. I'm not surprised you can't see what's going on wrong, with all the chopping and changing back and forth between HTML and PHP. Keep it Simple: <?php if(isset($_POST['Submit'])){ $name=$_POST["Name"]; } . . . $sql = 'SELECT * FROM dirCsv_500'; /* Added a missing ";" here */ if (!empty($name)) { $sql .= " where name like '%".$name."%'"; /* Added string concatenation */ } ?> /* Removed an extraneous ";" here that's actually in the HTML, not the PHP */ I think I can see what you're trying to do, but that's just not how you write PHP. You can "duck in and out" to embed bits of HTML in between the PHP code, but you can't embed bits of PHP code in between the PHP code! There's other things to worry about here as well. From a database perspective, your code will perform poorly on a large table, given the leading wildcard in your search criteria, e.g. '%fred%'. The database is unable to use an index for this and will scan the table serially (i.e. slowly). Even before that, though, you have an even bigger problem - you are wide open to a SQL Injection Attack. Obligatory XKCD Reference - Little Bobby Tables. Look at using Prepared Statements for your SQL to [partly] protect yourself against this. Regards, Phill W.
  10. Just a thought, but did you ever consider using sprintf() instead of echo()? sprintf( '<li><a href="%s" title="%s"><i class="%s"></i> %s</a></li>' , $row['url'] , $row['title'] , $row['icon'] , $row['header'] ); Regards, Phill W.
  11. Does the "3rd Party Website API" offer a method by which you can retrieve the data in the order you want? That would be easiest. Failing that, you're just going to have to take the data as it is provided and then do the sorting yourself. If you're really lucky, the dates will already be in a sortable format ... Regards, Phill W.
  12. Never, never trust data values submitted by the User! You are wide open to SQL Injection Attacks. Obligatory XKCD Reference: Little Bobby Tables Read up on Prepared Statements or, at the very least, encode the values that you are using to build your "SQL" - a String variable that just happens to contains something that your DBMS can understand. And Barand is absolutely right - be extra careful with Date values. When is 03/06/09? Spring, Summer or Autumn? Regards, Phill W.
  13. Conclusion? The ItemName Form field is not being passed across. Check the HTML that should be sending it. Regards, Phill W.
  14. Do you also drive your car with all the dashboard indicator [warning] lights covered up? Sorry but, to me, this is just absurd. You need to get your site into surgery and "operate" on it, to fix the underlying problems, not just whack a Band-Aid on it and hope for the best! Sooner or later, one of those [ignored] warnings/errors is going to actually break your site and, suddenly, it'll be "all hands to the pumps", trying to get your site back up and running again, against a tidal wave of errors only one of which is the actual trouble-maker, and you'll [possibly] be losing money the whole time you're doing it. Surely it's got to be better to take the time and trouble to do that investigative and corrective work now, before the heat is on? We don't know what your application is or what it is supposed to do, so it's impossible for us to comment. I'm just hoping it isn't in the Nuclear Power industry ... $config->maxCoreTemp = 'q' ; . . . $reactor->shutdownIfTemperatureExceeds( $config->maxCoreTemp ); Regards, Phill W.
  15. Classic "Buffering" problem: Hugely simplifying your code, note what happens with/to the sHTMLTemp variable: $sHTMLTemp = ""; while ($unirow = mysql_fetch_array($uniresult)) // Where $result is your result set { if ($temp != $unirow['number']) { $sHTMLTemp = preg_replace("/(.+),/","\\1",$sHTMLTemp); print $sHTMLTemp ; print "</tr>"; $sHTMLTemp = ""; } /* Lots of putting stuff into sHTMLTemp */ } /* -- END WHILE -- */ On change of "number", you print out the sHTMLTemp variable and clear it down, ready to be loaded with the next Player's data. When you get to the end of the loop, though, It's all set up with the last player's data ... but you don't actually print it out! Regards, Phill W.
  16. This is actually quite an informative error message: "Too few arguments to function curlCall() ..." "... 1 passed in /clientzone/modules/products.php on line 33" "... at least 2 expected in /clientzone/includes/functions.php:0" You've defined a function curlCall that takes "at least 2" arguments . You're now calling that function with only 1 argument. Bzzzt!! PHP says "No". Regards, Phill W.
  17. No. It doesn't do anything at all with slashes. As I said: So your file might look like this ... ... and, if you entered "apple", the code would generate the link: <a href="https://blabla.com/blablabla/blablablabla/apple" target="_blank" rel="noopener noreferrer">apple</a><br/> If you are expecting multiple links to be generated based on what you enter, then please explain how you would expect this to work. Regards, Phill W.
  18. 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.
  19. What does the generated HTML look like (Use the "View Source" tool in your browser). Remember that your PHP is effectively just building a String that gets sent to the browser for it to make sense of. Copy the link URL out of the browser and make sure that that it works on its own. It may simply be that $row['linkpage'] isn't a valid URL. Regards, Phill W.
  20. One of the [Unwritten] Rules of Relational Databases: Rows in a Table have no intrinsic order. The only way to guarantee the order is to use the "order by" clause on your select statements. select sub, ... from table1 order by sub ; As Requinix quite rightly said - store numeric data values in a fields with a numeric Data Type. Regards, Phill W.
  21. Indeed it can and it absolutely should have. However, whilst an item should legitimately have a name and an id, you appear to also have given [one of] yours an Id. DOM navigation is case-sensitive, so ... "id" != "Id" ... and GetElementById only uses id. Something more like this: <td><input type="text" id="item1sum" value="" name="item1sum" placeholder="item 1 sum"></td> Attribute names (id, value) are case-sensitive and may appear only once within each Element. Pick one id for the element and stick to it. Use CSS for styling, rather than hard-coding it into every element. Regards, Phill W.
  22. item1cost and otem1charge are both String values, taken from the "value" property of the Element. Performing arithmetic on them may or may not work as expected. Better to convert them (parse* functions) to the correct Data Type first. There's no need for the ".value" bit on the totalcharge line. You're not reading a DOM Element property here - just working with variables. You're not actually displaying the calculated value! document.getElementByid('item1charge').innerText = "Total Charge = " + totalcharge ; Setting InnerHTML is risky - it leaves your site open to Cross-Site Scripting Attacks. Regards, Phill W.
  23. I would say no. The displaying of the form and it's processing are closely coupled. There's not much benefit in splitting them out into separate files. Just because you process the data before displaying the form doesn't mean that the code to do that processing has to go first in the file! Call a function that does the work. That function can be defined anywhere in the file. Also, there are limits on the number of redirects you can chain together, so why introduce another one when you don't need it? Regards, Phill W.
  24. You must not send anything back to the browser before issuing the redirect. No HTML tags, not even whitespace. In the code you show, you're sending most of the form before issuing the redirect. It's conventional to do the POST processing first, then render the rest of the Page if the User is still "here". something like this: if ( Posted_Data_Present() ) { ProcessPostedData_IncludingAnyRedirects(); } DisplayForm_IncludingPostedData(); Regards, Phill W.
  25. Never use the root (or any other "superuser") account for running applications. These uber-powerful accounts should be kept solely for your use to clean up the mess when an Application goes wrong. Keep the Biggest and Best tools in the toolbox for yourself. Create an account specifically for the application to use and grant that account only the permissions that it needs to do its job. +1 for not showing us your [root] password. -1 again, though, for hard-coding it into your PHP source code. Database credentials need to be carefully guarded and having them lying around in plain text, even in a PHP file, is not a Good Idea. All that said, we have no idea why your "index file is not opening" ... you've shown us no PHP code to examine, nor [database or PHP] errors to diagnose. Details, details, details ... 🙂 Regards, Phill W.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.