User tests: Successful: Unsuccessful:
The global checkin action, resets the checked_out column with the default value, but the "Checking" task sets it to null. If a 3rd party extension doesn't accept null and uses a default value of 0 instead. The task exits with a -2 exit code. This pr resets the checked_out column the same way in the plugin as the core does in the model, when doing a global checkin.
It returns with exit code -2.
All items are checked in.
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
| Category | ⇒ | Front End Plugins |
| Labels |
Added:
PR-5.4-dev
|
||
It happens the same as with the global checkin code, which exists since ages. If it works there it will also work here. This pr does make sure that it is the same behavior and doesn't break extensions.
@sidd19898 did you create an event also and closed the browser window before you run the task?
Hi @laoneo — thanks for the clarification.
In my earlier test, I created the DPCalendar event but did not explicitly close the browser tab before running the Global Check-in task, which likely explains why I could not reproduce the issue.
I’ll re-run the test following your exact steps (create event → close browser → run check-in task) and report back with the results.
I tested this PR on a local Joomla 5.4-dev setup (PHP 8.x, MySQL, XAMPP).
Steps followed:
Installed DPCalendar Lite
Created an event
Opened the event and closed the browser tab without saving
Created and manually ran the Global Check-in scheduled task
Result:
The task completed successfully both before and after applying this PR.
This suggests that DPCalendar Lite correctly accepts NULL values for the checked_out column, so the edge case described in the PR could not be reproduced with this extension.
Testing with another third-party extension that enforces a default value of 0 instead of NULL would be needed to fully validate the bug scenario.
I checked with DP Calender Core:
Without the patch, I get an error code "-2". but success shows in the window:

With the patch, error code 5 "no content was returned"


Then I checked with another extension (SP Pagebuilder).
Without the patch, I get an error code "-2". but success shows in the window.

With the patch, I get an error code "5": "no content was returned"
Put error reporting to maximum and try again. Do you see an error message in the XHR request in the developer console?
| Labels |
Added:
bug
|
||
I have tested this item ✅ successfully on d90c478
I have tested this item ✅ successfully on d90c478
I have tested this item ✅ successfully on d90c478
| Status | Pending | ⇒ | Ready to Commit |
RTC
@crimle @ChrisHoefliger @rbuelund Which database(s) (type and version) have you used for testing?
We used: 10.5.29-MariaDB
It doesn't support it. You need to look for an extension who does.
It doesn't support it. You need to look for an extension who does.
@crimle @ChrisHoefliger @rbuelund Which database(s) (type and version) have you used for testing?
MySQLi 11.4.9-MariaDB
Pity. Would be really good to have a test with PostgreSQL (and also with MySQL 8 as it seems it has been tested only with MariaDB).
As stated in the description, this code runs since ages in the model already. This pr just hormonizes it and fixes a bug.
| Labels |
Added:
RTC
|
||
Thanks @laoneo for this PR, and @crimle , @ChrisHoefliger and @rbuelund for testing.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-02-04 19:48:55 |
| Closed_By | ⇒ | richard67 |
I tested this on a local Joomla 5.4-dev setup (PHP 8.x, MySQL, XAMPP).
I installed DPCalendar Lite via Install from Web and created a Global Check-in scheduled task using the default values.
Result:
The task completed successfully on 5.4-dev (before applying the PR).
After applying this PR, the task still completed successfully.
No errors or regressions were observed.
This indicates that DPCalendar Lite correctly accepts null values and therefore does not reproduce the edge case described in the PR.
Testing with a third-party extension that does not accept null values (and instead enforces a default like 0) would be required to reproduce the original issue, if such an extension is known.