__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter,Comments
Needs Dev / Bug Wrangler Feedback,28821,Admin page registered with add_menu_page() allows access through wrong URls and hightlights wrong top level menu item,,Administration,3.9.1,normal,normal,,defect (bug),new,dev-feedback,2014-07-10T21:05:19Z,2019-06-04T19:26:10Z,"'''Steps to reproduce:'''
* Add a top level admin menu page (with the plugin provided below).
* Access the new top level admin menu via the menu item (bottom of menu)
* Try to access it via one of the following URLs
{{{
http://example.com/wp-admin/options-general.php?page=trac
http://example.com/wp-admin/tools.php?page=trac
http://example.com/wp-admin/admin.php?page=trac
http://example.com/wp-admin/edit-comments.php?page=trac
http://example.com/wp-admin/edit.php?post_type=page&page=trac
http://example.com/wp-admin/upload.php?page=trac
http://example.com/wp-admin/edit.php?page=trac
http://example.com/wp-admin/index.php?page=trac
... etc ...
// Sub menu items that have the same behavior
http://vagrant.local/wp/wp-admin/plugin-install.php?page=trac
http://vagrant.local/wp/wp-admin/themes.php?page=custom-header&page=trac
http://vagrant.local/wp/wp-admin/themes.php?post-new.php?post_type=page&page=trac
... etc ...
}}}
'''Bug description:''' Every of the above links will (falsely) work and bring you to the registered page. The top level menu item will be hightlighted while the sub menu item does not exist.
The following URls will work (with above bug) as well, but ''not'' highlight any menu item:
{{{
http://example.com/wp-admin/edit-tags.php?taxonomy=post_tag&page=trac
http://example.com/wp-admin/edit-tags.php?taxonomy=category&page=trac
}}}
I would not really consider this a ''""feature""''.
----
'''Test Plugin'''
{{{
Hello Trac!
queried_object) &&
For example, when we have akamai injecting GET parameters to our home page, it just goes in an infinite 301 loop due to line 175 now evaluating TRUE when in the past it would evaluate as FALSE, and we'd like that back.
Please and thank you awesome wordpress team!",solomon123br,7
Needs Dev / Bug Wrangler Feedback,31300,redirect_canonical returns too early,,Canonical,,normal,normal,,defect (bug),new,dev-feedback,2015-02-11T17:00:31Z,2019-12-06T10:01:04Z,"If `$redirect_url` is not set or is not equal to `$requested_url` then `redirect_canonical()` returns early and does not trigger the `redirect_canonical` filter. This prevents plugins from being able to alter the canonical URL.
This bug was partially addressed in #8975 (it still returned early when the redirect and requested URL are the same), but this was reverted in #11700 without any indication as to why.
The attached patch ensures the filter triggers even when the `$redirect_url` is not set or is the same as `$requested_url`.",stephenharris,3
Needs Dev / Bug Wrangler Feedback,18385,"Canonical redirections not suited for Queries with multiple query vars and ""pretty permalinks"" in general",,Canonical,3.2,normal,normal,,enhancement,new,dev-feedback,2011-08-12T09:05:03Z,2019-06-04T19:22:40Z,"When the Canonical code was originally written, it served it's purpose quite well. However, over the years the number of Query vars which can be used to access content via has increased, and so have the number of archive views. This has lead to increased complexity in the Taxonomy canonical code which has needlessly caused bugs.
What I'm proposing, is that it might be time to lay to rest the current `if.. elseif.. elseif..` style checks, It's not possible for 1 if branch to handle every single access point without duplicating another branch.
As a result, I've put a half-finished together alternate version of Canonical, It's based on tallying up which query vars have been used/accounted for and removing any duplicates.. It's certainly not the best, but it's fairing better with the unit tests so far.
{{{
Unit Testing: http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_includes_canonical.php
Before: FF.......FFFF..FFF.....F......FFFFFF.F....F.....FF....FF...
After: FF...........FFF..................FF..................F....
}}}
It's a work in progress, but it's worth considering IMO.
Attaching a diff, and the full file (since the diff is going to be rather unreadable in some sections)",dd32,1
Needs Dev / Bug Wrangler Feedback,20283,Create new variable or function in $wp_query object to get canonical URL of any site's page,,Canonical,3.3.1,normal,normal,,enhancement,new,dev-feedback,2012-03-22T14:42:36Z,2019-06-04T19:22:53Z,"For the sake of Search Engine Optimization it's recommended to set canonical URL inside tag in any site's page. Incorrect URL can exist in search engine index. For example: http://example.com?some_param=some_val&cat=3,4. URL points to categories with id equals 3 and 4, but we have another unnecessary parameter 'some_param'. It's malicious! We must set canonical URL to http://example.com?cat=3,4.
So It's advance to have canonical URL generated some way. I propose to set function or variable inside WP_Query class to retrieve canonical URL to any opened page.
In WP_Query we have variable WP_Query::query which consists of all necessary parameters for that propose. But we must use $wp_rewrites also.
Any thoughts?
",egorpromo,3
Needs Dev / Bug Wrangler Feedback,10543,Incorrect (non-UTF-8) character handling in tag's name and slug,westi*,Charset,2.8.2,normal,normal,,defect (bug),accepted,needs-unit-tests,2009-08-04T05:26:11Z,2019-06-04T19:21:33Z,"Incorrect (non-UTF-8) character tag's name and slug are handled in different way: name is truncated on 1st such character, and in slug they are just removed (no truncation). WP should handle both in the same way - drop invalid characters, instead of truncation.
I found this issue recently. One of the Polish programs for adding posts to the Wordpresses does not encode tags in UTF-8 - it left them in ISO-8859-2. I notified author of this bug. Unfortunately there are many copies around, so it may take a long time before everyone upgrade.",sirzooro,20
Needs Dev / Bug Wrangler Feedback,30909,Allow passing ID for comment_form container and title,,Comments,,normal,normal,,defect (bug),new,dev-feedback,2015-01-05T13:01:56Z,2019-06-04T19:27:27Z,"Right now, there's a `div` hardcoded with `#respond` and a `h3` hardcoded with `reply-title`. These make it hard for the comment form to be used on archive pages, as they assume the comment form is only ever output on single pages.
(There are other IDs output in the form, however these are controllable through `id_form` and `id_submit`)",rmccue,8
Needs Dev / Bug Wrangler Feedback,12363,Comment permalink wrong when only listing one comment type,wonderboymusic,Comments,3.0,normal,normal,,defect (bug),assigned,dev-feedback,2010-02-24T14:31:51Z,2019-06-04T19:21:46Z,"If you pass the `type` parameter to `wp_list_comments()` (for example, to show comments only and no pings), then comment permalinks can easily use the wrong page number as they expect there to be pings included. This is apparent after leaving a comment and WordPress attempts to redirect back to your new comment.
At first I was thinking you could tell WordPress that you're filtering to a type and it could compensate when determining the page number, but then I realized perhaps it'd just be better for `wp_list_comments()` to check if there were 0 comments returned for the query and if so, see if there are any of that type of comment available. If so, then we know we're on too high of a page number and can instead display the highest existing page. Then again this introduces SEO issues.
Ideas on what to do are welcome.",Viper007Bond,4
Needs Dev / Bug Wrangler Feedback,35651,No longer any consistent way to add content to bottom of comments form,,Comments,4.4,normal,normal,,defect (bug),new,dev-feedback,2016-01-28T22:12:22Z,2019-08-19T01:44:25Z,"In #34731, there was a discussion on whether `comment_notes_after` should be directly after the comment form (now at the top by default), or at the bottom above the submit form (as the documentation described).
The decision was to change the documentation.
However, this now leaves no consistent way for themes/plugins to add content to the bottom of the form, above the submit button. Using `comment_notes_after` was a popular method to add notes like terms and conditios, or a subscribe checkbox etc, and consistent with the old documentation. All of these themes/plugins that relied on the positioning in the documentation will now have this output in the wrong place in the form.
`comment_form_after_fields` isn't an alternative since it only applies when the user is logged out.",smerriman,5
Needs Dev / Bug Wrangler Feedback,16365,Comment transition for new comments,,Comments,3.1,normal,minor,,enhancement,new,needs-docs,2011-01-24T21:07:46Z,2019-06-04T19:22:11Z,"As far as I can tell wp_transitions_comment_status() does not get called for new 'comments' based on my testing and review of comment.php in wp-includes.
There is a similar transition for posts that gets called for new 'posts' including hooks like 'new_to_publish' and 'new_to_private'.
I feel that there should be a similar hook to this form comments so that plugins can hook into new comments differently from comments moved from one existing status to another (like comment_unapproved_to_approved'.",MattyRob,24
Needs Dev / Bug Wrangler Feedback,22164,"Move comment ""keyboard shortcuts"" setting to comments -> screen options",,Comments,,normal,normal,,enhancement,new,dev-feedback,2012-10-11T14:14:23Z,2019-06-04T19:23:27Z,"Seems like it would make more sense to move the comment ""keyboard shortcuts"" setting from ""Your Profile"" to the screen options pane of edit-comments.php. Something like:
[[Image(http://f.cl.ly/items/1k210Z2V1o0b350I1n0V/keyboard-shortcuts.jpg)]]",lessbloat,8
Needs Dev / Bug Wrangler Feedback,23179,New avatar related option - use gravatar only for registered users,,Comments,,normal,normal,,enhancement,new,dev-feedback,2013-01-11T15:40:59Z,2019-06-04T19:23:48Z,"The use of gravater is problematic because there is no attempt to verify that a comment with which an email was used was actually left by the owner of the email (AFAICT gravatar doesn't even have an API for authentication).
This makes impersonating to someone else that have a gravatar in a wordpress site comments much too easy.
IMO non autogenerated gravatars should be displayed by default only for users for which it is known that they actually own the email address, which are usually only the registered users.",mark-k,4
Needs Dev / Bug Wrangler Feedback,16612,WordPress should return nocache headers for requests with comment cookies,,Comments,,normal,normal,,enhancement,new,dev-feedback,2011-02-21T22:45:21Z,2019-06-04T19:22:17Z,"Most themes, when displaying the comment form, change the HTML to pre-fill username, email address, and website when comment cookies are received in the HTTP request. Since the response does not have explicit nocache headers, per RFC2616 (http://www.ietf.org/rfc/rfc2616.txt) intermediate caches can use heuristics to determine the cache TTL for the response. Since there is 0 freshness data in the response, it is not really possible to perform good heuristics, but in practice, caches will assign a default TTL to this type of response. The result is that private information input by user A when submitting a comment can be returned to user B when making a request for the same URL.
To protect ourselves against this, we should call nocache_headers() when comment cookies are sent and the comment form is being displayed. Alternatively, we can send nocache headers for all requests with comment cookies regardless of the comment form being displayed or not (probably easier and maybe safer).
http://humboldtherald.wordpress.com/2011/01/27/gremlins/ is a story likely caused by an aggressive cache and the lack of nocache headers.",barry,7
Needs Dev / Bug Wrangler Feedback,12257,wpdb Scales Badly Due to Unnecessary Copies of All Query Results,,Database,,normal,critical,,defect (bug),assigned,dev-feedback,2010-02-17T03:08:06Z,2019-06-04T19:21:45Z,"While working on #11726, I encountered a reproducible crash in wpdb::query()
The following code causes memory exhaustion on large result sets:
{{{
while ( $row = @mysql_fetch_object($this->result) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}
}}}
The memory exhaustion message is error-controlled, causing a white screen of death even in debug mode.
I searched wp-db.php for references to $this->last_result, and I found no justification for these object reference copies. $this->last_result '''should''' be maintained as a MySQL resource and properly optimized using the MySQL client layer instead of this PHP nonsense.
Tagging for dev-feedback to discuss which Milestone is appropriate.",miqrogroove,31
Needs Dev / Bug Wrangler Feedback,18315,Add an index to the GUID column in the posts table,,Database,3.2.1,normal,normal,,enhancement,reopened,dev-feedback,2011-08-02T04:31:01Z,2019-06-04T19:22:38Z,"Running queries on the GUID column in the posts table is slow because the column is not indexed. The attached patch adds an index.
Note, this affects ticket #18286 - I will update that ticket with appropriate patches to reflect this request.",alexkingorg,11
Needs Dev / Bug Wrangler Feedback,20634,dbDelta is unforgiving about field declarations,,Database,1.5,normal,normal,,enhancement,new,dev-feedback,2012-05-08T03:27:05Z,2019-06-04T19:23:05Z,"the variable type is case sensitive:
int(22) != INT(22)
the mysql type BOOL or BOOLEAN comes back from the db as tinyint(1):
tinyint(1) != BOOLEAN
Not a huge issue, just annoying. Makes dbDelta fire off unnecessary sql.
",SidHarrell,8
Needs Dev / Bug Wrangler Feedback,59954,Gets error 404 in preview page,,Editor,6.4,normal,major,,defect (bug),new,dev-feedback,2023-11-23T12:34:22Z,2023-12-01T22:20:07Z,"In latest version of WordPress 6.4.1, we get error 404. It redirects to a undefined page.
For example link preview:
/wp-admin/post.php?post=34891&action=edit
Gets:
/wp-admin/undefined
We are using Classic Theme (GeneratePress) and we've tried with latest version of Gutenberg. But we have tried without plugins and other Theme like Twentytwenty four.",davidperez,3
Needs Dev / Bug Wrangler Feedback,27076,double newlines inserted before captions,,Editor,2.6,normal,normal,,defect (bug),new,dev-feedback,2014-02-09T13:35:31Z,2019-06-04T19:25:02Z,"Steps to reproduce:
- Upload some picture in the library and add some caption to it
- Edit a post/page using the visual editor and, after some text, insert the picture using the add media button, so a ""caption"" shorttag is created
- Go into text editing
- Suppress the two newlines that appeared before the ""caption"" shorttag
- Go into visual mode
- Go into text mode: the newlines reappeared
It is important to put something before the picture inserted in order to reproduce the bug, because the two newlines are not inserted if it is at the very beginning of a post/page.
This is annoying for example in a table with top-aligned cells, if in a cell you have some text, and in the cell just to the right you have a ""caption"", then the two won't be aligned, since the newlines are converted to an empty paragraph during the rendering.
From what I saw, the issue could be fixed by just removing the line n° 124 in wp-admin/js/editor.js:
{{{content = content.replace( /\s*\[caption([^\[]+)\[\/caption\]\s*/gi, '\n\n[caption$1[/caption]\n\n' );}}}",arupqfjm,1
Needs Dev / Bug Wrangler Feedback,25070,Add filter to use do_accordion_sections for post metaboxes,,Editor,3.6,normal,normal,,enhancement,new,dev-feedback,2013-08-18T15:44:46Z,2019-06-04T19:24:15Z,"It'd be really cool to be able to use the new do_accordion_sections to render post metaboxes. Adding a filter to allow devs to do that, will also make easier to render custom styles (tabs or whatever).
Attached patch is a really quick proof of concept.
",MZAWeb,5
Needs Dev / Bug Wrangler Feedback,51534,Add post type Blocks (reusable blocks) into menu,,Editor,5.5,normal,normal,,enhancement,reopened,dev-feedback,2020-10-15T13:41:48Z,2023-05-23T09:00:15Z,"Because you can manage all reusable blocks - creating new, changing or import from JSON, it will be convenient to have a proper menu link to 'edit.php?post_type=wp_block', possibly in the Appearance menu.",oglekler,20
Needs Dev / Bug Wrangler Feedback,22279,WordPress Export/Import deletes carriage returns,,Export,3.4.2,normal,normal,,defect (bug),new,dev-feedback,2012-10-25T20:02:42Z,2019-06-04T19:44:09Z,"WordPress export does not translate or escape bare CR characters in a CR/LF pair. They show up unfiltered in the WXR export file. I see this both in post_content and in strings that were serialized into a post_meta field. The CR characters are in the WXR file, unfiltered.
Then, WordPress import loses these CR characters. They are simply erased. It may be because SimpleXMLParser can't or won't open the XML file in binary mode, so line ending translation can & does happen. That's just a theory, but if it's true then this behavior might *not* happen on all platforms or with all PHP versions. (I'm seeing this on OS X 10.6.8, PHP 5.4.4.)
In the worse case -- mine -- the munged string is a small component of a complex datastructure that is serialized in a postmeta record. In this case, the entire meta_value field is deleted on import, because the data won't unserialize, because its length has changed.
It seems to me that WP Export should escape any character that might be threatened in transit. I'm no XML lawyer, but some sources claim that unescaped CR characters are invalid XML.
To reproduce:
* store a carriage return in a post.
* export it to a WXR file.
* examine the WXR file for the raw carriage return (`^M`).
* import that file.
* search for the carriage return.",mykle,4
Needs Dev / Bug Wrangler Feedback,35927,_wp_attachment_metadata meta_value wrong type in export,,Export,4.4.2,normal,normal,,defect (bug),new,dev-feedback,2016-02-23T20:50:59Z,2019-10-24T06:06:09Z,"this if from an export using wp 4.4.2, the particular post is from Dec 2010.
{{{
}}}
every width and height value is a string but should be an int!
{{{
s:5:""width"";s:3:""150"";s:6:""height"";s:3:""150"";
}}}
should be
{{{
s:5:""width"";i:150;s:6:""height"";i:150;
}}}
if i edit it manually, the import works.
could you provide database migration or something in the next update to fix the values?
this don't happen with newer articles.",davidak,2
Needs Dev / Bug Wrangler Feedback,36818,Export filter for post meta,,Export,,normal,normal,,enhancement,new,dev-feedback,2016-05-11T20:00:14Z,2019-06-04T19:58:11Z,"It would be handy if we had a filter for modifying post meta before it is written to an export file.
Our plugin stores serialized arrays in post meta that get corrupted from time to time during the export/import process. The attached patch/filter would allow us to store the data differently in an export file to prevent that from happening. ",justinbusa,10
Needs Dev / Bug Wrangler Feedback,9611,Make comment feeds fail with an error code when comments are closed,,Feeds,2.8,normal,normal,,enhancement,new,dev-feedback,2009-04-21T14:12:42Z,2019-06-04T19:42:34Z,"This is mostly a suggestion as an enhancement.
When you close a post's comments and pings, it should no longer output an rss feed. Instead, it should return a not found (404) or gone (410) error and die.
Likewise, if all posts and pages on a site disallow comments and pings, the comments feeds should not be broadcast, and should return the same error code.
Thoughts?",Denis-de-Bernardy,9
Needs Dev / Bug Wrangler Feedback,9510,Multiple feed fixes and enhancements,,Feeds,2.7.1,normal,major,,enhancement,new,dev-feedback,2009-04-11T09:36:47Z,2019-06-04T19:42:32Z,"Currently, the feed always returns the same subtitle, self link, alternate link and replies link no matter what the page type is. I think they should be different for each page type.",peaceablewhale,26
Needs Dev / Bug Wrangler Feedback,19643,Allow array for $extra_fields in request_filesystem_credentials,dd32,Filesystem API,3.0,normal,minor,,defect (bug),reviewing,dev-feedback,2011-12-22T07:47:38Z,2019-06-04T19:43:38Z,The current implementation for passing extra fields through request_filesystem_credentials() does not allow for an array of data to be passed. I came across this issue when trying to process a bulk installation of plugins with my plugin installation class. My patch fixes this from what I can tell and doesn't break anything that I can see from my testing.,griffinjt,17
Needs Dev / Bug Wrangler Feedback,48316,"Changeset 46482 breaks upload when using "".."" in upload_path.",,Filesystem API,5.2.4,normal,normal,,defect (bug),reopened,dev-feedback,2019-10-15T21:01:42Z,2024-02-07T13:39:06Z,"Hi,
We just found out that changeset [46482] in the latest WordPress 5.2.4 broke a huge number of our customer's sites (tens or thousands).
We uses a separate subdomain as upload directory. This is done by changing the option ""upload_path"" to ""../../media.example.com/www/"" (and ""upload_url_path"" to ""http://media.example.com"").
This change means that new directories (for example ""./2019/10/"") can't be created, which breaks the entire upload functionality.
If this changeset fixed some critical vulnerability which can't be fixed another way or if we are the only ones utilizing this feature, so be it. Otherwise this change might have to be reverted and reimplemented some other way.
",xpoon,31
Needs Dev / Bug Wrangler Feedback,21537,Email address sanitisation mangles valid email addresses,,Formatting,3.4.1,normal,normal,,defect (bug),new,dev-feedback,2012-08-10T11:24:50Z,2022-10-23T14:32:55Z,"If you change your email address to one including an ampersand then we mangle the address with html entities.
For example:
* This - peter&paul@sitting.in.a.tree.com
* Becomes - peter&paul@sitting.in.a.tree.com
This is due to the call to {{{wp_filter_kses}}} on {{{pre_user_email'}}} in {{{default-filters.php}}}.
The was added in [5906] for #4546.
I'm not sure if we need kses filtering for emails - if we do which should probably revert this conversion of the & => & afterwards.",westi,9
Needs Dev / Bug Wrangler Feedback,36397,add_query_arg doesn't work with numbered html entities,,Formatting,2.8,normal,normal,,defect (bug),new,dev-feedback,2016-04-01T13:36:24Z,2019-06-04T19:56:44Z,"In #20771 we'd like to use `esc_url` instead of `esc_html` to escape the url that is generated by `wp_nonce_url`. Unfortunately this is currently not possible because `add_query_arg` has some buggy behavior with regard to its dealing with hashes in urls. I am creating this ticket to deal with that issue separately.
`add_query_arg` searches for the first hash in a url and cuts everything that comes after it from the url as the hashfragment and appends it back at the end of the operation. There are two problems with this:
1. No hash found in the url necessarily indicates a hashfragment. It could also indicate a numbered html entity.
2. If there are multiple hashes in the url, we should probably only look at the last hash present to find a possible hashfragment.
This can for instance become a problem when we use`esc_url` on a url with more than one parameter. `esc_url` escapes ampersands by replacing them with their numbered html entity equivalents; `#038;`
When I now want to use `add_query_arg` on such a url, the parameters get moved to the end of the url because it thinks everything after the second parameter is a hashfragment.
I am adding a patch with a some passing and some failing testcases that cover this issue. I am also adding a patch that takes care of the issue of multiple hashes in the url and fixes the issue for ampersands, which should unblock #20771 if it were committed.",omarreiss,1
Needs Dev / Bug Wrangler Feedback,23308,"make_clickable problem with multiple ""Punctuation URL character""",,Formatting,3.5.1,normal,normal,,defect (bug),new,dev-feedback,2013-01-28T15:09:59Z,2019-06-04T19:44:27Z,"make_clickable problem with multiple ""Punctuation URL character""
E.g.
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
Results in this html code:
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
But obvious should be:
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
I suggest to replace:
wp-includes/formatting.php:1603
{{{
[\'.,;:!?)] # Punctuation URL character
}}}
with
{{{
[\'.,;:!?)]{1,} # Punctuation URL character
}}}",DrPepper75,4
Needs Dev / Bug Wrangler Feedback,11678,wpautop() fails on uppercase closing tags,,Formatting,2.9,normal,normal,,defect (bug),new,dev-feedback,2009-12-31T11:26:11Z,2019-06-04T19:42:47Z,"To reproduce, in a post enter:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
View the post (source) and you get:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
Because I (incorrectly) entered an uppercase closing tag, wpautop() thinks there is no closing tag so adds a , which then often renders as a double
tag. Close if this is not a bug, though I thought it may be good to do some sanitizing or something on uppercase tags.
",joehoyle,5
Needs Dev / Bug Wrangler Feedback,30644,"""wpautop"" Enhancements",,Formatting,,normal,normal,,enhancement,new,dev-feedback,2014-12-09T18:35:14Z,2020-08-11T00:30:02Z,"Since there are several problems (e.g. invalid markup) with the current ""wpautop"" function I tried to come up with a new approach. The text gets parsed and a little analyzed in order to generate valid and comprehensible markup.
The script is not really compatible with the current implementation since whitespaces and line breaks are added differently. Performance is slightly worse, depending on the input (normal text vs. heavy html) of course. Comments in the code are still missing.
I think Shortcodes should also be considered in this markup generation process so the additional use of ""shortcode_unautop"" could be avoided.
Please let me know what you think and test it if you like.
== Sample
=== Input
{{{
paragraph
paragraph testitalic
normal
paragraph
paragraph
paragraph
line
paragraph
paragraph
paragraph
Honor
this whitespace
paragraph
paragraph
paragraph
text
}}}
=== Output
{{{
paragraph
paragraph test
italic
normal
paragraph
paragraph
paragraph
line
paragraph
paragraph
paragraph
Honor
this whitespace
paragraph
paragraph
paragraph
text
}}}",stefanrz,5
Needs Dev / Bug Wrangler Feedback,26868,"Function 'make_clickable()' doesn't make hyperlinks from explicit URLs using the `mailto:`, `tel:` and other schemes that do not start with `//`",,Formatting,3.8,normal,normal,,enhancement,new,needs-unit-tests,2014-01-18T16:00:14Z,2019-06-04T19:45:21Z,"Function `make_clickable()` tries to recognise URLs and convert these into clickable hyperlinks. The function is by default configured as a filter for comment text.
Unfortunately, the function assumes that all explicitly declared URLs begin with the string `//` after the scheme and colon parts which is not the case for the `mailto:`, `tel:` and many other schemes. Such URLs could usefully be made clickable, especially for use on smartphones and tablets.
This also leads to inconsistencies between explicitly and implicitly declared URLs. For example, the string `myemail@mydomain.com` is converted into a clickable hyperlink whilst the string `mailto:myemail@mydomain.com` is not.
By contrast, the TinyMCE post editor correctly and automatically makes both implicit and explicit `mailto:` links clickable but does nothing with `tel:`.
For reference, the syntax of URLs is defined by http://tools.ietf.org/html/std66, the `mailto:` scheme by http://tools.ietf.org/html/rfc6068 and that for `tel:` by http://tools.ietf.org/html/rfc3966.
As #16892 has illustrated, parsing URLs can be hard. The use of `wp_allowed_protocols()` may help in detecting which strings we wish to make clickable.
Found whilst testing #22946.",mdgl,2
Needs Dev / Bug Wrangler Feedback,26759,New Generic Sanitize Functions for Core,,Formatting,3.8,normal,normal,,enhancement,new,dev-feedback,2014-01-02T17:54:48Z,2019-06-04T19:45:16Z,"Core currently supplies a number of sanitize functions:
{{{
sanitize_email()
sanitize_file_name()
sanitize_html_class()
sanitize_key()
sanitize_meta()
sanitize_mime_type()
sanitize_option()
sanitize_sql_orderby()
sanitize_post_field()
sanitize_text_field()
sanitize_title()
sanitize_title_for_query()
sanitize_title_with_dashes()
sanitize_user()
}}}
They all sanitize by usage, not by data type.
As such, I (and I suspect others) wind up using these to escape things they weren't initially meant for -- for the sake of brevity, and it's just quicker and leads to tidier code.
I believe it could result in better and simpler sanitizing if we were to include sanitize-by-format functions in core. For example,
{{{
wp_sanitize_numeric( $raw ); // [\d]
wp_sanitize_numeric_float( $raw ); // [\d\.,] allowing both commas and periods as decimal indicator and thousands seperator
wp_sanitize_hex( $raw ); // [\da-f] case-insensitive
wp_sanitize_alphanumeric( $raw ); // [\da-z] case-insensitive
wp_sanitize_letters( $raw ); // [a-z] case-insensitive
wp_sanitize( $raw, $regex ); // uses passed in regex to determine what to strip.
}}}
The specific functions to use are up for discussion. I'm just hoping to make it simpler for users to sanitize data by expected type.
As a side note, this will let folks use `wp_sanitize_numeric()` to sanitize integers larger than `PHP_INT_MAX` -- which tumblr and twitter IDs often happen to be for imports and feeds and the like (as casting to `(int)` isn't a good idea).",georgestephanis,3
Needs Dev / Bug Wrangler Feedback,22402,Stripping non-alphanumeric multi-byte characters from slugs,,Formatting,,normal,normal,,enhancement,new,dev-feedback,2012-11-10T05:07:10Z,2019-06-04T19:44:12Z,"`sanitize_title_with_dashes()` strips non-alphanumeric characters from a title to create a slug. Unfortunately it only strips ASCII non-alphanumeric characters. Apart from a few exceptions, all multi-byte characters are preserved. This means all non-Western (and plenty of Western) non-alphanumeric characters end up in the slug as they're treated just like any other multi-byte character.
As an example, here are some common non-alphanumeric Chinese characters which would ideally be stripped from slugs, but are not:
* 。 (U+3002, Ideographic Full Stop, %E3%80%82)
* , (U+FF0C, Fullwidth Comma, %EF%BC%8C)
* ! (U+FF01, Fullwidth Exclamation Mark, %EF%BC%81)
* : (U+FF1A, Fullwidth Colon, %EF%BC%9A)
* 《 (U+300A, Left Double Angle Bracket, %E3%80%8A)
* 》 (U+300B, Right Double Angle Bracket, %E3%80%8B)
Obviously it would be impractical to make a list of ''all'' the non-ASCII characters we want to strip from slugs. The list would be gigantic.
So the question is, would it be possible to use Unicode ranges to blacklist (or whitelist) whole ranges of characters to be stripped from (or preserved in) slugs? Is this practical or even desirable?
Or would it make more sense to continue using a list of just the most common multi-byte characters to be stripped?
The latter makes a whole lot more sense, but the former is a more complete solution.
Thoughts?",johnbillion,1
Needs Dev / Bug Wrangler Feedback,13425,Image Gallery of Private Post is publicly displayed,,Gallery,3.0,normal,normal,,defect (bug),reopened,dev-feedback,2010-05-17T20:12:20Z,2019-06-04T19:42:59Z,"Might have been forgotten only, I just ran over this inconsistency while beta-testing:
'''Description:'''
The Image Gallery of a Private Post is displayed (in another post via the Shorttag with id parameter) whereas, when clicking on the images to go to the attachment page, you get a 404 not found.
'''Example:'''
[http://hakre.wordpress.com/2010/05/17/cui-utils-rev2/#more-1184 Post with Gallery][[BR]]
[http://hakre.wordpress.com/2010/05/17/cui-utils-gnu-tools-fur-windows-32-with-a-simple-setup/gnu-win-cui-util-00-setup/ Attachment of that Gallery]
'''Steps to reproduce'''
Create a new Post, set a title and the Status to private.
Save as Draft.
Preview it, to get the ID easily from URL.
Upload a Bunch of Images.
Insert the Gallery Shorttag inside that Post Body.
Publish the Post.
Create a second new Post
Give it a Title and Insert the Gallery Shortcode with the ID from the last Post.
Publish.
View.
Copy the URL.
Open another Browser so to have a new User-Session.
Visit that URL.
'''Expected Behaviour'''
You should not see a gallery.
'''Behaviour'''
You see a gallery.
When clicking on a gallery link you get a 404 page.
'''Feedback'''
I see an inconsitency here but have no Idea how to deal with it.
So either the gallery should not be found as well (not found as in 404 but in this case: not output) or the attachment pages should be able to call as well.
Related: #11697",hakre,5
Needs Dev / Bug Wrangler Feedback,28801,Walker::walk makes an incorrect assumption if $top_level_elements is empty.,,General,3.8,normal,normal,,defect (bug),new,needs-unit-tests,2014-07-09T16:02:56Z,2019-06-04T19:46:05Z,"A colleague of mine was generating a sidebar sub-navigation for one of his projects. The subnavigation contained second-level and third-level navigation elements.
The problem my colleague was having was that occasionally third-level elements would not be nested underneath their parent element (also in the list of elements) on some pages.
My colleague was calling wp_list_pages with an array of page IDs that he wanted to render in the sub-navigation, wp_list_pages then turned the list of page IDs into a list of Page objects, and it sorted the page objects by their 'menu_order' attribute; the third-level navigational elements all had their 'menu_order' set to 0, whereas the second-level navigational elements all had 'menu_order' set to something more than 0 - causing the third-level elements to be the first elements in the list.
wp_list_pages later made a call to Walker::walk, passing along that list of pages. Here is a relevant code snippet from Walker::walk:
{{{
/*
* When none of the elements is top level.
* Assume the first one must be root of the sub elements.
*/
if ( empty($top_level_elements) ) {
$first = array_slice( $elements, 0, 1 );
$root = $first[0];
$top_level_elements = array();
$children_elements = array();
foreach ( $elements as $e) {
if ( $root->$parent_field == $e->$parent_field )
$top_level_elements[] = $e;
else
$children_elements[ $e->$parent_field ][] = $e;
}
}
}}}
'''The bug is this code's assumption that the first item in $elements is a suitable root-element for the entire list''' (sentence emboldened for anybody not wanting to read the wall of text). wp_list_pages ordered our list by 'menu_order' which put our 3rd-level elements at the top of the list - causing a 3rd-level element to be treated as the navigation's root.
I wrote up a quick fix for this (I'm not sure if it's the best fix, I'm not overly experienced in Wordpress), and for our project we'll use wp_list_pages with a custom walker class that implements my fix.
Here is the patch of my fix:
{{{
Index: public_html/wp-includes/class-wp-walker.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- public_html/wp-includes/class-wp-walker.php (date 1404915904000)
+++ public_html/wp-includes/class-wp-walker.php (revision )
@@ -217,12 +217,34 @@
/*
* When none of the elements is top level.
- * Assume the first one must be root of the sub elements.
+ * ~~Assume the first one must be root of the sub elements.~~ Disregard - RJ CGIT 2014-07-09
+ *
+ * ----------
+ *
+ * Modified by Rob Jackson, Castlegate IT; 2014-07-09:
+ * Do not assume the first element is root, instead loop through the elements
+ * until we find one whose parent is _not_ in the list of elements. If that fails,
+ * just fall back to the default behaviour of using the first element.
*/
if ( empty($top_level_elements) ) {
+ $root = false;
+ $element_ids = array_map(function($element){ return $element->ID; }, $elements);
+ foreach($elements as $element)
+ {
+ if (!in_array($element->post_parent, $element_ids))
+ {
+ $root = $element;
+ break;
+ }
+ }
+ unset($element);
+
+ if ($root === false)
+ {
- $first = array_slice( $elements, 0, 1 );
- $root = $first[0];
+ $first = array_slice( $elements, 0, 1 );
+ $root = $first[0];
+ }
$top_level_elements = array();
$children_elements = array();
}}}
Kind regards,
Rob
",rob-castlegate,2
Needs Dev / Bug Wrangler Feedback,28774,Hooking into wp_ajax_upload_attachment,,General,4.0,normal,normal,,enhancement,new,dev-feedback,2014-07-07T15:20:25Z,2019-06-04T19:46:04Z,"If you want to do something before/after an attachment has been uploaded - or replace the upload function entirely -- there doesn't seem to be a way to do that:
For other `wp_ajax_* calls`, you can unhook them and then hook in your own. This doesn't work for `wp_ajax_upload_attachment` because it ends up getting called directly from async-upload.php.
If we replace the direct call with another set of `do_action/add_action` (like admin-ajax has) you can now hook into upload like the other ajax actions.
See the proposed patch.",jshreve,2
Needs Dev / Bug Wrangler Feedback,30798,Ideas for improvements to to wp_die() usages,,General,,normal,normal,,enhancement,new,dev-feedback,2014-12-20T19:34:16Z,2019-06-04T19:47:06Z,"When a visitor to or a user of a WordPress powered site encounters a `wp_die()` message (traditionally handled by the `_default_wp_die_handler()` function) it is (likely intentionally) a very jarring experience. Having `wp_die()` produce human readable results is the least amount of assistance we could possibly provide when a not-completely-unanticipated event occurs, and I think in many instances we can provide a more positive experience.
Of our current 230 approximate usages, 33 appear to be `Cheatin’; uh?`'s which, while cute and full of personality, aren't particularly helpful to the innocent user who encounters them, nor are they stern enough to deflect any guilty parties from continuing to seek out unauthorized access.
The remaining 200 approximate usages typically drop an authorized user into a limbo state where their only option is going back in their browser history and hope their drafted content isn't bungled or lost. Maybe tucking some of these requests behind ajax actions would reduce that redirection? Or maybe enabling themes to have a template hierarchy for handling various error messages would be more user friendly?
I don't have a real improvement plan, and don't feel wholly qualified to solve this issue for the entire WordPress community, rather I'm hoping this ticket can foster some discussion about improving this trusted, though somewhat antiquated, piece of WordPress core.",johnjamesjacoby,5
Needs Dev / Bug Wrangler Feedback,31559,Meta boxes should have before/after hooks,,General,,normal,normal,,enhancement,new,dev-feedback,2015-03-07T20:38:33Z,2019-06-04T19:47:58Z,"Currently there is no way to hook into an existing metabox. If I wanted to modify the featured image metabox (add a checkbox or something), I'd have to unregister the metabox, and re-register w/ my own callback. This is not good for compatibility w/ other plugins, etc.
I propose before_callback and after_callback hooks for metaboxes.
Basically, we'd replace this:
{{{
echo '
\n"";
}}}
",jtsternberg,3
Needs Dev / Bug Wrangler Feedback,31206,Move AJAX action parameters out of the method body and into the declaration.,,General,4.2,normal,normal,,enhancement,new,dev-feedback,2015-02-01T23:09:49Z,2019-06-04T19:47:45Z,"`admin-ajax.php` has several methods that require an `$action` parameter, then immediately set that parameter in the body of the method to the desired string if it's not set, which seems a bit counter-intuitive.
I propose removing the conditional check completely (since it's not checking for a value, just the presence) and move the desired string into the method declaration as a default value.",morganestes,3
Needs Dev / Bug Wrangler Feedback,36120,Move wp_*_link() functions into wp-includes,,General,,normal,normal,,enhancement,new,dev-feedback,2016-03-05T14:51:04Z,2019-06-04T19:55:44Z,"The following link functions live in `wp-admin/includes/bookmark.php`:
* `wp_insert_link()`
* `wp_delete_link()`
* `wp_update_link()`
I would like to propose that these three functions be moved into `wp-includes/bookmark.php` so that they are available on any request, and not just requests inside `wp-admin`.
It would also be necessary to move the `wp_set_link_cats()` so that it is available inside the `wp_insert_link()` function.
Other similar functions live in `wp-includes` already, such as `wp_insert_post()`, `wp_insert_commet()`, etc. This change would allow links to work in the same way as those other content types.",JPry,3
Needs Dev / Bug Wrangler Feedback,27122,Optimization for PHP FPM,,General,3.8,normal,normal,,enhancement,new,dev-feedback,2014-02-13T22:59:21Z,2019-06-04T19:45:25Z,"This patch make {{{ wp_ob_end_flush_all }}} calling {{{ fastcgi_finish_request }}} instead of {{{ ob_end_flush }}} when php-fpm is used.
{{{ fastcgi_finish_request }}} flush the buffers '''and''' close the connection. This tweak increases page speed.
It also allows to run heavy tasks such as sending mail, writing logs or making complex calculations after the end of the request without slowing down the whole page load.
Symfony uses this tweak too, see this PR FOR further details: https://github.com/symfony/symfony/issues/1180",dunglas,13
Needs Dev / Bug Wrangler Feedback,33837,We should avoid Superglobals when possible,wonderboymusic,General,,normal,normal,,enhancement,assigned,dev-feedback,2015-09-11T19:53:44Z,2019-06-04T19:51:22Z,"We can probably add some helper functions that complete common tasks around Superglobal access
Examples of accessing here:
https://codeclimate.com/github/WordPress/WordPress/wp-admin/edit-comments.php
Something like `wp_verify_action( $action )` could replace the many instances of things like:
`isset( $_REQUEST['action'] ) && 'upload-attachment' == $_REQUEST['action']`
Without having to architect something like `Symfony/HttpFoundation`, we can make accessing them more rare.",wonderboymusic,24
Needs Dev / Bug Wrangler Feedback,27286,create menu page for custom post types,,General,3.8,normal,normal,,enhancement,new,dev-feedback,2014-03-05T21:13:20Z,2019-06-04T19:45:30Z,"Currently, there are dedicated functions for adding new items to a top-level navigation item, such as `add_posts_page`, `add_media_page`, `add_links_page`, and so on. These all act as a wrapper for the `add_submenu_page`. However, there is no dedicated function for custom post types. I am proposing to add a new function called `add_post_type_page` that works in the same way. It's basically a copy of `add_posts_page` with an additional parameter for the registered CPT.",norcross,3
Needs Dev / Bug Wrangler Feedback,60229,HTML API: Introduce HTML Templating,,HTML API,trunk,normal,normal,,enhancement,new,dev-feedback,2024-01-11T03:41:51Z,2024-03-07T17:03:47Z,"WordPress relies on developers remembering to perform proper escaping when building HTML strings. There's no mechanism to ensure that output HTML is safe. This patch introduces `WP_HTML_Template::render( $template, $args )` to do just that.
{{{#!php
"">
"">
%url>
HTML,
array( 'url' => 'https://s.wp.com/i/atat.png?w=640&h=480&alt=""atat>atst""' ),
);
}}}
outputs
{{{
https://s.wp.com/i/atat.png?w=640&h=480&alt="atat>atst"
}}}
This proposed templating syntax uses closing tags containing invalid tag names, so-called ""funky comments,"" as placeholders, because they are converted to HTML comments in the DOM and because there is near universal existing support for them in all browsers, and because the syntax cannot be nested. The `%` at the front indicates that the value for the placeholder should come from the args array with a key named according to what follows the `%`.
This proposal does not yet consider nested HTML, or ""raw"" HTML. It currently escapes all content. It would be great if the templating engine can properly and safely handle HTML passed into it without risking unintentional exposure, but there must also be some way to communicate that a value inside is already escaped //and that its safety is maintained//.
By relying on the HTML API, this templating only supports replacement of values //inside// HTML attributes or in plaintext (`#text`) nodes. It's not possible to inject HTML tags (unless nested support can be safely added), comments, or other HTML syntax.",dmsnell,15
Needs Dev / Bug Wrangler Feedback,29619,Make WP_HTTP_BLOCK_EXTERNAL more easy to use,,HTTP API,2.8,normal,normal,,enhancement,new,dev-feedback,2014-09-10T17:46:54Z,2019-06-04T19:46:22Z,"Currently when defining WP_HTTP_BLOCK_EXTERNAL it blocks all requests which would mean that WordPress itself becomes unusable because it then will also blocks it own requests to WordPress.org. Also oEmbeds stop working because they can't get their data.
My idea is to make an if statement like the localhost check to allow those requests. I do get that this constant is mainly for local development but would be great to have a easy way to have a semi locked down installation. So I'm curious what you guys think about this.",markoheijnen,1
Needs Dev / Bug Wrangler Feedback,12477,Search with special characters and similar terms,nbachiyski,I18N,,normal,normal,,feature request,new,dev-feedback,2010-03-02T17:42:46Z,2019-06-04T20:01:58Z,"I did:Tried searching for terms Metis and Métis
I saw:Those two searches turned up different sets of results.
I expected:The same set of search results, or at least everything when
I searched for Metis.
Can search be smarter when special characters are involved?",mrroundhill,2
Needs Dev / Bug Wrangler Feedback,21913,Detecting MIME Types in WXR Files,,Import,3.4.2,normal,normal,,enhancement,new,dev-feedback,2012-09-17T21:09:07Z,2019-06-04T20:03:48Z,"In the process of creating a service to convert TypePad data to WXR formatted files, we've encountered some unique problems with TypePad data. Namely, many TypePad files are saved without file extensions, which prevents the existing importer from importing those files into the wp-content/uploads folder.
In order to import and rename these otherwise ignored files, we've created a patch for the WordPress importer that does the following:
1. If there is an attachment in the WXR and the importer is not able to determine the file type from the file name (ie missing extension), the patched version will make a light (body-less) request to the web server where the file is hosted for information we can use about the file. The things we're interested in are file type, size, and filename.
2. If the importer is processing an attachment under the above situation, and it is able to determine the file type, then it will rewrite the local version of the file to have the appropriate file extension.
This is a simple bit of code, but it makes a huge difference as TypePad saves without file extensions quite regularly.
We've attached our patch and a sample WXR file from ragsgupta.com, the Brightcove co-founder's blog.",ReadyMadeWeb,7
Needs Dev / Bug Wrangler Feedback,36179,Password protected post with force_ssl_admin() and domain mapping not working,,Login and Registration,4.3.1,normal,normal,,defect (bug),new,dev-feedback,2016-03-09T13:48:42Z,2019-06-04T20:23:26Z,"Hi,
I'm running a WordPress multisite with ""define(FORCE_SSL_ADMIN, true)"" and domain mapping.
Our network site is using ssl (where users login to administrate their site). But a domain mapped site is not using ssl, which is working fine.
So, I have a post that is password protected. When I'm on the mapped domain and submit the password protect form, I then get redirected to ""wp-login.php?action=postpass"" over https and get a security warning.
It should not redirect me to https when I'm on a non-ssl mapped domain.
Thanks",tcdeskwolf,6
Needs Dev / Bug Wrangler Feedback,16482,Visibility: password-protected breaks with redirected domains,,Login and Registration,3.0.4,normal,normal,,defect (bug),new,dev-feedback,2011-02-07T18:58:45Z,2019-06-04T20:02:37Z,"Pre-requisite to reproduce: domain.com must redirect to www.domain.com (haven't tested with other subdomains than www, but I'm sure it would be the same).
1. password protect a page
2. visit domain.com/protected (which redirects to www.domain.com/protected)
3. enter password
4. something about the redirect OR the way the password is stored/checked is broken; you are redirected to the wp-admin (WordPress login) page.
Sanity check:
1. password protect a page
2. visit www.domain.com/protected (requiring no subdomain redirect)
3. enter password
4. successful log-in
",monkeyhouse,10
Needs Dev / Bug Wrangler Feedback,31166,wpmu_signup_user_notification filter is incorrect,,Login and Registration,3.0,normal,normal,,defect (bug),new,dev-feedback,2015-01-28T20:30:03Z,2019-06-04T20:10:50Z,"Simple ticket here,
The wpmu_signup_user_notification filter seems to be filtering the wrong option
{{{
if ( ! apply_filters( 'wpmu_signup_user_notification', $user, $user_email, $key, $meta ) )
return false;
}}}
If I'm thinking correctly, the filter should be filtering a boolean. If two filters are added to this and the first returns false, there is no way for the second filter to recover the $user variable.
This is how I see it working
WP4.1, /wp-includes/ms-functions.php line 919
{{{
if ( ! apply_filters( 'wpmu_signup_user_notification', true, $user, $user_email, $key, $meta ) )
return false;
}}}",johnrom,4
Needs Dev / Bug Wrangler Feedback,36317,Introduce a cookie prefix default constant,,Login and Registration,,normal,normal,,enhancement,new,dev-feedback,2016-03-24T01:41:57Z,2019-06-04T20:23:42Z,"Right now, all of WordPress's cookies are prefixed with the same `wordpress` namespace. A problem arises with `advanced-cache.php` caching solutions that load before `wp_cookie_constants()` is called, where the cookie prefix cannot be guessed.
The current work around is to stab at each cookie individually:
{{{
// Auth cookie
if ( defined( 'AUTH_COOKIE' ) && ( $this->cookie === AUTH_COOKIE ) ) {
return true;
}
// User cookie
if ( defined( 'USER_COOKIE' ) && ( $this->cookie === USER_COOKIE ) ) {
return true;
}
// Logged-in cookie
if ( defined( 'LOGGED_IN_COOKIE' ) && ( $this->cookie === LOGGED_IN_COOKIE ) ) {
return true;
}
}}}
And to special case the test cookie, like:
{{{
// Generic 'wordpress' cookies (that are not test cookies)
if ( ( substr( $this->cookie, 0, 9 ) === 'wordpress' ) && ( $this->cookie !== 'wordpress_test_cookie' ) ) {
return true;
}
}}}
But without a known and trusted cookie prefix, it's still an unpredictable environment.
-----
I'd like to re-propose an 8 year old issue (#6413) to introduce a new default constant to define a cookie prefix. This could turn the above snippet into something at least slightly more sane, like:
{{{
// Generic 'wordpress' cookies (that are not test cookies)
if ( defined( 'COOKIEPREFIX' ) ) {
$len = strlen( COOKIEPREFIX );
if ( substr( $this->cookie, 0, $len ) === COOKIEPREFIX ) && ( false !== strpos( $this->cookie, 'test_cookie', $len ) ) {
return true;
}
}
}}}
A `COOKIEPREFIX` constant would also allow plugins an easy way to drop themselves inside of WordPress's cookie namespace, which will help them play more nicely in environments where WordPress is not the only application within the domain.",johnjamesjacoby,
Needs Dev / Bug Wrangler Feedback,24465,Introduce filter for user password on registration,,Login and Registration,,normal,normal,,enhancement,new,dev-feedback,2013-05-30T17:12:35Z,2020-08-12T14:17:39Z,We should introduce a filter within {{{register_new_user}}} on the auto-generated password to make it easier for plugins to handle setting custom passwords.,jfarthing84,2
Needs Dev / Bug Wrangler Feedback,54298,Multisite: resetpassform always posts to the main-site wp-login.php file,,Login and Registration,,normal,normal,,enhancement,new,dev-feedback,2021-10-20T14:50:00Z,2023-10-01T01:52:18Z,The reset password form always posts to the main-site wp-login.php file. If the reset password form on a sub-site is being used then I'd expect the form to post to the sub-site wp-login.php file.,henry.wright,3
Needs Dev / Bug Wrangler Feedback,20019,wpmu_validate_blog_signup(): Allow '.' and '-' in blog names,,Login and Registration,3.0,normal,normal,,enhancement,reopened,dev-feedback,2012-02-10T23:04:29Z,2019-06-04T20:03:10Z,"Canonical uses Wordpress 3.x multisite as part of voices.canonical.com, for employees who do not have or wish to list their personal blog. The code is stock, except for one patch we maintain, which allows blog names (currently in WP as lowercase alphanumeric only) to also include '.' and '-'. This matches our global username format.
Attached is a patch extending wpmu_validate_blog_signup() to allow '.' and '-', with a tweak for the error text. We have been running the patch for awhile, and have not run across any problems with the rest of the code accepting this.",fo0bar,21
Needs Dev / Bug Wrangler Feedback,23779,Can't insert large image if it's smaller than media setting but larger than theme setting,,Media,3.0,normal,normal,,defect (bug),new,dev-feedback,2013-03-15T00:47:08Z,2019-06-04T20:05:06Z,"If you upload an image that is larger than $content_width but not larger than the ""large"" setting in settings->media, the option to insert a ""large"" image into the post isn't available even though the image is large enough.
It looks like it must use $content_width as the actual width of the large image that's inserted, and the large_size_w setting to decide whether to show that option or not.",aaroncampbell,12
Needs Dev / Bug Wrangler Feedback,31570,Infinite loop when filtering Media Library images by size in a modal (using wp_prepare_attachment_for_js),fuhton,Media,4.1.1,normal,normal,,defect (bug),assigned,dev-feedback,2015-03-09T13:48:25Z,2019-06-04T20:11:46Z,"In an attempt to restrict a post's Featured Image dimensions to imagers wider than 100px I implement the following code in `functions.php`:
{{{
function restrict_media_library_by_width($response, $attachment, $meta) {
if(isset($response['width']) && isset($response['height']) && $response['width'] > 100) {
return $response;
}
return false;
}
add_filter('wp_prepare_attachment_for_js', 'restrict_media_library_by_width', 10, 3);
}}}
I then click ""Set featured image"" and the Media Library modal that appears only loads one empty thumbnail and my Network panel in Chrome Dev Tools reveals it makes continued, repeated, infinite AJAX requests.
The only viable alternative I've found was to run a separate query within `ajax_query_attachments_args`, which is needed because the `_wp_attachment_metadata` key contains serialized data and that leaves no way to compare dimensions within a `meta_query`.
Obviously running this additional query is inefficient and more resource intensive than it should be. More details here: http://wordpress.stackexchange.com/questions/180500/filter-media-library-items-by-size/.",silb3r,4
Needs Dev / Bug Wrangler Feedback,23398,"Media Gallery - Clicking ""Restore Original Image"" in ""Scale Image"" pane loses 'Thumbnail Settings' pane.",,Media,3.4,normal,normal,,defect (bug),new,dev-feedback,2013-02-05T21:11:36Z,2019-06-04T20:04:54Z,"Reproduce the problem thusly:
Click ""Edit image"" in the ""Edit Media"" interface for any image.
`/wp-admin/post.php?post=1119&action=edit`
Scale the image a couple times in the 'Scale Image' pane. Update.
Click ""Restore Original Image"" in the 'Scale Image' pane.
Try to crop just the thumbnail.
The 'Thumbnail Settings' Pane is '''''gone'''''.
The image has to be deleted and re-uploaded to gain thumbnail control once again.",gr33nman,4
Needs Dev / Bug Wrangler Feedback,47529,Media manager doesn't display cropped images,,Media,4.9,normal,normal,,defect (bug),reopened,dev-feedback,2019-06-12T09:19:59Z,2019-06-14T14:59:22Z,"Media manager doesn't display cropped images
We should change the display to list mode to view cropped images
",dedidata,2
Needs Dev / Bug Wrangler Feedback,49601,layout width bugfix for img_caption_shortcode(),,Media,5.4,normal,normal,,defect (bug),reopened,dev-feedback,2020-03-08T19:00:36Z,2022-10-13T21:01:21Z,"`img_caption_shortcode()` in `wp-includes/media.php` is hardcoding an inline `style=""width:""` attribute on the outer `