Hey people.

Thanks for all the work on this module!

The 3.0.x branch triggers this error:

Seboettg\CiteProc\Exception\InvalidDateTimeException: Could not create valid date with year=, month=, day=. in Seboettg\CiteProc\Rendering\Date\DateTime->__construct() (line 45 of /var/www/html/vendor/seboettg/citeproc-php/src/Rendering/Date/DateTime.php).

Steps to reproduce

1. Create a reference of type "Audiovisual," populating the "Date Published" field with a date NOT in the format of MM/YYYY (e.g., "June-July/2026")
2. Create a View that renders citations in the default citation format and try to view.
3. Page fails to load, with the logs reporting the error above.

Issue fork bibcite-3423147

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

Finn Lewis created an issue. See original summary.

aardwolf’s picture

aardwolf commented
Title: TypeError: Unsupported operand types: string * int in AcademicPuma\CiteProc\DatePart->render() » Seboettg\CiteProc\Exception\InvalidDateTimeException: Could not create valid date with year=, month=, day=. in Seboettg\CiteProc\Rendering\Date\DateTime->__construct() (line 45 of /var/www/html/vendor/seboettg/citeproc-php/src/Rendering/Date/DateTime.php)
Status: Active » Postponed (maintainer needs more info)

Hi Finn Lewis
Update issue title since we don't use AcademicPuma.
Could you provide an example of such reference to let us check this issue?

finn lewis’s picture

finn lewis
Location Oxford
commented

Hi AardWolf!

Thanks for the reply.

The link to the commit I included above is where you swapped AcademicPuma to Seboettg

https://git.drupalcode.org/project/bibcite/-/commit/d9976bb3de1d619b1f73...

That was 03 August 2023

The current 2.0.0-beta3 is from 5th July 2023 and includes the AcademicPuma package: https://git.drupalcode.org/project/bibcite/-/blob/2.0.0-beta3/composer.j...

The current 3.0.0-beta3 is also from 5th July 2023 and includes the AcademicPuma package: https://git.drupalcode.org/project/bibcite/-/blob/3.0.0-beta3/composer.j...

It would be great if you can tag new releases with the swap from AcademicPuma to Seboettg.

Many thanks,

Finn

danepowell’s picture

danepowell commented

I got this error after upgrading to 3.x-dev as well. I think it's partially a problem with bibcite migrations, because a piece of content that was previously listed in biblio with the month as "July-September" got created in bibcite with the date published "July-September", which is invalid.

This seems to be only a problem with this date format; normally-formatted dates seemed to be imported correctly.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Title: Seboettg\CiteProc\Exception\InvalidDateTimeException: Could not create valid date with year=, month=, day=. in Seboettg\CiteProc\Rendering\Date\DateTime->__construct() (line 45 of /var/www/html/vendor/seboettg/citeproc-php/src/Rendering/Date/DateTime.php) » Seboettg\CiteProc\Exception\InvalidDateTimeException: Could not create valid date with year=, month=, day=
Version: 3.0.0-beta3 » 3.0.x-dev
mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Issue summary: View changes

srees made their first commit to this issue’s fork.

srees’s picture

srees commented

I also experience this error on 3.0.1 under Drupal 10.6.9

We have some inconsistent or missing date data post import of a large number of references. In an ideal situation we'd normalize this data (and still should/will) -- however, I don't believe a bad date field should result in a fatal error when listing contributions. The seboettg library throws exceptions as it should, but CiteprocPhp.php isn't handling them.

I've made an issue fork from 3.0.x that adds two things - sanitization and backup error handling. Both will log a message with a link to the problem entity if malformed date information is found. Sanitization allows a reference to still be rendered. If it is missed in sanitization, the error handling is graceful, logging it and returning an empty string (which should still give an empty line in a view, but at least not a fatal error).

mark_fullmer opened merge request !64

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

Thanks, srees. I've made the issue fork into a merge request and will plan to review this in the next week.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Issue summary: View changes
mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Active
mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

I made some revisions to the proposed implementation:

  1. The try/catch may catch things other than date processing errors, so the warning method has been updated not to make that assumption
  2. Instead of hardcoding the date fields, we source them from Citeproc
  3. Use PHP's checkdate() for date validation
mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Status: Active » Fixed

Thanks to everyone who contributed to this! I've merged this into the 3.0.x branch.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.