Handle malformed EDTF dates gracefully

I applied and tested the changes locally.
While they prevent the original Fatal error and correctly logs the warning, it triggers some new PHP Warnings listed as follows:

Warning 1:

Warning: Undefined array key 0 in Seboettg\CiteProc\Rendering\Date\Date->createDateTime() (line 236 of /var/www/drupal/vendor/seboettg/citeproc-php/src/Rendering/Date/Date.php)

Warning 2:

Warning: Undefined array key 0 in Seboettg\CiteProc\Rendering\Date\Date->createDateTime() (line 230 of /var/www/drupal/vendor/seboettg/citeproc-php/src/Rendering/Date/Date.php)

Warning 3:

Failed to parse EDTF date: 2024-2025. Error: Invalid edtf format 2024-2025

Are you able to see these PHP warnings on your end as well?

Hi @aryan-r-patel, when warning 3 was triggered, regarding malformed date 2024-2025, did you enter this date manually or was this triggered by a test?

Also the tests/pipelines in this module seem to be not setup, is it intentional that the test files are named ending with *Tests.php? Instead of *Test.php.

I'm pushing a fix for warnings 1 and 2.

@baysaa

Thank you for pushing the fixes for the first 2 warnings.

To answer your question, I entered the date manually using "drush php-eval" to bypass the UI's EDTF formatters.
As a note, I am still seeing warning 3. In my opinion, this is due to the EDTF Formatter identifying "2024-2025" as invalid EDTF.

Regarding the test files being named *Tests.php, I will consult with my supervisor here at DigitalUTSC (the maintainers of this module) to see if this naming was intentional or needs to be standardized to *Test.php.

I will update the issue once I have feedback from the team.

@aryan-r-patel warning 3 seems to be valid then if it's a user entered invalid date. It's correctly gracefully handling an invalid date as per the issue title.

If we want a year interval (i.e. from 2024 to 2025) as per EDTF spec, we should enter it as 2024/2025

@baysaa

Good point. I apologize, I should have been more clearer in my earlier message. I was confirming that the Fatal Error has gone and now we can see warning instead. (we are correctly identifying invalid dates now and handling them properly).
I will get back to you soon regarding the test file naming after consulting with the team.

Thank you for pointing out the difference in the test files naming for this module. We will be changing them from *Tests.php to *Test.php.

@baysaa
@aronnovak

Could we please wrap the logic in a try-catch block?
This would be a better approach and feels like a safer way to guarantee the "graceful handling" we're aiming for.

@aryan-r-patel, could you please elaborate on where exactly you would like the try/catch to be placed? Thanks!

You can possibly wrap the logic between $parser->parse($string); and $parsing_result->getEdtfValue(); calls.
If an error is caught, we can use \Drupal::messenger()->addWarning() to tell the user the date format is invalid. This prevents fatals while giving the user immediate feedback to try again with a valid format.

Merged in this PR: https://github.com/digitalutsc/citation_select/pull/43