__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,20070,Deprecate Blogger XML-RPC Methods,,XML-RPC,3.3,normal,normal,Future Release,enhancement,new,dev-feedback,2012-02-18T18:32:26Z,2020-09-21T19:41:58Z,"The XML-RPC API supports the legacy Blogger API methods, but these methods have apparently not been very well tested or maintained.
Given that the `wp.*` XML-RPC namespace now covers everything that the Blogger API does, I suggest the blogger methods be officially deprecated with an eye towards removing them in a future version.
At the very least, the MetaWeblog API should be used by clients instead, as it was explicitly designed to enhance and supersede the Blogger API.",maxcutler
Future Releases,36030,Expose site icon on wp.getUsersBlogs,,XML-RPC,,normal,normal,Future Release,enhancement,new,needs-unit-tests,2016-03-01T09:06:46Z,2019-06-20T14:07:35Z,"WordPress 4.3 has added the ability for site owners to manage their site’s favicon, but never exposed it over the XML-RPC protocol.
It's useful for XML-RPC clients to receive it back in the response of wp.getUsersBlogs, so they can show the proper icon beside the name of the site.
In the patch I've provided an empty value is returned if site_icon is not set on the blog. I've avoided returning a default value, since it's better to leave this responsibility to clients. If siteIcon is empty, the client should show their default icon, or nothing.",daniloercoli
Future Releases,37096,Unit tests for xmlrpc_getposttitle() and xmlrpc_getpostcategory() along with patch to trim and unique returned values,SergeyBiryukov,XML-RPC,0.71,low,minor,Future Release,enhancement,reviewing,dev-feedback,2016-06-14T00:24:25Z,2022-01-20T13:01:43Z,In tonight's Contrib 2 core we created this unit test for xmlrpc_getposttitle() function,pbearne
Future Releases,35993,Unit tests: XML-RPC Request routines,,XML-RPC,0.71,normal,normal,Future Release,enhancement,new,dev-feedback,2016-02-29T01:07:36Z,2022-01-20T13:01:43Z,"I wrote unit tests for the 3 methods regards to XML-RPC request in functions.php, the aim is improve de code coverage, theses methods are:
* xmlrpc_getposttitle()
* xmlrpc_getpostcategory()
* xmlrpc_removepostdata()
This patch cover 100% of coverage related to theses methods above.
Only one thing to consider, I didn't found any XML-RPC format on the WordPress doc with title and category, so I've created a simple XML format with both, following the methods the behaviour is the same.",borgesbruno
Future Releases,23020,wp.getPageList should act like wp.getPages,,XML-RPC,2.2,normal,normal,,defect (bug),new,dev-feedback,2012-12-20T13:47:13Z,2019-06-05T06:39:01Z,"I know that wp.getPageList is obsolete, but I think it should act like wp.getPages At the moment wp.getPageList returns even the trashed pages and doesn't return the status of the page.
The weird behavior i've seen with wp.getPageList on a third-party client is shown below:
- Refresh the pages list.
- The Page 'A' is in the list.
- Select the page 'A' and delete it.
- Refresh the pages list and the page is still there. Doh!",daniloercoli
Future Releases,23866,WordPress xmlrpc wp_getPosts filter for slug,,XML-RPC,3.4,normal,normal,,enhancement,new,dev-feedback,2013-03-26T20:09:31Z,2019-06-05T06:39:12Z,"When using the Wordpress xmlrpc, it is sometimes very useful to get posts based off of slugs rather than post id.
A use case for this would be synchronizing or migrating two Wordpress sites with the same posts, but with different databases and post ID's.
",SunWaves
Future Releases,42998,Custom HTML Widget uses widget_text twice in markup,,Widgets,4.8.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2017-12-29T16:34:43Z,2019-01-14T22:33:01Z,"In https://core.trac.wordpress.org/changeset/41117, classes were added to the Custom HTML Widget to apply the same styling as the Text Widget in themes.
However, there's an extra widget_text class that isn't in the Text Widget.
Example markup:
Custom HTML widget - The widget_text is on the section and the widget-wrap div.
{{{
Text Widget ContentCustom HTML
Text Widget
'; 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 Future Releases,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 Future Releases,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 Future Releases,54078,Underscore appended to media file on upload,,Upload,5.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-09-06T14:02:07Z,2021-09-07T14:35:04Z,"I noticed that a random underscore is appended to media files, when uploading them in an article. Im using the Classic Editor. The original file name was: **AB-LET.2018.133.AXH1.jpg** Once uploaded, it became: **AB-LET.2018.133.AXH1_.jpg** There was no prior file uploaded with that name (at least the media gallery does not find any).",spielautomat4 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,55635,"wp_convert_hr_to_bytes() report correct byte sizes for php.ini ""shorthand"" values",,Upload,,normal,normal,Awaiting Review,defect (bug),new,changes-requested,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,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 Future Releases,38481,wp_handle_upload_prefilter not used before deriving attachment title,,Upload,4.6.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2016-10-25T08:30:18Z,2019-03-26T21:28:44Z,"I created a module that modifies upload behavior. I use the wp_handle_upload_prefilter to alter the $_FILES data - specifically the 'name' property of the uploaded file. This works well for changing the name of the file being stored in the file system, but the title of the attachment post still accesses the $_FILES['async-upload']['name'] on line 281 of media.php. To be able to override the title, I had to hook into the 'sanitize_title' filter on line 293 of media.php - and doing that is, in my book, a hack. This sanitize_title filter should specify a context.",frodeborli Future Releases,38936,Alter Table Always Expects a COLUMN; Crashes on a CONSTRAINT,,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-11-24T17:25:13Z,2022-12-16T08:17:47Z,"Hello, I'm attempting to activate a plugin I'm developing. The database creation scripts have CONSTRAINTs on them. When I attempt to reactivate, I'm getting this error: {{{ WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONSTRAINT `mytable_mycol_foreign` FOREIGN KEY (`mycol' at line 1] ALTER TABLE wp_mytable ADD COLUMN CONSTRAINT `mytable_mycol_foreign` FOREIGN KEY (`mycol`) REFERENCES `myothertable` (`myothercol`) }}} As you can see the SQL error lies in `ADD COLUMN CONSTRAINT`. This is being generated in `wp-admin/includes/upgrade.php` around line 2392 {{{#!php $fielddef) { // Push a query line into $cqueries that adds the field to that table. $cqueries[] = ""ALTER TABLE {$table} ADD COLUMN $fielddef""; $for_update[$table.'.'.$fieldname] = 'Added column '.$table.'.'.$fieldname; } }}} `ADD COLUMN` is hardcoded and is creating this SQL error. I googled for a solution but didn't find anything. I've tried it with the constraints being part of the full table creation statement, and also as a stand alone statement, with the same results. ",philsown Future Releases,46292,"Bump `set_time_limit()` at the start of the update process, instead of mid-way.",,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-02-21T02:23:37Z,2022-12-15T21:44:11Z,"Currently WordPress calls `set_time_limit( 300 )` before it installs an update, however it calls this at the point between unzipping the files, and copying them into place. For plugins/themes/translations/etc it's [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-upgrader.php?marks=466#L447 this call] for core it's [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update-core.php?marks=882#L869 this one]. This, combined with the much higher core package sizes (More than doubled since 3.7) results in some people hitting the default php execution cap of 30 seconds during the download phase when testing locally (For example, 11MB @ 2.5mbit/s = 35 seconds). To make it more 'annoying', The `core_upgrader` Lock is put in place before the package is downloaded, so if they run into the timeout during downloading, the lock will still be in place in `wp_options` for 15 minutes. `set_time_limit` should be set at the start of the process, likely at the point of the locks being created, before downloads have begun.",dd32 Future Releases,56713,Check ACL permission before upgrading,,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-10-02T08:22:01Z,2022-10-17T00:37:51Z,"I am using ACL to define permissions of files and folder of my wordpress installation, but when I upgrade my wordpress installation using web ui tool, I am getting the following error: {{{ Warning: chmod(): Operation not permitted in /home/my-website/wp-admin/includes/class-wp-filesystem-direct.php on line 173 }}} Then the upgrade is stuck in an invalid state and I have to upgrade it manually. Wordpress upgrade program should check all its abilities before trying to upgrade and it should handle the case of using ACL for permissions. All permissions are good, it's just using ACL instead of MOD. The is the third upgrade I am experiencing this issue.",Cartman34 Future Releases,53298,Checking if wp-config-sample.php file exists before checking if wp-config.php exists,,Upgrade/Install,5.7.2,normal,trivial,Awaiting Review,defect (bug),new,dev-feedback,2021-05-29T20:34:43Z,2023-07-12T06:17:11Z,"Currently in WordPress core, wp-admin/setup-config.php checks if wp-config-sample.php file exists before checking if wp-config.php exists. If the sample file exists, it then checks if the wp-config.php file exists, and if so, suggests deletion if necessary. For security, some WordPress users may delete the sample file, and restrict open_basedir for directory above that of the web root directory. Because of these two cases, the current order produces the follow error: `PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/example/wp-config-sample.php) is not within the allowed path(s): (/var/www/example/web:/var/www/example/private:/var/www/example/tmp:/tmp:...) in /var/www/example/web/wp-admin/setup-config.php on line 46` If the check for existence of sample file could be moved after checking if wp-config.php exists, we could avoid this error and avoid checking if sample file exists if wp-config.php does and not checking both if they both do. i.e. Moving the section commented `Support wp-config-sample.php one level up, for the develop repo.` to after the section commented `Check if wp-config.php exists above the root directory but is not part of another installation.` in `wp-admin/setup-config.php`",machineitsvcs Future Releases,56431,Fatal Error on Update Page When a Plugin's Icon is Not Set,,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-08-24T17:04:02Z,2024-02-28T20:06:23Z,"When on the Dashboard > Updates page, if there is a plugin whose icon is not set, a fatal error is generated, and no plugins are listed in the update section. `PHP Fatal error: Uncaught Error: Cannot use object of type stdClass as array in /wp-admin/update-core.php:509` I have often seen this with plugins that are not hosted on wordpress.org. Mostly this is when you have a paid plugin that doesn't have an icon set. I think the fix should be as follows: `wp-admin/update-core.php` line 509: `if ( ! empty( $plugin_data->update->icons[ $preferred_icon ] ) ) {` should change to: `if ( is_array( $plugin_data->update->icons ) && ! empty( $plugin_data->update->icons[ $preferred_icon ] ) ) {` ",scott.deluzio Future Releases,54546,Fatal error receive while updating WP 5.8.2 to WP 5.9.,,Upgrade/Install,5.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2021-12-01T06:07:41Z,2022-08-30T10:11:49Z,"After updating to 5.9-beta1 via the [https://wordpress.org/plugins/wordpress-beta-tester/ Beta Tester plugin], I got the below error https://content.screencast.com/users/ApekshaShah/folders/Capture/media/8b2bed1a-ca74-4ebc-83c0-c2bb7d0c0eb3/LWR_Recording.png {{{ Fatal error: Uncaught Error: Class 'Requests_Exception' not found in C:\Users\User\Local Sites\first-localhost\app\public\wp-includes\Requests\Transport\cURL.php on line 443 }}} I also updated a few other sites on my local machine and I'm getting that error on the other sites. Full information: {{{ Unpacking the update... Verifying the unpacked files... Preparing to install the latest version... Enabling Maintenance mode... Copying the required files... Disabling Maintenance mode... Upgrading database... Fatal error: Uncaught Error: Class 'Requests_Exception' not found in C:\Users\User\Local Sites\first-localhost\app\public\wp-includes\Requests\Transport\cURL.php on line 443 Error: Class 'Requests_Exception' not found in C:\Users\User\Local Sites\first-localhost\app\public\wp-includes\Requests\Transport\cURL.php on line 443 }}} Call Stack: ||= # =||= Function =||= Location =|| || 1 || `{main}{}` || ..\update-core.php:0 || || 2 || `do_core_upgrade()` || ..\update-core.php:1106 || || 3 || `Core_Upgrader->upgrade()` || ..\update-core.php:887 || || 4 || `update_core()` || ..\class-core-upgrader.php:172 || || 5 || `wp_remote_post()` || ..\update-core.php:1409 || || 6 || `WP_Http->post()` || ..\http.php:179 || || 7 || `WP_Http->request()` || ..\http.php:608 || || 8 || `Requests->request()` || ..\class-http.php:394 || || 9 || `Requests_Transport_cURL->request()` || ..\class-requests.php:381 || || 10 || `Requests_Transport_cURL->process_response()` || ..\cURL.php:179 ||",apeksha10 Future Releases,60694,INDEX command denied to user 'wordpress'@'localhost' for table 'wp_trp_dictionary_bg_bg_en_us',,Upgrade/Install,6.4.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2024-03-05T15:14:32Z,2024-03-05T15:14:32Z,"Fresh install of Version 6.4.3. The only active plugin is TranslatePress - Multilingual Version 2.7.2 (Akismet and Hello Dolly are installed but not active). Loggin in as admin, the following error is displayed: INDEX command denied to user 'wordpress'@'localhost' for table 'wp_trp_dictionary_bg_bg_en_us'. phpMyAdmin shows that the wordpress user does not have the 'INDEX' privilege. Is there a reason why the INDEX privilege not be enabled for the wordpress database user?",4x4ever Future Releases,60397,Invalidate opcache after theme / plugin updates,seebeen,Upgrade/Install,6.4.2,normal,normal,Awaiting Review,defect (bug),assigned,dev-feedback,2024-01-31T10:10:01Z,2024-01-31T12:29:13Z,"Depending on the server opcache configuration, there is a high possibility of getting an Internal Server Error, or similar after updating a plugin / theme. Specific opchache settings I've verified that trigger the error are: {{{ [opcache] opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=24 opcache.max_accelerated_files=130987 opcache.max_wasted_percentage=2 opcache.use_cwd=1 opcache.validate_timestamps=1 opcache.revalidate_freq=5 opcache.revalidate_path=0 opcache.save_comments=1 opcache.enable_file_override=1 }}} Error happens because validate_timestamps is set to 1 and revalidate_freq is greater than 0. This means that after plugin update, error 500 will stay for up to revalidate_freq seconds due to invalid opcache. This can be mitigated by adding a opcache_invalidate or opcache_reset call upon successful update.",seebeen Future Releases,42281,No Autoupdate for Translation files,,Upgrade/Install,4.8.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-10-19T17:48:13Z,2023-07-09T16:13:08Z,"Codex says: Automatic translation file updates are already enabled by default, the same as minor core updates. But still a button ""update translations"" is shown in the Update Dashboard. This is ridiculous as I a) have no influence on accepting or skipping a certain translation, because b) there is no presention of the upcoming translation updates in advance As we have PTE and GTE for QA autoupdate is the right choice for translation files. Pls consider to remove the ""update translations"" buttons and substitute it with a email message as per minor core updates. ",stk_jj Future Releases,22287,Plugin in another plugin folder causes Activate link to be wrong on Download,,Upgrade/Install,3.4,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2012-10-26T15:30:52Z,2020-09-17T21:35:15Z,"I am not sure if shipping a plugin within another plugin is officially supported, but there is an inconsistency between the activate links in the Manage Plugins page, and the Activate Plugin on the Plugin Downloaded success page. This is because on the Manage Plugins page, the `get_plugins()` is going to scan the plugins dir and all dirs within it, however, on the Upgrade page, it calls `get_plugins()` specifying the plugin dir as the base (see https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-upgrader.php#L579) That will cause the ""embedded"" plugin to be picked up, and if it's alphabetically above the main plugin file (presumably) see code comment "" //Assume the requested plugin is the first in the list""",joehoyle Future Releases,42008,Show warning that usernames can't be changed,,Upgrade/Install,,normal,minor,Future Release,defect (bug),reviewing,close,2017-09-27T16:10:48Z,2020-11-01T11:47:08Z,"When we install WordPress, it says ""Please provide the following information. Don't worry, you can always change these settings later."" But When we want to change username, WordPress does not allow. See screenshots.",rinkuyadav999 Future Releases,33909,The `home` option not equivalent to the WP_HOME constant value in multisite and single instance,,Upgrade/Install,3.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2015-09-17T07:41:18Z,2022-12-03T19:16:01Z,"Hi, for this issue, I'm running a multisite instance with custom WordPress and wp-content directory paths where I set the constants '''WP_SITEURL''' and '''WP_HOME''' values as follow: * WP_HOME: http://mydomain.com/ * WP_SITEURL: http://mydomain.com/cms (where WordPress is installed) All the process during the installation is working perfectly and the multisite instance is installed as expected...except when you click on the admin toolbar button '''Visit site''' for example. Here is the issue, the site URL is set as '''http://mydomain.com/cms''' where it should be '''http://mydomain.com'''. This issue is becoming a user experience issue because both URLs with and without the '''cms''' URI are working. But all anchor tags href attribute have the wrong value. When looking at the database '''wp_options''' table, we can see that both '''home''' and '''siteurl''' options have a value of '''http://mydomain.com/cms''' which should only be '''siteurl''' with this value. I'm filling this issue mainly for multisite because the anchor tags used to visit the site have the wrong value but note that even for single WordPress installation, the options values are wrong in the '''wp_options''' table. Both have the same value where only the '''siteurl''' should get '''cms''' URI in this example. But when you're on a single instance all anchor tags href attributes have the correct URL in order to visit the site where in multisite they are wrong. So there are 2 things to look at here probably: * First why the '''wp_options''' values are not equal to the set constants '''WP_HOME''' and '''WP_SITEURL'''? * Second, why in a single instance URLs are correct (even if values in the database are wrong) and not on multisite? Best regards",jlambe Future Releases,44596,Welcome page text is repetitive,,Upgrade/Install,,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-07-17T14:15:03Z,2019-02-01T16:29:25Z,"Right now, the WordPress ""Welcome"" page/tab currently repeats nearly the same text 7 times in a row. The pattern is basically: `Version %number% addressed %number% bugs. For more information, see %link%.` The repetition is exacerbated by there being 7 minor releases in the 4.9 major branch, but considering this page is the first thing people see after upgrading, I think this can be communicated better. Screenshot imminent.",johnjamesjacoby Future Releases,46582,WordPress Core Updates: 'Last updated' date not showing correctly,,Upgrade/Install,5.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-03-21T06:44:12Z,2019-03-21T10:33:52Z,"For the WordPress Core Updates the date for last search is constantly showing January 1st 1970. My WordPress version is 5.1.1 in Development Mode.",markustippner Future Releases,15134,WordPress should not try to remove themes or plugins recursively if the directory is a symlink,pbiron*,Upgrade/Install,,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2010-10-16T11:46:29Z,2023-07-05T18:13:59Z,"Consider the situation: there is a server with multiple WordPress blogs hosted in it. Some plugins are common for all/many blogs and to save several (hundreds in our case) megs of the disk space, shared plugins are stored somehwere else (say, /var/www/wp-plugins) and there are symbolic links to /var/www/wp-plugins/from /home/ /wp-content/plugins/ . The onwer of the blog (user1) may not know these details and wants to update one of the plugins (plugin1) using automatic update feature. WordPress will then try to remove /home/user1/wp-content/plugins/plugin1/ recursively although /home/user1/wp-content/plugins/plugin1 is a symlink to /var/www/wp-plugins/plugin1. The obvious solution is to add a check to the filesystem classes that checks if the file is a symlink and if so, remove symlink with unlink() instead of trying to follow it and remove everything it sees. The advantage of this approach is that if the user symlinks a plugin to other user's data, those data will not be removed by WordPress (this can be very good for those hosts where all users are served by the same Apache user etc). ",vladimir_kolesnikov Future Releases,47452,WordPress taking time to login and throwing time-out error on upgrading,,Upgrade/Install,5.2.1,normal,critical,Awaiting Review,defect (bug),new,dev-feedback,2019-06-01T07:08:56Z,2022-11-15T18:21:31Z,"**Description**: When new updates are available, I upgraded to the new version but after the upgrade successful, I still see the upgrade version and after that WordPress started working very slow. Any operation performed on the platform will take more time to load and sometimes it comes up with ""connection time out"" error too. **Steps to reproduce** 1. Check for update 2. update your WordPress version from your site to version 5.2.1 3. Route to the dashboard, where you will see update button to version 5.2.1 4. Perform any operation like (user info, plugin page, widget page) it takes time to load and sometimes it throws ""connection time out"". **System Info:** System: Windows, Linux Browser: Chrome 74.0.3729.131 (Official Build) (64-bit) ",kevintran094 Future Releases,59177,dbDelta doesn't handle changing the DEFAULT value of a column from NULL to '',,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-08-23T15:40:02Z,2023-09-05T17:33:33Z,"Shouldn't this be a strict comparison https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/upgrade.php#L3064? Otherwise that condition will be false and the column will remain unchanged. ",bogdanhapcayardicom Future Releases,56751,"Add wp_get_environment_type() to update.php checks (core, plugins, themes)",,Upgrade/Install,5.5,normal,normal,Awaiting Review,enhancement,new,needs-docs,2022-10-06T22:50:41Z,2022-10-07T00:54:39Z,"While researching #meta6511 I noticed when WordPress checks for updates to itself, plugins, or themes, it does not send to `api.wordpress.org` what type of environment that it is: {{{ array( 'local', 'development', 'staging', 'production', ) }}} These are filterable, too. A few community members have questioned (in that ticket, Slack, Twitter...) whether non-production sites have the potential to influence installation counts. If WordPress sent the environment type, it could be aggregated over time and used later to more accurately respond to that question, perhaps even reported back if it is eventually deemed useful or actionable. I can imagine it being useful to myself, so I'm making this ticket to suggest it. I am choosing version 5.5 because that is when environment types were added.",johnjamesjacoby Future Releases,31744,"All PHP files in the root should be dummy files, pointing to wp-includes versions",,Upgrade/Install,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2015-03-24T01:25:03Z,2017-02-06T12:33:46Z,"I'm proposing that all of our PHP files in the WordPress root should be moved to `wp-includes`, and dummy versions put in the root that include the `wp-includes` versions of them. This will make things cleaner, and will open the door for us to do things like install a new version of WordPress in `wp-includes-8fb24cd9`, and pass a `?use-wp-includes=8fb24cd9` switch that loads that version. We could test the updated version of WordPress without touching the old version, and if it fails (WSOD, etc), we don't even have to roll back, because we haven't put the new version in `wp-includes` yet.",markjaquith Future Releases,48937,Auto-refresh maintenance mode screen,,Upgrade/Install,,normal,normal,Future Release,enhancement,new,dev-feedback,2019-12-11T15:35:48Z,2022-08-08T07:48:44Z,"''I [https://wordpress.org/support/topic/feature-request-with-solution-auto-refresh-maintenance-mode-screen/ already posted this] on the community forums, and was advised to post here instead.'' While WordPress updates a theme, a plugin or its core, it conveniently displays a message to any visitor: > Briefly unavailable for maintenance. Check back in a minute. Unfortunately, when presented with such a bland screen, most visitors will immediately leave and find a different website. If the visitor hasn’t disabled Javascript in his browser, it would be most helpful to make this a little more informative and add some automation: > Briefly unavailable for maintenance. > This page will automatically load when it is available. Have the webpage automatically refresh the page every (say) 10 seconds. Obviously, if the user has disabled Javascript, you can only display the brief message. = Solution I’m not really a programmer, but I’ve taken the default WordPress method and modified it to do just this — see below. You are welcome to use it as is, or to use the ideas and code within, to implement this feature automatically. I have tested this and it seems to work perfectly. A programmer might find a better way to implement it than I have done. There is one problem with what I’ve done, and that is the lack of translation for other languages. I don’t know how to cater for that. Thank you = Revised contents I took the file /wp-content/maintenance.php and modified it as follows. All that I did was to add a Sorry… Briefly unavailable for scheduled maintenance.
Please try again in a minute.
Thank you for your patience.