Problem/Motivation
Cores FileSystemInterface::basename() can cause container circular references with contrib.
#3259065: Circular reference detected for service "s3fsfileservice" with mime_type guesser
#3529457: Copy core 11.1.x ExtensionMimeTypeGuesser to s3fs
FileSystem::basename()is essentially a duplication of PHP native basename()
PHP Native basename() is path unware, it functions on a path based on the directory separator.
It appears this was intended to work around https://bugs.php.net/bug.php?id=37738 however that issue no longer appears to be present in PHP as of the 8.x branch https://3v4l.org/XcflK
It makes little to no sense for basename() logic to be overridden by contrib. Any such override inside Drupal will not extend to 3rd party libraries. Even Symfony makes 27 calls to the native basename() function (I can not assert any of these methods are used by Core).
Steps to reproduce
Proposed resolution
Remove FileSystemInterface::basename()
Optionaly: Retain FileSystem::basename() in a trait that can be included when necessary (although I see no need to do this).
Remaining tasks
User interface changes
None
Introduced terminology
None
API changes
FileSystemInterface::basename() deprecation/removal
Data model changes
None
Release notes snippet
FileSystemInterface::basename() is now deprecated, use basename() instead.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 3530461-nr-bot.txt | 91 bytes | needs-review-queue-bot |
Issue fork drupal-3530461
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:
- 11.x
compare
- 3530461-remove-filesysteminterfacebasename
changes, plain diff MR !12403
Comments
Comment #2
cmlaraComment #3
cmlaraWould be good to have a subsystem maintainer sign-off before any effort is put into code on this.
Pinging @kimb0 (Kim Pepper) on Slack.
Comment #4
kim.pepperLooks like you are correct. I'd be happy to deprecate/remove.
Confirmed that:
Here's an 3v4l snippet to test the standard basename() behavior:
https://3v4l.org/sqDsj
Comment #6
kim.pepperI reviewed the changes and confirmed that all use of
FileSystemInterface::basename()have been converted tobasename().My only question is on which version this will be removed in.
@deprecated in drupal:11.3.0 and is removed from drupal:13.0.0.Is it too late to have it removed in drupal 12.0.0 ?
Comment #7
cmlara@kim.pepper Thanks for the quick review. Was typing up the following while your review came in:
This was actually not as embedded in core as I expected it to be.
Set deprecation for 11.3 removal in 13.0 based on (the not yet accepted) discussion in #3518671: [policy, no patch] Defer disruptive 11.3 deprecations for removal until 13.0 out of concern it might be considered 'disruptive' (removing a method).
As an argument it is not disruptive:
basename()is PHP native and works in PHP8.1 which is the minimum supported version for any D10.x release. A module could easily support^10 || ^11 || ^12with just the native function.Above my position to make the final call on D12 vs D13 (willing to edit to D12 if it is approved).
This does impact a deprecation added in #2311679: Separate MIME type mapping from ExtensionMimeTypeGuesser the
file_systemwas added to the ExtensionMimeTypeGuesser as optional in D11.2 and would have been required in D12 will now be removed in D11.3.Comment #8
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #9
cmlaraBack to NR after the branch was rebased.
Never received a merge conflict email, did this actually have a conflict or was this a bot FP?
Comment #10
kim.pepperIt was a bot triggered comment that sent an email. I just rebased it.
Comment #11
nicxvan commentedI think this can be deprecated for removal in 12.
Disruptive deprecations are defined here: https://www.drupal.org/about/core/policies/core-change-policies/allowed-...
I think a deprecation that is literally a find and replace and the replacement supports 11+ is not disruptive.
Further since this removes a deprecation for the negotiator I think you need to update and insert the message there and say it's not allowed, some people may have updated.
We can't just remove that argument without deprecation since it was released.
I would also update the original cr with a note linking to this issue to follow since it's something that will only exist for a minor point
Comment #12
cmlaraNo conflict rebased on orgin/11.x
Deprecation set to D12.0
Deprecation added for constructor argument
Original related CR referenced to this issue
Comment #13
kim.pepperReviewed this again. I think it is good to go, but will leave as NR for others.
Comment #14
smustgrave commentedRemoving the sub-maintainer tag since this was worked on by the actual sub-maintainer :)
Did a search for "->basename(" and only instance is coming from the deprecation test
Issue summary is clear why this change can happen.
Reviewed both CRs and short and sweet. Kinda funny we made it required in 11.2 and not needed in 11.3 lol
Seems like a good replacements and no issues that I can see.
Comment #15
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #16
kim.pepperRebased on 11.x
Comment #17
kim.pepperComment #18
kim.pepperRandom fail
Comment #19
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #20
kim.pepperRebase on 11.x
Comment #21
kim.pepperComment #22
mstrelan commentedThanks for that. I looked through all the classes calling FileSystem::basename to ensure there were no leftover filesystem properties that were no longer in use. Can confirm there are none remaining.
Comment #23
kim.pepperI added
DeprecatedServicePropertyTraitfor the removed $fileSystem property.Comment #24
catchComment #25
catchThe constructor deprecations can be for removal in 12.x, we don't need to keep that around a full major release. I think the deprecation of the basename() method itself makes sense for removal in 13.0 though.
Comment #26
kim.pepperUpdated deprecations message in two constructors (
DirectoryWithMetadataDiscoveryandDirectoryWithMetadataPluginDiscoveryto be for removal in 12.x.I think I'm ok to put back to RTBC in this case.
Comment #28
catchThanks. I overlooked in my first pass that we're removing a deprecation we added in 11.2 - good reason not to keep them around for two majors given how often we're adding/removing parameters from constructors.
Committed/pushed to 11.x, thanks!