[wp-trac] [WordPress Trac] #51340: Stop chmodding files and folders

[WordPress Trac]

#51340: Stop chmodding files and folders
----------------------------+------------------------------
 Reporter:  malthert        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  5.3
 Severity:  major           |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by l3rady):

 Replying to [comment:5 SergeyBiryukov]:
 > Could you share the exact error message? There are at least 10 instances
 of `chmod()` in core, so it's not quite clear yet whether the ticket
 applies to the one in `WP_Filesystem_Direct` or any others too.


 {{{
 ErrorException: chmod(): Aws\S3\StreamWrapper::stream_metadata is not
 implemented!
 #6 includes/file.php(892): handleError
 #5
 /var/www/*******/releases/20210210123136/vendor/sentry/sentry/lib/Raven/ErrorHandler.php(0):
 chmod
 #4 includes/file.php(892): _wp_handle_upload
 #3 includes/file.php(953): wp_handle_upload
 #2 includes/media.php(301): media_handle_upload
 #1 includes/ajax-actions.php(2542): wp_ajax_upload_attachment
 #0 async-upload.php(33): null
 }}}

 [[Image(https://internal-s3-lon-cloud-bigfish-co-uk.s3.eu-
 west-2.amazonaws.com/scott/Screenshot%202021-02-12%20at%2011.25.54.png)]]

 In our case, we use AWS S3 stream wrapper and it doesn't support things
 like chmod. We have worked around the issue by extending
 Aws\S3\StreamWrapper and adding a stream_metadata function that returns
 false. However, that only fixes for our use case.

 There are many other filesystems out there and not all of them support
 thinks like chmod, touch and mkdir. Things were fine in WP land as all
 filesystem calls were error suppressed with `@`.

 It looks like someone has made the decision to not suppress errors as it
 feels very janky to do so, but when it comes to filesystem calls I think
 it is perfectly reasonable to do it.

 There is still the argument to be made if WordPress should be making chmod
 calls in the first place as per the OP's argument.

 I should have maybe posted my response as a new ticket however both the OP
 and my input has been triggered by the removal of error suppression.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51340#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform