[wp-trac] [WordPress Trac] #44038: Change personal data export path stored in request meta to relative paths

[WordPress Trac]

#44038: Change personal data export path stored in request meta to relative paths
-------------------------------------------------+-------------------------
 Reporter:  allendav                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  4.9.9
Component:  Privacy                              |     Version:  4.9.6
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests has-patch needs-    |     Focuses:
  refresh                                        |  administration
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  needs-unit-tests has-patch needs-testing => needs-unit-tests
     has-patch needs-refresh
 * focuses:   => administration


Comment:

 Thanks for the patch, @mrTall! [attachment:"44038.patch"] stores the
 relative patch for new exports, but it has one issue, and there are some
 additional scenarios that should be considered.

 [attachment:"44038.patch"] assumes the value stored in meta is always
 relative and adds the `$exports_dir` to the beginning of the value without
 examining it. Say a site has an old export (created before this change)
 that includes the full path in the meta value
 (`/srv/www/wordpress/public_html/wp-content/exports/exportfile.zip`, for
 example). The patch will always add the path to the beginning, even if it
 is the same, becoming `/srv/www/wordpress/public_html/wp-
 content/exports/srv/www/wordpress/public_html/wp-
 content/exports/exportfile.zip`.

 These are the scenarios that should also be accounted for:
 1. A relative path stored in meta (accounted for in
 [attachment:"44038.patch"]).
 1. A relative path stored in meta that becomes invalid (maybe a new plugin
 changes the data export directory via a filter, for example)
 1. A full path stored in meta that remains valid after this change.
 1. A full path stored in meta that becomes invalid when a site is migrated
 (either to a new server, or moving WordPress to a new directory on the
 same server).
 1. A full path stored in meta that remains valid, but the export directory
 has changed (plugin changes the data export directory).

 All these things considered, I think this is the best plan forward:

 - If a relative path is stored, assume it is in the current export
 directory. Unfortunately, old links will become dead, but this is how
 attachment files are currently handled (see `_wp_attached_file` meta key).
 - If a full path is stored, check if it is still valid and usable. If it
 is and it can be protected from being browsable, leave the full path in
 meta and continue to use that path to preserve export links.
 - If a full path is stored and it is not valid, usable, or cannot be
 protected from browsing, use the same filename but the current export
 directory and save the relative path to meta. Old links will also become
 dead here, though.

 @SergeyBiryukov does this make sense? Did I miss anything?

 The unit tests for this also depend on #44233. They should reside within
 the test class being created there.

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