Jump to content
#StayAtHome ×


  • Content Count

  • Joined

  • Last visited

  • Days Won


gizmola last won the day on March 26

gizmola had the most liked content!

Community Reputation

183 Excellent


About gizmola

  • Rank
    Prolific Member

Contact Methods

  • AIM
  • Website URL

Profile Information

  • Gender
  • Location
    Los Angeles, CA USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes. Essentially you re-think the way your app is constructed from a data point of view. You write routines that take whatever parameters are required and just return json data. The UI is all html and javascript that loads the data from ajax calls to your php api script(s). What the script returns is entirely up to you.
  2. To be fair to Saaima, I did not provide any code until posting of the attempts. I am sure the message was delivered as to what we expect in the future.
  3. We would need more information. From what I can see, these are 2 woo-commerce plugins. Do they NOT work together? And if so, what errors are you seeing? The 2nd plugin has a warning stating that it hasn't been updated in the last 3 WP releases.
  4. What distro is the NAS server based on? Do you have a package management tool you can use to add/update packages?
  5. Only SO can add something to their share function, and they can't share to "generic phpBB" so you will never see that. SO has a rest API that could be used to build a "shared" widget within a particular piece of software. See the documentation: https://api.stackexchange.com/docs. Ideally this would work by pasting a link in, and phpBB would need a component that interpreted the SO link, pulled the data for the question and presented it within the post.
  6. Seems you are overthinking/ developing this. The first year is a parameter you will be passing. You don't need any fancy math. If you want to consider possible problems with the parameter, these come to mind: what if string parameter doesn't equate to a valid year? what if string parameter is missing or empty? what if string parameter is in the future? what if the string parameter is a year equal to the current year? Here's a solution that handles all these possibilities: <?php function getCopyrightRange($startYear) { $currentYear = date('Y'); if (((int)$startYear == 0) || ($startYear > $currentYear)) { $startYear = $currentYear; } return ($startYear == $currentYear) ? "&copy;$startYear" : "&copy;$startYear - $currentYear"; } echo getCopyrightRange('1985') . PHP_EOL; echo getCopyrightRange('2025') . PHP_EOL; echo getCopyrightRange('') . PHP_EOL; echo getCopyrightRange('2020') . PHP_EOL; The tests are setup just for command line php testing, so obviously since this is intended to be html markup using an htmlentity, you wouldn't want or need that. Here's the results: &copy;1985 - 2020 &copy;2020 &copy;2020 &copy;2020 If you were writing some test cases, you'd likely have a case for each of these potential issues, assuming you were concerned about them.
  7. You will need to store the details of the order in an order table, perhaps with status. When an order is completed at paypal it will callback to one or more "webhook" url's you've onfigured, which are script(s) you would right to do processing on your server. Read through this section at Paypal: https://developer.paypal.com/docs/api-basics/ The script would need to parse the data the webhook script gets from paypal (ideally you should choose to use json format) and send the email you require, looking up the order in your order table.
  8. This isn't a "write some code for me for free site", it's a "here is what I tried, can you help me with my code" site.
  9. Initializing without php7. $_SESSION['cartid'] = isset($_SESSION['cartid']) ? $_SESSION['cartid'] : 0; $_POST['cartitem'] = isset($_POST['cartitem']) ? $_POST['cartitem'] : 0; $_POST['quantity']) = isset($_POST['quantity']) ? $_POST['quantity']) : 0; $_SESSION['lockedcard'] = isset($_SESSION['lockedcard']) ? $_SESSION['lockedcard'] : 0; $_SESSION['lockedpaypal'] = isset($_SESSION['lockedpaypal']) ? $_SESSION['lockedpaypal'] : 0; // Now you can omit any isset() calls, and concentrate on the if/else conditions of the variables.
  10. We never established what version of PHP you are using? Perhaps these few fundamentals will help you understand: PHP has arrays. An array is like a toolbox that has compartments. With PHP these compartments can be named ie the 'cartitem' in $_POST['cartitem']. You are using these arrays: $_POST which is the contents of a form that has been submitted, and $_SESSION which is a special array that stores variables on the server associated with a client/web browser. If you try and access a named array element (example: $_POST['cartitem']) and that array element has not been set with a value, PHP will generate an error. This is why you are checking first with isset(). isset let's you code around the possibility a variable will not be set. In your code, despite the fact that you think the session variables would have previously been set, obviously there are times when they aren't. For example, if I open a browser and go directly to your post page, the session variables won't be set. Personally speaking, big chains of and/or combinations are ugly and hard to maintain. Current best practices are to do early return when possible on individual problems, but in order to understand how to implement that we would need to see more than the if condition. What is done/not done given success or failure? This explains why Barand's code is so much cleaner and simpler, as it uses an operator '??" called the "null coalescing" operator, that helps make this whole isset chaining of code obsolete, as it makes it simple to assign optionally assigned or passed variables a default value. It was added in PHP7 however, so if you are on a version prior to 7, then it would explain why it would not work. With that said, I would rewrite things so that ALL the required variables are set to known values if they fail isset.
  11. Check the value of userid. Is it not a varchar? WHERE a.oracleid = '$userid' If you write code this way, you are using variable interpolation which opens your code up to SQL Injection. That is why I showed you the parameter passing method, which uses prepared statements and bound variables. You would not need the single quotes if you used the parameter, as it will determine the datatype from the type of the variable being passed.
  12. Right, I see the issue. You have to determine the most recent outer array you've added which is going to be numerically indexed. Try this: $json[count($json)-1]['__children'][] = array( A less hacky way would be to have a counter for the outer array loop that you increment anytime you add a new element. Because numeric arrays are zero based, the first element is going to be $json[0], then $json[1] etc.
  13. Most likely you simply need to pass the oracleid into the query as a parameter. Assuming this is PDO... $stmt = $conn->prepare("SELECT s.oracleid , s.staffname , date_format(date, '%W %d/%m/%Y') as absent FROM staff s CROSS JOIN date d LEFT JOIN attendance_records a ON s.oracleid = a.oracleid AND d.date = DATE(a.clockingindate) WHERE a.oracleid = ? ORDER BY s.oracleid, d.date "); $stmt->execute(array($oracleid)); $result = $stmt->fetchAll();
  14. Use parameters in your mysqli code. DO NOT interpolate or you will be creating code that is open to SQL injection. $query = "INSERT INTO a_rankings_select (grade ,position) VALUES (?, ?)"; // $con would be the mysqli connection resource $stmt = mysqli_prepare($con, $query); //2nd param is a string of character(s) describing type of param. In your case these are strings, so 'ss' mysqli_stmt_bind_param($stmt, 'ss', $grade, $position); if (mysqli_stmt_execute ($stmt) { // Insert succeeded } else { echo 'Error: Grade ranking insert failed. Check input/or database status'; } If you spit out the contents of mysql_error, just be aware you could be leaking database connection information which attackers would love to have. Better to log that data, and provide your own customized error message as I illustrated here.
  15. As to your generalized question, yes you should use prepared statements for all DML. The issue is that you don't understand PHP classes adequately so you are missing out on some essential stuff and writing code that can't run. For example: $this->insertNewEntry->$stmt->execute(); You are trying to access a class method 'insertNewEntry' as if it was an instance variable. It's not. If you had a fluent design you might be able to do that, but I'm not going to get into that at present. You should move the $stmt->execute call into the insertNewEntry() method where it belongs, and then your method call would simple be: $this->insertNewEntry($planned_workout_id, $exercise_id, $set_id, $weight, $reps); Correspondingly, insertNewEntry has no parameter list, so there's no way for it to get access to all the variables it needs. Those parameters need to be added to the method definition. An even bigger issue with the same method is this: $stmt = $this->$connect()->prepare( Again you have a number of mistakes. This is trying to run some unknown method name stored in a non-existant $connect variable. What you actually want is: $stmt = $this->connect()->prepare( This has a good chance to work, however, it's going to be pretty wasteful if you are constantly making new database connections for every query. You would be better off, having a class variable that stores the connection, and then simply using that in all of your DML oriented methods. I don't think that inheritance is a great way of doing this as all your parent db class does is make a database connection with hardwired parameters. There is no big win there. Having a db connection class is fine, but you would be better off designing it to accept the database credentials from a configuration file. Your saveWorkout class would be better off using dependency injection instead, and having connection class instance injected into the class at construction. I've recommended this series by Fabien Potencier who is the founder of the Symfony project many times over the years. It talks about the Dependency injection design pattern and explains what it is and why it's a good way to design your classes. Read it here: http://fabien.potencier.org/what-is-dependency-injection.html More likely what I would see you moving towards is an implementation of ActiveRecord which is a model/orm design pattern used by many MVC frameworks including Ruby on Rails, and in PHP frameworks like CakePHP and the very popular and modern Laravel framework. Your base class would then generalize select, save, update, delete methods, and you would have a derived model class for every table you deal with. I would expect that you would have a class named 'workoutLog' that would mimic the structure of your workout_log table, with attributes that get/set all the individual properties that match your database. You can then have generalized code in the model base class that understands how to construct the SQL needed based on the model. Typically you have getters and setters for each column, but these can also be generalized in the base class using PHP's magic methods __get, __set and __call. See https://www.php.net/manual/en/language.oop5.magic.php This would allow you to quickly develop a base class that didn't require each derived model class to have all the properties enumerated for the your tables, if you wanted to avoid that. If you only have a handfull of tables, it might be easier just to author each model class so that it matches the structure of database table. Browse the Laravel Eloquent documentation to get an idea how this type of thing should be structured: https://laravel.com/docs/5.8/eloquent, and look at some of the examples to see the type of code that you write to do database manipulation with an ActiveRecord style implementation. I realize this is a lot of material and suggestions, but then again, you could start with Symfony or Laravel and not reinvent the wheel as you are doing currently.
  • 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.