Leaderboard

try foreach ($array as $k => $d) { if ($k > 0) { if (strtotime($d) > strtotime($array[$k-1])+6) { $new[] = "-------------------"; } } $new[] = $d; } $new = Array ( [0] => 2021-02-10 09:04:48 [1] => 2021-02-10 09:04:54 [2] => 2021-02-10 09:05:00 [3] => 2021-02-10 09:05:06 [4] => 2021-02-10 09:05:12 [5] => 2021-02-10 09:05:18 [6] => ------------------- [7] => 2021-02-10 09:06:18 [8] => 2021-02-10 09:06:24 ) [edit...] Alternative solution... $new = []; $ne

$this (programming pun intended) is the correct syntax, but produced a different error than the one you posted about the undefined variable. what was the error message in $this case? i'm going to guess that the database connection probably failed and there's no useful error handling in the code. while not the cause of the most immediate problem, your main code should be responsible for creating the database connection, then use dependency injection to supply that to any class that needs it. by making each class responsible for getting a specific database connection, your code is not ge

TIP: If you are creating home-grown charts, plotting the values is the easy bit. 95% of the coding effort will be in the drawing of chart area, plot area, axes, axis labels, scaling, titles etc. You can sidestep this with a simple table with horizontal bars. EG CODE EXAMPLE... <?php $values = [ 'Strongly Disagree' => 7, 'Disagree' => 10, 'Neither' => 12, 'Agree' => 25, 'Strongly Agree' => 41 ]; function valueChart(&$values) { $ou

See

Of course it needs to exist: you're trying to use it. Can't very well use something that doesn't exist, can you? But perhaps it's not a "Config" class you need to use?

Barand You are the Best! I know sometimes I run in to an end and the solution is there but just hard to find after staring at the same code for days, you my friend are a great start to my weekend! Best to you. And just so you know I posted this on Stack Overflow and was told that I did not try enough and i should try harder before asking questions. I will speak highly of this form and stick around to see if I can help others as well.

You can't just claim that a .mp4 file is video/ogg. That's a lie. That said, you're also claiming that it's video/mp4, so as long as that is factually true (just because the file is .mp4 doesn't mean it is MPEG-4) then it should work is just about all browsers. All major browsers have an error console you can look at for hints as to why something is not working...

If you do decide to step things up a level I highly suggest just finding a good library to do your chart rendering. Chart.js is my tool of choice currently. It offloads the chart drawing to the client so all you have to do on the server side is generate a json structure.

Define customer/product as UNIQUE... CREATE TABLE `cart` ( `cart_id` int(11) NOT NULL AUTO_INCREMENT, `customerID` int(11) DEFAULT NULL, `productID` varchar(5) DEFAULT NULL, `quantity` int(11) DEFAULT NULL, PRIMARY KEY (`cart_id`), UNIQUE KEY `UNQ_cart_product` (`customerID`,`productID`) ) BEFORE +---------+------------+-----------+----------+ | cart_id | customerID | productID | quantity | +---------+------------+-----------+----------+ | 1 | 1 | ABC12 | 3 | | 2 | 1 | DEF23 | 5 | +---------+------------+-----------+---

Rule #3 is about avoiding something like this: function blah($list){ foreach ($list as $a){ if ($a['flag']){ foreach ($a['list'] as $b){ if ($b['flag']){ //something } else if ($b['flag2']){ foreach ($b['list'] as $c){ if ($c['x']){ //something } else { //other thing } } } } } } } It's hard to read, particularly when the //something's are longer than one line and it wastes horizontal space. It'd be better to pull chunks out into other functions, for example: function blah($list){ foreach ($list as $a){ if ($a

I pretty much agree with kicken, but feel the need to throw in my own two cents. First off, tip #3 is something everyone who codes should live by. To add to it, don't string together a million conditionals - I'm currently dealing with a code base that has a 180-line if-elseif-else tree and it makes me wanna barf. For what is supposed to be a conditional logic operation, this is shockingly devoid of both condition and logic. Personally, I think any sort of hard and fast numerical limit on function/method/class width or length is kinda manufactured. Use judgment and good formatting. Fo

That's far too restrictive and either something that was misunderstood or came from a crazy person. I came across a rule of thumb some time ago that I try to live by which goes a little something like this: A function should fit entirely on screen (no vertical scrolling required). How many lines this is will vary based on resolution/fonts and such, but ends up being around 65 lines for my environment. A single line shouldn't be longer than the width of the screen (no horizontal scrolling required). That ends up being around 120 characters for me. A function shouldn't h

I haven't seen a lot of your code, but the other thing that jumps out is that having functions where you are passing 4-5 parameters indicates that you probably have blocks of code that are trying to do too many things, and are not discrete enough. I certainly could look back at code I wrote in the past and admit I did the same thing on many occasions. This leads to the type of problems you are concerned about: large code base, concerns over side effects if you make a change, cascading throughout the code, lack of DRYness etc. This tends to happen when you build everything from scratch,

Defining a function with optional parameters is done the way you did it. <?php function foo($bar, $fruit=null, $candy=null) { echo "bar: $bar" . PHP_EOL; echo "fruit: $fruit" . PHP_EOL; echo "candy: $candy" . PHP_EOL; } foo('one bar'); foo('one bar', 'apple'); foo('one bar', null, 'snickers'); With basic functions, all parameters are passed by value, not pass by reference. $error = array('message' => ''); function testparams($msg, $error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); // Original error array was not changed

$_POST will normally always have values for each element in the form. However, some of the values may be "empty". So you would need to use 'empty' on each element rather than the entire array. As an aside, although it will not do what you want, based on the code comments your 'if' block should be: if (!empty($myArray)){ // Handle array }else{ // Handle empty array }

Make an array of the required form fields in php, then loop through that array on submission. If any of the fields are empty, add a message to an errors array. In the end of the actual, full form processing script if the errors array isn't empty, loop through the errors array and print out each individual error.

try <html> <head> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min.js"></script> <script type='text/javascript'> $().ready( function() { var burl = "https://api3.binance.com"; /////////// baseurl///////// var query = burl + '/api/v3/aggTrades'; $.get( query, {"symbol":"BTCUSDT"} , function(resp) { $("#demo").html("a - " + resp[0].a + "<br>") $("#demo").append("p - " + resp[0].p + "<br>") $("#demo").append("q - " + resp[0].

If you are not using Fetch then you need to parse the data: var xmlhttp = new XMLHttpRequest(); xmlhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { var myObj = JSON.parse(this.responseText); document.getElementById("demo").innerHTML = myObj.name; } }; xmlhttp.open("GET", "json_demo.txt", true); xmlhttp.send();

XAMPP is fine, sure. The point is that you're complaining about the hassle of having to upload files to some server somewhere every time you want to make a change. Well, you know what the easiest way to see changes is? If you don't have to move the files anywhere. Don't bring the files to the server. Bring the server to the files.

If that is how you want the output then GROUP BY may well be the answer student data... +-------+-----------+----------+ | regno | firstname | lastname | +-------+-----------+----------+ | 9738 | Jane | Jenkins | | 9844 | Janet | Gordon | | 9966 | Liz | Lyle | | 9978 | Olivia | Unwin | | 9979 | Curly | NULL | | 9980 | NULL | Larry | | 9981 | NULL | Mo | | 9982 | Fred | | | 9983 | Emily | NULL | +-------+-----------+----------+ query... SELECT CASE WHEN IFNULL(firstname, '') = '' THEN 'No first

I'll repeat it: 1. Those two RewriteConds are only applying to the first RewriteRule. 2. Better than repeating those two RewriteConds six times, you should have all !-f !-d URLs go through function.php. Then it looks at the URL and determines which func/lang+func/lang+func+sub/whatever to use, like how the .htaccess is trying to do now. 3. You do not have any RewriteRules that will apply to /. That means Apache will use your index.html. AJAX is not authentication, you need all of this stuff for everything.

If you echo '<pre>$json = ', print_r($json, 1), '</pre>'; you get $json = Array ( [terms] => http://www.xe.com/legal/dfs.php [privacy] => http://www.xe.com/privacy.php [from] => USD [amount] => 1.195 [timestamp] => 2021-02-09T16:52:00Z [to] => Array ( [0] => Array ( [quotecurrency] => NGN [mid] => 454.6559871014 ) ) ) Then follow the array keys to the value you want So you need echo $json['to'][0]['mid']

1. $_POST data can't be trusted, not just inside of SQL queries but also inside of $_SESSION. 2. You are not using remotely acceptable password practices. Learn about password hashing using and password_hash() and password_verify().

I don't know what solution you found "at the moment", but a while ago I told you that you have to update the URLs you put onto your site to use the new forms, and that it will not happen automatically for you. For example, that means you have to replace every <a href="/index_pl.php?src=home"> with <a href="/home">

CREATE TEMPORARY TABLE ( .... )

Five 🌟 🌟 🌟 🌟 🌟 for Barand

You're welcome. Good to hear I can make a difference somewhere 🙂

Just a guess but what if you don't have your repositories extend AbstractUserRepository and instead just be their own separate repositories?

starting to run out of crystal balls here... header() redirects tell the browser to go to a different place than they first tried to go. It has nothing to do with transitions. If you want a transition between pages then what you do with header() is irrelevant. If you're having a problem with transitions not working, forget the header() and make them work normally first.

A white screen means your PHP code broke. Look in your server error logs to find a reason why. Also, when you tried going to /home, did you watch what happened in the address bar? You saw it change, right? Did you pay close attention to what the new URL was? As for those links, the solution is to fix them. Don't write index_pl.php?src=home. Do write /home.

Apache does not fix your long URLs to be short. What it does is allow you to use short ones. In other words, you're thinking about URL rewriting backwards: short URL goes into the browser, long URL is what runs on the server. So go to /home and see what happens. Spoiler: it won't work. 1. Try adding an [R] flag to both of those RewriteRules so you can see what is happening. 2. RewriteConds only affect the single next RewriteRule. If you want them to apply to two RewriteRules then you need to use two copies of them.

Fixed: it was set up for the Dark theme but not the Light theme. Also checked the other custom CSS rules, but besides a small underline thing, there weren't any other rules (not related to coloring) that Dark had but Light was missing. However, it's possible/probable there are some HTML template differences.

It can be whatever, as long as stuff exists in the way it needs to exist at the moment it needs to exist. So you can getElementById a variable, sure, but the thing you're trying to find has to be on the page - not just sitting in a variable you got from AJAX.

I think you've got your order of operations mixed up. The pear DIV is inside the AJAX's HTML, so right now you're trying to insert that HTML into itself. There's also nothing in there targeting the "apple" element. The pear DIV has to exist on the page for you to insert something into it. It should not be in the response itself but rather already on the page, and the response would be just the apple part.

composer install will install whatever the composer.lock file says to install. If there is no composer.lock file then it behaves like composer update does. composer update will parse the composer.json file and calculate all the dependencies based on the given requirements and current operating environment. Once it determines what versions to install and verified the platform requirements it will write the final configuration to composer.lock so that it's quick and easy to install all those dependencies again if needed. So if you move your project, including the composer.lock file,

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["su

Perhaps it isn't clear, but with version control, and at this point, the world has standardized on git (for relatively good reasons in my opinion) there is no danger in changing "tested code." This assumes that you have a development/test deployment and a production deployment. If you only have "production" -- well, it goes without saying that the second you have any actual users, you are in big trouble. So, I will make the assumption you have a dev/test system, and again, there is no question that you can change anything you want with git, and test things, and you can do these te

Not understanding -- sure that is an issue for many people. I will grant you that there is a learning curve, and for many people the big picture is difficult. With that said, most of these projects had great documentation, and tutorials and demo projects to help people learn them. Writing everything from scratch was a mistake, because your site should have implemented MVC to give it a sane and maintainable structure, and you also clearly wrote lots of code that doesn't have a set of robust unit tests, so your site is inherently more buggy and less stable than it would have been if yo

A lot of my opinions should probably have the disclaimer "In theory, ...".