[PHP 8.1] "Passing null to parameter #1 ($datetime) of type string is deprecated" errors while searching in logbook

[pa8s]

Describe the bug
When I search for log entries I often get this PHP error where the 'Uploaded to LoTW' arrow is seen:

A PHP Error was encountered

Severity: 8192

Message: strtotime(): Passing null to parameter #1 ($datetime) of type string is deprecated

Filename: partial/log_ajax.php

Line Number: 200
data-original-title="LoTW Sent " data-toggle="tooltip" class="lotw-green">

To Reproduce
Steps to reproduce the behaviour:

1. Search for (part of) callsign.
2. Scroll down until error is seen.
3. White "Uploaded to LoTW" arrow is seen with PHP error above.

Expected behaviour
No error and green up arrow.
Looking into QSO data, the COL_LOTW_QSLRDATE has a valid date and COL_LOTW_QSL_RCVD is 'Y'.

Screenshots

Server
OS: FreeBSD 13.1
Server: nginx/1.22.1
PHP: 8.1.13
Git branch: dev
Git commit: 04e9960
Git Tag: 2.1-94-g04e99607

[phl0]

Can you please show the QSO details for that specific QSO? I am looking for values of COL_LOTW_QSL_SENT and COL_LOTW_QSLSDATE.
The COL_LOTW_QSLRDATE and COL_LOTW_QSL_RCVD obviously work fine as the green arrow shows.

[pa8s]

My mistake, the fields mentioned in the report are not that relevant, the fields below are obviously for the up arrow.

COL_LOTW_QSL_SENT = 'Y'
COL_LOTW_QSLSDATE = NULL

[phl0]

My mistake, the fields mentioned in the report are not that relevant, the fields below are obviously for the up arrow.

COL_LOTW_QSL_SENT = 'Y' COL_LOTW_QSLSDATE = NULL

Yes they are. But why is the COL_LOTW_QSLSDATE NULL?!

[phl0]

I mean I could fix the code to not run into an error here. But it seems that your LotW uploads do not set the upload date here. Maybe an issue of PHP 8.1.

[pa8s]

Yes they are. But why is the COL_LOTW_QSLSDATE NULL?!

I don't know, I see the mentioned error on multiple QSOs. Maybe those QSOs where uploaded to LoTW with another tool, I can't recall exactly.

[phl0]

Ok, let me check how to circumvent this error.

[phl0]

Fix PRred with #1849.

[pa8s]

Thank you this quick fix. :D

[phl0]

Thank you this quick fix. :D

uw.

[pa8s]

Although this issue is closed, I just saw the same thing when doing an advanced search. This time the problem is in search/search_result_ajax.php line number 322.

[pa8s]

Same error is visible in the QSO list when clicking on the 'Check log Call' or 'Check log Date/Time' button on the OQRS Requests list.

Filename: oqrs/qsolist.php Line Number: 143

[AndreasK79]

@pa8s You're finding all the PHP8.1 issues :) Will look into them.

[pa8s]

@pa8s You're finding all the PHP8.1 issues :) Will look into them.

I can't imagine I'm the only Cloudlog user with PHP8.1 ;)

[dg9vh]

Indeed you are not. I am running PHP Version 8.1.11 and have non of your problems here... curious. 73 de Kim DG9VH

[phl0]

Possible reason: @pa8s is running ENVIRONMENT set to development and @dg9vh production. The latter hides PHP warnings.

[phl0]

@pa8s Could you please test the code in #1893?

[phl0]

Although this issue is closed, I just saw the same thing when doing an advanced search. This time the problem is in search/search_result_ajax.php line number 322.

Fixed with 41d6da8 in #1893

[pa8s]

@pa8s Could you please test the code in #1893?

Just tested the code in pr 1893. Problem fixed.

[phl0]

Just tested the code in pr 1893. Problem fixed.

Tnx report.

[pa8s]

Possible reason: @pa8s is running ENVIRONMENT set to development and @dg9vh production. The latter hides PHP warnings.

Yes, I'm running in development mode.

[AndreasK79]

Fixed in dev.