No, there is no support for neural search at this time. Contributions are welcome!
We missed a few methods on \Drupal\file\Upload\InputStreamUploadedFile
Created 📌 [11.x] Remove deprecated methods in InputStreamUploadedFile Active
kim.pepper → created an issue.
We left in the method InputStreamUploadedFile::supportsMoveUploadedFile() from an approach that we ditched in favour of the InputStreamUploadedFile::validate() approach. Created
🐛
Remove incorrectly added InputStreamUploadedFile::supportsMoveUploadedFile()
Active
to clean this up.
kim.pepper → created an issue.
Yeah we still need to do 📌 Deprecate file_managed_file_save_upload(), file_save_upload() and _file_save_upload_from_form() and replace with a service Needs review which is mostly cleanup.
I think it's feasible that anonymous users would be able to see file upload progress, so I don't think it's an access thing. But I do agree we should check if the extension is enabled.
Created a MR.
kim.pepper → made their first commit to this issue’s fork.
📌 [PP-1] Refactor JSON-API file uploads to use FileUploadHandler Postponed Just landed so I think we are safe to mark this fixed now.
Thanks to everyone here for the years of work and support to get us to this point. Much appreciated. 🫶
No doubt there will be follow up issues to further refine and improve the code re-use here, but I think we are now in a much more secure situation that before.
Oh wow. This wraps up years of effort unifying file uploads. 🥲
Changed to `drupal:10.3.0` for removal in `drupal:11.0.0`.
Thanks for the review. I've addressed all feedback.
This feels rather close, and i'll be quite happy to have the "Temporary" class killed :D
Committed on 20 Mar 2019 so temporary for 5 years. 🤣
Feedback addressed and MR for 10.4.x created with BC layer.
Created MR for 10.4.x with BC layer.
📌 Refactor FileUploadResource to use FileUploadHandler RTBC is in 🎉 which unblocks 📌 [PP-1] Refactor JSON-API file uploads to use FileUploadHandler Postponed
Woohoo! 🎉 See you in 📌 [PP-1] Refactor JSON-API file uploads to use FileUploadHandler Postponed
📌 Refactor FileUploadResource to use FileUploadHandler RTBC is in so this is unblocked. 🙌
Once this goes in, we can start on 📌 [PP-1] Refactor JSON-API file uploads to use FileUploadHandler Postponed
Re-organizing parent meta issue.
Marking this as a meta issue now have two child issues that we want to do one at a time:
This is postponed on 📌 Refactor FileUploadResource to use FileUploadHandler RTBC as we are adding some new classes there that we will need here.
kim.pepper → created an issue.
@alexpott are you happy if we look into your concerns in 📌 Simplify how 'allow all extensions' file upload validation works Active ?
We should add a Universal object crate to PHPStan config to suppress this warning until we resolve it.
This came up in another issue somewhere, but I can't seem to find it.
Another example of a commit message that has no room for a meaningful message because it's just a list of contributors:
commit dae385398eb9860650b50f2aac087c33ee35083b (HEAD -> 11.x, origin/11.x)
Author: Lauri Eskola <lauri.eskola@acquia.com>
Date: Sat Apr 27 00:43:13 2024 +0300
Issue #3438895 by finnsky, larowlan, plopesc, m4olivei, ckrina, mherchel, catch, alexpott, nod_, deviantintegral, jwitkowski79, nod_, jponch, jwitkowski79, rkoller, Ana Barcelona, YurkinPark, finnsky, javi-er, alvarito75, ctrlADel, AaronMcHale, Emma Horrell, akshayadhav, claireristow, baluv3, bronzehedwick, NikMis, deviantintegral, hot_sauce, kostyashupenko, gnuschichten, keyboardcowboy, gdd, silviu, Prashant.c, ehsann_95, pjudge, rkoller, Shreya_th, starshaped, bal krishna, meeni_dhobale, mherchel, jo→
longwave → credited kim.pepper → .
MR needs to be closed.
Cleaned up after a few merge conflicts.
kim.pepper → made their first commit to this issue’s fork.
Addressed feedback so back to NR
Closing as won't fix. Please feel to re-open if you think there is a way to achieve this.
Committed to 2.x and 3.x. Thanks!
Created a MR so we can run gitlab ci.
kim.pepper → made their first commit to this issue’s fork.
dww → credited kim.pepper → .
Changing this to critical as it is a part of 📌 [PP-4] Unify file upload logic of REST and JSON:API Postponed which is critical.
I think this can be closed as outdated.
The next step forward for this effort is now ready for reviews: 📌 Refactor FileUploadResource to use FileUploadHandler RTBC
Many thanks to @larowlan for helping resolve the file extensions issues. 🙌🏻🥳
This is ready for reviews now.
There is a test failure due to a behaviour change. I'm scratching my head to work out why.
Before: example.php gets renamed:
example.php => example.php_.txt
After: example.php gets rejected because the .php extension isn't in the allow extensions list.
fubarhouse → credited kim.pepper → .
I tried to convert the test but ended up in a whole lot of pain. I'm not entirely sure if the sub-attributes make things better or worse.
Addressed feedback. Just one open question.
kim.pepper → made their first commit to this issue’s fork.
@Berdir #10 i had a look at 📌 Convert entity type discovery to PHP attributes Needs review and doesn't look this you are doing this anymore?
I have left the properties in for now.
Re: config_dependencies I found this in the docs for \Drupal\Core\Config\Entity\ConfigDependencyManager
* Classes for configurable plugins are a special case. They can either declare
* their configuration dependencies using the calculateDependencies() method
* described in the paragraph above, or if they have only static dependencies,
* these can be declared using the 'config_dependencies' annotation key.Yeah let's do this in 📌 Refactor FileUploadResource to use FileUploadHandler RTBC
Created a new MR that just checks if it is a FormUploadedFile and uses \Drupal\Core\File\FileSystemInterface::moveUploadedFile() or otherwise \Drupal\Core\File\FileSystemInterface::move()
Updated title and IS
A typehint of string|false would be more accurate. We never return TRUE.
I took the approach suggested in #30 of creating a file item from the field definition. I put it in a trait so it could get used by both REST and JSON API.
@alexpott Do we still want to postpone the deprecation to 12.x? It seems much less disruptive now.
@alexpott thanks for the review, but we still need to work out how to do this. See #28
I created a new issue to follow this same pattern for moveUploadedFile()
📌
Provide a method for FileUploads to be moved
Active
kim.pepper → created an issue.
Deprecated the old \Drupal\Tests\token\Kernel\KernelTestBase and added a CR.
@alexpott #25 we only ever return a string inline with the PHP dirname() function, so our documentation is wrong. The example you provided typehints the return type as bool which is wrong.
This is unblocked now that 🐛 \Drupal\file\Upload\FileUploadHandler::handleFileUpload() should alway check that the uploaded file is valid Fixed is in.
I couldn't find anything for enums in Drupal Coder or existing rules about enum case in https://github.com/slevomat/coding-standard or https://github.com/squizlabs/PHP_CodeSniffer
Thanks for confirming. This docs change looks good to me.
Even though we have 3 already, add myself as a supporter too.
@alexpott re: #26 I added the method to\Drupal\file\Plugin\Field\FieldType\FileFieldItemList::getUploadLocation() but not sure how to access that from a $field_definition.
Created a new MR based on 11.x.
I think we should go through the rest of the methods to ensure we have the correct documented return types.
Ah, we can't add return typehints on interfaces without breaking bc.
Can we take this further and add string|false a the typehint rather than just the docs?
I think the approach for validation here is a better one that the current version.
RTBC for me.
Rebased and test green so back to RTBC
We do have a rule in coder_sniffer but it's not case-sensitive https://git.drupalcode.org/project/coder/-/blob/8.3.x/coder_sniffer/Drup...
SlevomatCodingStandard.Namespaces.AlphabeticallySortedUses defaults to case-insensitive but looks like we can configure that to be case-sensitive.
https://github.com/slevomat/coding-standard/blob/master/SlevomatCodingSt...
+1 from me.
Added the template to the issue summary.
Addressed feedback.
kim.pepper → made their first commit to this issue’s fork.
Committed to 2.x. Thanks!
larowlan → credited kim.pepper → .
Leaving open for more fixes.
kim.pepper → created an issue.
Committed to 2.x
kim.pepper → created an issue.
#22 The fix was just tagged by @mglaman in a new release https://github.com/mglaman/phpstan-drupal/releases/tag/1.2.10
Removed hook_file_validate() and doc references to calling file_validate()
Had a look for docs that say we require a @return annotation and couldn't find one. Only docs for describing the format of the @return annotation.
https://www.drupal.org/docs/develop/standards/php/api-documentation-and-... →
Addressed feedback.
Created a MR to show what I mean.
Ah yes. But we also should have deprecated the hook in file.api.php docblock according to
https://www.drupal.org/about/core/policies/core-change-policies/drupal-d... →
Created 📌 Deprecate hook_file_validate() Active
kim.pepper → created an issue.
Published the CR
longwave → credited kim.pepper → .
🖐 I'm putting my hand up for issue credit for this one as I wrote the original mermaid that was posted to slack (see #34)
Addressed feedback.
Coming back to this after a long while, I am wondering why we didn't deprecate hook_file_validate() at the time?