Leaderboard

I enjoy the challenge when someone posts a problem I can get my teeth into.

I created an extra table to define which category the values were in mysql> select * from catval; +-----+------+ | val | cat | +-----+------+ | 1 | 4 | | 2 | 4 | | 3 | 4 | | 4 | 4 | | 5 | 3 | | 6 | 3 | | 7 | 2 | | 8 | 2 | | 9 | 1 | | 10 | 1 | +-----+------+ then $sql = "SELECT a.cat as cata , b.cat as catb FROM datatb d JOIN catval a ON d.grpa = a.val JOIN catval b ON d.grpb = b.val "; $result = $db->query($sql); //categories $cat = [ 4 => ['name'=>'1:4', 'recs'=>[]], 3 => ['name'=>'5:6', 'recs'=>[]], 2 => ['name'=>'7:8', 'recs'=>[]], 1 => ['name'=>'9:10','recs'=>[]] ]; $n = 0; while ($row = $result->fetch_assoc()) { $cat[$row['cata']]['recs'][$n][] = $row['cata']; $cat[$row['catb']]['recs'][$n][] = $row['catb']; $n++; } // the output echo "<table border='1' style='width:500px; border-collapse:collapse;'>"; foreach ($cat as $c) { echo "<tr><th>{$c['name']}</th>"; for ($i=0; $i<$n; $i++) { echo '<td style="text-align:center;">' . (isset($c['recs'][$i]) ? join(',', $c['recs'][$i]) : '&ndash;') . "</td>"; } echo "</tr>\n"; } echo "</table>\n";

It tells you exactly what to do on that page you linked. For a simple http to https redirect, just create a http vhost with a simple Redirect statement. For example, from my site's configuration: <VirtualHost *:80> ServerName aoeex.com ServerAlias www.aoeex.com Redirect permanent / https://aoeex.com/ </VirtualHost>

When you use <label for="xxx"> then the xxx should be the id of the object being labelled. This is useful with radio buttons or checkboxes and enables the user to click either the object or the label to check or uncheck. In your examples, <label for="yes"> is wrong since "yes" is not an id of anything.

When you get a keyboard that adds indenting and line breaks I'll read your code.

code that unconditionally (always) outputs the raw database statement errors for the connection, query, prepare, and execute statements, only helps hackers when they intentionally trigger errors, since these errors contain things like the database hostname/ip address, database username, if a password is being used or not, part of the sql syntax, and web server path information. the only time you should output the raw database statement errors is when learning, developing, or debugging code/query(ies) and you are viewing the site as the developer/programmer. at all other times, you should log these errors. the simple way of doing this is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any discrete error handling logic, since it doesn't add any value for a legitimate visitor to your site, and it will no longer get executed when there is an error (execution transfers to the nearest exception handler for the type of exception or to php if there is none.) the line that Barand posted enables exceptions for errors for the mysqli extension.

It's fine. Though you ideally shouldn't have a bunch of spaces everywhere like you do. Just put a space between attributes, not around the =. Using <input type="button"> creates a simple button that effectively does nothing. It will NOT submit your form. This type of button is mostly used in combination with javascript. Using <input type="submit"> creates a simple button that will submit the form and is a standard practice for submitting forms. Using <input type="reset"> creates a simple button that just resets the form's fields to their default values, it does NOT submit the form. Using <button> allows you to create nicer button because it allows more than just text. For example, you can combine text and an image. <button type="submit"> <img src="/images/search.png" alt=""> Search </button> With <button> you also have type="button", type="submit", and type="reset" which have the same semantics as on <input>. It doesn't really matter, though I personally find double-quotes on attribute values to be more correct and causes fewer issues. Use which ever one you want, but be consistent and use the same one everywhere. This is an artifact of the days when XHTML was popular and the thing to use. It's called a self-closing tag and is necessary in XHTML as everything must have an open and close tag to be XML compatible. These days it's best to stick to plain HTML which does not use XHTML specific things like self-closing tags. First of all, it is <label for="">, there's no underscore in there anywhere. Second, no you do not provide labels for each option in a select. The label is to describe the input as a whole, your options are labeled by their text content. They are both correct. It's mostly a matter of preference, or sometimes dictated by your layout. <label> can be be associated with an input either with the for attribute, or by having the input enclosed within it. Enclosing the input is convenient, but it may not always be possible when considering layout requirements.

I prefer option 4. EG mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT); $conn = mysqli_connect('localhost', 'someuser', 'wrong_password', 'test');

You actually have choice of mysqli or PDO to replace your mysql.* functions. Don't be fooled into thinking the easier route must mysqli because it's spelt almost the same. PDO is the simpler of the two interfaces.

And I agree that conf-available is not the right place for your RewriteRules. But you shouldn't be creating a new file in sites-available either and for basically the same reason: if you look through sites-available you'll find websites, and your RewriteRules are not websites. But they are used for a website, so put them in your site's configuration. As in inside the VirtualHost block. Alternatively, you could put the rules in a separate file somewhere (like within your application) and include it from inside the site configuration.

This is an environmental issue between your local server and your Production one, i.e. something is set up differently between the two. That require() statement is telling PHP to go and read the contents of some file and to fail if it cannot find that file. The file is specified in the variable, $view. To what value is this variable set to on your local server? Where does the PHP code set that value? Regards, Phill W.

Is the div in the DOM on page load or is it added dynamically later? You may have to use .on() to bind the event to the element.

Hello everyone, I am Abdellah and I an enthusiast PHP and Laravel developer. I do backend and frontend. I am from Cameroon and I am happy to be here. Thanks.

the main reason requinix stated that is because you are not validating input data before using it (which i have mentioned doing multiple times in this thread.) someone can cause your code to execute any php function, like phpinfo(), by simply setting $_GET['form_type'] to phpinfo when they request your page. do you really want someone to be able to see the phpinfo output from your site or execute any php function? your code needs to have direct, positive control over what gets executed on any page request.

... also, make sure to have mySQL error reporting on (if you don't have them on already).

Perhaps you would like to be so much like an AI bot it's funny. me made your day?

That's pretty much exactly what I said you needed to do, so...

perhaps $table .= join(',', $columnValue);

You don't say what data type '$columnValue' is so I am assuming it is int. $table .= strval($columnValue);

the most immediate problem is you have a logic 'hole' in the username/password check, where not all possibilities are addressed. when you use negative logic, you must complement both the conditional comparison in each term and the logic combining the terms. the complement of - if(a == b && c == d) is if(a != b || c != d). it is not if(a != b && c != d), in general, you should avoid using negative logic. you also need to use php's password_hash() when registering/storing the initial submitted password and use password_verify() when testing if a submitted password matches the saved hashed value. also, don't use a loop to fetch the data from a query that will at most match one row. just directly fetch/test the result from the query. lastly, the recommendations given in your last thread, less the ones that were specific to an INSERT query, apply to what you are currently doing. using those recommendations will result in the least amount of code/variables.

Very respectfully, are you really writing code for Online Banking? I'm hoping you're just doing a college class assignment.

You could roll your own. function twoColorCircle($a, $b, $sz) { $out = "<svg width='$sz' height='$sz' viewBox='0 0 1000 1000'> <linearGradient id='grad2' x1='0' y1='0' x2='1' y2='0'> <stop offset='0%' style='stop-color:$a'/> <stop offset='50%' style='stop-color:$a'/> <stop offset='50%' style='stop-color:$b'/> <stop offset='100%' style='stop-color:$b'/> </linearGradient> "; $c = 500; $r = 499; $out .= "<circle cx='$c' cy='$c' r='$r' fill='url(#grad2)' stroke='#000' /> </svg>"; return $out; } foreach ([16,32,64,128,256] as $sz) echo twoColorCircle('#5fc75d' , '#f19e2d' , $sz); echo '<br>'; foreach (['16em','8em','4em','2em','1em'] as $sz) echo twoColorCircle('#5fc75d' , '#f19e2d' , $sz);

One way is... $secs = 350000; $dt1 = new DateTime(); $dt2 = (clone $dt1)->add(new DateInterval('PT'.$secs.'S')); $diff = $dt1->diff($dt2); echo $diff->days . ' : ' . $diff->format('%h : %i : %s').'<br>'; //-> 4 : 1 : 13 : 20

It's easier when you contain all your mailing work in one single location instead of spreading calls to it throughout your application. It's perfectly acceptable to create your own mailing class that uses PHPMailer to do the work. Don't worry about those files. It should be mentioned somewhere, but otherwise it's mostly implied.

You're reading from some old documentation. PHPMailer\PHPMailer\PHPMailer looks weird but it is correct: the first "PHPMailer" is the organization, the second is the project, and the third is the class itself. https://github.com/PHPMailer/PHPMailer/blob/master/UPGRADING.md

Try a combination approach, increasing the contrast to reduce the noise.

Have you tried $im = imagecreatefromjpeg('../images/celule.jpg'); imagefilter($im, IMG_FILTER_GRAYSCALE); imagefilter($im, IMG_FILTER_CONTRAST, -1000); header("Content-type: image/jpeg"); imagejpeg($im); imagedestroy($im); Emulating you matlab example $im = imagecreatefromjpeg('../images/celule.jpg'); imagefilter($im, IMG_FILTER_GRAYSCALE); $white = imagecolorallocate($im, 255,255,255); $black = imagecolorallocate($im, 0,0,0); $w = imagesx($im); $h = imagesy($im); for ($x=0; $x<$w; $x++) { for ($y=0; $y<$h; $y++) { $c = imagecolorat($im, $x, $y); if ($c & 0xFF > 190) // blue component imagesetpixel($im, $x, $y, $white); else imagesetpixel($im, $x, $y, $black); } } header("Content-type: image/jpeg"); imagejpeg($im); imagedestroy($im); Gives an effect like this (top-left corner of image)

And what's the problem? I see some PHP code there which looks like it's on the right path. In fact it already has something to grayscale an image, so I would think that what you need to do is simply modify that to use black and white instead.

the warnings and notices are from php. they have nothing to do with with any framework the site is using for the presentation of information. the glob() is not matching any files and your code should test ( !empty($var) would work) before trying to access any of the results and output an appropriate message if no matching file was found. as to why the glob calls are failing, it would either be due to a problem with the spelling, capitalization, actual path being used, or there are no matching files inside the folders.

the posted code contains at least three places where it looks like characters were cut off from wherever this code was copied from, which would be producing fatal php parse/syntax errors. you should have the php error_reporting/display_errors settings in the php.ini on your system so that ALL php errors will get reported and displayed. putting these settings in your code won't help for parse/syntax errors since your code never runs to cause the settings to take effect. next, you have probably 5 times too many queries, code, and variables. some suggestions - use exceptions for database statement errors and in most cases let php catch the exceptions, where it will use its error related settings to control what happens with the actual error information. you can then remove all the error handling logic that you have now. INSERT queries don't have WHERE ... clauses. the account_number column should be added to the list of columns being inserted. don't put external, unknown, dynamic values directly into an sql query statement. use prepared queries. you would also want to switch to the much simpler PDO database extension. don't copy variables to other variables for no reason. you should NOT maintain a balance column in a single row by updating the value. any transaction that increases or decreases an amount should be handled by inserting a new row in the transactions table. the sets of INSERT queries that deducts the amount from the source account and adds the amount to the destination account need to be part of a database transaction, so that they will either both succeed and be committed or they will be rolled back. the post method form processing code should be before the start of the html document and should store any validation error messages in an array, then test/display the contents of this array at the appropriate location in the html document. any header() redirect needs an exit/die statement after it to stop program execution. don't use a loop to fetch a single row of data from a query. just directly execute the fetch statement one time. any dynamic value you output in a html context (email, web page) needs to have htmlentities() applied to it to help prevent cross site scripting.

Use $diff->days. $dt1 = new DateTime('2020-05-01'); $diff = $dt1->diff(new DateTime())->d; //--> 14; $diff = $dt1->diff(new DateTime())->days; //--> 44; ->d gives the days as in "1 month 14 days" ->days gives the total days Using SQL: select datediff(curdate(), '2020-05-01') as days; +------+ | days | +------+ | 44 | +------+

You can't loop over the column result-set multiple times. That code will work for the first data row, but then return false for every other data row because you've already reached the end of the column result set. You should fetch that column data into an array before hand then loop over that array. function getLuTableBody($lu_tableName) { $tableColumns=getTableColumns($lu_tableName); $columns = []; while ($columnData = $tableColumns->fetch_assoc()){ $columns[] = $columnData['COLUMN_NAME']; } //Might as well check for 0 columns and bail early. if (!$columns){ echo "problem with column data"; return; } $tableBodyHtml =""; $tableData=getTableData($lu_tableName); if ($tableData->num_rows > 0) { while($row = $tableData->fetch_assoc()) { foreach ($columns as $columnName){ $tableBodyHtml .= "<td>$row[$columnName]</td>"; } } } else { echo "problem with record data"; } return $tableBodyHtml; } You're also missing your <tr> </tr> tags for each row, and you shouldn't be echo'ing stuff if you find a problem. Throw an exception or return false or something.

Assuming PHP 5.3 or better and db date is in the format Y-m-d. $fromdb=new DateTime($datefromdb); $today=new DateTime(); $diff=$fromdb-$today; print("Difference is ".$diff.d." days); Note the result can be negative days.

Look closely at the tag pair in this line.

With composer you should be keeping your composer.lock file in your version control. If you upgrade and things don't work out then just revert your composer.lock and composer.json files, delete the entire vendor directory and run composer install and it will re-install whatever versions you previously had specified in the lock file. Googling your foreign key error seems to indicate a likely cause is column type mis-match. Maybe one of those updates changed the type of a column from int to bigint or similar. You'll need to check your different constraints to verify they match.

Neil, you left out: Make a sandwich Take power nap $$$ Profit!

1. Remove any PHP / Server Side code 2. Strip out any <img> tags 3. Strip out any <script> tags 4. Strip out any <link> tags to CSS files Job done. Should run like lightning!