BoldMinded

All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

Please read about the changes to BoldMinded add-on licensing.

Ticket: Expiration date not read/parsed

Status Resolved
Add-on / Version Publisher Lite 3.1.3
Severity
EE Version 5.3.0

Hop Studios

Mar 12, 2020

I noticed a bug after we installed Publisher Lite where the expiration saved doesn’t matched the {expiration_date} tag in the template.

I saved 03/20/2020 as the expiration date and the entry didn’t show up in the channel entry loop. When I added, show_expired=“yes” I get the entry but the {expiration_date} is just 1. I then uninstalled Publisher and found that the expiration date is changed to 12/31/1969 4:00 PM.

I think this is enough for you to investigate the issue.

- Gilbert

#1

BoldMinded (Brian)

Brand new install or an upgrade?

#2

Hop Studios

Site was upgraded from 4 to 5 and Publisher Lite from 3.1.2 to 3.1.3.

  • Gilbert
#3

BoldMinded (Brian)

I think this is related to a previous change you suggested. In Service/Entry/Entry.php, line 560 and 561, change them to this:

'expiration_date' => $defaultData['expiration_date'] ?? 0,
'comment_expiration_date' => $defaultData['comment_expiration_date'] ?? 0,
#4

Hop Studios

That seems to be it. I changed it and it is working now.

However, I noticed that the expiration_date set before installing publisher didn’t get translated to the Published/Draft copy.

I had an entry that for sure had expiration_date set as confirmed when I output it in the channel entry loop. I go to the edit screen and the expiration date field is blank. If I save the copy without specifying the expiration date, it will save and the expiration date will be null (or 0). The {expiration_date} is then 0 (which is the correct behaviour). However, I think it might be better that the expiration date field will show the original data rather than showing 0.

#5

BoldMinded (Brian)

I found the issue, but it will only be fixed for future installations. It wasn’t migrating the values.

Login to reply