Feeling Lucky
?
?
[#25261] - [4.0] Make sure the function matches the parent return type
- Fixed in Code Base
- 18 Jun 2019
- Medium
- Build: 4.0-dev
- # 25261
- Diff
- roland-d:feature/session-clear-compatibility
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Summary of Changes
This fixes a fatal error when accessing the site
Fatal error: Declaration of Joomla\CMS\Session\Storage\JoomlaStorage::setOptions(array $options) must be compatible with Joomla\Session\Storage\NativeStorage::setOptions(array $options): Joomla\Session\Storage\NativeStorage in libraries/src/Session/Storage/JoomlaStorage.php on line 23
Testing Instructions
- Checkout the current Joomla 4 branch
- Open the site and you get this fatal error:
Fatal error: Declaration of Joomla\CMS\Session\Storage\JoomlaStorage::setOptions(array $options) must be compatible with Joomla\Session\Storage\NativeStorage::setOptions(array $options): Joomla\Session\Storage\NativeStorage in libraries/src/Session/Storage/JoomlaStorage.php on line 23
- Apply this pull request
- Run
composer update - Reload the site
- Site now loads
Expected result
The site loads
Actual result
The site doesn't load
Documentation Changes Required
None
Pinging @wilsonge
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Labels |
Added:
?
|
||
| Category | Libraries | ⇒ | External Library Composer Change Libraries |
roland-d
- comment
- 18 Jun 2019
@mbabker Thanks for the input
@richard67 It should be ready now, I cleaned up the test instructions.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-06-18 18:37:14 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
wilsonge
- comment
- 18 Jun 2019
Tested this locally and works. Thanks!
wilsonge
- comment
- 18 Jun 2019
sorrrrrrry :/
Also for clarity, on the
Fatal error: A void function must not return a value in /usr/local/var/www/joomlacms/libraries/src/Session/Session.php on line 233error...Everything that's been typehinted is either new API for CMS 4.0 or Framework 2.0, or exists in a non-extendable scope (final class, private method, etc.). Anything that already exists in a stable CMS 3.x or Framework 1.x shouldn't be typehinted because of B/C breaks in changing signatures, unless the change was explicitly vetted (and there are some, but they're the exception to the rule). That one slipped in because we lost the
@since 1.0tag on the parent method in the Framework repo (it had@since __DEPLOY_VERSION__so I figured it was new when going through things). So if you start running into type issues, first look for a B/C break then revert that break (unless explicitly vetted and OK'd as such) before trying to adapt code to the changed signature.