ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter 23284,Wrong parameter order for stripos in wp-includes/functions.php,,General,3.5,normal,normal,3.5.2,defect (bug),new,has-patch,2013-01-24T14:07:22Z,2013-03-03T20:18:42Z,"In wp-includes/functions.php lines 658 and 661 stripos is used two times with parameters in the wrong order. This would be correct: {{{ if ( 0 === stripos( $uri, 'http://' ) ) { }}} {{{ } elseif ( 0 === stripos( $uri, 'http://' ) ) { }}}",Kalindor 23337,"TinyMCE, webkit and backspace/linebreak/italic issues",,TinyMCE,3.5.1,normal,normal,3.5.2,defect (bug),new,,2013-01-31T08:23:50Z,2013-04-30T08:42:07Z,"On WP 3.5.1 and nightly I notice irregularities in TinyMCE on webkit (Chrome, Safari). When editing existing paragraphs in TinyMCE visual mode: - After deleting a paragraph break, it is impossible to insert a single linebreak - When deleting paragraph breaks, sometimes text will be wrapped in `...` Steps to reproduce: 1. In a new post, type: ""One[return]two[return]three"" (i.e. three paragraphs) 2. Position the caret before the word ""three"". Hit [delete] to merge paragraphs two and three. 3. Do a shift+return key combo, which should insert a single linebreak. Instead, a paragraph break is inserted. 4. Place the caret before the word ""two"". Hit [delete] to merge paragraphs one and two. The third paragraph is italicised. Viewing the HTML source will show that it has been wrapped in an `em` tag with the id `""__mceDel""` Expected behaviour: - After deleting the space between two paragraphs, shirt+return should insert a single linebreak. - Text should not be italicised without the user having specified for TinyMCE to do so. I can consistently reproduce this behaviour in Chrome and Safari. Firefox seems to work as expected. I have tested with a clean install of WP 3.5.1 and the nightly build. I have tested on two different computers. OS: OS X Lion Browser: Chrome 24.0.1312.56, Safari 6.0.2",jnicol 23178,"Screen reader shortcut links generated by _render() from WP_Admin_Bar class should use rel=""nofolow""",,Toolbar,,normal,normal,3.5.2,defect (bug),new,has-patch,2013-01-11T13:07:29Z,2013-04-02T12:45:12Z,"Screen reader related links generated by _render() from WP_Admin_Bar class assume toolbar is being shown only to logged in users. When toolbar is being shown to visitors using {{{ function my_set_current_user() { if(!is_user_logged_in()){ add_filter('show_admin_bar', '__return_true'); } } add_action('set_current_user', 'my_set_current_user'); }}} search engines report 403 error code on every page of the website when trying to follow wp_logout_url() from one of these links (Logout link). Including rel=""nofollow"" into _render() should avoid this. ",Marko-M 23715,Plugins/Themes that rely on get_option('embed_autourls') may fail in 3.5.x,,Embeds,3.5,normal,normal,3.5.2,defect (bug),new,commit,2013-03-07T17:43:17Z,2013-04-18T06:56:31Z,"After upgrading to WordPress 3.5. or greater from 3.4.x and below, the option ""embed_autourls"" will still exist in the database. Plugins or Themes that make assumptions based on this may fail as regardless of the answer, the actual behavior is that embed_autourls is always on per http://codex.wordpress.org/Embeds WordPress will automatically turn that into a YouTube embed when the post is viewed. As of 3.5, Auto-embeds are automatically enabled and there is no setting to turn them off in the WordPress admin pages. Prior to 3.5, there was an ""Auto-embeds"" checkbox in Administration > Settings > Media SubPanel. Backwards compatibility could be preserved if this option would always return true from 3.5.x onward. Perhaps removing this option (from all sites if multisite) as an upgrade step could be another solution (though terrifying) to at least have a consistent (though not helpful) return value. These are just ideas that come to mind. I did a quick scan through the options code I didn't see a history of forcing an option to a specific value for historical purposes. I assume this ticket will likely result in a ""won't fix"" but I wanted to make a record of it in the event others search the bug database. Thank you for your time!",standardbanter 23555,Fatal error when sunrise added,,Multisite,3.5.1,low,normal,3.5.2,defect (bug),new,has-patch,2013-02-20T09:18:07Z,2013-03-18T13:46:48Z,"Hi, I have installed a WordPress multisite subdomains on a server. I have added a sunrise.php file on the wp-content folder. In this file there is a $wpdb->prepare without the needed argument at the end. WordPress throw a _doing_it_wrong() but this launch a Fatal error : {{{ Fatal error: Call to undefined function __() in /home/site/public_html/wp-includes/functions.php }}} {{{ Call Stack: 0.0001 335660 1. {main}() /home/site/public_html/wp-admin/network/settings.php:0 0.0001 335964 2. require_once('/home/site/public_html/wp-admin/network/admin.php') /home/site/public_html/wp-admin/network/settings.php:11 0.0001 336260 3. require_once('/home/site/public_html/wp-admin/admin.php') /home/site/public_html/wp-admin/network/admin.php:13 0.0002 336564 4. require_once('/home/site/public_html/wp-load.php') /home/site/public_html/wp-admin/admin.php:30 0.0002 337136 5. require_once('/home/site/public_html/wp-config.php') /home/site/public_html/wp-load.php:29 0.0002 337500 6. require('/home/site/public_html/wp-config-dev.php') /home/site/public_html/wp-config.php:6 0.0003 339004 7. require_once('/home/site/public_html/wp-settings.php') /home/site/public_html/wp-config-dev.php:109 0.0037 791980 8. require('/home/site/public_html/wp-includes/ms-settings.php') /home/site/public_html/wp-settings.php:87 0.0038 793784 9. include_once('/home/site/public_html/wp-content/sunrise.php') /home/site/public_html/wp-includes/ms-settings.php:18 0.0039 795552 10. wpdb->prepare() /home/site/public_html/wp-content/sunrise.php:41 0.0039 795872 11. _doing_it_wrong() /home/site/public_html/wp-includes/wp-db.php:995 }}} Is this normal that the translations function are not available ?",Rahe 23683,Fatal error in WP_User_Query,SergeyBiryukov,Users,3.4,normal,normal,3.5.2,defect (bug),reopened,commit,2013-03-04T05:54:40Z,2013-04-04T15:58:07Z,"To reproduce in single site: 1. Go to Users screen. 2. Enter a URL into the search input and click ""Search Users"". 3. You'll see a fatal error: {{{ Fatal error: Call to undefined function wp_is_large_network() in wp-includes/user.php on line 477 }}} `wp_is_large_network()` is only defined in Multisite admin: [[BR]] http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/includes/ms.php#L696 This can be reproduced when using `WP_User_Query` on front-end as well (in single site and Multisite). Introduced in [19886].",SergeyBiryukov 23418,banned names / illegal_names not being banned,,Multisite,3.5.1,normal,normal,3.5.2,defect (bug),new,has-patch,2013-02-08T04:41:52Z,2013-05-10T16:59:56Z,"new site registrations are ignoring the banned names i add to the list in network options. out of the gate the default banned names function works and the system does not let me register any of those default names. the illegal_names value in the wp_sitemeta table is populated with: '''''a:7:{i:0;s:3:""www"";i:1;s:3:""web"";i:2;s:4:""root"";i:3;s:5:""admin"";i:4;s:4:""main"";i:5;s:6:""invite"";i:6;s:13:""administrator"";}''''' when i add '''''seven eight nine''''' to the banned names field of the network setting page and save the page, the banned names field is populated with '''''www web root admin main invite administrator seven eight nine''''', just how you would expect. but now the illegal_names value in the db is '''''a:1:{i:0;s:61:""www web root admin main invite administrator seven eight nine"";}''''' notice how the serialized array only has one string now instead of the original multiple strings. once it is saved like this users can register any site name including defaults like admin and root plus the new names i added to the list. my setup: two fresh multisite 3.5.1 installs. one is on a vps and the other on a local xampp install. no plugins activated nor installed. using twenty twelve theme. these are test installs.",dohman