[2021.03] PHP Fatal Errors #9747
Comments
|
Let's get started again. ;-) 2021.01 stable, PHP 7.4 Addressed in #9780 |
Self-addressed. |
|
Please pull develop again, I'm guessing this has to do with @annando 's work being spread between multiple PRs that got merged one by one instead of all at once which wouldn't have caused this error. |
…g in Protocol\Diaspora - The database field iten.plink accepts NULL values - Address friendica#9747 (comment)
…g in Protocol\Diaspora - The database field item.plink accepts NULL values - Address friendica#9747 (comment)
|
@MrPetovan Yeah, in one of the PRs I forgot to push a commit that was then part of the following PR. |
|
Freshly cloned the repo and installed friendica (new database and same way of installing as a few days ago when I started working on the web UI). After the installation process, all pages return 500 errors. I get: Addressed in #9841 |
|
2021.03-dev PHP 7.4 I guess Addressed in #9851 |
Addressed in #9882 |
|
Thank you for the report, unfortunately we do not support PHP 8 at the moment. We are aware of this specific issue in the translation files but we do not have a good way to fix it yet. |
|
@MrPetovan that's PHP 7.4.14, not 8 |
|
Thank you for the added detail, I knew this syntax was considered as deprecated in PHP 7.4 but I didn't expect it to throw a Fatal Error before PHP 8. I'm not sure if this is just oversight on my part or a specific behavior of PHP governed by a configuration value. The issue with this specific error is that these As a workaround you can edit the file(s) manually to lift the error, we may end up updating them manually if we don't find an automatic solution. |
|
2021.01 php 7.4.14 These errors are causing some pretty big issues with my worker queue, so considering the discussion around develop's stability, I switched to 2020.03-dev. Still throwing these like crazy. |
|
2021.01 php 7.4.14 |
|
@MrPetovan It seems you try to use C-code for these translations that work incorrectly because of the wrong ternary association order in PHP, basically that's why they were forbidden for example for Russian expression you get 2 for 21 while the correct result is 0 so you need to add parser even for earlier PHP's Here is my quick and dirty solution: <?php
$cond = 'n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2';
//$cond = '3';
$cond = str_replace('n', '$n', $cond);
function parse($string, &$node = [])
{
$q = strpos($string, '?');
$s = strpos($string, ':');
if ($q === false && $s === false) {
$node = $string;
return;
}
if ($q === false || $s < $q) {
[$then, $else] = explode(':', $string, 2);
$node['then'] = $then;
parse($else, $parsedElse);
$node['else'] = $parsedElse;
} else {
[$if, $thenelse] = explode('?', $string, 2);
$node['if'] = $if;
parse($thenelse, $node);
}
}
function render($tree)
{
if (is_array($tree)) {
$if = trim($tree['if']);
$then = trim($tree['then']);
$else = render($tree['else']);
return "if ({$if}) { return {$then}; } else{$else}";
}
$tree = trim($tree);
return " { return {$tree}; }";
}
parse($cond, $tree);
echo is_string($tree) ? " return intval({$tree}); " : render($tree);
// if ($n%10==1 && $n%100!=11) { return 0; } elseif ($n%10>=2 && $n%10<=4 && ($n%100<10 || $n%100>=20)) { return 1; } else { return 2; } |
|
@realkinetix please have a look for entries in your workerqueue with the "command" field set to "APDelivery" that isn't done. In "parameter" you should see a JSON construct like |
|
Hi @annando Would it be considered a string if the field is ""? I checked a number of entries, and just showing id,parameter,created there's lots like: Sorry, I should mention that the actual query was: select id,parameter,created from workerqueue where command like '%apdelivery%' limit X; Just want to be clear that I was checking for the right thing. |
|
@sunchaserinfo Thank you so much for the suggestion, we'll try to use it in our .po to .php file converter! |
|
@realkinetix Can you delete those entries by hand? This |
|
OK, have done so. It's stopped those specific errors, will have to see how the rest of the worker tasks go. Would you like me to provide any follow-up/checks on this? |
|
@realkinetix I guess this call had been generated by the previous version? I now added some additional checks. |
|
I believe that these have been around for awhile based on the queue backlog - 2020.12, I believe. Unfortunately, I can't easily verify that now. |
|
2021-03-dev - 1395 / PHP 7.4 Still happens on current RC (2021-03-27) |
And the debugging, the invalid url is:
|
|
Thank you for the detailed report, it looks like a duplicated protocol in the URL, see the truncated parameter to |
|
In the meantime, please delete all the rows in your |
Now it does not throw any error. But also didn't resolve my issue #9899, the worker is still breaking the instance url 😞 |
|
Fair enough, let's take one thing at a time 😅 |
|
Updated to today's develop code, seeing: |
|
#9949 seems to have introduced the following fatal error on my node. With the result of no postings are shown in any timelines and single thread display. Going back to 574f778 (which is the PR before 9949) everything works again. This one was fixed with #9951 |
|
Looks similar but not identical to the predecessor: 2021.03-dev PHP 7.4 Addressed in #10139 |
Addressed in #10069 |
|
latest dev Addressed in #10144 |
|
@copiis according to https://stackoverflow.com/questions/31407010/cache-resources-exhausted-imagemagick it seems to be a memory issue. |
|
Yes, but we still should handle the exception in Friendica. |
Just to document this one. Maybe invalid, then I remove it from here. |
|
Oh, wrong thread. I use: |
Please report here any PHP Fatal error message obtained running the 2021.01 stable or 2021.03-dev versions.
Closes #9250
The text was updated successfully, but these errors were encountered: