[wp-trac] [WordPress Trac] #48316: Changeset 46482 breaks upload when using ".." in upload_path.

[WordPress Trac]

#48316: Changeset 46482 breaks upload when using ".." in upload_path.
----------------------------+-----------------------
 Reporter:  xpoon           |       Owner:  (none)
     Type:  defect (bug)    |      Status:  reopened
 Priority:  normal          |   Milestone:
Component:  Filesystem API  |     Version:  5.2.4
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:
----------------------------+-----------------------
Changes (by gerardreches):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 How all of this started and why is it so difficult to fix may be far from
 my understanding, but I'm in the following situation where I want the
 following structure:

 {{{
 public_html/
 --> content/
 |----> plugins/
 |----> themes/
 --> core/
 |----> wp-includes/
 |----> wp-admin/
 |----> etc
 --> uploads/
 --> wp-config.php
 --> index.php
 }}}

 This is based in [https://github.com/markjaquith/WordPress-Skeleton
 WordPress-Skeleton] and [https://deliciousbrains.com/move-wordpress-root-
 subdirectory/ this guide] from deliciousbrains. The former repository has
 over 1800 stars and 600 forks, quite a big user base. My only change here
 is that I don't want the uploads directory inside the wp-content. It makes
 more sense for me to have it separate, as one is meant to be for the
 public while the other one isn't.

 I am not using Git and I am not using symlinks, nor intend to. Not all
 hosting providers allow you to make use of those.

 While moving the core files and the wp-content directory is easy, it was
 impossible to achieve this structure by using the `UPLOADS` constant in
 the wp-config.php file. The only way to do it was by using the
 `uploads_path` option with either the absolute path or the relative path
 `../uploads`.

 Using the database option for this matter isn't a good approach, because
 it doesn't allow for easy migrations (after migrating the database from
 another site, the option will be replaced and the uploads path will be
 broken). Swapping the database could also break it. It's simply not
 obvious as a constant in the `wp-config.php` file is.

 Now, I do not understand what is going on with the `UPLOADS` constant and
 why it cannot be an absolute path nor why it doesn't behave in the same
 way as `uploads_path`. Maybe it is because the constant is taking care of
 both the path and the URL while the option only takes care of the path
 while there is another option taking care of the URL.

 My point is, **why don't we have a new pair of constants for the uploads
 path** just like we have `WP_CONTENT_DIR` and `WP_CONTENT_URL` for the
 **wp-content** directory that mimic what the database options do?

 Constants could be named **`WP_UPLOADS_DIR`** and **`WP_UPLOADS_URL`** and
 **they should not do other thing than exactly what the `uploads_path` and
 `uploads_url_path` options do**. Checking if the constant is defined, and
 in that case, using it wherever `get_option( 'uploads_path' )` and
 `get_option( 'uploads_url_path' )` are used. Their goal would be no more
 and no less than overriding the database option when defined.

 It makes so much sense in my head that I don't understand why this haven't
 been done yet, there has to be a catch. I'm no security expert, but if we
 can use an absolute path in `wp-config.php` for `WP_CONTENT_DIR` why
 couldn't we have it for a new `WP_UPLOADS_DIR` constant? It would just
 take precedence over the database value, and less than `UPLOADS`. I can't
 imagine any backward compatibility issues either.

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