__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Tickets Needing Feedback,6814,Async media crunching,adamsilverstein,Upload,2.5,normal,normal,Future Release,enhancement,assigned,dev-feedback,2008-04-23T00:19:05Z,2022-08-24T14:14:22Z,"The upload part of the new multi-uploader is pretty nice now, but it blocks on the ""crunching"" phase, which can sometimes take 20-60 seconds, I assume to create medium thumbnails and such.
The crunching part of the upload should not block the next file beginning the upload process, it should happen asynchronously with the rest of the process.",matt
Tickets Needing Feedback,12756,WPMU does not handle files with two or more dots in the filename,wpmuguru,Upload,2.9.2,normal,minor,Future Release,defect (bug),reopened,close,2010-03-29T07:23:50Z,2022-10-14T18:47:54Z,"* WPMU does download images that have two or more dots in the file name
> E.g., One..jpg One...jpg One....jpg
rewrites do work (checked)
* this is clearly a WP issue:
> /wp-content/blogs.php
...
$file = BLOGUPLOADDIR . str_replace( '..', '', $_GET[ 'file' ] );
if ( !is_file( $file ) ) {
status_header( 404 );
die('404 — File not found.');
}
...
> WPMU removes two dots!!!
> workaround:
$file = BLOGUPLOADDIR . $_GET[ 'file' ]; // name.ly: workaround for files with two or more dots
tested and works fine
",Namely
Tickets Needing Feedback,15924,Add 'media_default_link_type' option to parallel 'image_default_link_type',,Upload,,normal,normal,Future Release,enhancement,new,dev-feedback,2010-12-20T21:12:12Z,2019-05-15T20:48:42Z,"It is often recommended that site owners change the 'image_default_link_type' option to ""none"" if they don't plan on linking to full size images often from their posts. The problem is that this also affects the default link type for other media (uploaded zip files, pdfs, etc.) Adding an additional option for 'media_default_link_type' which behaves in the same way would get around this problem.
",goldenapples
Candidates for Closure,15955,move_uploaded_file mangles non-ascii characters on Windows platforms,SergeyBiryukov*,Upload,2.0,normal,major,Awaiting Review,defect (bug),accepted,close,2010-12-22T22:15:46Z,2018-07-09T19:14:56Z,"The `sanitize_file_name` function is not filtering alot of character entities like the degree symbol, this results in invalid media item paths, see the attached images.
wp-includes/formatting - Line 677
{{{
$special_chars = array(""?"", ""["", ""]"", ""/"", ""\\"", ""="", ""<"", "">"", "":"", "";"", "","", ""'"", ""\"""", ""&"", ""$"", ""#"", ""*"", ""("", "")"", ""|"", ""~"", ""`"", ""!"", ""{"", ""}"", chr(0));
}}}
This array is not dealing with invalid entities that could be used in a filename, and the regular expression further down is not catching these either.
wp-includes/formatting - Line 700
{{{
if ( preg_match(""/^[a-zA-Z]{2,5}\d?$/"", $part) ) {
}}}
See attached images, i used 4 varying names with unusual entities in them(each a copy of a sample jpg image).
Using a filter on the valid chars array results in the extension getting stripped off but the file still makes it through the upload routine however(which is worrying).
I'm no file validation expert, so i'm not sure if this is a critical problem(marked as normal), i'll leave this for you chaps to decide.
'''NOTE:''' Ignore my hostname in the screenies, it's a 3.0.3 installation, i'm just lazy with updating my virtual host settings.
See screenshots for steps to reproduce(just create a file with some dodgy character entities and upload it basically).",t31os_
Tickets Needing Feedback,16191,Uploaded files with quote marks in the filename are undisplayable in MS,,Upload,,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2011-01-11T19:28:49Z,2019-11-03T18:40:43Z,"If you upload a file with quote marks in the filename, e.g. `""Test"".jpg`, WordPress records the filename as `%22test%22.jpg` but the file is called `""Test"".jpg` (on 'nix-like systems anyway) so is undisplayable.
I'm unsure about the implications (security and otherwise) of my suggested patch (attached), so please give feedback. (I guess the other approach would be to retain the url-encoded characters and ensure that the file is named with the URL encoded version of the filename.)",simonwheatley
Tickets Needing Feedback,18043,Uploaded images disappear after loading if using compression w/Apache,,Upload,3.2.1,normal,major,Future Release,defect (bug),new,dev-feedback,2011-07-08T22:49:15Z,2019-05-15T21:02:03Z,"I have found an issue between WordPress (Multisite) + Google Chrome (Mac) which I think appeared on my sever when I enabled compression a few months ago, but could never reproduce because it only happens with images managed by a Multisite WordPress install, not static images.
With images that are static Apache sends the file and calculates the Content-Length its self so these images work fine but if you access a file uploaded to WordPress it uses the .htaccess redirect so the image requests are sent via ms-files.php for what ever reason.
The problem is that WordPress decides to calculate its own Content-Length header in the HTTP Response which means that security conscious browsers like Google Chrome freak out when the data they receive is less than they we're told by Apache and they resultantly disable the image.
The Content-Length calculation comes on line 43 of ms-files.php I don't know why its needed because Apache seems to sort it out automatically if you don't send your own header, in fact most of the file seems like an unnessisary load of processing, perhaps it needs reviewing but this is a major issue as it is a growing browser, on a growing platform.
Here is a great video of it in action: http://www.screencast.com/t/cUYKSegW0N
This issue has been repeatedly reported on the forum:
http://wordpress.org/support/topic/disappearing-images
http://wordpress.org/support/topic/multisite-images-broken
http://wordpress.org/support/topic/image-not-show-in-google-chrome-timthumbphp
Please fix this asap!",ctsttom
Tickets Awaiting Review,18474,Misleading error message when theme ZIP exceeds post_max_size,,Upload,3.2,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2011-08-18T16:16:03Z,2019-05-15T21:05:41Z,"''post_max_size'' is 32MB, now try to uploading a 40MB big ZIP.
You will get the ''Are you sure you want to do this? Please try again.'' message. But ''try again'' will not help.
Notice:
''Warning: POST Content-Length of 47774864 bytes exceeds the limit of 33554432 bytes in Unknown on line 0''",ocean90
Tickets Awaiting Review,18489,Create constants in default-constants.php for the uploads folder to allow better custom uploads location,eddiemoya,Upload,3.2.1,normal,normal,Awaiting Review,enhancement,reopened,,2011-08-19T20:11:41Z,2019-05-15T21:10:46Z,"There are cases in which a the uploads directory might need to be divorced WP_CONTENT_DIR, currently the only thing we can use is the UPLOADS constant, which works but is relative to ABSPATH and as such limits where the uploads directory can be moved to.
In default-constants.php we have constants for the wp-content, and plugins folder - the uploads folder is a natural addition to this. Currently there is only a poorly documented UPLOADS override in wp_uploads_dir, which can be overridden in wp-config.php. I also think there should be a similar constant for the themes folder, but I would that would be a bit more complex of a change.
I have create a new function in default-constants.php which introduce WP_UPLOADS_DIR and WP_UPLOADS_URL, which are called after wp_plugins_directory_constants() in wp-settings.php - because that function create WP_CONTENT_URL, which is needed in order to create WP_UPLOADS_URL.
It is important to note that I have not changed any of the precedent in terms of what overrides what - the uploads_path option still overrides the default location (or now, the potentially custom location) defined by the new constant, ''the old UPLOADS constant will still override either of them if it is set''. Thats the way it worked before and that behavior has been preserved.
Additionally, I have patched /wp-includes/function.php wp_uploads_dir to make use of these new constants as well as a little clean up of some related logic.
First patch to core - go easy.",eddiemoya
Tickets Awaiting Review,21981,Securing the uploads directory,,Upload,,normal,normal,Awaiting Review,enhancement,reopened,,2012-09-24T04:35:11Z,2023-06-25T07:15:26Z,"Look at implementing something similar to an .htaccess file in the uploads directory with:
{{{php_flag engine off}}}
This may not work in every server scenario, but let's open the conversation, and some scenarios is probably better than none anyway.",japh
Tickets Awaiting Review,22128,Adding upload mimetype in Multisite does not work if mimetype is not already defined,,Upload,3.0,normal,minor,Awaiting Review,defect (bug),new,,2012-10-08T13:13:54Z,2019-05-15T21:11:42Z,"'''Description'''
We would like to add 3gp to the list of file types to be uploaded in the sites of our network install.
We've tried to add 3gp to the Network Settings->Upload File Types setting for this. However after having saved the setting we were still not able to upload 3gp. It seems the user setting is being overruled by the list of global settings.
'''Steps to reproduce issue:'''
1. Use WordPress Network install (aka Multisite)
2. Add the file extension 3gp to the upload file types setting in Network Settings
3. Save Settings
4. Try to upload a 3gp file using the Media Library, it will fail with the message: 'Sorry, this file type is not permitted for security reasons.'
It seems the upload file types defined in the Network Settings cannot overrule / add new file types if this file type has not already been defined in the function wp_get_mime_types() (see file: wp-includes/functions.php).
'''Expected behaviour'''
Changing the Upload File Types by adding a new extension results in WordPress accepting files ending in this extension. Or warn the admin that this extension is unknown and more info (such as the full mime type) is needed.
'''Proposed solution'''
We are aware of the hook 'upload_mimes' to fix this with a plugin, but we suggest that the superadmin Network Settings->upload file type overrules WordPress' built-in defaults instead of the other way around.",BjornW
Tickets Awaiting Review,22150,Customizer: Remove Image doesn't remove from Media Library,,Upload,3.4,normal,normal,Awaiting Review,defect (bug),new,,2012-10-10T05:35:15Z,2019-05-15T21:12:16Z,"After uploading an image using the Theme Customizer, a ""Remove Image"" link appears - this seems to imply that clicking it will cause the image to be deleted entirely, rather than just hidden from the current view.
",pento
Tickets Awaiting Review,23188,Hardcoded relative url 'async-upload.php' in plupload/handlers.js,,Upload,3.5,normal,normal,Awaiting Review,defect (bug),new,,2013-01-12T11:47:48Z,2018-01-18T20:34:04Z,"On line 127 in plupload/handlers.js you can find relative path to 'async-upload.php'.
It rather should use wpUploaderInit.url (or something like that), so you could use WP Plupload in front-end for example or with your custom uploading scripts.
Now you can write your custom uploader script and provide it via wpUploaderInit, but on that line in handlers.js it is ignored (and if you run it in front-end, bad request to ./async-upload.php is made).",drozdz
Tickets Awaiting Review,23483,Incorrect image URL for subsites when using UPLOADS constant on multisite subdirectory installation,,Upload,3.5.1,normal,normal,Awaiting Review,defect (bug),new,,2013-02-15T18:56:54Z,2017-07-08T00:41:31Z,"If the UPLOADS constant is used on a Wordpress Multisite installed to subdirectory, using subdirectory mode, then image URLs for subsites are incorrect.
Example:
* WP MS installed to www.domain.com/wordpress, subdirectory not subdomain
* UPLOADS set to 'assets'
Main site uploads images to /wordpress/assets/... [[BR]]
Main site image URL is www.domain.com/wordpress/assets/...
1. Create subsite called 'subsite';
2. Subsite uploads images to /wordpress/assets/sites/2/...
3. Subsite image URL is www.domain.com/subsite/assets/sites/2/... when it should be www.domain.com/assets/sites/2/...
This is because wp_upload_dir() uses get_option('siteurl') to derive the URL. It is probably right for subdomain multisite but wrong in this use case.",creativeinfusion
Tickets Needing Feedback,23895,Max upload size 0 when post_max_size = 0,johnbillion,Upload,3.5.1,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2013-03-29T15:01:32Z,2017-11-29T14:29:56Z,"As a convention, post_max_size can be set to 0 to disable any limitation on max post size.
Quote from php.ini:
{{{
; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
}}}
WordPress does not take this into account in wp-admin/includes/template.php ",moscar09
Candidates for Closure,24251,Reconsider SVG inclusion to get_allowed_mime_types,,Upload,,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2013-05-02T19:36:57Z,2023-03-27T19:24:23Z,"There are some who think SVG should be included in core as an allowed mime type. Makes fine enough sense to me, since there is a good argument for it, and we have support for WordPerfect documents...so there's that.
Related: #20990",JustinSainton
Unpatched Enhancements,24934,More flexible response reporting in wp-plupload.js,,Upload,3.6,normal,normal,Future Release,enhancement,assigned,,2013-08-03T00:30:06Z,2019-05-15T21:13:41Z,"The wp-plupload.js wrapper to the plupload library only returns server responses to bound callbacks in the case of a well formed error (the server responds with {{{ { success: false } }}}).
Sometimes it may be useful to receive additional information from the server on ''successful'' upload. I have prepared a patch that allows for the {{{success}}} and {{{error}}} callbacks to receive server responses.",ippetkov
Tickets with Patches,25449,wp_upload_dir() doesn't support https,,Upload,3.8,normal,major,Future Release,defect (bug),reopened,has-patch,2013-09-30T13:11:15Z,2020-11-25T12:40:50Z,"The wp_upload_dir() function does not support https. I have added a simple is_ssl() check and a string replacement to serve the correct URL type.
'''Background behind what prompted me to write the patch:'''
I read a blog post by Kaspars Dambis in which he discussed fixing this problem via his own plugin, but it seems to me that since WordPress outputting an incorrect URL, that it would make most sense to fix it there.
http://kaspars.net/blog/wordpress/minit-plugin-ssl-https
",ryanhellyer
Tickets Awaiting Review,25650,"When switching between blogs, wp_upload_dir 'baseurl' and 'url' may be pointing to the current blog not the switched one",,Upload,3.6.1,normal,normal,Awaiting Review,defect (bug),new,has-patch,2013-10-21T14:36:08Z,2023-05-19T13:20:48Z,"Only tested on subfolder multisite (I don't have a way to test on a subdomain install right now).
It seems very similar to ticket #23483 but I'm not sure if it should be treated the same:
Example with two blogs in a network:
- www.mydomain.com/my-source-blog (ID:5)
- www.mydomain.com/my-destination-blog (ID:15)
I discover this while trying to move a post with images from a blog to another. The post is copied and images inside the post are copied too.
Starting point: The current blog ID is 15 (my-destination-blog). I'm trying to get upload URLs from the current blog:
{{{
switch_to_blog( 5 );
$source_upload_dir = wp_upload_dir();
$source_upload_baseurl = $source_upload_dir['baseurl'];
restore_current_blog();
$destination_upload_dir = wp_upload_dir();
$destination_upload_baseurl = $destination_upload_dir ['baseurl'];
}}}
At this point, $source_upload_baseurl is:
{{{
http://www.mydomain.com/my-destination-blog/wp-content/uploads/sites/5
}}}
Where should be:
{{{
http://www.mydomain.com/my-source-blog/wp-content/uploads/sites/5
}}}
$destination_upload_baseurl is fine.
It seems that if get_option( 'upload_url_path' ) returns false, wp_upload_dir() makes use of WP_CONTENT_URL constant that is set to the current blog URL at the beggining of the execution (in default-constants.php):
{{{
define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');
}}}
This value obviously does not change when switching a blog.
",igmoweb
Unpatched Enhancements,27860,Media Upload: Incorrect renaming increment for retina files,,Upload,3.9,normal,normal,Future Release,feature request,new,,2014-04-17T12:23:40Z,2019-05-15T21:14:35Z,"If a file is uploaded `myimgage.png` and then a second image is uploaded with the same name the file is renames `myimgage.png` to `myimgage1.png` this is fine.
However if a Retina image is uploaded using the Apple retina standard @2x i.e. `myimage@2x.png`
The increment is `myimage@2x1.png` this is not correct and should be `myimage1@2x.png`
Should be `myimage[[prefex]]@2x.png` NOT `myimage@2x[[prefex]].png` ",phillbooth
Tickets Awaiting Review,28238,Add filter to value returned from get_space_used(),,Upload,3.5,normal,normal,Awaiting Review,enhancement,new,has-patch,2014-05-13T18:20:06Z,2019-05-15T21:15:11Z,It would be helpful to have an additional filter to modify the returned value from the get_space_used() function in order to add additional space quantities without having to recreate the entire function by only having the 'pre_get_space_used' filter.,hereswhatidid
Tickets Awaiting Review,28367,Video upload failure is a dead end,,Upload,3.9.1,normal,normal,Awaiting Review,enhancement,new,,2014-05-26T15:41:46Z,2019-05-15T21:15:44Z,"""VID_1234.mp4 exceeds the maximum upload size for this site.""
That's what you see on most hosts when trying to upload a video, even one only a few seconds long. This is a dead end that could be so much more helpful. Just a link to a codex page on how to bump upload_max_filesize and post_max_size or install a video plugin would be welcome, but this seems a place where we should aspire to greater smoothness.",ryan
Tickets Awaiting Review,30384,Cannot hook plupload's JavaScript consistently,,Upload,4.0,normal,normal,Awaiting Review,enhancement,new,,2014-11-18T16:03:56Z,2019-05-15T21:15:59Z,"Visit /wp-admin/media-new.php and enter the following into the console:
window.uploader.bind('FileUploaded', function (){alert(1)})
Upload a file and once that's complete your function will be executed.
However if you visit /wp-admin/upload.php or /wp-admin/post-new.php and run that JavaScript you'll find that window.uploader is undefined.
I'm trying to prompt users to add additional information about the images they upload, but without access to the Uploader object that appears to be impossible.",tomdxw
Tickets Awaiting Review,31372,media-new.php stops uploading after max_execution_time set in php.ini,,Upload,4.1,normal,normal,Awaiting Review,defect (bug),new,,2015-02-18T19:59:13Z,2019-05-15T21:16:23Z,"== Environement ==
Windows Server 2008 (version 6, build 6002: SP2)
IIS Version 7.0.6000.16386
PHP Version 5.4.26
FastCGI
== Problem ==
When uploading a media file to Wordpress the upload only runs for the max_execution_time set in php.ini. When that time has elapsed (for slow connections or a large file) the multi-file uploader displays the generic error ""HTTP error."" The browser uploader stops with the PHP error ""max execution time reached""
Is this behavior by design?
== Proposed solutions ==
1. '''set `set_time_limit(0)` in media-new.php, so a upload can take as long as it needs''' [[br]] For IIS this solution is preferred, because FastCGI automatically stops script execution when a connection is lost. For Apache the additional code `ignore_user_abort(false);` might be needed to prevent the script from executing after the client has aborted, although that also is the standard behavior for Apache I think.
2. '''Display a more helpful error''' [[br]] ""HTTP error."" could practially mean everything. It took me at least 2 hours to find out what was causing the error. Displaying ""Your upload exceeded the max_execution_time set in PHP"" makes things already a lot more understandable.
== Thoughts about limits ==
File uploads are already limited by max_upload_size and max_post_size, so it should make sense to not also limit them on how long they can take.
Some users simply don't have a fast enough connection to complete the file upload in the max_execution_time specified by php.ini",au.merci
Candidates for Closure,32318,"Upload fails, wp_insert_attachment returned 0",,Upload,4.1.5,normal,normal,Awaiting Review,defect (bug),new,close,2015-05-08T22:34:11Z,2022-10-19T15:47:53Z,"One specific mp3 file was failing to attach, and it seems wp_insert_attachment is breaking with 0 returned, breaking update-attachment-metadata:
wp-admin/includes/media.php, line 360:
{{{
// Save the data
$id = wp_insert_attachment($attachment, $file, $post_id);
if ( !is_wp_error($id) ) {
wp_update_attachment_metadata( $id, wp_generate_attachment_metadata( $id, $file ) );
}
}}}
id = 0, caused by these lines in wp-includes/post.php, around line 3351:
{{{
if ( false === $wpdb->insert( $wpdb->posts, $data ) ) {
if ( $wp_error ) {
return new WP_Error('db_insert_error', __('Could not insert post into the database'), $wpdb->last_error);
} else {
return 0;
}
}
}}}
In this case the documentation is wrong, it didn't return the post id.",programmin
Tickets Awaiting Review,32704,Upload path is not set correctly after switch_blog,,Upload,3.0,normal,normal,Awaiting Review,defect (bug),new,,2015-06-18T15:06:15Z,2019-05-15T21:18:59Z,"When blog is switched and still using old multisite upload folders, upload
directory is not set correctly, which makes functions like
wp_get_attachment_image_src() return the wrong url.",ilanco
Candidates for Closure,33963,New function: `upload_url()`,,Upload,,normal,normal,Awaiting Review,enhancement,new,reporter-feedback,2015-09-22T12:32:57Z,2019-05-15T21:20:24Z,Retrieve the url to the uploads directory.,sebastian.pisula
Candidates for Closure,35310,"""Add Media"" dropzone shouldn't take up the entire modal window",,Upload,4.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-01-04T21:41:44Z,2019-05-15T21:20:58Z,"As @ocean90 mentioned in #28851,
> the whole `[""Add Media"" modal window]` is a dropzone for the uploader.
For example, if you drag and drop an item over the left, gray column where the ""Create Gallery"", ""Create Audio Playlist"" and ""Featured Image"" links are, the ""Add Media"" window will show that the dropzone covers this area as well.
Since I'm attempting to write a plugin to add an extra plupload drag-and-drop instance in the existing ""Add Media"" modal window, my custom dropzone will not take effect because WP's dropzone has precedence.
Would it be possible to limit WP's uploader dropzone to the ""Insert Media > Upload Files"" tab only?",r-a-y
Tickets Awaiting Review,35823,"Implement ""FS_CHMOD_FORCE"" constant; if set - media uploads and image resizing do NOT ignore FS_CHMOD_FILE",,Upload,,normal,normal,Awaiting Review,enhancement,new,,2016-02-12T23:46:25Z,2018-01-25T20:22:36Z,"Hello.
I want to re-open https://core.trac.wordpress.org/ticket/21251
I think that it's very strange to not giving an ability to globally override file permissions. Even though WP lead developers thinks that it's ""not good"" to use FS_CHMOD_FILE on file uploads - there should be a way to do it. It will not be default. Default behaviour won't be changed. Filters or other ways are a madness for users with many websites on board or for hosting providers which want to set basic options forcefully.
The problem:
One may expect that after setting constant FS_CHMOD_FILE - all files created or modified (maybe) by WordPress will have FS_CHMOD_FILE permissions. But for some wierd reason it is not so. I can understand the explanation from 21251 ticket. So it can be solved by creating a new constant which control the behaviour.
I've attached a patch which changes upload function's logic to understand FS_CHMOD_FORCE constant and honor it if it is defined. If it is not defined (default), behaviour will be the same as it was before.
After applied patch it will be possible to set the following in wp-config.php or globally:
{{{#!php
';
var_dump( FILEINFO_MIME_TYPE ) . '
';
var_dump( $finfo ) . '
';
var_dump( $file ) . '
';
var_dump( $real_mime ) . '
';
wp_die();
}}}
The output of the above code is below on LOCALHOST:
- PHP: Version 7.2.4
- System: Windows NT M 6.3 build 9600 (Windows 8.1 Professional Edition) i586
{{{
int(16)
resource(767) of type (Unknown)
string(46) ""C:\Users\Yum\AppData\Local\Temp/wxr-LccAYF.tmp""
string(8) ""text/xml""
}}}
But, It is different on the LIVE site.
- PHP: Version 7.0.32-4+ubuntu16.04.1+deb.sury.org+1
- System: Linux ip-172-31-25-204 4.4.0-134-generic #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018 x86_64
{{{
int(16)
resource(747) of type (Unknown)
string(19) ""/tmp/wxr-YNkiH5.tmp""
string(15) ""application/xml""
}}}",Mahesh901122
Candidates for Closure,45725,Unable to use the UPLOADS constant with WordPress in a different directory,,Upload,,normal,normal,Awaiting Review,enhancement,new,needs-docs,2018-12-20T13:07:46Z,2019-01-16T06:50:09Z,"=== The problem ===
When WordPress is installed in a different directory (you can achieve that by following [[https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory|these instructions]]), the **UPLOADS** constant is unable to function correctly in some cases according to the **wp_upload_dir()**'s output. Occasionally the constant accepts a relative path what will be appended to the **ABSPATH** constant to determine the **basedir** and to the **site_url()** function to determine the **baseurl** for the uploads location.
Although WordPress does let you move the CMS (it actually can be anywhere on the filesystem), however the uploads directory will always be relative to the CMS directory (**ABSPATH** constant) when using the **UPLOADS** constant.
=== The use case ===
There are multiple use cases which will be affected by this but let's consider the next few parameters:
* Website URL: example.com
* Website DIR: /foo/bar
* WordPress URL: example.com/wordpress
* WordPress DIR: /foo/bar/wordpress
Our goal is to store uploads at:
* Uploads URL: example.com/uploads
* Uploads DIR: /foo/bar/uploads
However when we defining the UPLOADS constant as 'uploads', will result in the following:
* Uploads URL: example.com/wordpress/uploads
* Uploads DIR: /foo/bar/wordpress/uploads
You might wonder what will happen when we use an absolute value for the constant instead, in this case '/foo/bar/uploads' is used:
* Uploads URL: example.com/wordpress//foo/bar/uploads
* Uploads DIR: /foo/bar/wordpress//foo/bar/uploads
=== The solution ===
Possible solutions where I could came up with are, the two following:
* Add another constant like **ABSPATH** to the index.php, this could be tricky for some people to update but the benefits of it are very useful. It will allow you to use one WordPress installation for all your WordPress websites. How you might wonder? [[https://stackoverflow.com/a/39195424/3157038|This is how]], I've been using this already for years!
* Another solution could be to introduce a new constant specifically for the uploads directory path and only use the current **UPLOADS** constant for the url.
Both of these solutions require to be implemented into the **_wp_upload_dir()** function [[https://core.trac.wordpress.org/browser/tags/5.0/src/wp-includes/functions.php#L1972|on line 1972 in wp-includes/functions.php]]
Have a look at the patch attached to this ticket, with the patch WordPress will introduce both the **UPLOADS_DIR** and **INDEX_ABSPATH** constant. According to some tests I did it should also be backward compatible.",Fleuv
Tickets Awaiting Review,45818,ALLOW_UNFILTERED_UPLOADS does not work on multisite,,Upload,,normal,normal,Awaiting Review,defect (bug),new,,2019-01-03T16:25:01Z,2022-09-22T17:34:48Z,"In a multisite environment ALLOW_UNFILTERED_UPLOADS does not work. It only works for super admin. /wp-includes/capabilities.php line ~385.
{{{#!php
Add New:
{{{
An error occurred in the upload. Please try again later.
}}}
I am using Twenty Nineteen theme with no plugins activated and I don't get the error when I remove the function.
https://codex.wordpress.org/Function_Reference/unzip_file
",troytempleman
Tickets Awaiting Review,47296,Attachments with very long filenames fail to save to the database,,Upload,,normal,normal,Awaiting Review,defect (bug),new,,2019-05-16T17:51:39Z,2022-01-04T19:22:50Z,"When an attachment is uploaded and the `attachment` post is inserted into the database, the `guid` is set to the attachment URL. The `guid` database column is limited to 255 characters, so a very long domain/filename combination can result in the post failing to save to the database with the vague message ""Could not insert post into the database"". The uploaded file does not get deleted from the uploads directory, and further attempts to upload the same file without renaming it will result in a different error, ""The uploaded file could not be moved to {location}"".
The issue occurs in `wpdb::strip_invalid_text()` and `wpdb::process_fields()`. `wpdb::strip_invalid_text()` trims the field contents down to 255 characters, and `wpdb::process_fields()` fails as a result of this data change.
The root cause is the same as #32315, though I believe this should still be tracked and handled separately. Judging by the trajectory of #32315, the user would be presented with a cryptic database-focused error message, whereas a better solution for this problem would be that the attachment successfully inserts.
=== To Replicate
1. Create a file and give it a name composed of 240+ characters (the ""tipping point"" length depends on the site's domain, amongst other factors, so this error can occur with shorter filenames).
2. Upload the file to WordPress anywhere media can be added.
3. The database insert should have failed with the error message, ""Could not insert post into the database"".
4. Attempt to upload the same file again to observe the error message, ""The uploaded file could not be moved to...""",mboynes
Tickets with Patches,47752,Fix upload of .srt files,,Upload,5.0.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2019-07-22T08:19:27Z,2019-09-22T21:49:24Z,"See #45615, #45622, [44438], [44439], and [44443].
Files with `.srt` extension are meant for video subtitles (captions), much like `.vtt` files. After the changes to make the mime type check stricter in WordPress 5.0.1 (backported to 4.9.9, etc.), uploading `.srt` files can fail because of mismatched MIME type check. Actually, `.vtt` can be served as `text/plain` depending on the server configuration.
Before WordPress 5.0.2, `.srt` files could be uploaded without issues.
For example, on a standard VVV install, the upload fails. Test file from the `mediaelement-files` GitHub repo:
https://github.com/mediaelement/mediaelement-files/blob/master/mediaelement.srt
",afercia
Tickets Awaiting Review,48369,Uploaded media files created with incorrect permissions if directory set to 751.,,Upload,5.2.3,normal,normal,Awaiting Review,defect (bug),new,,2019-10-18T17:20:11Z,2021-04-22T02:23:44Z,"
I discovered a very strange issue.. Files uploaded in the Media Library are having permissions set of 640 instead of 644.
I’ve tried setting a umask in the wp-config.php file, eg
define(‘FS_CHMOD_FILE’,0644);
This seems to have no effect.
Strangely, there are a number of wordpress sites on this box. Only 2 of these have this issue and the others all work fine and set the permissions to 644.
I have uploaded a simple PHP upload script to see if this is a PHP issue, but using the simple upload script the permissions are set to 644.. So I’m sure this is a wordpress issue.
I’ve then re-installed wordpress in the Admin interface, this didnt make any difference, I’m running 5.2.4 – the latest, I don’t think we had this issue before the last update but I cannot be 100% sure of that..
After digging in File.php I added some debug code:
// Set correct file permissions.
$stat = stat( dirname( $new_file ) );
error_log(“JSG: STAT MODE $stat[mode]”); // new line
$perms = $stat[‘mode’] & 0000666;
error_log(“JSG: $perms”); // new line
[18-Oct-2019 15:18:13 UTC] JSG: STAT MODE 16873
[18-Oct-2019 15:18:13 UTC] JSG: 416 <– this is bad right?
On another site which works fine with the same debug code I have:
DRT JSG: STAT MODE 16877
DRT JSG: 420
This made me look at the code and realise the issue.. If the DIR is set to 751, then the permissions on uploaded files are changed to 640.. but if the dir is 755 the permissions are set to 644..
Having permission of 751 is acceptable from a security point of view because the server does only needs to excuse permission on the dir to access the files within it. ",jonathangilpin
Tickets with Patches,48477,Add a hook before creating image sub-sizes,,Upload,5.3,normal,normal,Future Release,enhancement,new,dev-feedback,2019-10-31T22:49:49Z,2020-02-10T18:21:29Z,"Since things are moving for media thumbnails lately, it could be a good time to add a hook that fires right before thumbnails are created.
It would allow plugins to perform operations on the main file for example.",GregLone
Candidates for Closure,49042,"After WordPress automatically scales your uploaded images down, it loses track of the original images",,Upload,5.3,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2019-12-19T13:31:01Z,2022-08-28T02:17:38Z,"WordPress 5.3's new image scaling feature seems to have an overlooked issue.
1. Go to /wp-admin/upload.php
2. Upload a huge image.
3. WordPress will resize the image automatically and call your image (filename)-scaled.jpg
4. Go back to /wp-admin/upload.php
5. Delete the image permanently
6. Upload a new image with that same filename
7. The new image will now have ""-1"" attached to the end of it, because WordPress didn't delete the original (non-resized) image from the uploads folder.
There doesn't appear to be any way to remedy this via the UI, and it's bound to lead to both confusion and unnecessary files piling up on people's servers.
The best solution here, I think, would be to store the name of the original file somewhere (if it's not already being stored) and delete it too when somebody deletes the scaled image.",pikamander2
Tickets Awaiting Review,49622,Media reports upload success while No file was loaded!,,Upload,5.3.2,normal,normal,Awaiting Review,defect (bug),new,,2020-03-11T10:49:07Z,2020-03-11T10:51:51Z,"Latest WP 5.3.2
Scenario:
1. Working WordPress site.
2. After porting from another hosting
[make sure you have wrong url path for upload in wp_options
Cleary it happend unintensionaly.]
2. Load an image
Operation completes, with link to the new media (that does not realy exists...)
The problem: in wp_options - wrong path for upload
The bug: WordPress does NOT check that folder exists & load actually succeeded",mulli.bahr
Candidates for Closure,49658,Incorrect Upload Directory path using wp_upload_dir(),,Upload,5.3.2,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2020-03-17T11:35:05Z,2020-03-23T13:25:44Z,"I usually don't use windows when coding with WordPress.
I was creating a file in the uploads directory and decided to use wp_upload_dir() to get the upload directory path. When I printed the result, I noticed that the path returned was incorrect.
Below is the print_r result of the wp_upload_dir() function:
{{{
Array
(
[path] => C:\xampp\htdocs\test/wp-content/uploads/2020/03
[url] => http://localhost/jan/wp-content/uploads/2020/03
[subdir] => /2020/03
[basedir] => C:\xampp\htdocs\test/wp-content/uploads
[baseurl] => http://localhost/jan/wp-content/uploads
[error] =>
)
}}}
As soon as the path enters in the WordPress directory, backslashes are converted to front slashes.",amitkumarsingh
Tickets Awaiting Review,49725,Bug in plugin upload,,Upload,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-03-29T07:47:29Z,2020-03-30T07:54:45Z,"bug in wordpress version 5.3.2
how to exploit:
1. download wordpress and run into localhost.
2. trying to upload plugin than they are showing here only upload .zip file.
3. but we are trying to upload .php shell file.
4. now see file is upload successfully in database.
",offensive
Tickets Awaiting Review,50098,CSVs that contain HTML fail upload test,,Upload,,normal,normal,Awaiting Review,defect (bug),new,,2020-05-06T06:42:45Z,2020-05-06T06:42:45Z,"WordPress 5.0.1 (I believe) introduced file type checking so that uploaded files needed to be the correct MIME type for its extension. This caused CSVs detected as `text/plain` to fail the upload test. WordPress 5.0.3 fixed this so that .csv files can be uploaded if detected as `text/plain` (#45615, [44443]).
However, in trying to uploaded CSVs exported from WooCommerce, I have encountered CSVs that are detected as `text/html` if they have enough HTML in the product descriptions. So these files exported from WooCommerce cannot be re-uploaded to WooCommerce.
I have worked around the issue using the `wp_check_filetype_and_ext` filter, but ideally a similar carve-out for `text/plain` would be made for `text/html`.
I don't have time to write a patch right now, but I might be able to take a crack at it later this week/next week if no one else can.
For reference, this is how I bypassed the issue with the filter:
{{{
add_filter(
'wp_check_filetype_and_ext',
function( $wp_check_filetype_and_ext, $file, $filename, $mimes, $real_mime ) {
$wp_filetype = wp_check_filetype( $filename );
if ( 'text/html' === $real_mime && 'text/csv' === $wp_filetype['type'] ) {
$wp_check_filetype_and_ext = [
'ext' => $wp_filetype['ext'],
'type' => $wp_filetype['type'],
'proper_filename' => $filename,
];
}
return $wp_check_filetype_and_ext;
},
10,
5,
);
}}}",JakePT
Tickets Awaiting Review,50136,Files types not included in Upload file types are allowed to be uploaded because of loose file extension check,,Upload,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2020-05-09T14:27:00Z,2024-02-24T23:22:45Z,"A loose file-extension check in WordPress allows an extended number of file-types to be uploaded despite not be mentioned in Upload file types setting in a multisite.
This happens because the condition to check the file extensions passes even if part of the extension passes. ([https://github.com/WordPress/WordPress/blob/cad04902d6a162ba8320f82a6c65c7eb58cf9759/wp-includes/ms-functions.php#L1814 Code Link])
Steps To Reproduce:
On a WordPress Multisite -
1. Navigate to the Network settings, Add file type tx to the setting Upload file types
2. On any sub-sites, try to upload a .txt file and it should be uploaded.
3. Any file extension has to match in just part with the extensions allowed in the network setting to be allowed to be uploaded.
For example - If you add `xls` file type files `xlsm`, `xlsx` ,`xlsb` etc. are allowed to be uploaded.",Nikschavan
Candidates for Closure,50188,Disable Media uploader if PHP file_uploads is disabled,,Upload,,normal,minor,Awaiting Review,enhancement,new,dev-feedback,2020-05-16T19:32:36Z,2024-01-24T09:26:51Z,"Based on ticket #50038, if the PHP configuration is {{{file_uploads = Off}}} we should disable the Media upload.
Actually, when you upload a file and the file_uploads is disabled, WordPress uploads the file with a progress bar and, at the end, it gives an error because is disabled.
This should affect the Media upload, probably it should tell something like ""You can't upload a file, please check the Site Health for more information"" (or something like that) but also, in any file upload (like the Image / Video / Audio on Gutenberg) should allow to pick from the media but not show the upload button, also the plugin / theme upload.",JavierCasares
Tickets Awaiting Review,51789,Add system filesize resource limit to wp_max_upload_size function,,Upload,,normal,normal,Awaiting Review,enhancement,new,,2020-11-16T16:43:42Z,2020-11-18T19:44:38Z,"A file will that is smaller than `wp_max_upload_size` but larger than the soft filesize resource limit will not upload successfully.
[https://www.php.net/manual/en/function.posix-getrlimit.php posix_getrlimit] will return system resource limits.
`wp_max_upload_size` function should return the minimum of `upload_max_filesize`, `post_max_size`, and `posix_getrlimit()[soft filesize]`.
",yani.iliev
Tickets Awaiting Review,52531,Unable to upload .ico with PHP 7.4,,Upload,5.6.1,normal,normal,Awaiting Review,defect (bug),new,has-patch,2021-02-15T16:41:43Z,2021-08-09T16:40:24Z,"Hello,
I found the following related ticket: #11824
You can find attached an example file.
On PHP 7.3.21 libmagic is shown as 533 in phpinfo under ""fileinfo"" section.
On PHP 7.4.9 libmagic is shown as 537 in phpinfo under ""fileinfo"" section.
I tried to upload the same file as an admin on a fresh WP install on both versions on PHP, and it works with 7.3 while it doesn't with 7.4.
The error is ""Sorry, this file type is not permitted for security reasons."".
What I found is that `finfo_file` function returns either ""image/x-icon"" or ""image/vnd.microsoft.icon"" depending on the PHP version I'm using.
In the first case, this will be allowed because it matches WP's internal mime types array. But in the second case, it will simply return an invalid type error (empty `$type` and `$ext` variables).
I used the following workaround:
{{{#!php
$media_title,
'tmp_name' => $tmp_name,
);
try {
$media_id = media_handle_sideload(
$file, 0, null, array(
'post_author' => 0,
'post_name' => sanitize_title( $media_title ),
)
);
} catch ( \Exception $e ) {
error_log( print_r( $e, true ) );
}
if ( is_wp_error( $media_id ) ) {
error_log( print_r( $tmp_name, true ) );
}
}
}}}
=== Testing
I've tried to test adding these `error_log` lines into method `pdf_load_source` of class `WP_Image_Editor_Imagick` (file `wp-includes/class-wp-image-editor-imagick.php`)
{{{#!php
pdf_setup();
error_log( ""Filename: "" . print_r( $filename, true ) );
if ( is_wp_error( $filename ) ) {
return $filename;
}
try {
error_log( ""Trying with "" . print_r( $this->image, true ) );
// When generating thumbnails from cropped PDF pages, Imagemagick uses the uncropped
// area (resulting in unnecessary whitespace) unless the following option is set.
$this->image->setOption( 'pdf:use-cropbox', true );
error_log( ""Option use cropbox true"" );
// Reading image after Imagick instantiation because `setResolution`
// only applies correctly before the image is read.
$this->image->readImage( $filename );
error_log( ""Image read tried"" );
} catch ( Exception $e ) {
error_log( ""Catched"" );
// Attempt to run `gs` without the `use-cropbox` option. See #48853.
$this->image->setOption( 'pdf:use-cropbox', false );
error_log( ""Option use cropbox false"" . print_r( '', true ) );
$this->image->readImage( $filename );
error_log( ""Image read"" . print_r( '', true ) );
}
return true;
}
// ...
}
}}}
with this result in `debug.log`:
{{{
[23-Mar-2022 14:36:23 UTC] Into pdf_load_source
[23-Mar-2022 14:36:23 UTC] Filename: //wp-content/uploads/2022/03/Product-XXXXX-FilamentClear_2018-1.pdf[0]
[23-Mar-2022 14:36:23 UTC] Trying with Imagick Object
(
)
[23-Mar-2022 14:36:23 UTC] Option use cropbox true
}}}
And none of the following `error_log` prints coming after this last line.
=== Other details
* This happens with some pdf files (the one from the url in the code being one of them)
* I've tried changing php version to the latest 8.1, but the issue persists
",alceomazza
Tickets Awaiting Review,55635,"wp_convert_hr_to_bytes() report correct byte sizes for php.ini ""shorthand"" values",,Upload,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-04-27T21:43:16Z,2022-09-14T23:16:00Z,"Resolves #17725
When `wp_convert_hr_to_bytes()` was introduced in [4388] it provided a simplified mechanism to parse the values returned by functions like `ini_get()` which represent byte sizes. The over-simplified approach has led to issues in that function reporting the wrong byte sizes for various php.ini directives, leading to confusing problems such as uploading files that are rejected improperly or accepted improperly.
In this patch we're porting the parser from PHP's own source (which has remained stable for decades and probably can't change without major breakage) in order to more accurately reflect the values it uses when it reads those configurations.
Unfortunately PHP doesn't offer a mechanism to read its own internal value for these fields and a 100% port is extremely cumbersome (at best) due to the different ways that PHP and C handle signed integer overflow. These differences should only appear when supplying discouraged/invalid values to the system anyway, and PHP warns that in these situations things are likely to break anyway.
Over the years this function has been modified a couple of times in ways that this patch reverts:
- [38013] introduced a `PHP_INT_MAX` limit in a way that coerces hexadecimal and octal integer representations to decimal.
- [35325] replaced the hard-coded byte size with overwritable constants but if there were any occasion for someone to change those constants in `wp-config.php` then we would actually want to preserve the hard-coded values in `wp_convert_hr_to_bytes()` since that function refers to code inside of PHP, not inside of WordPress.
- The original code from [4388] looks for the presence of the suffixes //anywhere// within the value string and prioritizes `g` over `m` over `k` whereas PHP only looks at the last character in the input string (this is something that [https://core.trac.wordpress.org/attachment/ticket/17725/17725.3.diff 17725.3.diff] got right). This can cause unexpected parses, such as with `14gmk` when WordPress interprets it as 14GiB but PHP interprets it as 14KiB.
Further we do acknowledge the mismatch between PHP's definition of ""gigabyte""/""megabyte""/""kilobyte"" being factors of 1024 apart from each other and the standard of being 1000. WordPress follows PHP's convention so this is simply noted in the function and preserved.
This patch introduces new behaviors which might seem unexpected or wrong. It's important to consider that this function exists because PHP doesn't expose the values it parses from the php.ini directives. Therefore it's job in WordPress can be considered to do as best as it can to represent what's really happening inside of PHP; this may not match our intuition about what PHP should be doing. To that end the over-simplified code for the past 16 years has misreported many plausible-looking values like `100MB` (which PHP interprets as 100 bytes but WordPress thinks is 100 MiB).
**Testing**
In order to fully verify the updated code we have to understand PHP's interpretation of the php.ini directive values. One way to do this is to set a value, `upload_max_size` for instance, in any number of the possible configurable places and then make repeated uploads to see if it's rightfully accepted or rejected. This is cumbersome.
An alternative approach is to compile PHP locally with added instrumentation; this is the approach taken in preparing this PR. The following patch will report three values every time a ""Long"" value is parsed from a php.ini directive: the shorthand value being parsed, the bound `long` value before applying the magnitude suffix, and the possibly-overflowed value derived from applying the possible `g`, `m`, and `k` suffixes.
{{{#!diff
diff --git a/Zend/zend_operators.c b/Zend/zend_operators.c
index 8a0cc813..362cef76 100644
--- a/Zend/zend_operators.c
+++ b/Zend/zend_operators.c
@@ -164,6 +164,9 @@ ZEND_API zend_long ZEND_FASTCALL zend_atol(const char *str, size_t str_len) /* {
break;
}
}
+
+ printf(""zend_atol( \""%s\"" ) = %lld : %lld\n"", str, ZEND_STRTOL(str, NULL, 0), retval);
+
return (zend_long) retval;
}
/* }}} */
}}}
For example, a sampling of values run through PHP produces this output.
{{{#!bash
zend_atol( ""0"" ) = 0 : 0
zend_atol( ""0g"" ) = 0 : 0
zend_atol( ""1g"" ) = 1 : 1073741824
zend_atol( ""3G"" ) = 3 : 3221225472
zend_atol( ""3mg"" ) = 3 : 3221225472
zend_atol( ""3km"" ) = 3 : 3145728
zend_atol( ""boat"" ) = 0 : 0
zend_atol( ""-14k"" ) = -14 : -14336
zend_atol( ""-14chairsg"" ) = -14 : -15032385536
zend_atol( ""9223372036854775807"" ) = 9223372036854775807 : 9223372036854775807
zend_atol( ""9223372036854775807g"" ) = 9223372036854775807 : -1073741824
zend_atol( ""9223372036854775808"" ) = 9223372036854775807 : 9223372036854775807
zend_atol( ""0xt"" ) = 0 : 0
zend_atol( ""0x5teak_and_egg"" ) = 5 : 5368709120
}}}",dmsnell
Candidates for Closure,57764,MYSQL operations excessive CPU consumption issue.,,Upload,6.1.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2023-02-18T14:32:17Z,2023-02-20T02:11:17Z,"Hello,
There is very excessive CPU consumption in MYSQL process on our site. When we check this via Show MYSQL proccess we encounter this query.
{{{
SELECT post_mime_type, COUNT( * ) AS num_posts FROM wp_posts WHERE post_type = 'attachment' AND post
}}}
I am waiting for your help to solve the problem.",Blogizma
Tickets Awaiting Review,58155,Add filter to allow large image scaling of PNGs,,Upload,5.3.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-04-18T21:01:22Z,2023-04-19T15:49:31Z,"Due to Issue #48736,large image downscaling of PNGs is disabled because sometimes the new images are larger in filesize than the originals (particularly with PNG-8).
This is reasonable but should be filterable with the current state as the default.
There are use cases where users rarely, if ever, upload PNG-8s but do upload massive PNG-24s that would benefit from downscaling. Devs should be able to turn this feature on for PNGs as needed. ",pelstudio
Tickets Awaiting Review,58243,WordPress 6.2 duplicating images on upload,,Upload,6.2,normal,normal,Awaiting Review,defect (bug),reopened,,2023-05-03T13:09:07Z,2023-05-04T13:51:03Z,"Wordpress 6.2 seems to have an issue with the uploads of large images. It duplicates or even triplicates the same uploaded image (appending the usual -1, -2 to the name of the file).
This happens both in the new post screen and the library section. When the same image is replicated, only the last one is really ""processed"" (e.g. thumbnails and ""-scaled"" version generated). Just as note, I tried turning off the generation of the scaled version with no luck.
The issue presented itself on a production site after upgrading to 6.2 and I can confirm that rolling back to WP 6.1 ""resolved"" it. I successfully replicated the same issue on a freshly deployed 6.2 installation.
I'm attaching the test image used to replicate the issue.
Server info:
`
### wp-core ###
version: 6.2
site_language: en_US
user_language: en_US
timezone: +00:00
permalink: /%postname%/
https_status: false
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: open
environment_type: production
user_count: 1
dotorg_communication: true
### wp-paths-sizes ###
wordpress_path: /home/runcloud/webapps/app-ondricka
wordpress_size: 50.25 MB (52685903 bytes)
uploads_path: /wp-content/uploads
uploads_size: 130.27 MB (136601927 bytes)
themes_path: /wp-content/themes
themes_size: 12.35 MB (12951623 bytes)
plugins_path: /wp-content/plugins
plugins_size: 3.23 MB (3390376 bytes)
database_size: 2.30 MB (2408448 bytes)
total_size: 198.40 MB (208038277 bytes)
### wp-active-theme ###
name: Twenty Twenty-Three (twentytwentythree)
version: 1.1
author: the WordPress team
author_website: https://wordpress.org
parent_theme: none
theme_features: core-block-patterns, post-thumbnails, responsive-embeds, editor-styles, html5, automatic-feed-links, block-templates, widgets-block-editor
theme_path: /wp-content/themes/twentytwentythree
auto_update: Disabled
### wp-themes-inactive (2) ###
Twenty Twenty-One: version: 1.8, author: the WordPress team, Auto-updates disabled
Twenty Twenty-Two: version: 1.4, author: the WordPress team, Auto-updates disabled
### wp-plugins-inactive (3) ###
Akismet Anti-Spam: version: 5.1, author: Automattic, Auto-updates disabled
Hello Dolly: version: 1.7.2, author: Matt Mullenweg, Auto-updates disabled
LiteSpeed Cache: version: 5.4, author: LiteSpeed Technologies, Auto-updates disabled
### wp-media ###
image_editor: WP_Image_Editor_Imagick
imagick_module_version: 1690
imagemagick_version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
imagick_version: 3.7.0
file_uploads: File uploads is turned off
post_max_size: 256M
upload_max_filesize: 256M
max_effective_size: 256 MB
max_file_uploads: 20
imagick_limits:
imagick::RESOURCETYPE_AREA: 122 MB
imagick::RESOURCETYPE_DISK: 1073741824
imagick::RESOURCETYPE_FILE: 786432
imagick::RESOURCETYPE_MAP: 512 MB
imagick::RESOURCETYPE_MEMORY: 256 MB
imagick::RESOURCETYPE_THREAD: 1
imagick::RESOURCETYPE_TIME: 1.844674407371E+19
imagemagick_file_formats: 3FR, 3G2, 3GP, AAI, AI, ART, ARW, AVI, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DNG, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, H, HALD, HDR, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, JBG, JBIG, JNG, JNX, JPE, JPEG, JPG, JPS, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPEG, MPG, MRW, MSL, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIFF, VIPS, VST, WBMP, WEBP, WMV, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV
gd_version: bundled (2.1.0 compatible)
gd_formats: GIF, JPEG, PNG, WebP, BMP, XPM
ghostscript_version: 9.50
### wp-server ###
server_architecture: Linux 5.15.0-58-generic x86_64
httpd_software: LiteSpeed
php_version: 7.4.33 64bit
php_sapi: litespeed
max_input_variables: 1000
time_limit: 30
memory_limit: 256M
max_input_time: 60
upload_max_filesize: 256M
php_post_max_size: 256M
curl_version: 7.68.0 OpenSSL/1.1.1f
suhosin: false
imagick_availability: true
pretty_permalinks: true
htaccess_extra_rules: true
### wp-database ###
extension: mysqli
server_version: 10.4.28-MariaDB-1:10.4.28+maria~ubu2004-log
client_version: mysqlnd 7.4.33
max_allowed_packet: 16777216
max_connections: 100
### wp-constants ###
WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /wp-content
WP_PLUGIN_DIR: /wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG: false
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Undefined
DB_CHARSET: utf8
DB_COLLATE: undefined
### wp-filesystem ###
wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
`",cptjump
Candidates for Closure,58306,File extension restriction revoke,,Upload,,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2023-05-14T10:49:54Z,2023-05-14T20:17:34Z,"Hallo,
this is 2023, packing items into zip item for downloadable content is normal. Can we please revoke this weird function so the end-user can devicde what they want to allow or not, and not end-up looking for weird plugins to install or documents about tampering the config.php, yes?
[[Image()]]",teevee98
Tickets Awaiting Review,58513,Uploading JSON file of 1MB or less fails to upload,,Upload,6.2.2,normal,normal,Awaiting Review,defect (bug),new,,2023-06-12T11:21:01Z,2023-06-12T11:25:04Z,"When uploading a JSON file of exactly 1048577 bytes or less leads to:
{filename} has failed to upload.
Sorry, you are not allowed to upload this file type.
Even though the file type is allowed. Tested with JSON file of valid JSON of 1048578 bytes (success) and 1048577 byes (failure).",oliward@…
Tickets Awaiting Review,58787,when upload it multi upload duplicate the files in the media,,Upload,6.2.2,normal,normal,Awaiting Review,defect (bug),new,,2023-07-11T21:56:53Z,2023-10-30T19:36:30Z,"{{{
$attachment_id->get_error_message());
} else {
// The file was uploaded successfully
$response = array('success' => 'File uploaded successfully with attachment ID ' . $attachment_id);
}
} else {
// No file was selected
$response = array('error' => 'No file selected.');
}
// Send the response back to the client-side script
echo json_encode($response);
}
// IMPORTANT: Don't forget to exit at the end of your callback function
exit;
}
?>
}}}",wasimo
Tickets Awaiting Review,59097,Upload via link,,Upload,6.3,normal,minor,Awaiting Review,feature request,new,,2023-08-13T20:47:24Z,2023-08-14T14:13:45Z,"In the media part of the admin panel, add a way to upload files by pasting in the link",thedustry
Unpatched Bugs,59329,"Firefox gets ""ReferenceError: Â is not defined"" in unminified moxie.js",,Upload,,normal,minor,,defect (bug),new,close,2023-09-12T13:04:50Z,2023-11-04T09:36:22Z,"In unminified moxie.js, there exists some weird Unicode characters on line 7391, between the BinaryReader constructor fn and the call to Basic.extend(). In a hex editor, you can see the character bytes are ""C2A0"", which is a random Korean Hangul character in Unicode.
In Firefox (as of the latest 117), when using Divi, this causes an exception when loading unminified moxie.js. Firefox's Js loader interprets the first byte alone as Â, and fails while loading moxie.js.
I can replicate this in FF+Divi, but the problem does not appear in Chrome, Safari, or in FF when using other builders like Classic/Gutenberg/Elementor/Beaver. Minification strips out the problem bytes.
This link, https://stackoverflow.com/a/1462039/1201409, suggests the error is leftover from an earlier era of encoding a nonbreaking space before UTF-8 replaced other encodings.
Regardless of how the bytes got in there (and whether FF/Divi have bugs), they shouldn't be there, and luckily, the fix is trivial: delete them.",kinggmobb
Tickets Awaiting Review,59564,Not showing uploaded media in theme,,Upload,6.3.2,normal,critical,Awaiting Review,defect (bug),new,,2023-10-08T16:11:23Z,2024-02-08T15:06:26Z,"When user want login facing issue with wp admin area login please check attached screenshot with issue details and with uploaded media is not showing in theme
Login Screenshot - [https://ibb.co/BPV3Qsr]
Media Screenshot - [https://ibb.co/hCpS1Mn]",vipalok2023
Slated for Next Release,60398,"WordPress 6.4.3 MacOS/Linux Compressed Zip plugin archives ""Incompatible Archive"" on upload",peterwilsoncc,Upload,6.4.3,normal,normal,6.4.4,defect (bug),reopened,commit,2024-01-31T11:42:20Z,2024-03-20T20:52:58Z,"If I zip a plugin folder using MacOS right-click Compress command in the contextual menu, those archives are no longer accepted when using upload plugin. It returns ""Incompatible Archive"". This has worked up until now. Probably related to recent security updates for the plugin and theme uploader.
If I create a zip on the command line of the same folder that works correctly.",Endymion00
Slated for Next Release,60835,Fix and improve handling of uploading of font files,,Upload,,normal,normal,6.6,defect (bug),new,,2024-03-24T20:04:05Z,2024-03-24T23:12:22Z,"Follow up to #60652 and [57868].
As discussed at https://github.com/WordPress/wordpress-develop/pull/6211 the code that enables uploading of font files by replacing the output of `wp_handle_upload()` by using the `upload_dir` filter is not the best solution. In addition it implements nested filters that can be pretty confusing so understand and/or use for plugin and theme authors.
A more straightforward solution is needed for this and similar cases in the future.",azaozz