From wp-trac at lists.automattic.com Thu Nov 1 01:06:31 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 01:06:50 2007 Subject: [wp-trac] [WordPress Trac] #5299: JS/AJAX form validation Message-ID: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> #5299: JS/AJAX form validation ----------------------+----------------------------------------------------- Reporter: mdawaffe | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- Due to the new jQuery list manipulation code, there are a few forms in WP that, when submitted with no data (e.g. with a stray click or return), respond with "AJAX is teh b0rked". That's a error message not meant to be seen by users :) Currently, the jQuery wp-lists JS offers a few hooks where custom, per- form JS can be written to do arbitrary form validation and to prevent bad submissions. But repeating for each form "don't bother to submit if the form is empty. Display feedback as necessary instead" is obnoxious. Also, WP can already do arbitrary form validation using the WP_Error class (witness the Add User form), but could be touched up a bit to give better feedback. Proposed : 1. Via JS: If a form element is empty and has some ancestor element with class "required", that ancestor element gets a new "invalid" class and the form is not submitted. Rationale: We know right away something is wrong, so we give feedback without having to send a request to the server. 2. Via AJAX: If a WP_Error object is returned in the AJAX response (via the WP_Ajax_Response class), match up the error codes with the form elements and give a new "invalid" class to the first ancestor element with class "form-field" for each of those matching form elements. Also display the error messages as we currently do. Rationale: Since we can't know client side that the data is valid (without writing a lot of extra JS), we submit via AJAX and give feedback based on any WP_Error objects. Example : {{{
Name
Age
}}} If a user tries to submit an empty form, the first TR will immediately gets the "invalid" class and the form is not submitted. Why? It has the "required" class and one of it's descendants is an empty form element. If the user enters a "Shirley" into the name field and "young" in the age field and submits, suppose a WP_Error object is returned: {{{ object(wp_error)(2) { ["errors"]=> array(1) { ["age"]=> array(1) { [0]=> string(31) "You must give your age in years" } } ["error_data"]=> array(0) { } } }}} The TR with the age field in it is given the "invalid class" and the error message is shown. Why? Because the returned WP_Error object contains an error with code "age". So we'd have 3 methods of form validation. 1. Current hooks in wp-lists JS that allow submission to be canceled/relegated to traditional (non-AJAX) request. 2. Looking for blank inputs in elements with the "required" class. 3. Interpreting WP_Error objects sent back in the AJAX response. Attached : 1. Implements proposal. 2. Uses method 1 (current hooks) to prevent submission of blank on-the- fly AJAX category adding to posts on the Write screen. 3. Uses methods 2 (required) and 3 (WP_Error) in concert to validate other AJAX based forms: Category adding from Manage -> Categories and Blogroll -> Categories, User adding from Users. To Test : 1. Hit enter in a blank Add New User form. Name, email, password should turn red. 2. Enter " " as name, " " as email, "1" as password 1, "2" as password 2 in Add New User form. Submit. Fields should turn red, and detailed explanations are given. 3. Hit enter in blank ajax-cat form on Write -> Post screen. Nothing should happen. 4. Enter "{{{,,}}}" (three blank categories) into ajax-cat form. Submit. Request is actually submitted, but nothing will happen server side (good), and nothing will happen after response comes through (good). 5. Submit blank Add New Category form (Manage -> Categories). Name should turn red. 6. Enter " " as name in Add New Category form. Submit. Name should turn red, should get error message. 7. Repeat 5, 6 for Blogroll -> Categories form. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 02:11:28 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 02:11:35 2007 Subject: [wp-trac] Re: [WordPress Trac] #5300: User registration time not being saved In-Reply-To: <046.18c6385c95dfbc9a96b98cc5a1c8f77d@lists.automattic.com> References: <046.18c6385c95dfbc9a96b98cc5a1c8f77d@lists.automattic.com> Message-ID: <055.77c70a5bcd24027cf90a1e9ebc8d4aff@lists.automattic.com> #5300: User registration time not being saved ------------------------------+--------------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch commit | ------------------------------+--------------------------------------------- Changes (by mdawaffe): * keywords: => has-patch commit * owner: anonymous => mdawaffe * status: new => assigned -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 02:47:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 02:47:45 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.675c522388764424292a6337a42dd239@lists.automattic.com> #5298: https atom service document doesn't point to https collections ---------------------+------------------------------------------------------ Reporter: rubys | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by josephscott): * cc: josephscott (added) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 03:36:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 03:36:09 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.b95dd7267ccdcd20c6995c62037c9399@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Changes (by foolswisdom): * keywords: => has-patch * version: => 2.3.1 * milestone: 2.5 => 2.4 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 03:37:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 03:37:14 2007 Subject: [wp-trac] Re: [WordPress Trac] #5296: "Login" used in place of "Log In" (Grammar error) In-Reply-To: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> References: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> Message-ID: <051.f49c5780bb818c972f60bd9f6216580d@lists.automattic.com> #5296: "Login" used in place of "Log In" (Grammar error) -------------------------+-------------------------------------------------- Reporter: doug | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: Template | Version: Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Viper007Bond): http://dictionary.reference.com/search?q=login A perfectly valid usage of the word. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 04:43:25 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 04:43:30 2007 Subject: [wp-trac] Re: [WordPress Trac] #5296: "Login" used in place of "Log In" (Grammar error) In-Reply-To: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> References: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> Message-ID: <051.426adacaf0697b58e47357731f9b69be@lists.automattic.com> #5296: "Login" used in place of "Log In" (Grammar error) -------------------------+-------------------------------------------------- Reporter: doug | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Template | Version: 2.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Viper007Bond): I disagree. I think it is correct how it is now. "Login" isn't a mispelling of "log in", it's a completely different word and being properly used in this case IMO. Okay, so may not be the King's English or Oxford English or whatever (it's debatable), but in terms of the Internet, I think it's correct how it is and I'm strongly opposed to changing it. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 04:55:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 04:55:30 2007 Subject: [wp-trac] Re: [WordPress Trac] #5296: "Login" used in place of "Log In" (Grammar error) In-Reply-To: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> References: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> Message-ID: <051.fa5d009b885a81b92cdb4deab31d8a02@lists.automattic.com> #5296: "Login" used in place of "Log In" (Grammar error) -------------------------+-------------------------------------------------- Reporter: doug | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Template | Version: 2.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by foolswisdom): No point in arguing with you then. http://www.nytimes.com/ https://www.paypal.com/ http://www.basecamphq.com/ -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:08:59 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:09:04 2007 Subject: [wp-trac] Re: [WordPress Trac] #5296: "Login" used in place of "Log In" (Grammar error) In-Reply-To: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> References: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> Message-ID: <051.a9e363c8e904043e9f55c1b0a1cd8ead@lists.automattic.com> #5296: "Login" used in place of "Log In" (Grammar error) -------------------------+-------------------------------------------------- Reporter: doug | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Template | Version: 2.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Viper007Bond): Hmm. Then why does PayPal have "Account login"? Don't get me wrong, I get what you guys are saying, but it just seems "wrong". It would make sense for the button on the form to say "log in" as that's what you are doing -- logging in, but the link on the homepage is taking you to the "login form" and clicking it isn't logging you in. Or at least that's what make sense to my non-English teacher self. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:16:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:17:01 2007 Subject: [wp-trac] [WordPress Trac] #5301: WordPress can "leak" if a username is valid Message-ID: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ----------------------------+----------------------------------------------- Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: Administration | Version: 2.3 Severity: normal | Keywords: has-patch ----------------------------+----------------------------------------------- When you enter a valid username but an invalid password, WordPress lets you know the username is valid by complaining that only the password is invalid. Attached patch combines the two error messages so that if either the username or the password is wrong, it says the same error message which gives less away. Makes it harder for a hacker to gain access to a blog. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:21:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:22:01 2007 Subject: [wp-trac] Re: [WordPress Trac] #5301: WordPress can "leak" if a username is valid In-Reply-To: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> References: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> Message-ID: <059.11318d9c72b31561a4c840ec4f873bcd@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ----------------------------+----------------------------------------------- Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: Administration | Version: 2.3 Severity: normal | Resolution: Keywords: has-patch | ----------------------------+----------------------------------------------- Comment (by Viper007Bond): Oh, props to http://dougal.gunters.org/blog/2007/10/30/securing-wordpress -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:35:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:35:43 2007 Subject: [wp-trac] Re: [WordPress Trac] #5300: User registration time not being saved In-Reply-To: <046.18c6385c95dfbc9a96b98cc5a1c8f77d@lists.automattic.com> References: <046.18c6385c95dfbc9a96b98cc5a1c8f77d@lists.automattic.com> Message-ID: <055.8b47fc4dc41e2fea7975927743cf915d@lists.automattic.com> #5300: User registration time not being saved ------------------------------+--------------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch commit | ------------------------------+--------------------------------------------- Comment (by ryan): Lines 150 and 151 of admin-ajax.php have a syntax error. 150 is missing a semi-colon and 151 seems out-of-place. I removed 151 and put a semi on 150 and everything worked as described. Big ++. We need to return WP_Error from more of the functions used in admin- ajax.php. Some of them still return 0 for back compat reasons. We could add an arg to them that allows the caller to request WP_Error return. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:38:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:38:29 2007 Subject: [wp-trac] Re: [WordPress Trac] #5299: JS/AJAX form validation In-Reply-To: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> References: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> Message-ID: <055.e0d46c7ccb1ee500049ad5c0d7fa1c85@lists.automattic.com> #5299: JS/AJAX form validation ----------------------+----------------------------------------------------- Reporter: mdawaffe | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ryan): Lines 150 and 151 of admin-ajax.php have a syntax error. 150 is missing a semi-colon and 151 seems out-of-place. I removed 151 and put a semi on 150 and everything worked as described. Big ++. We need to return WP_Error from more of the functions used in admin- ajax.php. Some of them still return 0 for back compat reasons. We could add an arg to them that allows the caller to request WP_Error return. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:43:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:43:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #5301: WordPress can "leak" if a username is valid In-Reply-To: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> References: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> Message-ID: <059.842321307597adda40ad86c6b646b35e@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ----------------------------+----------------------------------------------- Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: Administration | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | ----------------------------+----------------------------------------------- Changes (by foolswisdom): * version: 2.3 => 2.3.1 * milestone: 2.3.2 => 2.5 Comment: False security? #3708 , #4290 . -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:44:48 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:44:57 2007 Subject: [wp-trac] Re: [WordPress Trac] #5299: JS/AJAX form validation In-Reply-To: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> References: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> Message-ID: <055.1f4450640b1f89ac272deea0132a5d3d@lists.automattic.com> #5299: JS/AJAX form validation -----------------------------------+---------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch 2nd-opinion | -----------------------------------+---------------------------------------- Changes (by mdawaffe): * keywords: => has-patch 2nd-opinion * owner: anonymous => mdawaffe * status: new => assigned Comment: 5299b.diff 1. Fixes syntax error on line 150. 2. Line 151 is kept. It skips the addition of a category if it's name is {{{''}}}. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:49:33 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:49:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5299: JS/AJAX form validation In-Reply-To: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> References: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> Message-ID: <055.0df590f68599823e73176442e8cbf5a9@lists.automattic.com> #5299: JS/AJAX form validation -----------------------------------+---------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch 2nd-opinion | -----------------------------------+---------------------------------------- Comment (by mdawaffe): While they're up for grabs, what do people think about the class names? {{{ invalid = some input in this box is no good form-field = this box contains some inputs (that might end up being invalid) required = this box contains required inputs }}} Should we standardize them? {{{ form-invalid form-field form-required input-invalid input-field / input-holder input-required }}} I guess I like the {{{form-}}} prefixed variants the best. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:51:23 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:51:28 2007 Subject: [wp-trac] Re: [WordPress Trac] #5299: JS/AJAX form validation In-Reply-To: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> References: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> Message-ID: <055.d4d7eded6449dbcaa79c840f147ab09f@lists.automattic.com> #5299: JS/AJAX form validation -----------------------------------+---------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch 2nd-opinion | -----------------------------------+---------------------------------------- Comment (by ryan): Prefixed ones sound good to me. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 05:55:09 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 05:55:15 2007 Subject: [wp-trac] Re: [WordPress Trac] #5301: WordPress can "leak" if a username is valid In-Reply-To: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> References: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> Message-ID: <059.7f4010b14e24e3d06ad5be8ed0d8e1f7@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ----------------------------+----------------------------------------------- Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: Administration | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | ----------------------------+----------------------------------------------- Comment (by Viper007Bond): Son of a... I knew I shoulda searched. That's what I get for being lazy. As mentioned in #3708, a username can still be found via alternate methods in some cases. But yeah, it doesn't stop things in the end, but why provide a username validator when we don't have to? This patch obviously won't stop a determined hacker, but just may make their life slightly harder in some cases. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 06:08:13 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 06:08:18 2007 Subject: [wp-trac] Re: [WordPress Trac] #5299: JS/AJAX form validation In-Reply-To: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> References: <046.999fc440967d0a830ebc6e91a0b42aa0@lists.automattic.com> Message-ID: <055.572978423b4fd9bffb3deaf421e6b5ab@lists.automattic.com> #5299: JS/AJAX form validation -----------------------------------+---------------------------------------- Reporter: mdawaffe | Owner: mdawaffe Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch 2nd-opinion | -----------------------------------+---------------------------------------- Comment (by mdawaffe): 5299c.diff 1. {{{form-}}} prefixed classes. 2. Fix line 151 for realies. Thanks rboren :) 3. Bug in on the fly link category addition. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 06:55:57 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 06:56:04 2007 Subject: [wp-trac] [WordPress Trac] #5302: upload breaks Message-ID: <045.d1aa516b04e2f4cdb3261d972b202c9e@lists.automattic.com> #5302: upload breaks ---------------------+------------------------------------------------------ Reporter: pizzamx | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Keywords: upload sql ---------------------+------------------------------------------------------ Upload function breaks when creating a new post or editing an existing post. The file *did* get uploaded, and the problem occurs when trying to modify the database: {{{ 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 'WHERE ID = '3' LIMIT 1' at line 1] UPDATE wp2_posts SET WHERE ID = '3' LIMIT 1 }}} ps., tested on a fresh copy checked out from trunk -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 07:22:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 07:25:06 2007 Subject: [wp-trac] [WordPress Trac] #5303: "Manage > Pages" becomes very slow with hundreds of pages Message-ID: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> #5303: "Manage > Pages" becomes very slow with hundreds of pages -----------------------+---------------------------------------------------- Reporter: MartijnD | Owner: anonymous Type: task | Status: new Priority: low | Milestone: 2.5 Component: General | Version: Severity: normal | Keywords: -----------------------+---------------------------------------------------- Apologies if this has been mentioned before, I couldn't find a relevant related bug. I am currently building a prototype blog / content site that has several hundreds of "Pages"; and things have slown down a lot. With just over 250 pages, generation of "Manage > Pages" takes over 30 seconds, which causes PHP time out errors on the server. Some profiling shows that most time is spend in: \wp-admin\includes\template.php 166: function page_rows() The code for hierarchal display is very inefficient, as it loops over and over the full set of posts to check if a post and a parent are related. 180: if ( $hierarchy && ($post->post_parent != $parent) ) 181: continue; Forcing $hierachy to false reduces the page creation time to 7-8 seconds. Still not great, it should be possible to do this in < 2 seconds. Please take this as suggestion for improvement. If I have time, I will look into finding a more efficient piece of code -- for now I still have a couple more pages to add ;-) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 07:58:17 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 07:58:24 2007 Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be used without including wp-settings.php In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> Message-ID: <057.3f17cc119d588200f9f9f574622617c6@lists.automattic.com> #5276: Allow wp-config.php to be used without including wp-settings.php --------------------------------------+------------------------------------- Reporter: mastermind | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: wp-config.php standalone | --------------------------------------+------------------------------------- Comment (by DD32): > we can't change wp-config.php easily. Very true, However, Luckely at present its a require_once statement. I'll suggest another method, add {{{ require_once( dirname(__FILE__) . '/wp-settings.php'); }}} to wp-blog-header.php and remove it from the default sample wp-config.php. If users still have the line in their wp-config.php, then it'll still work as expected, However, it'll mean that users can make their wp-config.php a stand alone file if a plugin requires it. (Who knows, If it was mentioned in a announcement, come a few releases down the track, it might be safe to assume that its no longer included). It means it wont be useful in the immediate future, but overtime it'll become available. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:02:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:02:28 2007 Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be used without including wp-settings.php In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> Message-ID: <057.e18099cf435f73f203df197839bbec32@lists.automattic.com> #5276: Allow wp-config.php to be used without including wp-settings.php --------------------------------------+------------------------------------- Reporter: mastermind | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: wp-config.php standalone | --------------------------------------+------------------------------------- Comment (by DD32): Hm, Just noticed removing that line from wp-config breaks other parts of WP. What should WP be including to kick-start itself? {{{wp-config.php}}} or {{{wp-blog-header.php}}} ? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:13:05 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:13:10 2007 Subject: [wp-trac] Re: [WordPress Trac] #5218: SAVEQUERIES: log calling function name In-Reply-To: <048.658e870a76381bb7f849fb8c96e4f26a@lists.automattic.com> References: <048.658e870a76381bb7f849fb8c96e4f26a@lists.automattic.com> Message-ID: <057.8598e8677658aa934a44a1442e088e36@lists.automattic.com> #5218: SAVEQUERIES: log calling function name -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by DD32): Another place which this would be useful is the SQL Errors, It'd be nice for the SQL error messages to include the function which is running the failing SQL. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:16:19 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:16:25 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.6d3358741f38492f2454ea239a7bb7c1@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Comment (by aroundmyroom): Version 2.3.1-RC1 is indeed removing the array issue everywhere after applying the patch in the plugin.php I will update my test wordpress with the latest version tonight and check again. Replying to [ticket:5261 aroundmyroom]: > version 2.1.3 is working without any problem, but with the release of version 2.2.2 there was introduced a bug called: ARRAY bug > at the support forums you can read this issue from other people as well > http://wordpress.org/support/topic/118367/page/2 > the solution for 2.2.2. was given by user SEVENETH posting some code to be changed in the plugin.php > > Trying to upgrade from 2.1.3 to 2.3 causes for me a lot of array issues inside the dashboard and options including the loss of all categories > > During my testing for 2.3 and now 2.3.1 I see the same issue > > if tracking my test weblog at http://www.aroudmyroom.com/test you also can see that there does exist an array category made by the system itself > > The server is running > PHP Version 4.3.9 > Apache/2.0.52 (CentOS > > in the support forums it seems that the ticket for the array issue was too easily closed and too easily refered to an necessary update for PHP and/or ZEND > -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:27:25 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:27:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #5302: upload breaks In-Reply-To: <045.d1aa516b04e2f4cdb3261d972b202c9e@lists.automattic.com> References: <045.d1aa516b04e2f4cdb3261d972b202c9e@lists.automattic.com> Message-ID: <054.a3049803c2ea6d290d751ca7ea8976f5@lists.automattic.com> #5302: upload breaks ----------------------------------+----------------------------------------- Reporter: pizzamx | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: upload sql has-patch | ----------------------------------+----------------------------------------- Changes (by DD32): * keywords: upload sql => upload sql has-patch -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:38:13 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:38:18 2007 Subject: [wp-trac] [WordPress Trac] #5304: Cannot upload images that are not Gif/jpeg/png Message-ID: <042.a730459ee82a73937b32553beabbdfd6@lists.automattic.com> #5304: Cannot upload images that are not Gif/jpeg/png ----------------------------+----------------------------------------------- Reporter: DD32 | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Keywords: ----------------------------+----------------------------------------------- An error is raised when uploading non gif/jpeg/png files if PHP reconises the image type. An example of this is a BMP file. wp_create_thumbnail Assumes that the filetype is of the given types, and fails otherwise. I've attached a patch which aborts creating the thumbnail if its not a supported type, But a better patch would be to change the function to use the IMAGETYPE_XXX constants(Instead of 1,2,3) and to support the full range of image formats. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:48:12 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:48:17 2007 Subject: [wp-trac] Re: [WordPress Trac] #5284: Editing & Posting Comments Causes Errors In-Reply-To: <043.918501dd08ae32d1a8dcfe924a670c83@lists.automattic.com> References: <043.918501dd08ae32d1a8dcfe924a670c83@lists.automattic.com> Message-ID: <052.a3f9e5641a3ab290b44bf455cb9baa62@lists.automattic.com> #5284: Editing & Posting Comments Causes Errors ---------------------+------------------------------------------------------ Reporter: asiah | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: Component: General | Version: Severity: normal | Resolution: wontfix Keywords: | ---------------------+------------------------------------------------------ Changes (by Nazgul): * milestone: 2.5 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:48:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:48:27 2007 Subject: [wp-trac] Re: [WordPress Trac] #5297: Unexpected behavior with plugins and global variables In-Reply-To: <048.bc1947e49af00cbffb8a7e06677ef076@lists.automattic.com> References: <048.bc1947e49af00cbffb8a7e06677ef076@lists.automattic.com> Message-ID: <057.6a5cfd8809e851354ad6b09dcf1a0874@lists.automattic.com> #5297: Unexpected behavior with plugins and global variables ----------------------------+----------------------------------------------- Reporter: PaulButler | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: Component: Administration | Version: Severity: normal | Resolution: invalid Keywords: | ----------------------------+----------------------------------------------- Changes (by Nazgul): * milestone: 2.5 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 08:48:35 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 08:48:40 2007 Subject: [wp-trac] Re: [WordPress Trac] #5289: wp_list_authors doesnt work with echo=false In-Reply-To: <045.393a85cad41bc886231d4fdd453cba32@lists.automattic.com> References: <045.393a85cad41bc886231d4fdd453cba32@lists.automattic.com> Message-ID: <054.00a0583e9efc4a881904b632465d55b1@lists.automattic.com> #5289: wp_list_authors doesnt work with echo=false ----------------------+----------------------------------------------------- Reporter: fgubert | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: Component: Template | Version: 2.3.1 Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by Nazgul): * milestone: 2.3.2 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 12:11:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 12:11:41 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.e1bed2796f4ad23732d413bd5daab33b@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Comment (by darkdragon): Which patch did you use? Mine or the one in the forum? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 12:14:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 12:15:04 2007 Subject: [wp-trac] Re: [WordPress Trac] #3686: index page gives 404 when using non-default permalinks In-Reply-To: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com> References: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com> Message-ID: <053.f0b3f1654e5a658b099636e4f373fb18@lists.automattic.com> #3686: index page gives 404 when using non-default permalinks ----------------------------------------+----------------------------------- Reporter: jamesw | Owner: markjaquith Type: defect | Status: new Priority: low | Milestone: 2.4 Component: General | Version: 2.1 Severity: normal | Resolution: Keywords: permalinks pages 404 error | ----------------------------------------+----------------------------------- Comment (by jamesw): If it helps anyone diagnose what's wrong, I've set up a PHPInfo page that should allow those a bit better skilled to see what my potential problem might be. http://www.mameworld.net/agemame/test.php I haven't tried the workaround listed above, as I'm reluctant to change permalink structures, particularly since I already have issues with canonical redirects. I'm not posting a ticket for that, though, because it's probably down to my REQUEST_URI being screwed up. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 13:04:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 13:04:51 2007 Subject: [wp-trac] Re: [WordPress Trac] #5296: "Login" used in place of "Log In" (Grammar error) In-Reply-To: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> References: <042.d2b6e8fa3876080cd875e6449d711dbb@lists.automattic.com> Message-ID: <051.bf17ecdc79b9644dfd1991612ae33bca@lists.automattic.com> #5296: "Login" used in place of "Log In" (Grammar error) -------------------------+-------------------------------------------------- Reporter: doug | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Template | Version: 2.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by doug): I'm not talking about Oxford English, just English. :) As you say, "log in" and "login" are different words (whether used on the Internet or not), and I think it's important to use the right one. Replying to [comment:8 Viper007Bond]: > It would make sense for the button on the form to say "log in" as that's what you are doing -- logging in, but the link on the homepage is taking you to the "login form" and clicking it isn't logging you in. I'm glad you agree the button on the login form should say "Log In" because it is indeed performing an action and thus requires a verb. As for the link on the homepage, it's less clear, but I would argue that a typical user sees this and thinks "I need to click here to log in," not "I need to click here because this takes me to the login form, which will let me log in." It's a subtle difference, but users tend to think in actions, not objects. You (or the application) would tell someone: "Log in [to do more stuff]" not "go the login form." And again, this is the approach the WordPress forums take. Thanks for considering. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 14:04:04 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 14:04:11 2007 Subject: [wp-trac] Re: [WordPress Trac] #5301: WordPress can "leak" if a username is valid In-Reply-To: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> References: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> Message-ID: <059.ba016590698fb16516d8a5266b477194@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ---------------------------------+------------------------------------------ Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: Administration | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch, security | ---------------------------------+------------------------------------------ Changes (by dougal): * keywords: has-patch => has-patch, security Comment: Thanks for putting this ticket in. I was going to do it myself, but just hadn't found the time yet. Disclosing whether the username or password was incorrect like this is a definite security no-no. This is oooold security-fu. Security-by- obscurity? In a sense. But when you give somebody a definite part of the key, it just makes the rest that much easier. Any security knowledge base out there will tell you not to give this type of info away. Look back over the old changelogs for SSH sometime. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 14:23:55 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 14:24:00 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.c44b02448d9e93c37244886d004be095@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Comment (by aroundmyroom): Darkdragon: I used your patch and for 2.3.1RC1 it was working indeed, the forum fix I only used in 2.2.2 now just copied all 2.3.1 sources over the 2.1.3RC1 location & using same config: re-applied the patch onto the new plugin.php But now the ARRAY is again appearing in the Pages (see http://www.aroundmyroom.com/test -> right side column and in the admin menu you can see it clearly selecting ie. categories, for a new category everywhere we see 'ARRAY' like: Presentation Current Theme Array Array by Array Array All of this theme?s files are located in Array. or when selecting users: Authors & Users you do not see anything .. at the profile Yahoo IM: ARRAY Jabber / Google Talk: ARRAY So the patched worked for 2.1.3RC1 but for 2.1.3 a no go in my plugin.php it is around line 104 $r = isset($GLOBALS['wp_filter'][$tag][$priority][$function_to_remove]); $GLOBALS['wp_filter'][$tag][$priority][$function_to_remove] = array(); unset($GLOBALS['wp_filter'][$tag][$priority][$function_to_remove]); unset($GLOBALS['merged_filters'][$tag]); } this is not working in 2.3.1 but did in 2.3.1RC1 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 14:25:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 14:25:38 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.9ee473a7dd41dab6b04ebbd37d41957d@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Comment (by aroundmyroom): erratum: " So the patched worked for 2.1.3RC1 but for 2.1.3 a no go " must be .... 2.3.1RC but for 2.3.1 a no go .. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 15:36:45 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 15:36:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #5274: Automatic pingback comments created for blog post that link to blog pages on the local blog In-Reply-To: <045.09f89e864ed1402f80aff24632e0ae93@lists.automattic.com> References: <045.09f89e864ed1402f80aff24632e0ae93@lists.automattic.com> Message-ID: <054.979abb8e53f53134c843342378de009d@lists.automattic.com> #5274: Automatic pingback comments created for blog post that link to blog pages on the local blog ---------------------+------------------------------------------------------ Reporter: Skywing | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: Component: General | Version: 2.3.1 Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by westi): * milestone: 2.5 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 15:36:40 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 15:39:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #5274: Automatic pingback comments created for blog post that link to blog pages on the local blog In-Reply-To: <045.09f89e864ed1402f80aff24632e0ae93@lists.automattic.com> References: <045.09f89e864ed1402f80aff24632e0ae93@lists.automattic.com> Message-ID: <054.a26668c4db31536657c7eda66ce625e8@lists.automattic.com> #5274: Automatic pingback comments created for blog post that link to blog pages on the local blog ---------------------+------------------------------------------------------ Reporter: Skywing | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by westi): * status: new => closed * resolution: => invalid Comment: This is by design. Pages support comments fine if your theme disables them. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 15:48:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 15:48:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #4545: Slashing consistency In-Reply-To: <049.c5627490e8fabb49d8403fd187a48f43@lists.automattic.com> References: <049.c5627490e8fabb49d8403fd187a48f43@lists.automattic.com> Message-ID: <058.98bd4d026ecbfdbcfb5a21a04a928595@lists.automattic.com> #4545: Slashing consistency -------------------------+-------------------------------------------------- Reporter: markjaquith | Owner: anonymous Type: task | Status: new Priority: normal | Milestone: 2.4 Component: Security | Version: 2.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by pishmishy): I'm not sure that this ticket is worth keeping open when #4553 appears to be addressing this issue. Resolve as duplicate? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:13:20 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:13:26 2007 Subject: [wp-trac] Re: [WordPress Trac] #2756: Reduce memory usage when many pages and users are present In-Reply-To: <042.e3fc5e924e68e1ac4e38f6fa4ea3aed4@lists.automattic.com> References: <042.e3fc5e924e68e1ac4e38f6fa4ea3aed4@lists.automattic.com> Message-ID: <051.1285ffe188b32ef71ffdafaf94144967@lists.automattic.com> #2756: Reduce memory usage when many pages and users are present --------------------------------+------------------------------------------- Reporter: ryan | Owner: anonymous Type: enhancement | Status: closed Priority: normal | Milestone: 2.1 Component: Administration | Version: 2.0.2 Severity: normal | Resolution: fixed Keywords: performance memory | --------------------------------+------------------------------------------- Changes (by foolswisdom): * status: new => closed * resolution: => fixed * milestone: 2.5 => 2.1 Comment: Lets call this done, and create a new bug with some details -- I wonder if anyone knows what this is about anymore anyway. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:14:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:14:27 2007 Subject: [wp-trac] Re: [WordPress Trac] #5303: "Manage > Pages" becomes very slow with hundreds of pages In-Reply-To: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> References: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> Message-ID: <056.b50624be84824f4fe208ad25858138ff@lists.automattic.com> #5303: "Manage > Pages" becomes very slow with hundreds of pages -----------------------+---------------------------------------------------- Reporter: MartijnD | Owner: anonymous Type: task | Status: new Priority: low | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by ryan): Yes, that code is awful. Improvements are definitely welcome. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:16:51 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:16:56 2007 Subject: [wp-trac] Re: [WordPress Trac] #5303: "Manage > Pages" becomes very slow with hundreds of pages In-Reply-To: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> References: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> Message-ID: <056.cdd5cbbdbdcd86632fc18bce4c056ccd@lists.automattic.com> #5303: "Manage > Pages" becomes very slow with hundreds of pages -----------------------+---------------------------------------------------- Reporter: MartijnD | Owner: anonymous Type: task | Status: new Priority: low | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by foolswisdom): Relates to #5303? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:20:51 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:20:57 2007 Subject: [wp-trac] Re: [WordPress Trac] #5304: Cannot upload images that are not Gif/jpeg/png In-Reply-To: <042.a730459ee82a73937b32553beabbdfd6@lists.automattic.com> References: <042.a730459ee82a73937b32553beabbdfd6@lists.automattic.com> Message-ID: <051.90bc55a9ff7f6b70dd7cba4d1cb0ac66@lists.automattic.com> #5304: Cannot upload images that are not Gif/jpeg/png ------------------------------------------+--------------------------------- Reporter: DD32 | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch developer-feedback | ------------------------------------------+--------------------------------- Changes (by foolswisdom): * keywords: => has-patch developer-feedback -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:26:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:26:28 2007 Subject: [wp-trac] Re: [WordPress Trac] #5301: WordPress can "leak" if a username is valid In-Reply-To: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> References: <050.869abd700cbf812902cbafd7590ddff0@lists.automattic.com> Message-ID: <059.7baf0738ecf9f7c72b797c4ce30a9644@lists.automattic.com> #5301: WordPress can "leak" if a username is valid ---------------------------------+------------------------------------------ Reporter: Viper007Bond | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: Administration | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch, security | ---------------------------------+------------------------------------------ Comment (by foolswisdom): The loss of usability has no benefit if this information can be attained trivially other ways. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:37:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:37:50 2007 Subject: [wp-trac] Re: [WordPress Trac] #5303: "Manage > Pages" becomes very slow with hundreds of pages In-Reply-To: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> References: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> Message-ID: <056.a20a1705a183a9b3e428a063488853f6@lists.automattic.com> #5303: "Manage > Pages" becomes very slow with hundreds of pages -----------------------+---------------------------------------------------- Reporter: MartijnD | Owner: anonymous Type: task | Status: new Priority: low | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Comment (by foolswisdom): Gah, relates to 3614? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 16:37:54 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 16:37:59 2007 Subject: [wp-trac] Re: [WordPress Trac] #3614: Scaling issue with hundreds of pages In-Reply-To: <049.c1ed6899e94a2d178a80c197a0cbca6b@lists.automattic.com> References: <049.c1ed6899e94a2d178a80c197a0cbca6b@lists.automattic.com> Message-ID: <058.ea902873e570aee0b8d7e7cf98ff2c0e@lists.automattic.com> #3614: Scaling issue with hundreds of pages --------------------------+------------------------------------------------- Reporter: markjaquith | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.4 Component: Optimization | Version: 2.0.7 Severity: critical | Resolution: Keywords: needs-patch | --------------------------+------------------------------------------------- Comment (by foolswisdom): Relates to #5303? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 17:11:19 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 17:11:25 2007 Subject: [wp-trac] Re: [WordPress Trac] #4115: getCategoryList should not include Blogroll in list of categories In-Reply-To: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com> References: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com> Message-ID: <057.586bb22a9a5d6d7e653fc042c82db45b@lists.automattic.com> #4115: getCategoryList should not include Blogroll in list of categories -------------------------+-------------------------------------------------- Reporter: redsweater | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: XML-RPC | Version: 2.2 Severity: normal | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Changes (by redsweater): * summary: getCategoryList should exclude empty categories by default => getCategoryList should not include Blogroll in list of categories Comment: I'm changing the Summary from: getCategoryList should exclude empty categories by default to: getCategoryList should not include Blogroll in list of categories That better emphasizes my core concern here. I thought when I first reported this that it might get better traction if I stated the problem as more of a "consistency problem." But what I really want is to get that dang "Blogroll" item out of the category list, because it confuses my users (and ultimately causes users to resent WordPress's behavior). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 17:12:47 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 17:12:53 2007 Subject: [wp-trac] Re: [WordPress Trac] #5303: "Manage > Pages" becomes very slow with hundreds of pages In-Reply-To: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> References: <047.a53bb4764248dfb894898e1eb6836e14@lists.automattic.com> Message-ID: <056.9bec05046996a91c5dc6cbe6d7c9be31@lists.automattic.com> #5303: "Manage > Pages" becomes very slow with hundreds of pages -----------------------+---------------------------------------------------- Reporter: MartijnD | Owner: anonymous Type: task | Status: new Priority: low | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Changes (by besonen): * cc: davidb@panix.com (added) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 17:42:23 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 17:42:32 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.157862d89f027292d0a6309ee4e679c1@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by mattyrob): > Who would have known, turns out this is bad mojo, and doesn't play nice with other configurations, causing regressions #5273 and 5294 . Seems that in some environments if you are smart enough to set the Sender, you are dumb to be a spammer, and so they run it through "callout verification". That's bad news - seems we're damned if we do set Sender and we're damend if we don't depending on the server config :-( I think we should set it to be honest as it's consistent and valid. Any host dropping email that sets Sender is being overly strict IMO. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 18:25:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 18:25:42 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.54bc36fd71c76f0dde840f64eadead22@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by lloydbudd): Replying to [comment:9 mattyrob]: > consistent and valid. That's the problem, for most members it isn't valid. wordpress@[domain] doesn't exist. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 19:19:06 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 19:19:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.100b18d33f87bc56a7954915c45975f6@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by westi): I guess the solution is going to be: * Revert the change * For those people that need Sender set I will make available a simple plugin which sets it - a reverse of the one available on here http://trac.wordpress.org/attachment/ticket/5273/no-sender.php -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 20:17:23 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 20:17:30 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.fa0e6b1d09ba89a7f05cdaaef39ee2c3@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by lloydbudd): westi, sounds good. A longer term project may be to evaluate using the admin email address or helping set and ensuring a valid email is used (maybe using this same "callout verification" technique, hehe) -- its own ticket, for another day. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 21:27:54 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 21:28:02 2007 Subject: [wp-trac] [WordPress Trac] #5305: permalinks broken when article name is numeric Message-ID: <045.015dba03a5b592cfc89fb519871f734a@lists.automattic.com> #5305: permalinks broken when article name is numeric ---------------------+------------------------------------------------------ Reporter: thomask | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: major | Keywords: permalinks, number ---------------------+------------------------------------------------------ if you create numeric-only post name, the generated slug is this number - this conflicts with article ID, so it returns different article or 404 page, never the article. It can be then solved by generating manual slug with some char in it, but i think it would be better to include some char in that case, e.g. underscore, like _123 Also if someone will try to solve this, it would be nice to solve other problem - if post slug is begining with the slug of the category, than the category page returns that post, not the category -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 21:44:10 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 21:44:16 2007 Subject: [wp-trac] Re: [WordPress Trac] #5305: permalinks broken when article name is numeric In-Reply-To: <045.015dba03a5b592cfc89fb519871f734a@lists.automattic.com> References: <045.015dba03a5b592cfc89fb519871f734a@lists.automattic.com> Message-ID: <054.a7ff0608b44dbdda3e30f63d5400b3a3@lists.automattic.com> #5305: permalinks broken when article name is numeric --------------------------------+------------------------------------------- Reporter: thomask | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: permalinks, number | --------------------------------+------------------------------------------- Comment (by lloydbudd): thomask, can you include your Permalink Structure? And provide specific examples? This could help duplicate the problem. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 21:57:10 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 21:57:14 2007 Subject: [wp-trac] Re: [WordPress Trac] #4528: post_modified not set for first save of draft In-Reply-To: <049.fea049ec0c8610913e464dce9b1195cc@lists.automattic.com> References: <049.fea049ec0c8610913e464dce9b1195cc@lists.automattic.com> Message-ID: <058.6a546c98217bfb3dbdf363df50513d3e@lists.automattic.com> #4528: post_modified not set for first save of draft ----------------------------+----------------------------------------------- Reporter: markjaquith | Owner: markjaquith Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.3 Severity: normal | Resolution: Keywords: | ----------------------------+----------------------------------------------- Changes (by brh): * cc: brh@numbera.com (added) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 22:12:49 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 22:12:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.5becd86bf8a39afa16131aa3a8342950@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by westi): Replying to [comment:12 lloydbudd]: > westi, sounds good. A longer term project may be to evaluate using the admin email address or helping set and ensuring a valid email is used (maybe using this same "callout verification" technique, hehe) -- its own ticket, for another day. I'm pretty sure we used to use the admin address at one point - I can't remember exactly why it changed to the current method. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 1 23:30:02 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 1 23:30:12 2007 Subject: [wp-trac] [WordPress Trac] #5306: Canonical redirect conflicts with hosting provider's redirect Message-ID: <044.b9be7501a00dacd084274b5f3bd46d79@lists.automattic.com> #5306: Canonical redirect conflicts with hosting provider's redirect -------------------------+-------------------------------------------------- Reporter: vocaro | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3 Severity: normal | Keywords: -------------------------+-------------------------------------------------- WordPress 2.3 includes a new canonical redirect feature. It is designed to deal with such problems as Google seeing `yoursite.com` and `www.yoursite.com` as two different entities. Some hosting providers offer a similar redirect feature. With DreamHost, for example, you can configure your domain so that the web server redirects any request for `www.yoursite.com` to `yoursite.com` (i.e., it removes the `www` prefix). When both of these features are enabled at the same time, they conflict with each other. You will experience HTTP errors such as: Too many HTTP redirects or: Firefox has detected that the server is redirecting the request for this address in a way that will never complete. To fix this problem, you must go to the WordPress admin page and switch to the Options > General section. For the WordPress address and Blog address entries, remove the `www` prefix from both URLs. The canonical redirect feature should be changed so that this problem doesn't occur. For example, canonical redirection could be disabled by default, or perhaps there is some way for WordPress to detect the `www` prefix removal by the web server and then automatically remove `www` from the URL entries in the WordPress settings. At the very least, there should be a documentation note on this problem and how to fix it. This ticket is related to #5089 and #5017. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 10:12:01 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 10:12:08 2007 Subject: [wp-trac] Re: [WordPress Trac] #5306: Canonical redirect conflicts with hosting provider's redirect In-Reply-To: <044.b9be7501a00dacd084274b5f3bd46d79@lists.automattic.com> References: <044.b9be7501a00dacd084274b5f3bd46d79@lists.automattic.com> Message-ID: <053.b8a8c39ba3745d848579f14020a99652@lists.automattic.com> #5306: Canonical redirect conflicts with hosting provider's redirect -------------------------------+-------------------------------------------- Reporter: vocaro | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: reporter-feedback | -------------------------------+-------------------------------------------- Changes (by westi): * keywords: => reporter-feedback Comment: Can you confirm what you have set in the WordPress Address and Blog Address sections of the options screen. It sounds like you have them misconfigured. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 10:14:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 10:14:10 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.2d1f4419bc11b20c3bc8d9dabbbe2ecf@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Changes (by westi): * owner: anonymous => westi * status: new => assigned -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 10:17:18 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 10:17:25 2007 Subject: [wp-trac] Re: [WordPress Trac] #5295: wp-links-opml.php will not display a single link category In-Reply-To: <044.65c208aa9e0295645685056bc9be0cb6@lists.automattic.com> References: <044.65c208aa9e0295645685056bc9be0cb6@lists.automattic.com> Message-ID: <053.e9f9e590b0a51bfb630c33e18933ad0c@lists.automattic.com> #5295: wp-links-opml.php will not display a single link category ---------------------+------------------------------------------------------ Reporter: vrypan | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: opml | ---------------------+------------------------------------------------------ Changes (by westi): * owner: anonymous => westi * status: new => assigned -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 10:21:43 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 10:21:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #5287: Setup table names inside wpdb In-Reply-To: <042.da84756ea2414992e580e5855b8966f4@lists.automattic.com> References: <042.da84756ea2414992e580e5855b8966f4@lists.automattic.com> Message-ID: <051.20bde50fcca8ac256212aec506741597@lists.automattic.com> #5287: Setup table names inside wpdb ---------------------+------------------------------------------------------ Reporter: ryan | Owner: ryan Type: defect | Status: closed Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: fixed Keywords: wpdb | ---------------------+------------------------------------------------------ Comment (by westi): Don't we need to use the function too? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 11:15:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 11:15:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #4755: WordPress should use code from the modified kses at Sourceforge.net In-Reply-To: <047.3f2c13bc7857929ceb6b636206ce0069@lists.automattic.com> References: <047.3f2c13bc7857929ceb6b636206ce0069@lists.automattic.com> Message-ID: <056.6e40c5d81e8963d15f02c6bb82d36d18@lists.automattic.com> #4755: WordPress should use code from the modified kses at Sourceforge.net --------------------------+------------------------------------------------- Reporter: alpha2zee | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Optimization | Version: Severity: normal | Resolution: Keywords: | --------------------------+------------------------------------------------- Comment (by alpha2zee): This kses mod has evolved into [http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/index.php htmLawed]. * highly and easily customizable * ~45 kb single-file, non-OOP code with peak basal memory usage of ~0.5 MB * improved tag balancing, entity checks and conversions * remains kses-compatible * NEW: transformation of deprecated tags/attributes * NEW: anti-email/link spam measures * NEW: absolute/relative URL conversions * NEW: filtering/conversion of bad characters introduced by Microsoft Word, etc. * etc... see [http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawed_README.htm htmLawed documentation] A testing script is in the [http://bioinformatics.org/phplabware/downloads/htmLawed.zip download]; htmLawed can also be [http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php tried online]. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 11:15:54 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 11:15:59 2007 Subject: [wp-trac] [WordPress Trac] #5307: Partially back out changeset 5273, ticket 5181 Message-ID: <043.b9d3324220a43283ac4f7575844c9189@lists.automattic.com> #5307: Partially back out changeset 5273, ticket 5181 ---------------------+------------------------------------------------------ Reporter: rubys | Owner: westi Type: defect | Status: new Priority: high | Milestone: 2.4 Component: General | Version: 2.4 Severity: major | Keywords: has-patch ---------------------+------------------------------------------------------ 2.4-bleeding has been deployed on wordpress.com which exposes a problem with the patch associated with [http://trac.wordpress.org/ticket/5181 ticket 5181]. This ticket partially backs that change out until a proper fix can be made. The root issue is that the app support and the rest of wp produce feeds differently, and in the process interpret the database differently. The app support will put HTML in $post->post_content, but the rest of wordpress assumes that the post_content contains text which, after passed through various filters, produces html. This is a subtle difference which doesn't show up immediately, but the simple presence of blank lines will cause the two to produce noticeably different results. For app to function properly, there needs to be a way to "unfilter" (x)html, i.e., a way to reverse engineer what text would produce the equivalent of a given (x)html result after filtering. But to that proper fix will take time, so meanwhile the 2.3 functionality should be restored -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 14:58:23 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 14:58:31 2007 Subject: [wp-trac] [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 Message-ID: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Keywords: cookie error ----------------------------+----------------------------------------------- After upgrading to WP 2.3 I (like everyone else) was experiencing the "cookie error" every time I logged into my site. When WP 2.3.1 was released I assumed that the new upgrade would fix the cookie errors, but it hasn't. Not matter on what computer or with what browser I try it with I always get the cookie error. I wasn't sure if any of the patches would work on 2.3.1 so I haven't tried them. I did however, try to see if my wp_config.php file had spacing issues and it didn't. I'm not sure what the next step is to fix this issue. Can I get some help? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 17:21:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 17:21:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5196: Support "minor edits" in Atom In-Reply-To: <043.83e5b6d4482dab476da4762820682a15@lists.automattic.com> References: <043.83e5b6d4482dab476da4762820682a15@lists.automattic.com> Message-ID: <052.4e91190bb66093f239647a04c2c37ca2@lists.automattic.com> #5196: Support "minor edits" in Atom -------------------------+-------------------------------------------------- Reporter: rubys | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by rubys): [http://ascher.ca/blog/2007/11/01/marsedit-wordpress-planet-and-minor- updates/ MarsEdit, Wordpress, Planet, and minor updates] -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 17:23:54 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 17:24:00 2007 Subject: [wp-trac] [WordPress Trac] #5309: 'Insert/edit image' dialog changes empty fields to default values Message-ID: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> #5309: 'Insert/edit image' dialog changes empty fields to default values --------------------------+------------------------------------------------- Reporter: hermanschaap | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Keywords: --------------------------+------------------------------------------------- I first add a picture by uploading it and then clicking 'Send to editor'. Then I click the picture and click the 'Insert/edit image' button. In the dialog, the size is not filled out. I change the image description and click Update. Now, the picture is set to a size of 1x1. I see two solutions: 1) Add the size (and perhaps some of the other fields) to the image tag when sending it to the editor. 2) Change the 'Insert/edit image' dialog, so it ignores empty fields. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 21:34:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 21:34:31 2007 Subject: [wp-trac] [WordPress Trac] #5310: XMLRPC interface should expose mechanism for listing and deleting media resources Message-ID: <048.0bbebe99e47858b4857b9fb9ab498fe1@lists.automattic.com> #5310: XMLRPC interface should expose mechanism for listing and deleting media resources -------------------------+-------------------------------------------------- Reporter: redsweater | Owner: josephscott Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: XML-RPC | Version: 2.3.1 Severity: normal | Keywords: -------------------------+-------------------------------------------------- Right now the XMLRPC interface supports the "newMediaObject" mechanism that is part of the MetaWeblog API, but lacks any method for inspecting or otherwise manipulating media objects. I think to support a richer remote client experience, the XLMRPC interface should support at least a method for listing the media objects that have been previously uploaded (similar to what appears in the "Browse" tab of the wp-admin post editor), and for deleting a media asset that is present. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 22:01:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 22:01:38 2007 Subject: [wp-trac] Re: [WordPress Trac] #5310: XMLRPC interface should expose mechanism for listing and deleting media resources In-Reply-To: <048.0bbebe99e47858b4857b9fb9ab498fe1@lists.automattic.com> References: <048.0bbebe99e47858b4857b9fb9ab498fe1@lists.automattic.com> Message-ID: <057.254c84a02676b920897b943b7ed6a725@lists.automattic.com> #5310: XMLRPC interface should expose mechanism for listing and deleting media resources -------------------------+-------------------------------------------------- Reporter: redsweater | Owner: josephscott Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: XML-RPC | Version: 2.3.1 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by josephscott): * cc: josephscott (added) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Fri Nov 2 22:29:43 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Fri Nov 2 22:29:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #4616: is_email isn't rfc2822 conformant In-Reply-To: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> References: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> Message-ID: <053.8ffc5f02ef484fcbdc15e4bd7d12dede@lists.automattic.com> #4616: is_email isn't rfc2822 conformant -----------------------+---------------------------------------------------- Reporter: hendry | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by Bobcat): OK, here's a proposal of what we should accept: 1. Allow local@example.com, where local can contain alphanumeric characters plus ! # $ % * / ? | !^ { } ` ~ & ' + - = _ . 2. As a design goal, check for the restrictions on the placement of the . character. 3. Do not allow the form of email address where the local part is a quoted string. i.e., double quotes would not be allowed. 4. Blog by Email will accept two forms for the From or Reply-To lines: either a plain email address all by itself as defined above, or a name in quotes (which is ignored) followed by an email address enclosed in angle brackets. 5. Only one address in the From or Reply-To lines will be used. This should handle almost all of the address formats in use. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 04:32:16 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sat Nov 3 04:32:22 2007 Subject: [wp-trac] Re: [WordPress Trac] #5290: Adding the_author_role() template tag In-Reply-To: <048.e8129b10d0016cb1cd4bd42f39a2c11e@lists.automattic.com> References: <048.e8129b10d0016cb1cd4bd42f39a2c11e@lists.automattic.com> Message-ID: <057.67b256bdc88b6a11891790bd83681cc7@lists.automattic.com> #5290: Adding the_author_role() template tag ----------------------------------+----------------------------------------- Reporter: Kafkaesqui | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Template | Version: 2.4 Severity: normal | Resolution: Keywords: author role template | ----------------------------------+----------------------------------------- Comment (by Kafkaesqui): Just uploaded a diff with a better version of get_the_author_role(). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 06:11:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sat Nov 3 06:11:54 2007 Subject: [wp-trac] [WordPress Trac] #5311: HTTP-header X-Pingback when pingbacks are turned off Message-ID: <041.283215f2bd5b49f41341a2009770ed88@lists.automattic.com> #5311: HTTP-header X-Pingback when pingbacks are turned off ---------------------+------------------------------------------------------ Reporter: ose | Owner: anonymous Type: defect | Status: new Priority: low | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: minor | Keywords: http pingback security ---------------------+------------------------------------------------------ When switching off pingbacks under options/discussion, wordpress still sends an X-Pingback http header back to the browser. This has two disadvantages: - It causes unnecessary traffic by other servers trying to ping wordpress - It reveals more information then necessary (essentially reveals that a server is running wordpress even if the web master tries to hide that fact in other places for security reasons). Expected behavior: When pingbacks are disables, wordpress should not send the X-Pingback header to the browser. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 08:09:27 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sat Nov 3 08:09:33 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.178f83a396449c2821d352284985d951@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3 Severity: normal | Resolution: worksforme Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by aroundmyroom): * cc: darkdragon (added) * status: new => closed * resolution: => worksforme Comment: update: after the failing 2.3.1 again I re-applied the forum patch: $r = isset($GLOBALS['wp_filter'][$tag][$priority][$function_to_remove]); $wp_filter[$tag][$priority][serialize($function_to_remove)] = array(); unset( $wp_filter[$tag][$priority][serialize($function_to_remove)] ); unset($GLOBALS['merged_filters'][$tag]); if( true === $r) { unset($GLOBALS['wp_filter'][$tag][$priority][$function_to_remove]); unset($GLOBALS['merged_filters'][$tag]); } return $r; } and the array issue disappeared everywhere from main page as in dashboard options users menu is working again, profile is ok etc.. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 08:14:26 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sat Nov 3 08:14:32 2007 Subject: [wp-trac] [WordPress Trac] #5312: wp-admin/includes/image.php overhaul Message-ID: <042.2a6c41c0ab9c94ebab9b68d4ec8ba7f6@lists.automattic.com> #5312: wp-admin/includes/image.php overhaul ----------------------------+----------------------------------------------- Reporter: DD32 | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Keywords: has-patch ----------------------------+----------------------------------------------- This ticket relates to #4151, #4709 and #5304 I've cleaned the file up to reduce duplicated code, Added PHPDoc comments, and included mentioned tickets within the cleanup. Notes:[[BR]] * {{{function get_udims()}}} duplicated {{{wp_shrink_dimensions()}}}, Switched it to use {{{wp_shrink_dimensions()}}} instead.[[BR]] * It appears that {{{get_udims()}}} is not used anywhere else in WP.[[BR]] * depreciated 3rd param($effect) to {{{wp_create_thumbnail()}}} as it isnt used within the function.[[BR]] * IMAGETYPE_XXX introduced with PHP 4.3.0 it appears, Added to compat.php.[[BR]] * The inline documentation may not be the best, And doesnt include Long descriptions for most of the functions.[[BR]] * Most functions should return a WP_Error object instead on error, For most compatibilit current patch follows previous error handling route. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 22:35:49 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:00:17 2007 Subject: [wp-trac] Re: [WordPress Trac] #5313: iframe being injected In-Reply-To: <048.ac94f7f48af8279f20a6da93eefc0f87@lists.automattic.com> References: <048.ac94f7f48af8279f20a6da93eefc0f87@lists.automattic.com> Message-ID: <057.c72f6916406e72f6cc0214dec623e4c1@lists.automattic.com> #5313: iframe being injected ------------------------+--------------------------------------------------- Reporter: Columcille | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.5 Component: Security | Version: 2.3.1 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by Columcille): * component: General => Security -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 09:54:11 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:26:27 2007 Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be used without including wp-settings.php In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> Message-ID: <057.e9734d282391db1d14f02ac69c334151@lists.automattic.com> #5276: Allow wp-config.php to be used without including wp-settings.php --------------------------------------+------------------------------------- Reporter: mastermind | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: wp-config.php standalone | --------------------------------------+------------------------------------- Comment (by mastermind): Replying to [comment:10 DD32]: > What should WP be including to kick-start itself? {{{wp-config.php}}} or {{{wp-blog-header.php}}} ? {{{wp-blog-header.php}}} makes much more sense. {{{wp-config.php}}} suggests that it only contains configuration data, and in cases like the one outlined in the first note, it's rather unfortunate that one can't cleanly load *only* the configuration. DD32, could you possibly tell us what you found out about other parts of WP breaking without this line? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 11:00:00 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:27:26 2007 Subject: [wp-trac] Re: [WordPress Trac] #5309: 'Insert/edit image' dialog changes empty fields to default values In-Reply-To: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> References: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> Message-ID: <059.a62398a2d153b49c997ba70c5b2b40ec@lists.automattic.com> #5309: 'Insert/edit image' dialog changes empty fields to default values -------------------------------+-------------------------------------------- Reporter: hermanschaap | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: reporter-feedback | -------------------------------+-------------------------------------------- Comment (by westi): Possibly relates to #5087 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 19:09:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:30:28 2007 Subject: [wp-trac] Re: [WordPress Trac] #4715: Lost of Priority with Merge_filters and $wp_filters['all'] In-Reply-To: <048.7a211309ca32f4134bc5b190c06364a9@lists.automattic.com> References: <048.7a211309ca32f4134bc5b190c06364a9@lists.automattic.com> Message-ID: <057.927a2f3b65141f5d68390c0f0f3bfd8f@lists.automattic.com> #4715: Lost of Priority with Merge_filters and $wp_filters['all'] ------------------------------------------------------------------+--------- Reporter: darkdragon | Owner: anonymous Type: defect | Status: new Priority: lowest | Milestone: 2.4 Component: General | Version: 2.3 Severity: trivial | Resolution: Keywords: has-patch merge_filters filters plugin.php confirmed | ------------------------------------------------------------------+--------- Comment (by ryan): see #5231 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 14:15:45 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:31:17 2007 Subject: [wp-trac] Re: [WordPress Trac] #5312: wp-admin/includes/image.php overhaul In-Reply-To: <042.2a6c41c0ab9c94ebab9b68d4ec8ba7f6@lists.automattic.com> References: <042.2a6c41c0ab9c94ebab9b68d4ec8ba7f6@lists.automattic.com> Message-ID: <051.cf432068b58ffe05c42b2c2e8f53ab4e@lists.automattic.com> #5312: wp-admin/includes/image.php overhaul ----------------------------+----------------------------------------------- Reporter: DD32 | Owner: westi Type: enhancement | Status: assigned Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch | ----------------------------+----------------------------------------------- Changes (by westi): * owner: anonymous => westi * status: new => assigned -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 16:20:58 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:31:45 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.02dd309e2910d121f0f65acfa95fe1d4@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by westi): Not quite sure this patch is right at the moment. Is doing the callback https check on every request to xmlrpc.php really a good idea? Would we not do better to just make sure if you access via https then you stay on https by basing the returned urls on the request url? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 19:06:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:32:15 2007 Subject: [wp-trac] Re: [WordPress Trac] #5253: filter category_description call too many (2) in category_description() function In-Reply-To: <046.2ff1ef49f0c79bc3fe4d47d24d083701@lists.automattic.com> References: <046.2ff1ef49f0c79bc3fe4d47d24d083701@lists.automattic.com> Message-ID: <055.79557430e5a93bc0283b86304fb1ab08@lists.automattic.com> #5253: filter category_description call too many (2) in category_description() function ------------------------------------------------------------+--------------- Reporter: michelwp | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.4 Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: sanitize_term_field get_term_field needs-patch | ------------------------------------------------------------+--------------- Comment (by ryan): Does that help? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 10:51:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:33:36 2007 Subject: [wp-trac] Re: [WordPress Trac] #5311: HTTP-header X-Pingback when pingbacks are turned off In-Reply-To: <041.283215f2bd5b49f41341a2009770ed88@lists.automattic.com> References: <041.283215f2bd5b49f41341a2009770ed88@lists.automattic.com> Message-ID: <050.e9438b0cff9c509bcaf036132ecf1bb4@lists.automattic.com> #5311: HTTP-header X-Pingback when pingbacks are turned off ------------------------------------+--------------------------------------- Reporter: ose | Owner: anonymous Type: defect | Status: closed Priority: low | Milestone: Component: General | Version: 2.3.1 Severity: minor | Resolution: invalid Keywords: http pingback security | ------------------------------------+--------------------------------------- Changes (by westi): * status: new => closed * resolution: => invalid * milestone: 2.4 => Comment: The options under options..discussion are not a global option for whether or not pingbacks are enabled but are just the defaults for new posts. There is no option to disable pingbacks. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 19:10:17 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:34:39 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.bb175c4492d27746104a2cc49f7bf70f@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour ------------------------+--------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by ryan): Anyone take a crack at this yet? I'll give it a look next week if no one jumps in. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 17:21:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:35:02 2007 Subject: [wp-trac] [WordPress Trac] #5313: iframe being injected Message-ID: <048.ac94f7f48af8279f20a6da93eefc0f87@lists.automattic.com> #5313: iframe being injected ------------------------+--------------------------------------------------- Reporter: Columcille | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: major | Keywords: ------------------------+--------------------------------------------------- I don't know what's causing this but the problem is being reported by a few people at http://wordpress.org/support/topic/134928. In short, an iframe is turning up in certain posts, clearly being put there via some exploit. Problem has been reported across a few versions of WordPress, including 2.3.1. Note that the iframe wasn't contained in a theme or any source files, it was in the post itself stored in the database. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 10:59:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:35:10 2007 Subject: [wp-trac] Re: [WordPress Trac] #5309: 'Insert/edit image' dialog changes empty fields to default values In-Reply-To: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> References: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> Message-ID: <059.6b66c63792f67cd4121e6036770ef2b9@lists.automattic.com> #5309: 'Insert/edit image' dialog changes empty fields to default values -------------------------------+-------------------------------------------- Reporter: hermanschaap | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: reporter-feedback | -------------------------------+-------------------------------------------- Changes (by westi): * keywords: => reporter-feedback Comment: What browser are you using? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 10:02:29 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:36:27 2007 Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be used without including wp-settings.php In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com> Message-ID: <057.2abf0911bb0a385d1b6180d07c5c2344@lists.automattic.com> #5276: Allow wp-config.php to be used without including wp-settings.php --------------------------------------+------------------------------------- Reporter: mastermind | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: wp-config.php standalone | --------------------------------------+------------------------------------- Comment (by DD32): > DD32, could you possibly tell us what you found out about other parts of WP breaking without this line? I removed the line, and the login form broke :) wp-login.php, wp-app.php, wp-atom.php just to name a few kick start WP by including wp-config.php. Once i realised others used it i havnt probed closer as i was after some direction from more seasoned developers. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 18:36:33 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:45:29 2007 Subject: [wp-trac] [WordPress Trac] #5314: comments_link ignores parameters Message-ID: <048.2e509123cfacca78c73e21e9063fe8d0@lists.automattic.com> #5314: comments_link ignores parameters ------------------------+--------------------------------------------------- Reporter: Columcille | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Keywords: ------------------------+--------------------------------------------------- The fucntion comments_link in wp-includes/comment-template.php ignores parameters passed to it. The function has no code to make use of the parameters defined in the function and explained at codex.wordpress.org. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sat Nov 3 16:07:17 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 00:48:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #5295: wp-links-opml.php will not display a single link category In-Reply-To: <044.65c208aa9e0295645685056bc9be0cb6@lists.automattic.com> References: <044.65c208aa9e0295645685056bc9be0cb6@lists.automattic.com> Message-ID: <053.472068ae07af0a7dfc99e25fc88e2934@lists.automattic.com> #5295: wp-links-opml.php will not display a single link category ---------------------+------------------------------------------------------ Reporter: vrypan | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: opml | ---------------------+------------------------------------------------------ Changes (by westi): * milestone: 2.3.2 => 2.4 Comment: Replying to [comment:1 ryan]: > I think get_term($link_cat, 'link_category') will work. That doesn't work with the current code. The suggest change in the ticket does though. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 01:11:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 01:54:23 2007 Subject: [wp-trac] Re: [WordPress Trac] #5313: iframe being injected In-Reply-To: <048.ac94f7f48af8279f20a6da93eefc0f87@lists.automattic.com> References: <048.ac94f7f48af8279f20a6da93eefc0f87@lists.automattic.com> Message-ID: <057.21307d678fa13ee685d7a2561cbf44fe@lists.automattic.com> #5313: iframe being injected ------------------------+--------------------------------------------------- Reporter: Columcille | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.5 Component: Security | Version: 2.3.1 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by lloydbudd): Copying DD32's forum comment here: Can anyone take a read through their webservers access logs and look for anything suspect accessing the admin pages? Also check for other users, and change the admin passwords. It is hard to work out what is happening here without knowing where the problem is coming from. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 01:27:57 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 01:56:28 2007 Subject: [wp-trac] [WordPress Trac] #5315: Awaiting Moderation (#): # is not always updated correctly in JS Message-ID: <046.539053125be12c1f1ff7a12abc118633@lists.automattic.com> #5315: Awaiting Moderation (#): # is not always updated correctly in JS ----------------------+----------------------------------------------------- Reporter: mdawaffe | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Keywords: ----------------------+----------------------------------------------------- The number in the Comments -> Awaiting Moderation subtab gets updated via JS when comments are approved, unapproved or deleted. There are a couple of bugs, though. When the number is updated to 0, it is removed rather than set to "0" (a jQuery oddity). When a comment is deleted from the Comments -> Amaiting Moderation tab (rather than from the Comments -> Comments tab), the number is not changed. Attached fixes both. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 01:34:00 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 01:56:53 2007 Subject: [wp-trac] Re: [WordPress Trac] #2244: Make login error check case-sensitive In-Reply-To: <047.2d10cde07bf318c6fcee302a20cb2750@lists.automattic.com> References: <047.2d10cde07bf318c6fcee302a20cb2750@lists.automattic.com> Message-ID: <056.37f7b96155e68c2ef21f4f7ddfceb978@lists.automattic.com> #2244: Make login error check case-sensitive ----------------------------+----------------------------------------------- Reporter: Spider007 | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.0 Severity: normal | Resolution: Keywords: 2nd-opinion | ----------------------------+----------------------------------------------- Comment (by DD32): Personally I think it should be case insensitive usernames, which is how the core WP code currently operates (as the DB layer is case insensitive).[[BR]] Passwords are still case sensitive as md5's are case sensitive. I've attached a patch which cleans up the wp_login function, The empty password code was removed as thats handled in the login form anyway. I'll also attach one which has case sensitive user logins, and displays the correct error. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 01:36:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 01:57:05 2007 Subject: [wp-trac] Re: [WordPress Trac] #2244: Make login error check case-sensitive In-Reply-To: <047.2d10cde07bf318c6fcee302a20cb2750@lists.automattic.com> References: <047.2d10cde07bf318c6fcee302a20cb2750@lists.automattic.com> Message-ID: <056.d32a7a829820e61783df557747bbde5b@lists.automattic.com> #2244: Make login error check case-sensitive -----------------------------------+---------------------------------------- Reporter: Spider007 | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.0 Severity: normal | Resolution: Keywords: 2nd-opinion has-patch | -----------------------------------+---------------------------------------- Changes (by DD32): * keywords: 2nd-opinion => 2nd-opinion has-patch -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 02:09:06 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 02:09:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.abd6fb6dba17fb0bd20d45164e560eac@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Changes (by darkdragon): * keywords: => has-patch needs-testing Comment: Yeah, the patch fixes several other bug problems. Combines bug fixes for #4715, #5261, and fixes a notice based in _wp_build...(). Has extra @param documentation -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 02:47:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 02:47:48 2007 Subject: [wp-trac] [WordPress Trac] #5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping options Message-ID: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com> #5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping options ----------------------------+----------------------------------------------- Reporter: DD32 | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Keywords: has-patch options ----------------------------+----------------------------------------------- I floated this idea back in September on wp-hackers: http://comox.textdrive.com/pipermail/wp- hackers/2007-September/thread.html#14425 ([wp-hackers] adding delete/autoload to options.php) Basically this patch allows options to be deleted from the options.php page(By checking its checkbox - a JS confirmation is done before form submitting to make sure the user intends to delete them), Viewing of Serialized data, And also groups the options by name. Grouping is achieved by taking the first word in the term, Ie. "test" in "test_plugin_data", If there are more than 2 terms with such a groupname, then they're promoted into their own section, This makes it easier to mass-select a particular 'groups' options to delete. An invert selection option is also available for each group, So if a user wants to delete all the RSS cache items, They can either select all the cache items to remove, or, Select the items they wish to keep(in the rss section) and click Invert. I've attached a plugin which is identical to the patch for those not wanting to apply the patch. The linked wp-hackers thread mentioned also having an option to set autoload, I have not yet done that (As it'll require modifying/creating other functions) yet, But would like to include it, Just not sure how in the UI it could be managed without looking too crowded. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 02:49:49 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 02:50:02 2007 Subject: [wp-trac] Re: [WordPress Trac] #5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping options In-Reply-To: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com> References: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com> Message-ID: <051.8157e15492b281f71963c083876f4e5a@lists.automattic.com> #5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping options -------------------------------+-------------------------------------------- Reporter: DD32 | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch options | -------------------------------+-------------------------------------------- Changes (by DD32): * type: defect => enhancement -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 05:45:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 05:45:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.4cd93f4aa47510275a5ab22263d8b6b4@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Is there any reason to have both filters and actions in $wp_filter? How about we separate actions into $wp_action with a merge_actions() function. Also, do_action() looks like it is always calling merge_filters() instead of checking to see if that tag is already merged. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 05:45:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 05:45:55 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.b32fe4317cdd3d185e5ff38d67e938ff@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Changes (by ryan): * milestone: 2.5 => 2.4 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 13:44:12 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 13:44:25 2007 Subject: [wp-trac] [WordPress Trac] #5317: get_posts returns invalid data when using category= parameter Message-ID: <046.22c1c51f46953a96d9ace5b5ef4b9684@lists.automattic.com> #5317: get_posts returns invalid data when using category= parameter ----------------------+----------------------------------------------------- Reporter: MichaelH | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Take a new 2.3.1 install with this code: {{{$myposts = get_posts('category=2');}}} You would expect to get NO results, as an out-of-the-box install has no posts with category 2, but that code will return the "Hello World!" post. Guessing this might be caused by get_posts not discerning between post categories and link categories (e.g. the link with link_id=1 in category 2 causes post with ID=1 to be returned). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 14:48:45 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 14:49:00 2007 Subject: [wp-trac] Re: [WordPress Trac] #4616: is_email isn't rfc2822 conformant In-Reply-To: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> References: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> Message-ID: <053.94137990263253ce1b5b2ea0b9853f29@lists.automattic.com> #4616: is_email isn't rfc2822 conformant -----------------------+---------------------------------------------------- Reporter: hendry | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by jhodgdon): Please also consider that the domain part of the address could legally be "localhost", rather than something.com. This is very useful for test box set-ups, but is not allowed currently by WordPress. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 15:49:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 15:49:35 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.1432f4313a7394da0daed97e4f6f1b07@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Changes (by rubys): * cc: rubys (added) Comment: Am I misreading line 20 in {{{xmlrpc.php}}} incorrectly? The intent of this patch is to only do this check when fetching the {{{rsd}}} document. See [http://intertwingly.net/blog/2007/10/31/WordPress-SSL-TLS-and-AtomPub this post] for background. Some place in the traversal from {{{http://foo.wordpress.com/}}} => {{{xmlrpc.php?rsd}}} => {{{/wp- app.php/service}}} => {{{/wp-app.php/posts}}} or {{{/wp- app.php/attachments}}} there needs to be an indication that {{{https}}} should be used. Doing this when rendering the front-page would clearly be overkill. Doing it on every fetch of the service document would be better. Doing it only when fetching the discovery document seems (to me at least) to be better yet. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:02:34 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:03:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #4207: Pluggable DB Down Page In-Reply-To: <045.2800dbd9e4c15f1a503da1e1102e8f3d@lists.automattic.com> References: <045.2800dbd9e4c15f1a503da1e1102e8f3d@lists.automattic.com> Message-ID: <054.b3baa2eba4925a479361f1187a09f021@lists.automattic.com> #4207: Pluggable DB Down Page -------------------------+-------------------------------------------------- Reporter: linickx | Owner: darkfate Type: enhancement | Status: assigned Priority: low | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Changes (by darkfate): * keywords: needs-patch => has-patch Comment: I'm marking this has-patch. If anyone agrees with westi, I encourage them to make another patch. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:12:55 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:13:08 2007 Subject: [wp-trac] Re: [WordPress Trac] #5277: Posts are de-categorized when upgrading to 2.3.x In-Reply-To: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> References: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> Message-ID: <050.6894cae653810109154bd142a3b9ae5d@lists.automattic.com> #5277: Posts are de-categorized when upgrading to 2.3.x ----------------------+----------------------------------------------------- Reporter: dtc | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by darkfate): So I guess this is happening when a post is in multiple categories? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:15:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:15:34 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.18208f3cea495c540476c67c2b8d90d5@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): For the sake of KISS, I just kept it as is. I did not realize that it was supposed to check to see if it is merged. Well, that would probably fix your issue. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:22:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:22:45 2007 Subject: [wp-trac] Re: [WordPress Trac] #4570: Comment link cannot contain IRIs In-Reply-To: <044.dab38c86deb3dff72fd9c19c860747e4@lists.automattic.com> References: <044.dab38c86deb3dff72fd9c19c860747e4@lists.automattic.com> Message-ID: <053.0e5f1dec6348dc6cebb54bfdf9e773de@lists.automattic.com> #4570: Comment link cannot contain IRIs ----------------------+----------------------------------------------------- Reporter: link92 | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: 2.4 Component: General | Version: 2.0.10 Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by darkfate): * status: new => closed * resolution: => fixed -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:24:43 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:24:55 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.4125705f008bcf4fa24c9bb9eba8133f@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): I added two more patches that fix the issue ryan bought up. I also realized that the assignment in remove_filter() would actually decrease time with creating and allocating memory for what would amount to temporary variables. I used if statements instead. If the array portion exist, then it will be deleted and on then. This is a lot less time allocated towards checking whether it exists and remove it, then the worse case which is check that it exists, does not exist, create it, destroy it. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:26:01 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:26:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.06974198dfac0e3e5580708b55c27e81@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Not to mention the speed boost from not doing the merging each time for action. Although, I haven't done any speed benchmarks, I don't think it would be all that terrible. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 16:28:37 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 16:28:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.4ce0e29f01ac327ea61a0d41eaf474b3@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Replying to [comment:9 ryan]: > Is there any reason to have both filters and actions in $wp_filter? How about we separate actions into $wp_action with a merge_actions() function. Also, do_action() looks like it is always calling merge_filters() instead of checking to see if that tag is already merged. After some thought, it would make sense to separate the two, in order to keep any overriding nature from happening. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 18:34:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 18:34:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #4616: is_email isn't rfc2822 conformant In-Reply-To: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> References: <044.f364717657cdc0423a4a301f8ed20c40@lists.automattic.com> Message-ID: <053.e986b91566c539a44fc4146086edab0c@lists.automattic.com> #4616: is_email isn't rfc2822 conformant -----------------------+---------------------------------------------------- Reporter: hendry | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by Bobcat): Both of the proposed implementations above allow '@localhost'. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 18:46:42 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 18:46:54 2007 Subject: [wp-trac] Re: [WordPress Trac] #4570: Comment link cannot contain IRIs In-Reply-To: <044.dab38c86deb3dff72fd9c19c860747e4@lists.automattic.com> References: <044.dab38c86deb3dff72fd9c19c860747e4@lists.automattic.com> Message-ID: <053.24fa6ceb4017383f563eacfb6a5c56ff@lists.automattic.com> #4570: Comment link cannot contain IRIs ----------------------+----------------------------------------------------- Reporter: link92 | Owner: anonymous Type: defect | Status: reopened Priority: high | Milestone: 2.4 Component: General | Version: 2.0.10 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by westi): * status: closed => reopened * resolution: fixed => Comment: Not sure this is currently fixed - just filterable leaving open for now. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 18:53:48 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 18:54:00 2007 Subject: [wp-trac] Re: [WordPress Trac] #5287: Setup table names inside wpdb In-Reply-To: <042.da84756ea2414992e580e5855b8966f4@lists.automattic.com> References: <042.da84756ea2414992e580e5855b8966f4@lists.automattic.com> Message-ID: <051.aaf9d37592a63f766d30ae93228f87a1@lists.automattic.com> #5287: Setup table names inside wpdb ---------------------+------------------------------------------------------ Reporter: ryan | Owner: ryan Type: defect | Status: closed Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: fixed Keywords: wpdb | ---------------------+------------------------------------------------------ Comment (by westi): Replying to [comment:2 westi]: > Don't we need to use the function too? I see this slipped into a previous checkin ;-) http://trac.wordpress.org/changeset/6299#file6 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 20:23:08 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 20:23:20 2007 Subject: [wp-trac] Re: [WordPress Trac] #5261: Array issues in plugins.php In-Reply-To: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> References: <050.881ca25f5bcc91a94d201933b40a7a86@lists.automattic.com> Message-ID: <059.46c4af92146e7730e54f73f2989e75ff@lists.automattic.com> #5261: Array issues in plugins.php --------------------------+------------------------------------------------- Reporter: aroundmyroom | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3 Severity: normal | Resolution: worksforme Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by Nazgul): * milestone: 2.3.2 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 22:17:55 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 22:18:09 2007 Subject: [wp-trac] [WordPress Trac] #5318: 'Next page' link broken when using slug that contains the word 'page' Message-ID: <046.523b3650b7f27d73afdf09fa19b8b366@lists.automattic.com> #5318: 'Next page' link broken when using slug that contains the word 'page' ----------------------+----------------------------------------------------- Reporter: Eminence | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: major | Keywords: ----------------------+----------------------------------------------------- The 'Next page' and 'Previous page' links are broken when you're are browsing posts in a category that has 'page' in it's slug. For example: You are at: http://yourblog.com/index.php/category/frontpage/page/2/ The previous page link incorrectly points to: http://yourblog/index.php/category/front The next page link incorrectly points to: http://yourblog/index.php/category/front/page/3/ (the correct links should be /index.php/category/frontpage/ and /index.php/category/frontpage/page/3/) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 22:33:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 22:33:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #2959: wp_list_pages does not add current_page_item class on page_for_posts In-Reply-To: <046.f1e112f412166f2ae24fc66d92bb4075@lists.automattic.com> References: <046.f1e112f412166f2ae24fc66d92bb4075@lists.automattic.com> Message-ID: <055.303a39d8f5f46d809daa8f1b10f1f0d2@lists.automattic.com> #2959: wp_list_pages does not add current_page_item class on page_for_posts -------------------------+-------------------------------------------------- Reporter: skeltoac | Owner: ariejan Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: Template | Version: 2.1 Severity: normal | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Changes (by ariejan): * owner: ryan => ariejan * status: new => assigned Comment: Ping Does anyone know why this bug hasn't been fixed yet? Are there any problems in particular that prevent this bug from being fixed? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 23:30:11 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 23:30:26 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.c2a118a49e663f0bcbca83f5bd80743c@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Indeed. Add the separation of filters and actions to your patch and I think we're good. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Sun Nov 4 23:49:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Sun Nov 4 23:49:24 2007 Subject: [wp-trac] Re: [WordPress Trac] #5162: Extract additional image metadata from EXIF/IPTC In-Reply-To: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com> References: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com> Message-ID: <057.79bb9b738f222dab137f15e3b6460f71@lists.automattic.com> #5162: Extract additional image metadata from EXIF/IPTC -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: ryan Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by ryan): * owner: anonymous => ryan -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 00:00:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 00:00:55 2007 Subject: [wp-trac] Re: [WordPress Trac] #5162: Extract additional image metadata from EXIF/IPTC In-Reply-To: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com> References: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com> Message-ID: <057.b47ef0edf1e3e845db2551b10f5002f3@lists.automattic.com> #5162: Extract additional image metadata from EXIF/IPTC -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: ryan Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by ryan): * milestone: 2.5 => 2.4 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 01:05:57 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 01:06:09 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.23db0c7475314128f79adf343e106a59@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Well, what you have to realize is that I'm insane and that is a no can do, unless you want me to rewrite the entire Plugin Library into an Object Oriented approach. I'll let someone more sane do what you wish. Unless you just want me to append '_action' to all actions and '_filter' to all filters for removing, adding, and calling. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 03:20:25 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 03:20:38 2007 Subject: [wp-trac] [WordPress Trac] #5319: Single post feeds Message-ID: <048.22454d3e8be8884f4c77b4a2e82a9e76@lists.automattic.com> #5319: Single post feeds -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- The included patch adds a .../feed/post/ rewrite rule that allows fetching a single post as an XML feed. Sort of a complementary to the post comments feed. http://example.com//2007/09/04/simple-markup-test/feed/ - the post comments feed http://example.com//2007/09/04/simple-markup-test/feed/post/ - the single post content feed -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 03:33:02 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 03:33:13 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.dab2c5ead312216cefb36961051cc73f@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Perhaps I'm insane because I don't see why you can't just separate add_action from add_filter and use separate arrays for filters and actions. Full separation of the two. I'll write it, just want to make sure I'm not missing something. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 03:39:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 03:39:35 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.b4a771cf7b2565be3785a567fee8cd46@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Duplicate code? Why would you have similar code in two different places when you have code in one place and called in two different places. I can't do that, but if you're willing then I think it would work. Dude, I cringe whenever I look at the similar code branches in do_action, apply_filters, and do_action_ref_array. About lose my sanity I do. Although, I have no non-drastic solution. Just purely maddening. The classes I threw together would require a couple more hours. I just don't see myself finishing it when your solution would only take about 30 minutes to an hour (testing included), if even that. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 04:12:10 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 04:12:22 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.c08b6cea9060a1fb5abda426a9214cea@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Well, to clarify, I did think about separation, but I do rather like having one function do all of the work. In the class, basically, I had one method that would take the $tag, $function_to_add, $priority, and $accepted_args and build the array, and then return it. Damn it! I just realized that the code I wrote wouldn't work! Damn you coordinate system! You '''have''' to duplicate the addition code! I was thinking an assignment from an function would work, but it wouldn't. If you did that you would overwrite everything that was in the array and would only store the new tag system. You also can't easily assign it to a variable and then use it in the array (tried that, pretty worthless). An extra three lines in add_action won't hurt anything. It would completely decouple filters from actions, which would require that the Plugin API documentation at the codex be updated. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 04:34:25 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 04:34:37 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.56a48db278d240140d6bb6e889e8fcfa@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by darkdragon): Well, you know, the patch failed. Sigh. Oh well, I'll just let you do it then. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 05:01:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 05:01:37 2007 Subject: [wp-trac] Re: [WordPress Trac] #2959: wp_list_pages does not add current_page_item class on page_for_posts In-Reply-To: <046.f1e112f412166f2ae24fc66d92bb4075@lists.automattic.com> References: <046.f1e112f412166f2ae24fc66d92bb4075@lists.automattic.com> Message-ID: <055.d368a7fad7b0aa231293d0863b0437c0@lists.automattic.com> #2959: wp_list_pages does not add current_page_item class on page_for_posts -------------------------+-------------------------------------------------- Reporter: skeltoac | Owner: ariejan Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: Template | Version: 2.1 Severity: normal | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Comment (by lloydbudd): ariejan, "needs-patch" -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 05:19:14 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 05:19:27 2007 Subject: [wp-trac] Re: [WordPress Trac] #5319: Single post feeds In-Reply-To: <048.22454d3e8be8884f4c77b4a2e82a9e76@lists.automattic.com> References: <048.22454d3e8be8884f4c77b4a2e82a9e76@lists.automattic.com> Message-ID: <057.a042aaf742c4f3d4beb5995d3b0b7a88@lists.automattic.com> #5319: Single post feeds -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by lloydbudd): This is an interesting idea, but I can't help but wonder if it is dodging a question ;-) Is a more meaningful experience to define including the post in the comment feed as well. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 05:31:10 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 05:31:23 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.a3babf96bbbd85f603ffc860cc61c4c5@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Using the array union operators means that duplicated keys won't be overwritten. I think we should just forget about giving all a priority and just fire the all hooks either before or after the regular hooks. No merge needed. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 05:51:35 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 05:51:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #4469: Accept 'open' and 'closed' as valid values for mt_allow_comments and mt_allow_pings in XML-RPC In-Reply-To: <049.594049e1c352a680bc0a1ed7b26dc8da@lists.automattic.com> References: <049.594049e1c352a680bc0a1ed7b26dc8da@lists.automattic.com> Message-ID: <058.ea7389258f558cc46f350c04f2117d8f@lists.automattic.com> #4469: Accept 'open' and 'closed' as valid values for mt_allow_comments and mt_allow_pings in XML-RPC -------------------------+-------------------------------------------------- Reporter: josephscott | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: 2.2.1 Component: XML-RPC | Version: 2.2 Severity: normal | Resolution: fixed Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by yatrip): New patch for the 2.2 branch. [http://www.yatrip.com ????] -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 06:56:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 06:56:39 2007 Subject: [wp-trac] Re: [WordPress Trac] #4517: Bundle Sandbox theme, and also set 'sandbox' as the default template for themes without a stylesheet In-Reply-To: <050.c175d069caf74346d426b69b67b5ff3b@lists.automattic.com> References: <050.c175d069caf74346d426b69b67b5ff3b@lists.automattic.com> Message-ID: <059.1bd11d0b501a28e3ed024145977db389@lists.automattic.com> #4517: Bundle Sandbox theme, and also set 'sandbox' as the default template for themes without a stylesheet ------------------------------+--------------------------------------------- Reporter: JeremyVisser | Owner: anonymous Type: enhancement | Status: new Priority: low | Milestone: 2.4 Component: Template | Version: Severity: minor | Resolution: Keywords: has-patch commit | ------------------------------+--------------------------------------------- Comment (by Speedboxer): Patch '''4517-bundle-sandbox-1.0.diff''' adds Sandbox 1.0 as a bundled theme. It's added in wp-includes/theme.php also. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 06:57:17 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 06:57:32 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.5e9d8aa28ec1958e20162950692139cc@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Patch gets rid of the merge entirely. 'all' filters and actions are done first, followed by the filter or action being invoked. Filters and actions are separated completely. The xdebug profiler shows notable speedup in add_action() and add_filter() with apply_filters() and do_action() being about the same speed as before. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 07:01:37 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 07:01:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #5319: Single post feeds In-Reply-To: <048.22454d3e8be8884f4c77b4a2e82a9e76@lists.automattic.com> References: <048.22454d3e8be8884f4c77b4a2e82a9e76@lists.automattic.com> Message-ID: <057.c7e921f59039a49fc165f7319dab9380@lists.automattic.com> #5319: Single post feeds -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by tellyworth): Ideally, sure, but the RSS specs in particular don't provide a clean way to do that. I went with this solution (to meet an esoteric requirement) because the only code required was on the rewrite side. I guess the general issue being solved here is: the query and feed code support this feature, but it's not exposed as a clean URL. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 08:12:02 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 08:12:15 2007 Subject: [wp-trac] [WordPress Trac] #5320: Improve performance of seems_utf8() and uf8_uri_encode() Message-ID: <042.e95d5b14c874885ee2f7f7715ef543a6@lists.automattic.com> #5320: Improve performance of seems_utf8() and uf8_uri_encode() ---------------------+------------------------------------------------------ Reporter: ryan | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Keywords: performance ---------------------+------------------------------------------------------ seems_utf8() and uf8_uri_encode() call strlen() several times within loops. strlen() only needs to be called once and its result assigned to a variable that is tested within the loops. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 08:17:14 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 08:17:26 2007 Subject: [wp-trac] [WordPress Trac] #5321: when post title or content contain ".htaccess", post can't be saved Message-ID: <045.4031670bd99d7507e4caa89e6506209d@lists.automattic.com> #5321: when post title or content contain ".htaccess",post can't be saved ---------------------+------------------------------------------------------ Reporter: netrobo | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Keywords: ---------------------+------------------------------------------------------ when post title or content contain ".htaccess",post can't be saved. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 09:18:36 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 09:18:47 2007 Subject: [wp-trac] Re: [WordPress Trac] #5321: when post title or content contain ".htaccess", post can't be saved In-Reply-To: <045.4031670bd99d7507e4caa89e6506209d@lists.automattic.com> References: <045.4031670bd99d7507e4caa89e6506209d@lists.automattic.com> Message-ID: <054.5bb542a97eec4eb9bcec62b926328ddf@lists.automattic.com> #5321: when post title or content contain ".htaccess",post can't be saved ---------------------+------------------------------------------------------ Reporter: netrobo | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by DD32): Unable to reproduce on trunk. My guess is that mod_security or another security package on the server is blocking it rather than WordPress. What is the actual error message and what version of WordPress is it? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 11:06:01 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 11:06:14 2007 Subject: [wp-trac] Re: [WordPress Trac] #5321: when post title or content contain ".htaccess", post can't be saved In-Reply-To: <045.4031670bd99d7507e4caa89e6506209d@lists.automattic.com> References: <045.4031670bd99d7507e4caa89e6506209d@lists.automattic.com> Message-ID: <054.3920929d8958d45c4e73f8fdf1e99990@lists.automattic.com> #5321: when post title or content contain ".htaccess",post can't be saved ---------------------+------------------------------------------------------ Reporter: netrobo | Owner: anonymous Type: defect | Status: closed Priority: normal | Milestone: Component: General | Version: Severity: normal | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by markjaquith): * status: new => closed * resolution: => invalid * milestone: 2.5 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 13:57:04 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 13:57:21 2007 Subject: [wp-trac] Re: [WordPress Trac] #5277: Posts are de-categorized when upgrading to 2.3.x In-Reply-To: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> References: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> Message-ID: <050.841f9cf6113f9c4e97578a7c98f5b355@lists.automattic.com> #5277: Posts are de-categorized when upgrading to 2.3.x ----------------------+----------------------------------------------------- Reporter: dtc | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by dtc): No, it happens also when the post is in a single category. The errors appear on a server powered by WAMP. Increasing memory usage does not solve the errors (server set to use 64+ MB for script usage). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 14:01:51 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 14:35:29 2007 Subject: [wp-trac] Re: [WordPress Trac] #5318: 'Next page' link broken when using slug that contains the word 'page' In-Reply-To: <046.523b3650b7f27d73afdf09fa19b8b366@lists.automattic.com> References: <046.523b3650b7f27d73afdf09fa19b8b366@lists.automattic.com> Message-ID: <055.d0194af423114db401b6007814870a7c@lists.automattic.com> #5318: 'Next page' link broken when using slug that contains the word 'page' ----------------------+----------------------------------------------------- Reporter: Eminence | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by xknown): The attached patch against trunk seems to fix the problem. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 14:49:16 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 15:29:20 2007 Subject: [wp-trac] Re: [WordPress Trac] #1258: Curly quotes mixups In-Reply-To: <055.a30f0e860d0436f770378729f9ecdbdb@lists.automattic.com> References: <055.a30f0e860d0436f770378729f9ecdbdb@lists.automattic.com> Message-ID: <064.c52049d10109c9c81f5518ea377c34cb@lists.automattic.com> #1258: Curly quotes mixups -------------------------------+-------------------------------------------- Reporter: Denis de Bernardy | Owner: Type: defect | Status: closed Priority: normal | Milestone: 2.4 Component: Template | Version: 2.1 Severity: normal | Resolution: worksforme Keywords: needs-patch | -------------------------------+-------------------------------------------- Changes (by pishmishy): * status: new => closed * resolution: => worksforme Comment: I can't seem to replicate this in the trunk as of today. Posting: 'hello', 'world', 'tis Appears to balance the quotes correctly. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 15:50:54 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 15:51:06 2007 Subject: [wp-trac] Re: [WordPress Trac] #1748: root-relative links should be converted to absolute in rss feeds In-Reply-To: <051.03ffb7e7087e4840dcc92964667f9afb@lists.automattic.com> References: <051.03ffb7e7087e4840dcc92964667f9afb@lists.automattic.com> Message-ID: <060.82b3daa636b1de28d53fe20a7908f418@lists.automattic.com> #1748: root-relative links should be converted to absolute in rss feeds ---------------------------+------------------------------------------------ Reporter: digitalgimpus | Owner: markjaquith Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 1.5.2 Severity: normal | Resolution: Keywords: needs-patch | ---------------------------+------------------------------------------------ Changes (by pishmishy): * summary: relative links should be converted to absolute in rss feeds => root-relative links should be converted to absolute in rss feeds Comment: I don't believe that there's a full solution to this ticket. The intended destination of a relative link inside a post is ambiguous. A relative link to foo/bar.html can link to http://myblog.com/foo/bar.html on the main page, http://myblog.com/category/uncategorized/foo/bar.html in the archives and http://myblog.com/2007/11/05/8/foo/bar.html when viewing a single post. What we can do is attempt to fix "root-relative" links (those starting in /). I'm not sure this is worth fixing. Can someone point to the place where relative links are not allowed? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 16:44:16 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 16:44:30 2007 Subject: [wp-trac] Re: [WordPress Trac] #5307: Partially back out changeset 5273, ticket 5181 In-Reply-To: <043.b9d3324220a43283ac4f7575844c9189@lists.automattic.com> References: <043.b9d3324220a43283ac4f7575844c9189@lists.automattic.com> Message-ID: <052.a853f3d8d62ce61cefda9811b19ad68d@lists.automattic.com> #5307: Partially back out changeset 5273, ticket 5181 -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: new Priority: high | Milestone: 2.4 Component: General | Version: 2.4 Severity: major | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Changes (by josephscott): * cc: josephscott (added) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 16:50:35 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 16:50:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #1258: Curly quotes mixups In-Reply-To: <055.a30f0e860d0436f770378729f9ecdbdb@lists.automattic.com> References: <055.a30f0e860d0436f770378729f9ecdbdb@lists.automattic.com> Message-ID: <064.9350cea14e1b59b75b2c03bc5558f5c5@lists.automattic.com> #1258: Curly quotes mixups -------------------------------+-------------------------------------------- Reporter: Denis de Bernardy | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Template | Version: 2.1 Severity: normal | Resolution: worksforme Keywords: needs-patch | -------------------------------+-------------------------------------------- Changes (by lloydbudd): * milestone: 2.4 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 17:03:16 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 18:30:29 2007 Subject: [wp-trac] Re: [WordPress Trac] #5235: Add Pre-flight checks to install In-Reply-To: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> References: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> Message-ID: <052.6c3082269704bd455184e15020b0d4a6@lists.automattic.com> #5235: Add Pre-flight checks to install -------------------------+-------------------------------------------------- Reporter: westi | Owner: pishmishy Type: enhancement | Status: assigned Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Changes (by pishmishy): * owner: anonymous => pishmishy * status: new => assigned -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 18:53:58 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 18:54:10 2007 Subject: [wp-trac] Re: [WordPress Trac] #5277: Posts are de-categorized when upgrading to 2.3.x In-Reply-To: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> References: <041.d363f2f691659ddda48b2cc38ea1e1f9@lists.automattic.com> Message-ID: <050.3f8a4e448e0dd7267f832007c9058519@lists.automattic.com> #5277: Posts are de-categorized when upgrading to 2.3.x ----------------------+----------------------------------------------------- Reporter: dtc | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by darkfate): Well I guess it might have something to do with tagging. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 18:56:59 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 18:57:12 2007 Subject: [wp-trac] [WordPress Trac] #5322: RSS feed managemenet Message-ID: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> #5322: RSS feed managemenet ----------------------------+----------------------------------------------- Reporter: jdingman | Owner: anonymous Type: enhancement | Status: new Priority: low | Milestone: 2.5 Component: Administration | Version: Severity: minor | Keywords: rss feed ----------------------------+----------------------------------------------- There's presently no way to manage what the RSS feed outputs. I'm suggesting that there be a way to manage which categories are either included or excluded from all feeds. being able to select particular categories to NOT be fed to subscribers would be a huge help. let me know if you need clarification beyond what I wrote. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 19:11:00 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 19:11:14 2007 Subject: [wp-trac] Re: [WordPress Trac] #5322: RSS feed managemenet In-Reply-To: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> References: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> Message-ID: <055.3eed7d63225dea822f0b9aee4f0dc245@lists.automattic.com> #5322: RSS feed managemenet ----------------------------+----------------------------------------------- Reporter: jdingman | Owner: anonymous Type: enhancement | Status: new Priority: low | Milestone: 2.5 Component: Administration | Version: Severity: minor | Resolution: Keywords: rss feed | ----------------------------+----------------------------------------------- Comment (by jdingman): Update, http://zeo.unic.net.my/notes/exclude-category-in-wordpress/ this does the same thing for excluding particular categories, but it would be great if there was a user-friendly way to do it rather than having to search Google, then implement a function. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Mon Nov 5 19:52:14 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Mon Nov 5 19:52:25 2007 Subject: [wp-trac] Re: [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address In-Reply-To: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> References: <046.09634736e941d3d69c41a4793e947266@lists.automattic.com> Message-ID: <055.175f6455749dc979318d62416e3aa7eb@lists.automattic.com> #5007: Email notifications fail on hosted sites that check sender address ------------------------+--------------------------------------------------- Reporter: jlwarlow | Owner: anonymous Type: defect | Status: reopened Priority: low | Milestone: 2.3.2 Component: General | Version: 2.2.2 Severity: minor | Resolution: Keywords: regression | ------------------------+--------------------------------------------------- Comment (by mattyrob): Replying to [comment:13 westi]: > > I'm pretty sure we used to use the admin address at one point - I can't remember exactly why it changed to the current method. My plugin tries to pull the admin details including the address - I often run into support issues because users have deleted the admin entry (ID = 1) from the database. This may be why that method is no longer used. It may also be because the supplied email could be on a different domain than the blog. I think future work on using a valid email would be good. In the meantime I guess we'll have to reverse this change. :-( -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 00:48:28 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 00:48:42 2007 Subject: [wp-trac] Re: [WordPress Trac] #5322: RSS feed managemenet In-Reply-To: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> References: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> Message-ID: <055.e58b76a7edf43063c811fda8a1bf8841@lists.automattic.com> #5322: RSS feed managemenet ----------------------------+----------------------------------------------- Reporter: jdingman | Owner: anonymous Type: enhancement | Status: new Priority: low | Milestone: 2.5 Component: Administration | Version: Severity: minor | Resolution: Keywords: rss feed | ----------------------------+----------------------------------------------- Comment (by Viper007Bond): Plugin territory IMO 'cause as that link shows, it's super easy to do. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 00:57:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 00:58:10 2007 Subject: [wp-trac] Re: [WordPress Trac] #4857: More issues with wpautop() In-Reply-To: <050.edcf1e5c35f85246856f317f877f1a56@lists.automattic.com> References: <050.edcf1e5c35f85246856f317f877f1a56@lists.automattic.com> Message-ID: <059.bf9e2cdfc6f1b27aaaa1d96ec40a6b93@lists.automattic.com> #4857: More issues with wpautop() ---------------------------------+------------------------------------------ Reporter: Viper007Bond | Owner: mdawaffe Type: defect | Status: assigned Priority: low | Milestone: 2.4 Component: Template | Version: 2.3 Severity: normal | Resolution: Keywords: wpautop needs-patch | ---------------------------------+------------------------------------------ Changes (by mdawaffe): * keywords: needs-patch => wpautop needs-patch * owner: anonymous => mdawaffe * status: new => assigned Comment: I look at your first (and second) example and expect the paragraph to only wrap around "Foo": {{{

Foo

Bar
}}} since paragraph elements can only contain inline content*. For that reason, I do not expect the paragraph to wrap the whole thing: {{{ mdawaffe thinks this is wrong

Foo

Bar

}}} * http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_p -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 05:47:41 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 05:47:54 2007 Subject: [wp-trac] Re: [WordPress Trac] #5309: 'Insert/edit image' dialog changes empty fields to default values In-Reply-To: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> References: <050.53707c0c3ba758b7438f2e8ad82fbb23@lists.automattic.com> Message-ID: <059.67405f1fc70eb10322afc8093d98598e@lists.automattic.com> #5309: 'Insert/edit image' dialog changes empty fields to default values -------------------------------+-------------------------------------------- Reporter: hermanschaap | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: reporter-feedback | -------------------------------+-------------------------------------------- Comment (by hermanschaap): I am using Internet Explorer and Windows Vista. And yes, it looks like it is related to #5087. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 12:06:53 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 12:07:06 2007 Subject: [wp-trac] Re: [WordPress Trac] #5235: Add Pre-flight checks to install In-Reply-To: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> References: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> Message-ID: <052.3e7cccd102b920d817f130ed15e80984@lists.automattic.com> #5235: Add Pre-flight checks to install -------------------------+-------------------------------------------------- Reporter: westi | Owner: pishmishy Type: enhancement | Status: assigned Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Comment (by pishmishy): I've added a rough draft of a potential preflight check. I don't know if this is the sort of direction people would like to see it take, so I'd appreciate any feedback. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 14:35:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 14:35:58 2007 Subject: [wp-trac] Re: [WordPress Trac] #5322: RSS feed management In-Reply-To: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> References: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> Message-ID: <055.30db4f63de7e683b45be15252279a205@lists.automattic.com> #5322: RSS feed management ----------------------------+----------------------------------------------- Reporter: jdingman | Owner: anonymous Type: enhancement | Status: new Priority: low | Milestone: 2.5 Component: Administration | Version: Severity: minor | Resolution: Keywords: rss feed | ----------------------------+----------------------------------------------- Changes (by santosj): * summary: RSS feed managemenet => RSS feed management -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 14:51:41 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 14:51:54 2007 Subject: [wp-trac] [WordPress Trac] #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post Message-ID: <047.aa89e65bf7b76cfb8c869e797bc9bf67@lists.automattic.com> #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post -----------------------+---------------------------------------------------- Reporter: minusfive | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: normal | Keywords: write post page custom field save redirect -----------------------+---------------------------------------------------- If you try to add a custom field to a new post / page, without first saving it (i.e. "Save and continue editing", "Save" or "Publish"), WordPress will kick you out / redirect you away from the write screen without giving you an option to save the post, and will arbitrarily save the post as an unpublished, title-less POST even if it was originally being created from the Write Page screen. Hope I explained myself correctly :) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 14:56:00 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 14:56:11 2007 Subject: [wp-trac] Re: [WordPress Trac] #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post In-Reply-To: <047.aa89e65bf7b76cfb8c869e797bc9bf67@lists.automattic.com> References: <047.aa89e65bf7b76cfb8c869e797bc9bf67@lists.automattic.com> Message-ID: <056.e8bd529728e103aa22ff03b146639a69@lists.automattic.com> #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post --------------------------------------------------------+------------------- Reporter: minusfive | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.3.2 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: write post page custom field save redirect | --------------------------------------------------------+------------------- Comment (by pishmishy): This doesn't happen with me and the development code. Is there anything odd about your environment? Could it be your browser doing something odd? James -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 15:13:20 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 15:13:32 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.d2e3a4dc0b954f2ae7f6735d8e979899@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by openlycreative): I am really not happy with the lack of support on this issue. I have been using WordPress for quite a while now and have had several issues with lack of response to issues on the message boards in the past and (apparently) here as well. I don't want to have to sink several hundred dollars into a CMS if I don't have to, but the lack of support is a big problem for me. This "cookie error" is causing problems for my clients and I just can't have that. Opensource is great, but only if there is a dedicated staff to debug these kinds of issues. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 15:17:42 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 15:17:54 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.4acb134b4d46690153d61f25bd949298@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by pishmishy): Please can you precisely describe how to replicate the "cookie error", we can then work on fixing the problem. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:18:53 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:19:06 2007 Subject: [wp-trac] Re: [WordPress Trac] #5322: No options to manage what categories the RSS feed includes In-Reply-To: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> References: <046.b051d42917554c6626431a079be1f6c8@lists.automattic.com> Message-ID: <055.59e714f60c3a0f56da11d2a2679fe461@lists.automattic.com> #5322: No options to manage what categories the RSS feed includes ----------------------------+----------------------------------------------- Reporter: jdingman | Owner: anonymous Type: enhancement | Status: closed Priority: low | Milestone: Component: Administration | Version: Severity: minor | Resolution: wontfix Keywords: rss feed | ----------------------------+----------------------------------------------- Changes (by foolswisdom): * status: new => closed * summary: RSS feed management => No options to manage what categories the RSS feed includes * resolution: => wontfix * milestone: 2.5 => Comment: I agree with Viper007Bond, plugin territory, closing as won't fixed for now, pending a compelling experience. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:20:05 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:20:17 2007 Subject: [wp-trac] Re: [WordPress Trac] #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post In-Reply-To: <047.aa89e65bf7b76cfb8c869e797bc9bf67@lists.automattic.com> References: <047.aa89e65bf7b76cfb8c869e797bc9bf67@lists.automattic.com> Message-ID: <056.f2c4c8da3ed106da2b54cf7943230d85@lists.automattic.com> #5323: Write Post / Page inadvertently redirects when adding a custom field without first saving the post --------------------------------------------------------+------------------- Reporter: minusfive | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: normal | Resolution: duplicate Keywords: write post page custom field save redirect | --------------------------------------------------------+------------------- Changes (by foolswisdom): * status: new => closed * resolution: => duplicate * milestone: 2.3.2 => Comment: Duplicate of #3700 I think. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:20:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:20:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #3700: Adding a custom field to an unsaved Page before publishing causes weirdness In-Reply-To: <049.7b65847c64c66ed3e90fa481e139ade9@lists.automattic.com> References: <049.7b65847c64c66ed3e90fa481e139ade9@lists.automattic.com> Message-ID: <058.ba4da13dfaa92fc92aef3127b58c4aa4@lists.automattic.com> #3700: Adding a custom field to an unsaved Page before publishing causes weirdness ----------------------------+----------------------------------------------- Reporter: markjaquith | Owner: Andy Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.1.3 Severity: normal | Resolution: Keywords: needs-patch | ----------------------------+----------------------------------------------- Comment (by foolswisdom): Also reported in #5323 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:27:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:27:45 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.f0ea8bba1c9270273d8f41643f9209a8@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by foolswisdom): openlycreative, I understand your frustration. People tend to prioritize their work based on their own needs and interests. Your note reads a little bit like you are looking for something for nothing -- I imagine in reality you have contributed a lot to WordPress through promoting and deploying to your clients. if it is costing you money than I suggest you spend money on a solution and give the solution back to the community. Email the wp-pro list with a request for quote. Otherwise as pishmishy suggests, we will need a reproducable scenario. If you can duplicate the issue with a fresh install from multiple browsers from multiple computers than it suggests it might be specific to the server environment -- one of the cookie issues was just that, where installing to a subdirectory was a factor. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:33:53 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:34:05 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.b3b20f5fab0380ba301e5e1922d7a822@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by Michaelh): Links to related forum topics: http://wordpress.org/support/topic/141338 http://wordpress.org/support/topic/142244 http://wordpress.org/support/topic/142244 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 16:57:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 16:57:45 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.e34dc0d765264ad5850349f43fabe560@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by pishmishy): Replying to [comment:4 Michaelh]: > Links to related forum topics: Thank you for the links. Unfortunately your posts to the forum don't contain information on how we can replicate the issue so we can work on fixing it. Once I can replicate your problem I'd be happy to work on fixing it. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 17:09:24 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 17:09:36 2007 Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after upgrade to 2.3.1 In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com> Message-ID: <061.bf03b12bbbd727a76aeb148835b635fa@lists.automattic.com> #5308: continued cookie error after upgrade to 2.3.1 ----------------------------+----------------------------------------------- Reporter: openlycreative | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: cookie error | ----------------------------+----------------------------------------------- Comment (by pishmishy): Problem may be related to #5076 ? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 18:31:09 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 18:31:21 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.e675946022bddeb26331f771aa02b019@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): tellyworth ran unit tests and said it looks alright. Committing. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 18:31:56 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 18:32:08 2007 Subject: [wp-trac] Re: [WordPress Trac] #5181: Refactoring Atom support; baby step #1 In-Reply-To: <043.0362d55465f275b28bf1b7199dd3e14c@lists.automattic.com> References: <043.0362d55465f275b28bf1b7199dd3e14c@lists.automattic.com> Message-ID: <052.72718225e8eae2fb2721425b65ef0efd@lists.automattic.com> #5181: Refactoring Atom support; baby step #1 --------------------------------+------------------------------------------- Reporter: rubys | Owner: westi Type: enhancement | Status: closed Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: fixed Keywords: has-patch has-docs | --------------------------------+------------------------------------------- Comment (by foolswisdom): (In [6315]) Back out some of changeset [5273] from #5181. Props rubys. fixes #5307 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 18:32:06 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 18:32:18 2007 Subject: [wp-trac] Re: [WordPress Trac] #5232: Get the current action and current filter name In-Reply-To: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> References: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> Message-ID: <057.19d535f4d68c37cc07ada38d38eab298@lists.automattic.com> #5232: Get the current action and current filter name -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by ryan): Needs update now that #5231 went in. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 19:12:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 19:12:34 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.85456cfdfc86a3fafd1a36d31ea8e28f@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by westi): Replying to [comment:5 rubys]: > Am I misreading line 20 in {{{xmlrpc.php}}} incorrectly? The intent of this patch is to only do this check when fetching the {{{rsd}}} document. > > See [http://intertwingly.net/blog/2007/10/31/WordPress-SSL-TLS-and- AtomPub this post] for background. Some place in the traversal from {{{http://foo.wordpress.com/}}} => {{{xmlrpc.php?rsd}}} => {{{/wp- app.php/service}}} => {{{/wp-app.php/posts}}} or {{{/wp- app.php/attachments}}} there needs to be an indication that {{{https}}} should be used. Doing this when rendering the front-page would clearly be overkill. Doing it on every fetch of the service document would be better. Doing it only when fetching the discovery document seems (to me at least) to be better yet. Sorry - I read the patch too quick :-( Indeed this does only apply when we are returning the rsd. I think i would be happier if we moved the check for https availablity out to a generic function and then just had an apply_filter call in xmlrpc.php so that a plugin could force a https url without the run-time cost of the check if the admin knows that https is available for accessing the blog. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 19:30:49 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 19:31:01 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.3ec650b7d6b5dbd0584009e0c9d6b759@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by westi): Could you try that new untested patch on for size? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 20:06:00 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 20:06:11 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.fe7e66ef54a7b1055e5d6496f06def31@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by rubys): Replying to [comment:7 westi]: > Could you try that new untested patch on for size? A number of minor issues fixed (unmatched parens in xmlrpc.php, get_bloginfo does an implicit echo, apply_filters does not do an implicit echo). One substantive change: blog_is_accessable_via_ssl() => url_is_accessable_via_ssl($url). Two reasons for this (1) on my test site https://rubix.home/wordpress (note no trailing slash) returns a 404, and (2) this given the potential plugin the full url and complete freedom to modify any or all of it. P.S. s/accessable/accessible/ ? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 20:22:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 20:22:56 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.a45072378e01cd3d5a5eed0e15adc869@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Changes (by mdawaffe): * status: closed => reopened * resolution: fixed => Comment: With separation of $wp_filter from $wp_action, we need to change some of the hardcoded references to $wp_filter. Attached adds $wp_action to unsets in wp-settings.php (necessary?) and fixes get_plugin_page_hook(). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 20:28:32 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 20:28:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.8b17e96ece84f55e66b513dfc828a340@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): mdawaffe suggested wrapping these checks in some API. has_filter() and has_action(). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 20:30:41 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 20:30:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.a80a6ffe69739e9ea1436962d33cafd8@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by santosj): Could it be combined with the functionality to get current hook executed? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 21:07:30 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 21:07:41 2007 Subject: [wp-trac] Re: [WordPress Trac] #5232: Get the current action and current filter name In-Reply-To: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> References: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> Message-ID: <057.9111c56337b0564bf549e9babd21a359@lists.automattic.com> #5232: Get the current action and current filter name -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by tellyworth): the revised-r6317 patch is a quick update to work with #5231. It still uses a single $wp_current_filter global to store the current filter or action name. Perhaps it's worth improving it to store the filter and action separately. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 21:10:50 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 21:11:01 2007 Subject: [wp-trac] Re: [WordPress Trac] #5232: Get the current action and current filter name In-Reply-To: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> References: <048.e39d6f1c2954664065e0f72a8fa2351b@lists.automattic.com> Message-ID: <057.432649a1d595d18dad999d60ee8bc398@lists.automattic.com> #5232: Get the current action and current filter name -------------------------+-------------------------------------------------- Reporter: tellyworth | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by santosj): Given the execution of PHP and the pushing and popping, I don't think it is worth it. You could put some metadata in along with the tag to say whether it is an action or a filter. However, creating a separate global doesn't seem logical. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 21:25:40 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 21:25:55 2007 Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document doesn't point to https collections In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com> Message-ID: <052.ef1f9ee1baee73b8c834df645132768b@lists.automattic.com> #5298: https atom service document doesn't point to https collections -----------------------+---------------------------------------------------- Reporter: rubys | Owner: westi Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: normal | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Comment (by westi): Replying to [comment:8 rubys]: > Replying to [comment:7 westi]: > > Could you try that new untested patch on for size? > > A number of minor issues fixed (unmatched parens in xmlrpc.php, get_bloginfo does an implicit echo, apply_filters does not do an implicit echo). > > One substantive change: blog_is_accessable_via_ssl() => url_is_accessable_via_ssl($url). Two reasons for this (1) on my test site https://rubix.home/wordpress (note no trailing slash) returns a 404, and (2) this given the potential plugin the full url and complete freedom to modify any or all of it. > > P.S. s/accessable/accessible/ ? Thanks for the test and update - I had to run and have dinner so I chucked up my in progress code! I'll have a look at getting this checked in tomorrow -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 21:59:12 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 21:59:24 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.1c8d1046d382752ec6868756ff579047@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Patch implements has_filter and has_action and uses them where needed. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Tue Nov 6 23:09:39 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Tue Nov 6 23:13:32 2007 Subject: [wp-trac] [WordPress Trac] #5324: 404 error on empty category page Message-ID: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Keywords: --------------------------+------------------------------------------------- spoken to many people who believe this isn't good functionality and probably a bug. i'm not a coder so I might be wrong, but i hope not. wordpress returns a 404 error when a category page is viewed that's empty. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 00:04:18 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 00:04:29 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.d35ab39fb71cf907cd289cd6e7bf72d6@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by mdawaffe): has_filter_with_arg.diff = has_filter.diff plus the following. 1. {{{has_filter( $tag )}}} improved to return false if {{{$wp_filter[$tag]}}} is empty (not just if not set). 2. {{{remove_filter( $tag, $func, $priority )}}} improved to unset {{{$wp_filter[$tag][$priority]}}} as necessary (so that {{{has_filter()}}} can work). 3. new {{{has_filter( $tag, $function )}}} syntax. Returns {{{$priority}}} if {{{$function}}} is attached to {{{$tag}}}, {{{false}}} otherwise. 4. tweak to internally used {{{_wp_filter_build_unique_id()}}} to make {{{has_filter( $tag, $function )}}} work. 5. same for {{{*_action}}}. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 00:31:13 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 00:31:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.4d18a1d46e62d9c83ee20d0f6561e1ef@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): {{{ if ( !count($GLOBALS['wp_filter'][$tag][$priority]) ) }}} Could that be: {{{ if ( empty($GLOBALS['wp_filter'][$tag][$priority]) ) }}} -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 00:32:19 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 00:32:30 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.60a12683314bc08506c46d905528145f@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by mdawaffe): Yes, should do. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 03:54:05 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 03:54:22 2007 Subject: [wp-trac] [WordPress Trac] #5325: sanitize_post and sanitize_post_field are very expensive no-ops Message-ID: <046.06cd79e4cc702d7e71a8151c9f68b9b5@lists.automattic.com> #5325: sanitize_post and sanitize_post_field are very expensive no-ops --------------------------+------------------------------------------------- Reporter: Quandary | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: Optimization | Version: 2.3.1 Severity: major | Keywords: --------------------------+------------------------------------------------- Simple, commonly-called template functions (the_title, get_permalink, etc.) are all channeled through the get_post function. While get_post implements caching, it caches content before it's been filtered, ''not'' after. This means that sanitize_post is called for each and every call to get_post. I loaded a test page 5 times in a test configuration that had 86 calls to get_post (mostly via get_the_title and get_permalink). Instrumentation results from APD indicate that fully 8-15% (~9.5% avg.) of the page generation time was spent in sanitize_post and sanitize_post_field, even though nearly all of the calls were for "raw" data, and no filtering was actually taking place. I added a simple early bail-out to bypass the no-op actions, and this reduced the hit to .1-.2% across another 5 page loads (no, that's not a typo ;). I'm attaching a patch to fix this bug, but this is only the immediate problem (get_post appears to be called with "raw" ''way'' more frequently then with "display"). Opening another bug on the filtering implementation ''may'' be warranted. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 03:59:05 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 03:59:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #5325: sanitize_post and sanitize_post_field are very expensive no-ops In-Reply-To: <046.06cd79e4cc702d7e71a8151c9f68b9b5@lists.automattic.com> References: <046.06cd79e4cc702d7e71a8151c9f68b9b5@lists.automattic.com> Message-ID: <055.edad62de62def6f0650c049d6e13115d@lists.automattic.com> #5325: sanitize_post and sanitize_post_field are very expensive no-ops --------------------------+------------------------------------------------- Reporter: Quandary | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.3.2 Component: Optimization | Version: 2.3.1 Severity: major | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by Quandary): * keywords: => has-patch -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 06:21:02 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 06:21:13 2007 Subject: [wp-trac] Re: [WordPress Trac] #5325: sanitize_post and sanitize_post_field are very expensive no-ops In-Reply-To: <046.06cd79e4cc702d7e71a8151c9f68b9b5@lists.automattic.com> References: <046.06cd79e4cc702d7e71a8151c9f68b9b5@lists.automattic.com> Message-ID: <055.08e7e79d81a19e0d7dfd926fbc9e1c90@lists.automattic.com> #5325: sanitize_post and sanitize_post_field are very expensive no-ops --------------------------+------------------------------------------------- Reporter: Quandary | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.3.2 Component: Optimization | Version: 2.3.1 Severity: major | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by ryan): * status: closed => reopened * resolution: fixed => Comment: Thanks. Applied to trunk. I also did this for sanitize_term. Nominating for 2.3 inclusion. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 09:48:58 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 09:49:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #5235: Add Pre-flight checks to install In-Reply-To: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> References: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> Message-ID: <052.f0c33511dad4dd0e3c954673f06035b0@lists.automattic.com> #5235: Add Pre-flight checks to install -------------------------+-------------------------------------------------- Reporter: westi | Owner: pishmishy Type: enhancement | Status: assigned Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Changes (by pishmishy): * keywords: needs-patch => has-patch -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 10:10:34 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 10:10:49 2007 Subject: [wp-trac] Re: [WordPress Trac] #5272: WordPress allows anonymous user to see slug for private post by guessing post number In-Reply-To: <045.2ee8ebcf130603e00b7e2e5f88cba146@lists.automattic.com> References: <045.2ee8ebcf130603e00b7e2e5f88cba146@lists.automattic.com> Message-ID: <054.275302f5217ec08c4c0421489b55011e@lists.automattic.com> #5272: WordPress allows anonymous user to see slug for private post by guessing post number -------------------------+-------------------------------------------------- Reporter: tzafrir | Owner: pishmishy Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Changes (by pishmishy): * owner: anonymous => pishmishy * status: new => assigned Comment: Confirming that the bug exists in trunk. Worth fixing as the slug may have been automatically derived from post data that the user didn't want to disclose. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 10:34:20 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 10:34:33 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.03cf9626b60b87b86da3bf20b7588b44@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: needs-patch | --------------------------+------------------------------------------------- Changes (by Viper007Bond): * keywords: => needs-patch * version: => 2.4 * milestone: 2.5 => 2.4 Comment: Confirmed on trunk. Displays the error 404 page and sends a 404 header for the archive view of an empty but existing category. It should display as normal and when the template check for `have_posts()` or whatever fails, the "no matching posts" error will be shown. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 10:47:23 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 10:47:37 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.abe103491538ac71382f1eaa6a4db8c0@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by tellyworth): all_action_fix_r6322.patch fixes a bug where the all action only ran once. Unit tests are here: http://svn.automattic.com/wordpress-tests/wp-testcase/test_actions.php http://svn.automattic.com/wordpress-tests/wp-testcase/test_filters.php -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 11:02:28 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 11:02:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5272: WordPress allows anonymous user to see slug for private post by guessing post number In-Reply-To: <045.2ee8ebcf130603e00b7e2e5f88cba146@lists.automattic.com> References: <045.2ee8ebcf130603e00b7e2e5f88cba146@lists.automattic.com> Message-ID: <054.1210e4d891cecf65a7f4f50024c6d6b0@lists.automattic.com> #5272: WordPress allows anonymous user to see slug for private post by guessing post number -----------------------------------------------------+---------------------- Reporter: tzafrir | Owner: pishmishy Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.3.1 Severity: major | Resolution: Keywords: has-patch canonical redirection private | -----------------------------------------------------+---------------------- Changes (by pishmishy): * keywords: needs-patch => has-patch canonical redirection private Comment: Fix is to add an additional condition to be satisfied before canonical redirection can take place. Not entirely happy with my patch but it does fix the problem. Someone more familiar with query.php can probably come up with an is_private() function. is_empty works just as well though. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 11:04:09 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 11:04:24 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.cafb7d0872fff149207d22e4964bed01@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: needs-patch | --------------------------+------------------------------------------------- Comment (by pishmishy): Question... Does this occur only when you manually construct the URL itself, or is WordPress automatically generating a link to the page for the empty category which results in a 404? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 13:25:22 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 13:25:35 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.23266d7ed24bd15f5645a6e7a972d083@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: pishmishy Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by pishmishy): * keywords: needs-patch => has-patch * owner: anonymous => pishmishy * status: new => assigned Comment: Sorry, ignore that file. It's not complete. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 13:40:09 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 13:40:28 2007 Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> Message-ID: <053.abcf926ffb4dc0acf53045b21b95d832@lists.automattic.com> #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 ---------------------------------------------+------------------------------ Reporter: abtime | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: i18n | Version: 2.2 Severity: critical | Resolution: Keywords: i18n has-patch 2nd-opition test | ---------------------------------------------+------------------------------ Comment (by thenlich): This bug is still present in Wordpress 2.3 on Linux/amd64/PHP 5.2.3 It worked for me to remove the & 0xFFFFFFFF's. Solution is described here: http://faq.wordpress-deutschland.org/wieso-zeigt-wordpress-trotz- sprachdatei-englischen-text-an/ -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 13:40:59 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 13:41:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> Message-ID: <053.c5c0977436ccca751b089f33300e74d7@lists.automattic.com> #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 ---------------------------------------------+------------------------------ Reporter: abtime | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: i18n | Version: 2.2 Severity: critical | Resolution: Keywords: i18n has-patch 2nd-opition test | ---------------------------------------------+------------------------------ Comment (by thenlich): Addition: Bug still present in 2.3.1 also. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 13:45:17 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 14:22:03 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.e77c0a8300971ef02fe31fc752826182@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: pishmishy Type: defect | Status: assigned Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Comment (by Viper007Bond): Replying to [comment:2 pishmishy]: > Question... > > Does this occur only when you manually construct the URL itself, or is WordPress automatically generating a link to the page for the empty category which results in a 404? Well, it's the same URL, so... ;) -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 15:11:08 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 15:11:22 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.beaa0ebb0629da6c6db6577db572ea56@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: has-patch | --------------------------+------------------------------------------------- Changes (by pishmishy): * owner: pishmishy => anonymous * status: assigned => new Comment: Actually I think this one is beyond me to fix cleanly. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 15:27:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 15:27:17 2007 Subject: [wp-trac] Re: [WordPress Trac] #5235: Add Pre-flight checks to install In-Reply-To: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> References: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com> Message-ID: <052.877ac35c6e05b534975e959b23311f29@lists.automattic.com> #5235: Add Pre-flight checks to install -------------------------+-------------------------------------------------- Reporter: westi | Owner: pishmishy Type: enhancement | Status: assigned Priority: normal | Milestone: 2.5 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Comment (by santosj): There should be more logic to make sure they have {{{Allow_Fopen_URL}}} or the PHP configuration to get URLs. That is important, but not required. I was thinking about perhaps having levels (green, yellow, red) that the other installers have (OpenAds). Instead of displaying all of them, just display the yellow and halt on red (ask to continue with message saying "Hey, yo some parts of WordPress won't function correctly. Get bettre [intentionally misspelled] host." Since I don't have any involvement, I would rather like anything that is done. The above just suggestion, if I had a chance to do something. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 17:02:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 17:02:57 2007 Subject: [wp-trac] [WordPress Trac] #5326: Don't use sanitize_title in widgets API Message-ID: <042.a66ff198e8f797cdc62d204910626f2a@lists.automattic.com> #5326: Don't use sanitize_title in widgets API ---------------------+------------------------------------------------------ Reporter: ryan | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Keywords: performance ---------------------+------------------------------------------------------ widgets.php calls sanitize_title() on widget IDs. For the new API (functions starting with wp_), this isn't necessary. sanitize_title() is a slow function that does lots of stuff we don't need to do when sanitizing an ID. Let's just drop the sanitization and take the ID as is. For the old widgets API (functions without wp_), the sanitization can stay for maximum back-compat. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 17:06:57 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 17:07:11 2007 Subject: [wp-trac] Re: [WordPress Trac] #5326: Don't use sanitize_title in widgets API In-Reply-To: <042.a66ff198e8f797cdc62d204910626f2a@lists.automattic.com> References: <042.a66ff198e8f797cdc62d204910626f2a@lists.automattic.com> Message-ID: <051.519ec748bdb9914558d506050b954b34@lists.automattic.com> #5326: Don't use sanitize_title in widgets API -------------------------+-------------------------------------------------- Reporter: ryan | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: performance | -------------------------+-------------------------------------------------- Comment (by ryan): This patch reduced the number of calls to sanitize_title() from 103 to 2 on my testbed. The amount of time spent in sanitize_title() dropped from almost 10% to a fraction of a percent. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 19:24:53 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 19:25:06 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.0d7d7c5497e01f974e0604d158f82895@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by mdawaffe): Replying to [comment:34 tellyworth]: > all_action_fix_r6322.patch fixes a bug where the all action only ran once. Does do_action_ref_array need a similar fix? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 19:33:03 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 19:33:13 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.df48860b08d827050f92331436618772@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): I'm finding that several plugins are doing add_action where they mean add_filter, and vice versa. Now that we've split filters and plugins, these plugins break. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 19:59:19 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 19:59:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.8ea35e8a4a5201ddd604c9536e2f4ad5@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): I think we need to revert back to one array for both filters and actions. 'all' support can be simplified to pass the name of the hook and an array of all the args to functions hooked to 'all'. An 'all' function would not be expected to return a value. 'all' functions won't filter anything. They just get notification of the hook being processed and the args passed to that hook and that's it. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 21:21:11 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 21:21:24 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.864e5847efd1e3e24978593acfcfbab7@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by santosj): Can you add type of hook (filter|action) or is that what you mean? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:06:28 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:06:40 2007 Subject: [wp-trac] [WordPress Trac] #5327: Possible stupid bug of the plugin system Message-ID: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: 2.5 Component: General | Version: 2.3.1 Severity: blocker | Keywords: ---------------------+------------------------------------------------------ I have just wasted 4+ hours because WP '''breaks horribly''' without any warning or error message when there is '''more than one empty line''' under the last {{{?>}}} tag in the source code of a plugin. I found out about this accidentally while trying desperately to fix a problem with a plugin of mine. Can anybody confirm this? The only thing I do not want to read is that it is a feature or a necessary evil or anything similar... Thanks -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:08:16 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:08:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.8d6b00b4f741e8c113c260124de54b79@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: new Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by gnot): * milestone: 2.5 => -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:11:33 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:11:44 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.a654aa651a037e27987ce87d7be2c74a@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Changes (by santosj): * status: new => closed * resolution: => invalid Comment: This isn't a WordPress issue. It is a PHP issue. It is a common problem with a known solution. All WordPress files must not have more than one empty line (none would be better). If you remove the {{{?>}}} from PHP only files, it would prevent this from happening again. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:17:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:17:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.bcad3a728695a3399911c812c06832ed@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Comment (by gnot): Damn, I do not want to write anything in PHP again... -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:21:15 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:21:26 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.537810d92dddce6b4e037cffbeb2757c@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Comment (by santosj): Why? Most likely what happened was that you have display_errors set to '0', which is why no errors or warnings came up. If you had turned it on, you most likely would have received an error about trying to send headers after they were already sent (Most common cause of this happening). All languages are going to have little "gotchas" that you have to figure out. It technically isn't a PHP issue either, since it is the expected behavior and documented. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:22:30 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:22:41 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.8109a66ee53a9f7b05cbe6166ac8bfcf@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Comment (by santosj): Well, at least now you know and knowing is half the battle. The other half is fixing or preventing it from happening again. That and turning on Display Errors on your development server (if not already on). -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 22:26:21 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 22:26:32 2007 Subject: [wp-trac] Re: [WordPress Trac] #5327: Possible stupid bug of the plugin system In-Reply-To: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> References: <042.35eb7700e4e33e81a5b2ffaa596b0a2a@lists.automattic.com> Message-ID: <051.8c41772d7281d44df3804b87d43f4c39@lists.automattic.com> #5327: Possible stupid bug of the plugin system ---------------------+------------------------------------------------------ Reporter: gnot | Owner: anonymous Type: defect | Status: closed Priority: high | Milestone: Component: General | Version: 2.3.1 Severity: blocker | Resolution: invalid Keywords: | ---------------------+------------------------------------------------------ Comment (by gnot): Problem is that I was trying to fix the plugin on my live blog :) Anyway, despite my anger about the wasted time, I'd like to thank you for the information. I am not a professional. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 23:53:14 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 23:53:26 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.332bd71c0999d0c7476f7c7d902c1f1f@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): Patch brings actions and filters back together in $wp_filter. 'all' functions are passed the name of the action/filter and all arguments. This means that 'all' hooks don't need to use current_filter() to get the current action/filter. We could also pass the hook type (filter or action), although I don't know how practically useful that is to the plugins that would be using 'all' hooks. Functions attached to 'all' are not expected to return anything. This avoids needing a filter versus action distinction, allowing us to use one array to store both. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Wed Nov 7 23:55:46 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Wed Nov 7 23:55:58 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.70391727ab4279b1970849876165827a@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by ryan): I also incorporated tellyworth's fix and moved the argument processing in do_action() down below the check to see if the action is set. This avoids unnecessary func_get_arg() calls. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 00:16:20 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 00:16:34 2007 Subject: [wp-trac] Re: [WordPress Trac] #3907: WP reverts to default theme on file access collision In-Reply-To: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> References: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> Message-ID: <051.a17d8db4816415f1afcc9feed658a3e0@lists.automattic.com> #3907: WP reverts to default theme on file access collision -------------------------+-------------------------------------------------- Reporter: _ck_ | Owner: anonymous Type: defect | Status: new Priority: low | Milestone: 2.5 Component: Template | Version: 2.2 Severity: major | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Comment (by ryan): How about we just lose this? We reset broken themes when visiting the Presentation admin page. Let's call that good enough. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 00:33:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 00:33:51 2007 Subject: [wp-trac] Re: [WordPress Trac] #3907: WP reverts to default theme on file access collision In-Reply-To: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> References: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> Message-ID: <051.86303e064e014fe5a898ed7d0fac26a5@lists.automattic.com> #3907: WP reverts to default theme on file access collision -------------------------+-------------------------------------------------- Reporter: _ck_ | Owner: anonymous Type: defect | Status: new Priority: low | Milestone: 2.5 Component: Template | Version: 2.2 Severity: major | Resolution: Keywords: needs-patch | -------------------------+-------------------------------------------------- Comment (by lloydbudd): +1 to removing the call validate_current_theme() from wp-settings.php file_exists can fails (returns false) when there is file contention. I've been working with a friend who supports a number of busy blogs and on two different hosting environments he has issue with regular resets -- and by regular, I don't mean I can see a pattern to the time interval, sometimes it can be a few minutes a part, sometimes a few hours. validate_current_theme with its 2 file checks is useful for basic sanity when going to the Presentation tab, and it would be great if it did more checking, but a synchronous wp_file_exists on every load of WP seems awkward, and won't detect most problems with a theme. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 00:35:40 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 00:35:52 2007 Subject: [wp-trac] Re: [WordPress Trac] #3907: WP reverts to default theme on file access collision In-Reply-To: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> References: <042.b028703ad64185af71d8606815310c02@lists.automattic.com> Message-ID: <051.bce1856c4fc6dd9da63d836d1a3ca6e1@lists.automattic.com> #3907: WP reverts to default theme on file access collision -----------------------+---------------------------------------------------- Reporter: _ck_ | Owner: anonymous Type: defect | Status: new Priority: low | Milestone: 2.4 Component: Template | Version: 2.2 Severity: major | Resolution: Keywords: has-patch | -----------------------+---------------------------------------------------- Changes (by lloydbudd): * keywords: needs-patch => has-patch * milestone: 2.5 => 2.4 -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 01:28:44 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 01:28:56 2007 Subject: [wp-trac] Re: [WordPress Trac] #5231: add_action('all', ...) causes unexpected behaviour In-Reply-To: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> References: <048.79c9cb0b973f423a432edcebd7bd7185@lists.automattic.com> Message-ID: <057.95946c7a29130e66343ad003939fa3b0@lists.automattic.com> #5231: add_action('all', ...) causes unexpected behaviour -------------------------------------+-------------------------------------- Reporter: tellyworth | Owner: anonymous Type: defect | Status: reopened Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch needs-testing | -------------------------------------+-------------------------------------- Comment (by tellyworth): Unit tests pass against [6324]. There are no tests for has_filter/has_action yet though. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 02:01:07 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 02:01:19 2007 Subject: [wp-trac] Re: [WordPress Trac] #4715: Lost of Priority with Merge_filters and $wp_filters['all'] In-Reply-To: <048.7a211309ca32f4134bc5b190c06364a9@lists.automattic.com> References: <048.7a211309ca32f4134bc5b190c06364a9@lists.automattic.com> Message-ID: <057.b150981f63d6302b722b0f11892622db@lists.automattic.com> #4715: Lost of Priority with Merge_filters and $wp_filters['all'] ------------------------------------------------------------------+--------- Reporter: darkdragon | Owner: anonymous Type: defect | Status: closed Priority: lowest | Milestone: 2.4 Component: General | Version: 2.3 Severity: trivial | Resolution: fixed Keywords: has-patch merge_filters filters plugin.php confirmed | ------------------------------------------------------------------+--------- Changes (by darkdragon): * status: new => closed * resolution: => fixed Comment: No longer relevant to WordPress 2.4. Closing as fixed, since merge_filters no longer exists or used. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 02:28:59 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 02:29:12 2007 Subject: [wp-trac] Re: [WordPress Trac] #5324: 404 error on empty category page In-Reply-To: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> References: <050.538ea420ae5db09f3b3a05473e42510b@lists.automattic.com> Message-ID: <059.1d10a49bf5152af1091d2dcae53db9ec@lists.automattic.com> #5324: 404 error on empty category page --------------------------+------------------------------------------------- Reporter: othellobloke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: 2.4 Severity: normal | Resolution: Keywords: needs-patch | --------------------------+------------------------------------------------- Changes (by Viper007Bond): * keywords: has-patch => needs-patch -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 12:09:04 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 12:09:16 2007 Subject: [wp-trac] [WordPress Trac] #5328: Make default feed format pluggable Message-ID: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com> #5328: Make default feed format pluggable ---------------------+------------------------------------------------------ Reporter: rubys | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Keywords: has-patch ---------------------+------------------------------------------------------ Provide a filter hook that a plugin could replace that would allow the plugin to control the default feed format. Additionally, the filter could provide the mime_type, display_name, short_name, and long_name to themes so that they could adjust, if they so desire. The provided patch adjusts the default theme to make use of this new filter. Simply drop in [http://intertwingly.net/stories/2007/11/08/atom- feed-format.phps this plugin] and activate it, and the pages automatically adapt. Deactivate the plugin, and the pages revert back to RSS 2.0. Additional plugins could be defined for RSS 0.92 or RSS 1.0. This patch does *not* change the default feed format from RSS 2.0. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 12:15:29 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 12:15:43 2007 Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format pluggable In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com> References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com> Message-ID: <052.132b949948ec02668e737d41905d1a75@lists.automattic.com> #5328: Make default feed format pluggable -------------------------+-------------------------------------------------- Reporter: rubys | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 2.4 Component: General | Version: Severity: normal | Resolution: Keywords: has-patch | -------------------------+-------------------------------------------------- Changes (by rubys): * type: defect => enhancement -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 14:55:08 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 14:55:20 2007 Subject: [wp-trac] [WordPress Trac] #5329: "submit for review" feature checks wrong permission and publishes Message-ID: <050.55ad130767d738b1bdae2a3de0e6c291@lists.automattic.com> #5329: "submit for review" feature checks wrong permission and publishes ----------------------------+----------------------------------------------- Reporter: jeremyclarke | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: Administration | Version: 2.3.1 Severity: normal | Keywords: has-patch ----------------------------+----------------------------------------------- The bug relates to the new post submission feature where users who can't publish their own posts can submit them for review rather than just saving them as draft and informing the site admin that they want it published. The worst case scenario has users clicking on a button that says "submit for review" but actually publishing the articles to the blog. in /wp-admin/edit-form-advanced.php on line 172 the logic checks to see if a user has the publish_posts capability/role and if they do not, it labels the "publish" button as "submit for review" instead. 172 173 174 175 176 This is linked with line 69 of /wp-admin/includes/post.php which processes the post status and sets it to pending based on user capabilities: 69 if ('publish' == $_POST['post_status'] && !current_user_can( 'edit_published_posts' )) 70 $_POST['post_status'] = 'pending'; 71 } As far as I can tell, there is no reason why the processing check should use the "edit_published_posts" role rather than the publish_posts role, especially considering that the publish_posts role was the one originally used to determine the text on the button. In the case of our site, or any where authors need help initially editing their posts but are trusted to make changes once the post is approved (and thus have edit_published_posts but not publish_posts), this results in people seeing the text "submit for review" but actually having their posts published to the blog, which of course can have terrible results. Any reason why this is this way? Seems like it should be fast-tracked into core and anyone using this functionality should probably patch it for themselves. NOTE: the edit_published_posts role I think is only available to authors through the role manager plugin, so if you aren't using it you probably aren't at risk, i think that's why this wasn't noticed when it was first implemented, for most installs publish_posts and edit_published_posts are available/unnavailable to the same user types). This is my first patch, so if there's a problem with the diff please let me know. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 16:42:19 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 16:42:31 2007 Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com> Message-ID: <053.b17143ff01dd0a3649276763250a47bb@lists.automattic.com> #3780: gettext fails to determine byteorder on 64bit systems with php5.2.1 ---------------------------------------------+------------------------------ Reporter: abtime | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 2.4 Component: i18n | Version: 2.2 Severity: critical | Resolution: Keywords: i18n has-patch 2nd-opition test | ---------------------------------------------+------------------------------ Comment (by nbachiyski): Could everybody, please, try the both patches and report if any is working. -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 17:37:38 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 17:37:55 2007 Subject: [wp-trac] Re: [WordPress Trac] #4852: Incorrect grammar when author ends with an s In-Reply-To: <044.a2d2ad5dcb35902e98a687cec37c5a3e@lists.automattic.com> References: <044.a2d2ad5dcb35902e98a687cec37c5a3e@lists.automattic.com> Message-ID: <053.529b164ba1dc1dc79744124e1d01c46f@lists.automattic.com> #4852: Incorrect grammar when author ends with an s ---------------------+------------------------------------------------------ Reporter: Nazgul | Owner: anonymous Type: defect | Status: new Priority: low | Milestone: 2.4 Component: i18n | Version: 2.3 Severity: trivial | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by regulatethis): The grammar is actually correct, as filosofo indicates above. Shouldn't this be set to invalid? -- Ticket URL: WordPress Trac WordPress blogging software From wp-trac at lists.automattic.com Thu Nov 8 18:05:47 2007 From: wp-trac at lists.automattic.com (WordPress Trac) Date: Thu Nov 8 18:05:59 2007 Subject: [wp-trac] Re: [WordPress Trac] #3492: Visual Rich Editor wipes out various CSS class or style attributes In-Reply-To: <044.3e6ecb85cee9f819d3e123e5cd897191@lists.automattic.com> References: <044.3e6ecb85cee9f819d3e123e5cd897191@lists.automattic.com> Message-ID: <053.10ebed9fdd35548642cf1c9acc3fdf5f@lists.automattic.com> #3492: Visual Rich Editor wipes out various CSS class or style attributes ---------------------+------------------------------------------------------ Reporter: figcar | Owner: anonymous Type: defect | Status: reopened Priority: high | Milestone: 2.4 Component: TinyMCE | Version: 2.3 Severity: major | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by derjohng): I had the same problems as flurischt. So, I tried to modify the editor_plugin.js. I thought I have solved 
 and foolswisdom's table tags problem.

 And 
  •  problem, according to ticket:4667, it's not allowed.

 benchmark20071109.txt is the file that I had tested. But, I am not sure
 this can "address all types of attribute loss" :p

 Please try it and let me known whether this works well or not.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov  8 18:14:46 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov  8 18:14:57 2007
Subject: [wp-trac] Re: [WordPress Trac] #3720: Problems with permission
In-Reply-To: <049.60c5e4dc0397045b01e2c0c0d010fa23@lists.automattic.com>
References: <049.60c5e4dc0397045b01e2c0c0d010fa23@lists.automattic.com>
Message-ID: <058.acf405acf2734156caea83cbe76c0f71@lists.automattic.com>

#3720: Problems with permission
-------------------------------+--------------------------------------------
 Reporter:  kanishigami        |        Owner:  anonymous
     Type:  defect             |       Status:  new      
 Priority:  high               |    Milestone:  2.4      
Component:  Administration     |      Version:  2.1      
 Severity:  normal             |   Resolution:           
 Keywords:  permission delete  |  
-------------------------------+--------------------------------------------
Comment (by regulatethis):

 Can't reproduce this in 2.4-bleeding (as of r6325). Are there any more
 details?

 Does this happen all the time?
 Any details about the posts you are trying to delete?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov  8 18:28:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov  8 18:29:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #3566: Request for new function
 get_page_parents
In-Reply-To: <047.6a7135c4982cd5875893dc678bf91481@lists.automattic.com>
References: <047.6a7135c4982cd5875893dc678bf91481@lists.automattic.com>
Message-ID: <056.daca9e9d4ab65b2524d3401f88f58b8b@lists.automattic.com>

#3566: Request for new function get_page_parents
-------------------------+--------------------------------------------------
 Reporter:  snakefoot    |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:  2.1      
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by Huskey):

 Your solution has a bug and returns the page title for $nicename = TRUE
 and vice-versa, which is wrong. Also, it lacks the check for a valid page
 object returned. Here's the updated code:

 {{{
 function get_page_parents($id, $link = FALSE, $separator = '/', $nicename
 = FALSE) {
         $chain = '';
         $parent = &get_page($id);
         if ( is_wp_error( $parent ) )
                 return $parent;

         if ( $nicename )
                 $name = $parent->post_name;
         else
                 $name = $parent->post_title;

         if ( $parent->post_parent )
                 $chain .= get_page_parents($parent->post_parent, $link,
 $separator, $nicename);

         if ( $link )
                 $chain .= ''.$name.'' . $separator;
         else
                 $chain .= $name.$separator;
         return $chain;
 }
 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov  8 19:30:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov  8 19:30:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #4852: Incorrect grammar when author
 ends with an s
In-Reply-To: <044.a2d2ad5dcb35902e98a687cec37c5a3e@lists.automattic.com>
References: <044.a2d2ad5dcb35902e98a687cec37c5a3e@lists.automattic.com>
Message-ID: <053.fb3eafe2a2a4719e6284e8c4b81fb625@lists.automattic.com>

#4852: Incorrect grammar when author ends with an s
---------------------+------------------------------------------------------
 Reporter:  Nazgul   |        Owner:  anonymous
     Type:  defect   |       Status:  closed   
 Priority:  low      |    Milestone:           
Component:  i18n     |      Version:  2.3      
 Severity:  trivial  |   Resolution:  invalid  
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by Nazgul):

  * status:  new => closed
  * resolution:  => invalid
  * milestone:  2.4 =>

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov  8 23:59:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:00:07 2007
Subject: [wp-trac] Re: [WordPress Trac] #4599: XMLRPC should implement a
 method for deleting categories
In-Reply-To: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
References: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
Message-ID: <057.fd1e066a07376b6c449e8e9f76f3a643@lists.automattic.com>

#4599: XMLRPC should implement a method for deleting categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  josephscott
     Type:  enhancement  |       Status:  new        
 Priority:  normal       |    Milestone:  2.4        
Component:  XML-RPC      |      Version:  2.2.1      
 Severity:  normal       |   Resolution:             
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by josephscott):

 The attached diff adds a new method, wp.deleteCategory(blog_id, username,
 password, category_id).  Will return a 0 (zero) or a 1.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:00:55 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:01:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #4599: XMLRPC should implement a
 method for deleting categories
In-Reply-To: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
References: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
Message-ID: <057.7424c4e30390169a9f9e91937a77027c@lists.automattic.com>

#4599: XMLRPC should implement a method for deleting categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  josephscott
     Type:  enhancement  |       Status:  new        
 Priority:  normal       |    Milestone:  2.4        
Component:  XML-RPC      |      Version:  2.2.1      
 Severity:  normal       |   Resolution:             
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by josephscott):

 Forgot the mention, this contains a small clean up item for wp.newCategory
 as well.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:02:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:03:08 2007
Subject: [wp-trac] Re: [WordPress Trac] #4599: XMLRPC should implement a
 method for deleting categories
In-Reply-To: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
References: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
Message-ID: <057.7b5d576444fc7ef5a26759a079c94ba3@lists.automattic.com>

#4599: XMLRPC should implement a method for deleting categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  josephscott
     Type:  enhancement  |       Status:  new        
 Priority:  normal       |    Milestone:  2.4        
Component:  XML-RPC      |      Version:  2.2.1      
 Severity:  normal       |   Resolution:             
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by josephscott):

 * cc: josephscott (added)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:17:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:17:23 2007
Subject: [wp-trac] Re: [WordPress Trac] #4982: XMLRPC should expose draft
 status of entries
In-Reply-To: <048.f4cf3ae2edbe2d3c6465d3fee29665da@lists.automattic.com>
References: <048.f4cf3ae2edbe2d3c6465d3fee29665da@lists.automattic.com>
Message-ID: <057.eab9099937fedbd0101268ed0d7ba86f@lists.automattic.com>

#4982: XMLRPC should expose draft status of entries
------------------------+---------------------------------------------------
 Reporter:  redsweater  |        Owner:  anonymous
     Type:  defect      |       Status:  new      
 Priority:  normal      |    Milestone:  2.4      
Component:  XML-RPC     |      Version:  2.3      
 Severity:  normal      |   Resolution:           
 Keywords:              |  
------------------------+---------------------------------------------------
Comment (by josephscott):

 The diff adds the 'post_status' field to data returned from
 metaWeblog.getPost and metaWeblog.getRecentPosts.  Just as a note,
 wp.getPage already provides this for pages in the 'page_status' field.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:31:44 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:31:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #4599: XMLRPC should implement a
 method for deleting categories
In-Reply-To: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
References: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
Message-ID: <057.0a95dbbe2f34ee35c4696aa2b3d7881b@lists.automattic.com>

#4599: XMLRPC should implement a method for deleting categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  josephscott
     Type:  enhancement  |       Status:  new        
 Priority:  normal       |    Milestone:  2.4        
Component:  XML-RPC      |      Version:  2.2.1      
 Severity:  normal       |   Resolution:             
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by josephscott):

 Joe Cheng brought up a good point, when a category that is deleted has
 children be aware that all of the children will be bumped up a level.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:33:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:33:27 2007
Subject: [wp-trac] Re: [WordPress Trac] #4982: XMLRPC should expose draft
 status of entries
In-Reply-To: <048.f4cf3ae2edbe2d3c6465d3fee29665da@lists.automattic.com>
References: <048.f4cf3ae2edbe2d3c6465d3fee29665da@lists.automattic.com>
Message-ID: <057.fa197e5cf024badf3a46a9a334fd0743@lists.automattic.com>

#4982: XMLRPC should expose draft status of entries
------------------------+---------------------------------------------------
 Reporter:  redsweater  |        Owner:  anonymous
     Type:  defect      |       Status:  new      
 Priority:  normal      |    Milestone:  2.4      
Component:  XML-RPC     |      Version:  2.3      
 Severity:  normal      |   Resolution:           
 Keywords:  has-patch   |  
------------------------+---------------------------------------------------
Changes (by josephscott):

  * keywords:  => has-patch

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 00:33:39 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 00:33:51 2007
Subject: [wp-trac] Re: [WordPress Trac] #4599: XMLRPC should implement a
 method for deleting categories
In-Reply-To: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
References: <048.7e5a5da5dfbbfcabd1acf5c87dd6abe0@lists.automattic.com>
Message-ID: <057.fa05561686eb937ca1e6ad7621f298df@lists.automattic.com>

#4599: XMLRPC should implement a method for deleting categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  josephscott
     Type:  enhancement  |       Status:  new        
 Priority:  normal       |    Milestone:  2.4        
Component:  XML-RPC      |      Version:  2.2.1      
 Severity:  normal       |   Resolution:             
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Changes (by josephscott):

  * keywords:  => has-patch

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 02:42:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 02:43:09 2007
Subject: [wp-trac] [WordPress Trac] #5330: wxr import inserts tags with
 numbers instead of names
Message-ID: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>

#5330: wxr import inserts tags with numbers instead of names
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |       Owner:  anonymous
     Type:  defect      |      Status:  new      
 Priority:  normal      |   Milestone:  2.5      
Component:  General     |     Version:           
 Severity:  normal      |    Keywords:           
------------------------+---------------------------------------------------
 The wp importer incorrectly inserts tags with the term ID number in place
 of its name.  The first post with that tag works fine, but subsequent
 posts get bogus numeric tags instead.

 It seems to be a simple type issue, numeric string vs int.  The enclosed
 patch fixes it in the importer, but the same issue might affect other code
 also.  Perhaps the fix belongs at a lower level, in wp_set_object_terms()
 or is_term() (I think the is_int() check in is_term() is the root cause).

 Reproduced in unit testing:

 http://svn.automattic.com/wordpress-tests/wp-testcase/test_import_wp.php

 {{{
 There was 1 failure:

 1) test_all_posts(TestImportWP)
 Failed asserting that two strings are equal.
 expected string 
 difference      
 got string      <11>
 /home/zem/projects/wordpress/wordpress-tests/wp-
 testcase/test_import_wp.php:82
 /home/zem/projects/wordpress/wordpress-tests/wp-testlib/base.php:330
 /home/zem/projects/wordpress/wordpress-tests/wp-test.php:91
 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 03:37:23 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 03:37:35 2007
Subject: [wp-trac] Re: [WordPress Trac] #5330: wxr import inserts tags with
 numbers instead of names
In-Reply-To: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
References: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
Message-ID: <057.5c949082555cbb0f30656c4e234dae44@lists.automattic.com>

#5330: wxr import inserts tags with numbers instead of names
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |        Owner:  anonymous
     Type:  defect      |       Status:  new      
 Priority:  normal      |    Milestone:  2.5      
Component:  General     |      Version:           
 Severity:  normal      |   Resolution:           
 Keywords:              |  
------------------------+---------------------------------------------------
Comment (by tellyworth):

 Here's the import file used by the unit test:

 http://svn.automattic.com/wordpress-tests/wp-
 testdata/export/asdftestblog1.2007-11-09.xml

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 03:46:22 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 03:46:34 2007
Subject: [wp-trac] Re: [WordPress Trac] #4115: getCategoryList should not
 include Blogroll in list of categories
In-Reply-To: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
References: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
Message-ID: <057.9b143e04b138fefa7d6e572e3e0e5207@lists.automattic.com>

#4115: getCategoryList should not include Blogroll in list of categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  anonymous
     Type:  defect       |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  XML-RPC      |      Version:  2.2      
 Severity:  normal       |   Resolution:           
 Keywords:  needs-patch  |  
-------------------------+--------------------------------------------------
Comment (by josephscott):

 I've been trying to reproduce this with no luck.  I suspect that r5758
 fixed this for us back in June.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 03:48:00 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 03:48:11 2007
Subject: [wp-trac] Re: [WordPress Trac] #5330: wxr import inserts tags with
 numbers instead of names
In-Reply-To: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
References: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
Message-ID: <057.23ff2931b8b4956bbdda2c77ceaacd14@lists.automattic.com>

#5330: wxr import inserts tags with numbers instead of names
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |        Owner:  anonymous
     Type:  defect      |       Status:  new      
 Priority:  normal      |    Milestone:  2.5      
Component:  General     |      Version:           
 Severity:  normal      |   Resolution:           
 Keywords:              |  
------------------------+---------------------------------------------------
Comment (by tellyworth):

 The problem starts around here:

 http://trac.wordpress.org/browser/trunk/wp-admin/import/wordpress.php#L390

 {{{
 390                         $tag_obj = get_term_by('slug', $slug,
 'post_tag');
 391                         $tag_id = 0;
 392                         if ( ! empty($tag_obj) )
 393                             $tag_id = $tag_obj->term_id;
 }}}

 $tag_obj->term_id is a numeric string, not an int.  It gets passed through
 as a string to wp_set_post_tags(), wp_set_object_terms() and is_term().
 is_term() sees that it's not an int, and assumes it's a tag name rather
 than an ID.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 06:51:17 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 06:51:30 2007
Subject: [wp-trac] Re: [WordPress Trac] #4115: getCategoryList should not
 include Blogroll in list of categories
In-Reply-To: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
References: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
Message-ID: <057.b5f4b5d795c642f227d4426813b82d00@lists.automattic.com>

#4115: getCategoryList should not include Blogroll in list of categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  anonymous
     Type:  defect       |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  XML-RPC      |      Version:  2.2      
 Severity:  normal       |   Resolution:           
 Keywords:  needs-patch  |  
-------------------------+--------------------------------------------------
Comment (by redsweater):

 When I do a getCategoryList against my test blog on Wordpress.com, I still
 get the Blogroll item:

 
 categoryId1356
 categoryNameBlogroll
 

 Wouldn't the Wordpress.com install have the fix from June that is alleged
 to have fixed it?

 (My test wordpress.com blog: http://sweatertest.wordpress.com/)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wordpress at dd32.id.au  Fri Nov  9 10:38:52 2007
From: wordpress at dd32.id.au (DD32)
Date: Fri Nov  9 10:39:10 2007
Subject: [wp-trac] Extend options.php to allow deletion,
 Viewing of Serialized, And
 grouping options (was: [wp-hackers] adding delete/autoload to options.php)
Message-ID: 

Hi List, 
I just thought i'd float this here again and see what peoples thoughts are on this.
In short:
This ticket is designed to allow the options.php page be used to delete items, as well as viewing serialized data, And it groups options together into their own section if they share a common prefix.
The ticket also includes the patch in plugin form, so if you would like to take a look, you can simply install the plugin instead of applying the diff.

I havn't added the autoload param. yet, i'm after UI feedback and unsure of how to present it.

Heres the ticket:
http://trac.wordpress.org/ticket/5316

Heres the original floatation:
http://comox.textdrive.com/pipermail/wp-hackers/2007-September/thread.html#14425 ([wp-hackers] adding delete/autoload to options.php) 

D
From wordpress at dd32.id.au  Fri Nov  9 10:42:31 2007
From: wordpress at dd32.id.au (DD32)
Date: Fri Nov  9 10:42:36 2007
Subject: [wp-trac] Extend options.php to allow deletion, Viewing of
	Serialized,
	And grouping options (was: [wp-hackers] adding delete/autoload to
	options.php)
In-Reply-To: 
References: 
Message-ID: 

Apologies.. Should've read the email address closer! 
Maybe this list should be setup so people cant acedentally send emails to it..

On Fri, 09 Nov 2007 21:38:52 +1100, DD32  wrote:

From wp-trac at lists.automattic.com  Fri Nov  9 11:32:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 11:32:21 2007
Subject: [wp-trac] [WordPress Trac] #5331: Category pagination permalinks
	broken
Message-ID: <050.ada8b4cb202ee8f5019bde79860a9079@lists.automattic.com>

#5331: Category pagination permalinks broken
--------------------------+-------------------------------------------------
 Reporter:  AnkurKothari  |       Owner:  anonymous                    
     Type:  defect        |      Status:  new                          
 Priority:  normal        |   Milestone:  2.3.2                        
Component:  General       |     Version:                               
 Severity:  major         |    Keywords:  pagination category permalink
--------------------------+-------------------------------------------------
 Using pretty permalinks (such as http://exampleblog.com/catname/post-
 slug), category pages can be reached via http://exampleblog.com/catname,
 but the pagination links point to http://exampleblog.com/catname/page/x,
 instead of http://exampleblog.com/category/catname/page/x.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 13:46:34 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 13:46:50 2007
Subject: [wp-trac] [WordPress Trac] #5332: Previous Entries / Next Entries
 link broken when using widget search
Message-ID: <042.aa3c2b9a4967ffccc31ae3c296c54173@lists.automattic.com>

#5332: Previous Entries / Next Entries link broken when using widget search
---------------------+------------------------------------------------------
 Reporter:  Vimm     |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.4      
Component:  General  |     Version:  2.2.3    
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 I've noticed that (for example) on the default template when searching a
 blog using the search widget the Previous Entries and Next Entries links
 have the wrong path.  However, if I do a bad search and then run a search
 using the search bar that shows up on the error page it works fine.  When
 comparing the two I noticed that the widget form's action element is
 missing the trailing "/" which causes the links to be generated
 incorrectly if the blog is in a subdirectory of the domain.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 15:56:25 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 15:56:39 2007
Subject: [wp-trac] Re: [WordPress Trac] #3994: MetaWeblog
 metaWeblog.getCategories problem
In-Reply-To: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
References: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
Message-ID: <052.fb02a0adc7fcb83a145633a41f1719b1@lists.automattic.com>

#3994: MetaWeblog metaWeblog.getCategories problem
------------------------------------------------------------------------+---
 Reporter:  whilo                                                       |        Owner:  anonymous
     Type:  defect                                                      |       Status:  new      
 Priority:  normal                                                      |    Milestone:  2.4      
Component:  XML-RPC                                                     |      Version:  2.2      
 Severity:  normal                                                      |   Resolution:           
 Keywords:  xmlrpc, compliance, specs, clients, metaweblog, categories  |  
------------------------------------------------------------------------+---
Changes (by dougal):

  * keywords:  => xmlrpc, compliance, specs, clients, metaweblog,
               categories

Comment:

 This mis-implementation has been out there for several years now, so the
 major clients are either explicitly or implicitly working around it. We
 need to test the clients against a 'fixed' version of the method and make
 sure nothing breaks. If the major clients don't break with the change, we
 can get a fix committed. Otherwise, we might need to coordinate with the
 client authors to see how we can smooth out a more gradual migration to
 spec compliance.

 The spec is vague. One must assume that the category name is what should
 be used as the 'name' portion of the parent struct, though the category
 slug might be a good candidate, as well. The use of an array probably
 stemmed from the fact that the category portion of a post struct is
 implemented as an array in the spec.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 16:11:01 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 16:11:15 2007
Subject: [wp-trac] Re: [WordPress Trac] #5331: Category pagination
	permalinks broken
In-Reply-To: <050.ada8b4cb202ee8f5019bde79860a9079@lists.automattic.com>
References: <050.ada8b4cb202ee8f5019bde79860a9079@lists.automattic.com>
Message-ID: <059.928f2143de36c8e82accf11e0a44e7a2@lists.automattic.com>

#5331: Category pagination permalinks broken
-------------------------------------------+--------------------------------
 Reporter:  AnkurKothari                   |        Owner:  anonymous
     Type:  defect                         |       Status:  new      
 Priority:  normal                         |    Milestone:  2.5      
Component:  General                        |      Version:  2.3.1    
 Severity:  major                          |   Resolution:           
 Keywords:  pagination category permalink  |  
-------------------------------------------+--------------------------------
Changes (by foolswisdom):

  * version:  => 2.3.1
  * milestone:  2.3.2 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 16:18:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 16:18:22 2007
Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine
 byteorder on 64bit systems with php5.2.1
In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
Message-ID: <053.a8d30b3f34cb652b89b44a2bde214c8e@lists.automattic.com>

#3780: gettext fails to determine byteorder on 64bit systems with php5.2.1
---------------------------------------------+------------------------------
 Reporter:  abtime                           |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  normal                           |    Milestone:  2.4      
Component:  i18n                             |      Version:  2.2      
 Severity:  critical                         |   Resolution:           
 Keywords:  i18n has-patch 2nd-opition test  |  
---------------------------------------------+------------------------------
Comment (by qb):

 Replying to [comment:21 nbachiyski]:
 > Could everybody, please, try the both patches and report if any is
 working.

 Both patches not working for me on Wordpress 2.3.1 / Linux 64 / PHP 5.2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 16:32:43 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 16:32:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #3566: Request for new function
 get_page_parents
In-Reply-To: <047.6a7135c4982cd5875893dc678bf91481@lists.automattic.com>
References: <047.6a7135c4982cd5875893dc678bf91481@lists.automattic.com>
Message-ID: <056.7e5ba0feb45957f2f5d88b5aaa8e8027@lists.automattic.com>

#3566: Request for new function get_page_parents
-------------------------+--------------------------------------------------
 Reporter:  snakefoot    |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:  2.1      
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Changes (by Huskey):

 * cc: Huskey (added)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 17:25:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 17:25:23 2007
Subject: [wp-trac] Re: [WordPress Trac] #3994: MetaWeblog
 metaWeblog.getCategories problem
In-Reply-To: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
References: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
Message-ID: <052.0877a7799c1343d2a50a85735a764952@lists.automattic.com>

#3994: MetaWeblog metaWeblog.getCategories problem
------------------------------------------------------------------------+---
 Reporter:  whilo                                                       |        Owner:  anonymous
     Type:  defect                                                      |       Status:  new      
 Priority:  normal                                                      |    Milestone:  2.4      
Component:  XML-RPC                                                     |      Version:  2.2      
 Severity:  normal                                                      |   Resolution:           
 Keywords:  xmlrpc, compliance, specs, clients, metaweblog, categories  |  
------------------------------------------------------------------------+---
Comment (by josephscott):

 Just as a note to whilo and others who might be following this, there is
 discussion on the http://lists.automattic.com/mailman/listinfo/wp-xmlrpc
 list about this issue.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 18:06:33 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 18:06:44 2007
Subject: [wp-trac] Re: [WordPress Trac] #3994: MetaWeblog
 metaWeblog.getCategories problem
In-Reply-To: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
References: <043.4268be9da45a946a6d9d552179984877@lists.automattic.com>
Message-ID: <052.5eb728a0a9e7a3445f5fd35a69de8882@lists.automattic.com>

#3994: MetaWeblog metaWeblog.getCategories problem
------------------------------------------------------------------------+---
 Reporter:  whilo                                                       |        Owner:  anonymous
     Type:  defect                                                      |       Status:  new      
 Priority:  normal                                                      |    Milestone:  2.4      
Component:  XML-RPC                                                     |      Version:  2.2      
 Severity:  normal                                                      |   Resolution:           
 Keywords:  xmlrpc, compliance, specs, clients, metaweblog, categories  |  
------------------------------------------------------------------------+---
Comment (by redsweater):

 foolswisdom said it best at the outset. Unless there's a clear scenario
 where not fixing this is causing harm, it shouldn't be considered. The
 MetaWeblog spec is not clear enough or widely enough followed to have
 fixes done "just to be in compliance."

 Also, MetaWeblog API per se is rather uncommonly used these days as most
 clients will prefer the MovableType or WordPress supersets, in which case
 the mt.getCategoryList method would be used instead.

 I don't think you guys should waste your time trying to fix or compromise
 for this issue. It would be change for change's sake, and a waste of time
 when real problems need fixing.

 Daniel

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 18:45:55 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 18:46:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #4115: getCategoryList should not
 include Blogroll in list of categories
In-Reply-To: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
References: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
Message-ID: <057.4c48e7f4ebd69e1f0e032af4be21f163@lists.automattic.com>

#4115: getCategoryList should not include Blogroll in list of categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  anonymous
     Type:  defect       |       Status:  closed   
 Priority:  normal       |    Milestone:  2.4      
Component:  XML-RPC      |      Version:  2.2      
 Severity:  normal       |   Resolution:  fixed    
 Keywords:  needs-patch  |  
-------------------------+--------------------------------------------------
Changes (by redsweater):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 It looks like the Blogroll item I described above was a fluke. Somehow in
 my testing I must have selected that Blogroll item from the list and thus
 caused a real Blogroll category to get created on my Wordpress.com test
 account.

 I tested against a clean 2.3.1 install and the bug does appear to be
 fixed! Nice.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 20:32:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 20:32:16 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.5de1ea46abca154c81b159138b1e1cf0@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 How about a get_default_feed() function that applies a default_feed filter
 and a get_feed_info($feed) for getting details for that feed?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 21:43:38 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 21:43:51 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.07ac3df2304d91296f46de6446851ea3@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 I'm still seeing the old patch, I think.  Attached is what I had in mind.
 It's not complete.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 21:44:34 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 21:44:47 2007
Subject: [wp-trac] Re: [WordPress Trac] #4115: getCategoryList should not
 include Blogroll in list of categories
In-Reply-To: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
References: <048.abd5b8c8ab2922fb2e6fb99f1bc39b3d@lists.automattic.com>
Message-ID: <057.6f71ac5c54bbe123a51e8dcfae63d3a7@lists.automattic.com>

#4115: getCategoryList should not include Blogroll in list of categories
-------------------------+--------------------------------------------------
 Reporter:  redsweater   |        Owner:  anonymous
     Type:  defect       |       Status:  closed   
 Priority:  normal       |    Milestone:  2.3      
Component:  XML-RPC      |      Version:  2.2      
 Severity:  normal       |   Resolution:  fixed    
 Keywords:  needs-patch  |  
-------------------------+--------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.4 => 2.3

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 21:45:53 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 21:46:05 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.e614a89e717e7d22bc331094814810d0@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 Notes about the patch.  We could go ahead and add info for all the feeds
 we ship with to get_feed_inf().  I added some checks need to make sure we
 correctly create links when permalinks are not enabled.  Category feed
 links generated by wp_list_categories() follow the default.  The same can
 be done for authors.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 23:18:03 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 23:18:15 2007
Subject: [wp-trac] [WordPress Trac] #5333: Adding custom fields before
 saving a page transforms the page into a post
Message-ID: <049.fcda32173edf5616a0dbe1d9c40a94b5@lists.automattic.com>

#5333: Adding custom fields before saving a page transforms the page into a post
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |       Owner:  anonymous
     Type:  defect       |      Status:  new      
 Priority:  normal       |   Milestone:  2.4      
Component:  General      |     Version:  2.4      
 Severity:  normal       |    Keywords:           
-------------------------+--------------------------------------------------
 - Go to the write page screen
 - add a custom field
 - write and save/publish your page
 - go to the manage pages screen, notice your page isn't there
 - go to the manage posts screen, you'll find that your page was saved as a
 draft post

 I believe that when the custom fields are added an auto-save is done so
 that they can be associated with an id.  Unfortunately it seems to always
 do the save as a post even when one the page screen.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 23:23:42 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 23:23:53 2007
Subject: [wp-trac] [WordPress Trac] #5334: Inconsistent errors when trying
 to add a custom field
Message-ID: <049.d66e8407dbd1f1d8105db9a9c063ac0e@lists.automattic.com>

#5334: Inconsistent errors when trying to add a custom field
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |       Owner:  anonymous
     Type:  defect       |      Status:  new      
 Priority:  normal       |   Milestone:  2.4      
Component:  General      |     Version:  2.4      
 Severity:  normal       |    Keywords:           
-------------------------+--------------------------------------------------
 If you try to add a custom field with a key but no value then the
 following error is displayed: "AJAX is teh b0rked."

 If you try to add a custom field with a value but no key then you don't
 get any sort of response at all.  The custom field isn't added and you
 don't get any sort of error message.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 23:41:36 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 23:41:49 2007
Subject: [wp-trac] Re: [WordPress Trac] #5333: Adding custom fields before
 saving a page transforms the page into a post
In-Reply-To: <049.fcda32173edf5616a0dbe1d9c40a94b5@lists.automattic.com>
References: <049.fcda32173edf5616a0dbe1d9c40a94b5@lists.automattic.com>
Message-ID: <058.c769e68b6878b2a0ab1836633ea4f010@lists.automattic.com>

#5333: Adding custom fields before saving a page transforms the page into a post
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |        Owner:  anonymous
     Type:  defect       |       Status:  closed   
 Priority:  normal       |    Milestone:           
Component:  General      |      Version:  2.4      
 Severity:  normal       |   Resolution:  duplicate
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by lloydbudd):

  * status:  new => closed
  * resolution:  => duplicate
  * milestone:  2.4 =>

Comment:

 Duplicate of #3700 ;-)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov  9 23:42:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov  9 23:42:27 2007
Subject: [wp-trac] Re: [WordPress Trac] #3700: Adding a custom field to an
 unsaved Page before publishing causes weirdness
In-Reply-To: <049.7b65847c64c66ed3e90fa481e139ade9@lists.automattic.com>
References: <049.7b65847c64c66ed3e90fa481e139ade9@lists.automattic.com>
Message-ID: <058.38f9607d9b501561728136931e7f80e3@lists.automattic.com>

#3700: Adding a custom field to an unsaved Page before publishing causes weirdness
----------------------------+-----------------------------------------------
 Reporter:  markjaquith     |        Owner:  Andy 
     Type:  defect          |       Status:  new  
 Priority:  normal          |    Milestone:  2.4  
Component:  Administration  |      Version:  2.1.3
 Severity:  normal          |   Resolution:       
 Keywords:  needs-patch     |  
----------------------------+-----------------------------------------------
Comment (by lloydbudd):

 Also reported in #5333 .

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 01:35:59 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 01:36:13 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.ebe46e107001127925978cabbd57506a@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by rubys):

 The way I figure it, going from hardcoding the default feed format to
 hardcoding the info for all of the feed formats is but a half step.  A
 plugin is still required, and allowing people to control the full info
 means they can add I?RSS icons, or links to the feed validator, or
 translate the long name into Russian or whatever.  Furthermore, specific
 themes could even check for additional information that is not provided by
 the default.

 If you look at the actual sample plugin for Atom, it really isn't all that
 much burden to the plugin authors, and reduces bloat from the WP Core.

 *shrug*

 I suggest you try the patch.  Create a clean wordpress install with the
 default theme, install the patch and active the Atom plugin and see what
 you think.  If you still prefer hardcoding the info for the feed formats
 in the core, I'm entirely OK with that.

 Unrelated: any idea why Trac won't show an HTML preview for my patches,
 but will show yours?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 12:55:58 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 12:56:11 2007
Subject: [wp-trac] Re: [WordPress Trac] #5334: Inconsistent errors when
 trying to add a custom field
In-Reply-To: <049.d66e8407dbd1f1d8105db9a9c063ac0e@lists.automattic.com>
References: <049.d66e8407dbd1f1d8105db9a9c063ac0e@lists.automattic.com>
Message-ID: <058.37fa5477498181922033393d168c6ec7@lists.automattic.com>

#5334: Inconsistent errors when trying to add a custom field
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |        Owner:  anonymous
     Type:  defect       |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:  2.4      
 Severity:  normal       |   Resolution:           
 Keywords:  needs-patch  |  
-------------------------+--------------------------------------------------
Changes (by Viper007Bond):

  * keywords:  => needs-patch

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 19:26:35 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 19:26:46 2007
Subject: [wp-trac] [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
Message-ID: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |       Owner:  anonymous
     Type:  defect        |      Status:  new      
 Priority:  normal        |   Milestone:  2.2.3    
Component:  Optimization  |     Version:  2.3      
 Severity:  normal        |    Keywords:  has-patch
--------------------------+-------------------------------------------------
 This patch uses foreach to reduce the time it takes to execute
 apply_filters (on my box) from an average of 120,694 ticks/standard
 deviation 33,038 ticks, to an average of 99,149 ticks/standard deviation
 20,636 ticks. The sample size was 20 runs each, before and after.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 21:29:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 21:29:32 2007
Subject: [wp-trac] Re: [WordPress Trac] #3433: Option FollowSymLinks
In-Reply-To: <055.0cf1838707e6f6505c3bcff23c721149@lists.automattic.com>
References: <055.0cf1838707e6f6505c3bcff23c721149@lists.automattic.com>
Message-ID: <064.d18ed2aa82142bb467500918a34ec52a@lists.automattic.com>

#3433: Option FollowSymLinks
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |        Owner:  anonymous
     Type:  defect             |       Status:  new      
 Priority:  normal             |    Milestone:  2.4      
Component:  General            |      Version:  2.0      
 Severity:  normal             |   Resolution:           
 Keywords:                     |  
-------------------------------+--------------------------------------------
Comment (by darkfate):

 To my knowledge, there is no way to check with PHP that it's there.
 WordPress would have to write a test htaccess file and then ask the user
 if the redirection was working right. It's just not worth it since the
 majority of users have it enabled on their server. Maybe we can put a
 checkbox on the permalinks page that says something like "If you are
 experiencing 403 errors while using permalinks, check this box, otherwise
 don't touch it!"

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 21:54:26 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 21:54:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
In-Reply-To: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
References: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
Message-ID: <055.2966fcb099c6145f2326a8388f34f6e5@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |        Owner:  anonymous
     Type:  defect        |       Status:  new      
 Priority:  normal        |    Milestone:  2.2.3    
Component:  Optimization  |      Version:  2.3      
 Severity:  normal        |   Resolution:           
 Keywords:  has-patch     |  
--------------------------+-------------------------------------------------
Comment (by Quandary):

 Stats on the second patch:

 ||||original||patched||
 ||total runtime (mean)||1,972,854||1,943,093||
 ||total runtime (std dev)||116,697||110,741||
 ||add_filter (mean)||14,424||14,592||
 ||add_filter (std dev)||5,458||3,224||
 ||apply_filters (mean)||120,694||103,971||
 ||apply_filters (std dev)||33,038||25,880||

 Sample size is still 20.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 21:58:25 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 21:58:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #5235: Add Pre-flight checks to
	install
In-Reply-To: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com>
References: <043.6b0b82bc5f7a4f58b82fdc1066a79dd2@lists.automattic.com>
Message-ID: <052.bd38927688b68d60be44b517cdea4421@lists.automattic.com>

#5235: Add Pre-flight checks to install
-------------------------+--------------------------------------------------
 Reporter:  westi        |        Owner:  pishmishy
     Type:  enhancement  |       Status:  assigned 
 Priority:  normal       |    Milestone:  2.5      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by darkfate):

 @DD32: Yes, there should also be check for mail()

 I don't think WP should recommend a different host, but do like what's in
 the patch already. There should obviously be a check again button so that
 a person who operates their own server can change it and just hit check
 again and have the next button turn into a link if everything is good to
 go.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 21:38:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 22:05:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #5305: permalinks broken when
 article name is numeric
In-Reply-To: <045.015dba03a5b592cfc89fb519871f734a@lists.automattic.com>
References: <045.015dba03a5b592cfc89fb519871f734a@lists.automattic.com>
Message-ID: <054.4c232d4b9f1dcad9996747589732c62d@lists.automattic.com>

#5305: permalinks broken when article name is numeric
--------------------------------+-------------------------------------------
 Reporter:  thomask             |        Owner:  anonymous
     Type:  defect              |       Status:  new      
 Priority:  normal              |    Milestone:  2.3.2    
Component:  General             |      Version:  2.3.1    
 Severity:  major               |   Resolution:           
 Keywords:  permalinks, number  |  
--------------------------------+-------------------------------------------
Comment (by darkfate):

 I don't think he's using permalinks. I think he's saying, like if his post
 slug is 123 and his title is 123, it breaks. It looks like 2.4 trunk
 doesn't break like that though. Unless it is a specific permalink
 structure.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 22:55:25 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 22:55:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #4595: Allow users to choose type of
	RSS feeds
In-Reply-To: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
References: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
Message-ID: <055.1c821913aff9403871f1ac3c6efd9079@lists.automattic.com>

#4595: Allow users to choose type of RSS feeds
----------------------------+-----------------------------------------------
 Reporter:  terraces        |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * keywords:  has-patch, suggested-improvement => has-patch

Comment:

 Relates to #5328.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 10 23:15:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 10 23:16:08 2007
Subject: [wp-trac] Re: [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
In-Reply-To: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
References: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
Message-ID: <055.3d75488b235789b370aa3096db020b3f@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |        Owner:  anonymous
     Type:  defect        |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.3      
 Severity:  normal        |   Resolution:           
 Keywords:  has-patch     |  
--------------------------+-------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.2.3 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 00:07:49 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 00:08:01 2007
Subject: [wp-trac] Re: [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
In-Reply-To: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
References: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
Message-ID: <055.b5830d1d14714babab53409dde4666ae@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.3      
 Severity:  normal        |   Resolution:           
 Keywords:  has-patch     |  
--------------------------+-------------------------------------------------
Changes (by lloydbudd):

  * type:  defect => enhancement

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 02:49:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 02:49:43 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.7c79a7b9e80b81cc2636f2b41c13a48f@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 My patch marks the long name for translation.  Realistically, for
 translation to be useful, feed info for all feeds need to be in core so
 that the strings will be in the default message catalog.  Otherwise, the
 plugin will need to ship with its own translations.  i18n theme authors
 probably won't bother changing their themes to use feed info if it means
 relying on an outside catalog. The fact that this requires theme changes
 and has i18n impact makes this more involved than if we were just changing
 the default feed links to do atom instead of rss2. comments_feed_link(),
 for example, is useless for an i18n-ready theme.  Such themes would have
 to do something like:

 {{{
 
    
 }}}

 Let's split this into two parts.  The first part would make it possible to
 change the default feed in the guts of WP.  The second would allow themes
 to be feed type neutral, which is the bigger change.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 10:21:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 10:21:22 2007
Subject: [wp-trac] [WordPress Trac] #5336: Wordpress Mangles  tag's
Message-ID: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>

#5336: Wordpress Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |       Owner:  anonymous
     Type:  defect    |      Status:  new      
 Priority:  normal    |   Milestone:           
Component:  TinyMCE   |     Version:  2.3.1    
 Severity:  normal    |    Keywords:           
----------------------+-----------------------------------------------------
 I'm trying to embed some flash to a page on my site, I'm entering the
 correct  &  code into the page, which displays fine.

 However, If I goto edit the page at a later date the code gets mangled,
 wordpress inserts a  before the  and replaces me closing
 /> with >

 This is a real pain, as it means I have to re-edit my flash every time i
 alter the page.

 Is there a tag to prevent wordpress altering html, or should this be
 reported as a bug? - I'm guessing the html tidy process doesn't like
  & 

 The HTML i'm adding to the code window can be seen here:

 ---
 
 
 
 
 
 --

 I know that as a wordaround I could probably disable the TinyMCE editor,
 but 95% of the time it's fine.

 Dave

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 17:34:38 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 17:34:51 2007
Subject: [wp-trac] [WordPress Trac] #5337: Wrong timezone with comment_time
 and the_time since DST ended
Message-ID: <044.ec6079982b1d5f2246907b669df901c7@lists.automattic.com>

#5337: Wrong timezone with comment_time and the_time since DST ended
---------------------+------------------------------------------------------
 Reporter:  jrawle   |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.3.2    
Component:  General  |     Version:  2.3.1    
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 I am designing a theme where I want the current timezone to be displayed
 after the time in comment and post timestamps. For example, I use  with my default time format set to H:i T.

 I am in the UK, and until the clocks changed on 28 October everything was
 fine. Posts or comments written during a summer gave the time as e.g.
 "14:00 BST" while those written in the winter said "13:00 GMT".

 However, since BST ended, I now see "UTC" for all datestamps, irrespective
 of whether they were posted during the summer or winter. So the two
 examples given above would now show "14:00 UTC" and "13:00 UTC"
 respectively, despite the fact that the first one is incorrect. I also
 don't understand why it switched from using GMT to UTC.

 I do not know whether this bug is present in other timezones.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 17:39:02 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 17:39:14 2007
Subject: [wp-trac] [WordPress Trac] #5338: Preformance Tweaks for WordPress
 Trunk Plugin API, plugin.php
Message-ID: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |       Owner:  anonymous
     Type:  enhancement   |      Status:  new      
 Priority:  normal        |   Milestone:  2.4      
Component:  Optimization  |     Version:  2.4      
 Severity:  normal        |    Keywords:           
--------------------------+-------------------------------------------------
 Clean up Plugin API functions and some optimization tweaks based on WP-
 Hackers discussion.

  * Use Foreach instead of while loops
  * Move 'all' hook call to its own function
  * Set current filter tag variable after the check for the hook's
 existence.
  * Remove merged_filters variable

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 18:22:43 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 18:22:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.f7cd2b5d0d9cf7b4711896338ad99294@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by jasonadamyoung):

 If this is going to be part of core - is there any reason why this
 shouldn't be part of the wp_options?  I admittedly haven't traced the
 execution of this everywhere, but it seems like
 get_option('default_feed_format') would be preferred over get_default_feed
 and still hardcoding 'rss2' in that (or even hardcoding it in a sense in a
 wp_feed_selector).

 I might be missing something in the overhead of the options use, but it
 looks like the options already have filter hooks - and sticking this in
 wp_options leaves open the door for a interface plugin to set the default
 feed format from within the admin interface.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 18:47:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 18:48:07 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.ed8123b13a61fc2b8ff796fe268720f3@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by rubys):

 Replying to [comment:6 ryan]:
 > Let's split this into two parts.The first part would make it possible to
 change the default feed in the guts of WP.

 That would be [http://trac.wordpress.org/ticket/4595 Ticket 4595].

 > The second would allow themes to be feed type neutral, which is the
 bigger change.

 Once of the various patches to ticket 4595 is committed, I'll gladly
 generate a new patch for 5328 which builds upon this.  Making a subset of
 the various names translatable and/or actually translating them could be a
 third ticket.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 19:30:22 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 19:30:33 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.ec938d7f450050b737585ddeeba1d7b0@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.4      
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by Quandary):

 The foreach setup breaks in this implementation, because the priority
 array is not pre-filled; you'll get a bug if, e.g., a pri-1 callback adds
 a pri-2 callback on the currently-executing hook, and there are no pri-2
 callbacks yet. Please see the ''second'' patch attached to bug #5335.

 I'm also pretty sure that filters (as implemented for apply_filters) are
 applicable to strings ''only''. do_action is more generic, but it has a
 completely separate implementation for that.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 19:35:17 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 19:35:26 2007
Subject: [wp-trac] Re: [WordPress Trac] #4595: Allow users to choose type of
	RSS feeds
In-Reply-To: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
References: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
Message-ID: <055.92758c7b27a2f0bdd1cc9089785bc5f1@lists.automattic.com>

#4595: Allow users to choose type of RSS feeds
----------------------------+-----------------------------------------------
 Reporter:  terraces        |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------
Changes (by rubys):

 * cc: rubys (added)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 19:44:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 19:45:03 2007
Subject: [wp-trac] Re: [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
In-Reply-To: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
References: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
Message-ID: <055.42d7a643c41ea118df2560e913432341@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.3      
 Severity:  normal        |   Resolution:           
 Keywords:  has-patch     |  
--------------------------+-------------------------------------------------
Comment (by Quandary):

 For the record, this patch is written and tested against ''2.3.1'', not
 2.4/trunk.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 19:45:42 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 19:45:53 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.1fe3a8b6f41e2b32bfef18fb07f5d3c1@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.4      
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by darkdragon):

 I can't and will not advocate something so hackish. What about plugins
 that hook into at priority of '11' or '12'? Plugins that want to execute
 after everything else would want to hook into priority of 11, as I have
 done before with 'init'.

 If that is the case, then everything else is pointless and should be
 reverted back, since it has been known to work.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 19:55:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 19:55:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.66cd42e025f8920b23f75c9f1c2705d1@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.4      
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by Quandary):

 ... because the documentation '''specifically''' states that priority
 levels are 1-10. Anyone doing otherwise is broken.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:04:32 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:04:43 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.2bbb12557920fc88aeaccc267bf119c4@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.4      
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by darkdragon):

 Yeah, then it should lock those numbers in, which it doesn't. It allows
 for any number, therefore unofficially, any priority number must be
 supported. The documentation states that to keep things standard, but
 without checks in the code, then it really is just an '''suggestion''' on
 what the plugin authors should do and not what they must do. If it was
 something they must do, then an error would have been thrown.

 The point is, if I hook into 11, then I mostly know that it will be
 processed last and if I hook into '0' I can guess that it will be run
 before anything else.

 There is no point arguing this, either we add in the checks or we don't,
 but unless we do, then filling the priority list manually is not an
 option.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:10:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:10:20 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.862cd828284885bf72557db326806173@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.4      
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by Quandary):

 You also need to pre-define it if you take out the array sort (I don't see
 any sorting being done on $wp_filters anymore). Otherwise, the priorities
 will get all screwed up. Pri-10 will likely wind up running first, because
 it'll usually be the first level created.

 {{{
 
 }}}

 === Output ===

 {{{
 This is supposed to be last
 This is supposed to be first
 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:13:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:13:29 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.05e1ff7dc472abdba5d0fdc1f2eb0f37@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------------------+-------------------
 Reporter:  darkdragon                                  |        Owner:  anonymous
     Type:  enhancement                                 |       Status:  new      
 Priority:  normal                                      |    Milestone:  2.4      
Component:  Optimization                                |      Version:  2.4      
 Severity:  normal                                      |   Resolution:           
 Keywords:  plugins.php phpdoc has-patch needs-testing  |  
--------------------------------------------------------+-------------------
Changes (by darkdragon):

 * cc: plugins.php, phpdoc, has-patch, needs-testing (removed)
  * keywords:  => plugins.php phpdoc has-patch needs-testing

Comment:

 Look at the taxonomy. Apply filters are used on objects. Therefore the
 documentation is correct.

 Replying to [comment:5 Quandary]:
 > You also need to pre-define it if you take out the array sort (I don't
 see any sorting being done on $wp_filters anymore). Otherwise, the
 priorities will get all screwed up. Pri-10 will likely wind up running
 first, because it'll usually be the first level created.
 >
 > {{{
 > 
 > $example = array();
 > $example[10] = "This is supposed to be last";
 > $example[1] = "This is supposed to be first";
 >
 > foreach($example as $text)
 >     echo "$text\n";
 >
 > ?>
 > }}}
 >
 > === Output ===
 >
 > {{{
 > This is supposed to be last
 > This is supposed to be first
 > }}}

 This the reason I had keywords 'needs-testing', I had thought this is the
 case. Without testing, it is unknown whether this would be the case. I
 will submit a new patch that fixes this.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:54:42 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:54:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.8ff7c84e1f67ad484d60c986e88d9a9d@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Changes (by darkdragon):

  * keywords:  plugins.php phpdoc has-patch needs-testing => plugins.php
               phpdoc needs-patch
  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:55:45 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:55:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.290ef7924669da76c6efcd977c6d7a5c@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by filosofo):

 Replying to [comment:3 Quandary]:
 > ... because the documentation '''specifically''' states that priority
 levels are 1-10. Anyone doing otherwise is broken.

 Where do you see that?  Even the default filters in wp-includes/default-
 filters.php have much higher numbers than that.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 20:57:13 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 20:57:23 2007
Subject: [wp-trac] [WordPress Trac] #5339: Unused $pwd variable in
	wp_login() function
Message-ID: <043.3403137f56f45eda0177324e359797c0@lists.automattic.com>

#5339: Unused $pwd variable in wp_login() function
--------------------------+-------------------------------------------------
 Reporter:  epper         |       Owner:  anonymous
     Type:  enhancement   |      Status:  new      
 Priority:  low           |   Milestone:  2.3.2    
Component:  Optimization  |     Version:           
 Severity:  minor         |    Keywords:           
--------------------------+-------------------------------------------------
 I was looking the code of wp_login() in wp-includes/pluggable.php and I've
 seen that there's an unused variable: $pwd on line 305:

 {{{
 303             } else {
 304                 $error = __('ERROR: Incorrect
 password.');
 305                 $pwd = '';
 306                 return false;
 307             }
 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 21:07:49 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 21:08:02 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.1d262451b21d1f4890a8dc5cc9ce87d9@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by Quandary):

 [http://codex.wordpress.org/Function_Reference/add_action Wiki].
 Apply_filter does not have a corresponding limit. This should go to a new
 bug; it's tangential to the patch.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 21:18:35 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 21:18:48 2007
Subject: [wp-trac] Re: [WordPress Trac] #5328: Make default feed format
	pluggable
In-Reply-To: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
References: <043.40242ba56ae7d3e8fca582ab27d94486@lists.automattic.com>
Message-ID: <052.81aa2e0f8c7af22fd7922bc47d31efff@lists.automattic.com>

#5328: Make default feed format pluggable
-------------------------+--------------------------------------------------
 Reporter:  rubys        |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 FWIW, here's the patch I've been playing with.  It adds a feed_type arg to
 wp_list_authors() and wp_list_categories().  It deprecates old _rss_link()
 functions and moves all feed_link functions to link-template.php so that
 they are not so scattered.  No template changes are made.  That's for
 later.

 This patch still uses get_default_feed() rather than an option.  I'll
 bring up adding an option for this in the next dev meeting.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 21:32:07 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 21:32:19 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.0ea0326cd40e47f33ced52b84fedf719@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by ryan):

 We've documented 1 - 10 in the past, but it was never enforced in code and
 some places in WP use values like 15, 20, 25, and 50.  We could probably
 go to a 0 - 15 scale and set values > 15 to 15.  I think 0-15 would cover
 most current uses.  The priorities used in default-filters can be changed
 to fall in this range. There's no reason for priorities as high as 50.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 22:04:01 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 22:04:12 2007
Subject: [wp-trac] [WordPress Trac] #5340: Regex warning in convert_smilies
Message-ID: <048.7fd2e4fcd0697c1aca188d76a3c8bbd6@lists.automattic.com>

#5340: Regex warning in convert_smilies
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |       Owner:  anonymous
     Type:  defect      |      Status:  new      
 Priority:  normal      |   Milestone:  2.5      
Component:  General     |     Version:           
 Severity:  normal      |    Keywords:           
------------------------+---------------------------------------------------
 It's possible for convert_smilies() to produce warnings if the
 $wp_smiliessearch global is empty.  The enclosed patch is a simple
 defensive conditional to guard against that possbility.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 11 22:27:40 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 11 22:27:53 2007
Subject: [wp-trac] Re: [WordPress Trac] #5339: Unused $pwd variable in
 wp_login() function
In-Reply-To: <043.3403137f56f45eda0177324e359797c0@lists.automattic.com>
References: <043.3403137f56f45eda0177324e359797c0@lists.automattic.com>
Message-ID: <052.0873a5aa5247a3197b850ef0b6235e18@lists.automattic.com>

#5339: Unused $pwd variable in wp_login() function
--------------------------+-------------------------------------------------
 Reporter:  epper         |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  low           |    Milestone:  2.3.2    
Component:  Optimization  |      Version:           
 Severity:  minor         |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by DD32):

 Perhaps #2244 should be decided upon too, I think i removed that variable
 in the patch there too.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 01:45:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 01:45:14 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.e3df015b128a7a8260a232f36038578c@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by Viper007Bond):

 The cap '''can't''' be 10 as that'd break tons of plugins. Many, many of
 my plugins need to run after `wpautop()` slaughters the post for example.

 Personally, I think a cap of 20 would be best. This would put the default
 of 10 right in the middle and allow for enough post-10 room to run enough
 filters to do most anything in the right order.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 02:13:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 02:13:21 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.673c92c6867f4bcc902f2afc222b1167@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by darkdragon):

 I think no cap is best, since this is sounding like a WTF
 ([http://worsethanfailure.com Worse Than Failure]). The story about the
 guy who kept trying to check the database connection and try to reconnect,
 up to 5000 times.

 I don't think the wiki should be updated. Adding the checks in might
 hinder plugin developers and would only slow down the Plugin API. I think
 Plugin developers should give be given faith in that what they've written
 is what they meant and not mangle and slap their hand when we feel they've
 done something wrong.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 03:26:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 03:26:25 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.21c8d28387e33a24a1850ef74e0f21fb@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by Viper007Bond):

 Yeah, I too personally prefer the flexibility of no limit, but then again,
 you don't really need 10000 filters/actions.

 I think it's worth imposing a cap only if it gives us a performance
 increase and if that's the case, see my previous comment about the
 suggested cap.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 04:36:02 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 04:36:13 2007
Subject: [wp-trac] [WordPress Trac] #5341: New wp.getCommentModerationCount
 XML-RPC method
Message-ID: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>

#5341: New wp.getCommentModerationCount XML-RPC method
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |       Owner:  anonymous
     Type:  enhancement  |      Status:  new      
 Priority:  normal       |   Milestone:  2.4      
Component:  XML-RPC      |     Version:           
 Severity:  normal       |    Keywords:  has-patch
-------------------------+--------------------------------------------------
 The WordPress Comment Moderation Notifier http://www.howtogeek.com/howto
 /the-geek-blog/how-to-geek-software-wordpress-comment-moderation-notifier/
 is a Windows app that notifies users about the number of comments in the
 moderation queue.  It does this by requiring a plugin that adds an XML-RPC
 method called geek.getCommentModerationCount.

 This seems like a helpful bit of information to expose, so I put together
 a patch against -trunk to implement this.  It is basically the same code
 as the plugin with only a few modifications.

 The included patch calls the method wp.getCommentModerationCount, other
 WordPress specific methods are under wp.* so this seemed like the best
 place for it.  It also includes an alias for the
 geek.getCommentModerationCount method so that this app and others based on
 it will work unmodified.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 05:37:03 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 05:37:14 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.ffbeb7cc6d717e9319cd6c2c8610a2c3@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by ryan):

 We need to profile it to see if its worthwhile.  Is losing the need to
 sort the priorities worth it?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 05:44:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 05:44:28 2007
Subject: [wp-trac] [WordPress Trac] #5342: Output WP_Error message when
 adding categories via AJAX
Message-ID: <042.5b5b81d4275d39b8f4cc7cfccc41b818@lists.automattic.com>

#5342: Output WP_Error message when adding categories via AJAX
---------------------+------------------------------------------------------
 Reporter:  ryan     |       Owner:  anonymous          
     Type:  defect   |      Status:  new                
 Priority:  normal   |   Milestone:  2.4                
Component:  General  |     Version:                     
 Severity:  normal   |    Keywords:  ajax category error
---------------------+------------------------------------------------------
 Currently, adding categories via AJAX output a generic error message when
 something goes wrong in wp_insert_category() since that function does not
 return WP_Error for back-compat reasons.  Let's add an option to
 wp_insert_category() that tells it to return WP_Error instead of 0.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 05:45:12 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 05:45:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #5342: Output WP_Error message when
 adding categories via AJAX
In-Reply-To: <042.5b5b81d4275d39b8f4cc7cfccc41b818@lists.automattic.com>
References: <042.5b5b81d4275d39b8f4cc7cfccc41b818@lists.automattic.com>
Message-ID: <051.09c3faeac5ff4e2c39ee725dac43b26c@lists.automattic.com>

#5342: Output WP_Error message when adding categories via AJAX
---------------------------------+------------------------------------------
 Reporter:  ryan                 |        Owner:  anonymous
     Type:  defect               |       Status:  new      
 Priority:  normal               |    Milestone:  2.4      
Component:  General              |      Version:           
 Severity:  normal               |   Resolution:           
 Keywords:  ajax category error  |  
---------------------------------+------------------------------------------
Old description:

> Currently, adding categories via AJAX output a generic error message when
> something goes wrong in wp_insert_category() since that function does not
> return WP_Error for back-compat reasons.  Let's add an option to
> wp_insert_category() that tells it to return WP_Error instead of 0.

New description:

 Currently, adding categories via AJAX outputs a generic error message when
 something goes wrong in wp_insert_category() since that function does not
 return WP_Error.  Let's add an option to wp_insert_category() that tells
 it to return WP_Error instead of 0.  We must maintain returning 0 by
 default for back-compat reasons.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 08:15:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 08:16:04 2007
Subject: [wp-trac] Re: [WordPress Trac] #5341: New
 wp.getCommentModerationCount XML-RPC method
In-Reply-To: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
References: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
Message-ID: <058.371aa6df7dce68cbc9eca55cf48ca4ea@lists.automattic.com>

#5341: New wp.getCommentModerationCount XML-RPC method
-------------------------+--------------------------------------------------
 Reporter:  josephscott  |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  XML-RPC      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:  has-patch    |  
-------------------------+--------------------------------------------------
Comment (by redsweater):

 I applaud the enthusiasm to add new support to the API, but I'm worried
 that jumping right on ideas like this might not be the way to go about it.
 Developing and adding to the API should come with some deliberation, and
 should strive to expose as much information from the system as possible,
 in a way that is consistent with the rest of the API.

 I feel like the plugin is cool, and allowed the author to achieve
 something cool. But it's such a pinpointed piece of information, it seems
 really weird to expose just this through the API without thinking about
 all the other related information that might be exposed along with it. Why
 just the moderated comment count? Why not the comment details that go
 along with it? Why not the UNmoderated comments?

 I don't think you should let the very narrow goals of the plugin dictate
 what your API looks like. The development of the API over the years has
 been frustratingly slow at times, but surely this can wait for more than a
 few days after the plugin was released before it creeps into the supported
 API?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 09:52:18 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 09:52:32 2007
Subject: [wp-trac] Re: [WordPress Trac] #5337: Wrong timezone with
 comment_time and the_time since DST ended
In-Reply-To: <044.ec6079982b1d5f2246907b669df901c7@lists.automattic.com>
References: <044.ec6079982b1d5f2246907b669df901c7@lists.automattic.com>
Message-ID: <053.b695a43ec9a1c8d3f313677dc9027bec@lists.automattic.com>

#5337: Wrong timezone with comment_time and the_time since DST ended
----------------------------------------+-----------------------------------
 Reporter:  jrawle                      |        Owner:  anonymous
     Type:  defect                      |       Status:  new      
 Priority:  normal                      |    Milestone:  2.4      
Component:  General                     |      Version:  2.3.1    
 Severity:  normal                      |   Resolution:           
 Keywords:  time date timezone dst utc  |  
----------------------------------------+-----------------------------------
Changes (by jrawle):

  * keywords:  => time date timezone dst utc
  * milestone:  2.3.2 => 2.4

Comment:

 From the PHP manual http://www.php.net/mktime :

 is_dst
     This parameter can be set to 1 if the time is during daylight savings
 time (DST), 0 if it is not, or -1 (the default) if it is unknown whether
 the time is within daylight savings time or not. If it's unknown, PHP
 tries to figure it out itself. This can cause unexpected (but not
 incorrect) results.

 The parameter is deprecated in PHP 5.1.0 and "the new timezone handling
 features should be used instead."

 For servers in the UK, it seems PHP is "figuring out" that they are on
 British time in the summer, but in the winter it gets it slightly wrong
 and assumes the machine is permanently on UTC (hence UTC not GMT).

 Perhaps this should be addressed in Wordpress along with other issues
 surrounding timezones, for example automatic DST?

 Other timezones could be affected if PHP makes the wrong guess as to the
 timezone.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 12:59:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 12:59:21 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.26943b611964b32d7f30e4c94cfa1f29@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------+-------------------------------
 Reporter:  darkdragon                      |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  Optimization                    |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  plugins.php phpdoc needs-patch  |  
--------------------------------------------+-------------------------------
Comment (by darkdragon):

 Replying to [comment:14 ryan]:
 > We need to profile it to see if its worthwhile.  Is losing the need to
 sort the priorities worth it?
 No.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 16:40:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 16:41:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #5189: Widgets with non-english
 character in their name are not saved
In-Reply-To: <042.6e91a8e13c8f503a48b018cb93746d91@lists.automattic.com>
References: <042.6e91a8e13c8f503a48b018cb93746d91@lists.automattic.com>
Message-ID: <051.7fca31b5518eb6eda638f94e10e2f2f6@lists.automattic.com>

#5189: Widgets with non-english character in their name are not saved
----------------------------+-----------------------------------------------
 Reporter:  omry            |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.5      
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Comment (by nyuhuhuu):

 I cannot reproduce it, it works nice for me.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 16:53:36 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 16:53:50 2007
Subject: [wp-trac] [WordPress Trac] #5343: Users without comment moderation
 priv's shouldn't be able to see comments in moderation
Message-ID: <051.2d316b39d2a19e8ee38a85db702963ec@lists.automattic.com>

#5343: Users without comment moderation priv's shouldn't be able to see comments
in moderation
----------------------------+-----------------------------------------------
 Reporter:  simonwheatley   |       Owner:  anonymous               
     Type:  enhancement     |      Status:  new                     
 Priority:  normal          |   Milestone:  2.5                     
Component:  Administration  |     Version:                          
 Severity:  normal          |    Keywords:  comments privileges user
----------------------------+-----------------------------------------------
 Currently users without comment moderation privileges can see the comments
 in moderation. This could be inappropriate for certain users.

 I am working on a Wordpress Mu blogging system for a series of primary
 school classes and we'll necessarily be giving young children logins to
 the WP admin area. We want to allow commenting on the blog, and will be
 using Akismet and the standard comment moderation filters to ensure that
 spam comments or comments with an adult subject matter are not published
 and are not visible to the young students.

 My proposed patch inserts some additional filters into the comment
 selection SQL on edit.php comments to ensure that unapproved comments are
 not selected if the current user cannot moderate_comments.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 16:58:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 16:58:45 2007
Subject: [wp-trac] [WordPress Trac] #5344: Users without comment moderation
 priv's shouldn't be able to see comments in moderation
Message-ID: <051.03cb1f4a02766f1b45a30750eb57bd43@lists.automattic.com>

#5344: Users without comment moderation priv's shouldn't be able to see comments
in moderation
----------------------------+-----------------------------------------------
 Reporter:  simonwheatley   |       Owner:  anonymous               
     Type:  enhancement     |      Status:  new                     
 Priority:  normal          |   Milestone:  2.5                     
Component:  Administration  |     Version:                          
 Severity:  normal          |    Keywords:  comments privileges user
----------------------------+-----------------------------------------------
 Currently users without comment moderation privileges can see the comments
 in moderation. This could be inappropriate for certain users.

 I am working on a Wordpress Mu blogging system for a series of primary
 school classes and we'll necessarily be giving young children logins to
 the WP admin area. We want to allow commenting on the blog, and will be
 using Akismet and the standard comment moderation filters to ensure that
 spam comments or comments with an adult subject matter are not published
 and are not visible to the young students.

 My proposed patch inserts some additional filters into the comment
 selection SQL on edit.php comments to ensure that unapproved comments are
 not selected if the current user cannot moderate_comments. I've only
 patched wp-admin/edit.php, which is the only place I can find where this
 problem exists.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 17:06:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 17:07:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #5343: Users without comment
 moderation priv's shouldn't be able to see comments in moderation
In-Reply-To: <051.2d316b39d2a19e8ee38a85db702963ec@lists.automattic.com>
References: <051.2d316b39d2a19e8ee38a85db702963ec@lists.automattic.com>
Message-ID: <060.7ab990bc7f1aaf41784b1211bc958fbc@lists.automattic.com>

#5343: Users without comment moderation priv's shouldn't be able to see comments
in moderation
--------------------------------------+-------------------------------------
 Reporter:  simonwheatley             |        Owner:  anonymous
     Type:  enhancement               |       Status:  closed   
 Priority:  normal                    |    Milestone:  2.5      
Component:  Administration            |      Version:           
 Severity:  normal                    |   Resolution:  duplicate
 Keywords:  comments privileges user  |  
--------------------------------------+-------------------------------------
Changes (by westi):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 Dupe of #5344

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 17:07:01 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 17:07:10 2007
Subject: [wp-trac] Re: [WordPress Trac] #5343: Users without comment
 moderation priv's shouldn't be able to see comments in moderation
In-Reply-To: <051.2d316b39d2a19e8ee38a85db702963ec@lists.automattic.com>
References: <051.2d316b39d2a19e8ee38a85db702963ec@lists.automattic.com>
Message-ID: <060.1272a2f4931dff77c515e6ef72a12405@lists.automattic.com>

#5343: Users without comment moderation priv's shouldn't be able to see comments
in moderation
--------------------------------------+-------------------------------------
 Reporter:  simonwheatley             |        Owner:  anonymous
     Type:  enhancement               |       Status:  closed   
 Priority:  normal                    |    Milestone:           
Component:  Administration            |      Version:           
 Severity:  normal                    |   Resolution:  duplicate
 Keywords:  comments privileges user  |  
--------------------------------------+-------------------------------------
Changes (by westi):

  * milestone:  2.5 =>

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 19:09:31 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 19:09:41 2007
Subject: [wp-trac] Re: [WordPress Trac] #5336: TinyMCE Mangles  tag's
In-Reply-To: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
References: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
Message-ID: <055.5add96ea6fa7ce42b5dc8d7401079281@lists.automattic.com>

#5336: TinyMCE Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  TinyMCE   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by lloydbudd):

  * summary:  Wordpress Mangles  tag's => TinyMCE Mangles 
              tag's
  * milestone:  => 2.5

Old description:

> I'm trying to embed some flash to a page on my site, I'm entering the
> correct  &  code into the page, which displays fine.
>
> However, If I goto edit the page at a later date the code gets mangled,
> wordpress inserts a  before the  and replaces me closing
> /> with >
>
> This is a real pain, as it means I have to re-edit my flash every time i
> alter the page.
>
> Is there a tag to prevent wordpress altering html, or should this be
> reported as a bug? - I'm guessing the html tidy process doesn't like
>  & 
>
> The HTML i'm adding to the code window can be seen here:
>
> ---
>  codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0"
> height="600" width="500">
> 
> 
> 
>  src="/Files/polaroid.swf" menu="false" quality="high" bgcolor="#fff"
> flashvars="flickrID=17378729@N00" type="application/x-shockwave-flash"
> pluginspage="http://www.macromedia.com/go/getflashplayer" height="600"
> width="500" />
> --
>
> I know that as a wordaround I could probably disable the TinyMCE editor,
> but 95% of the time it's fine.
>
> Dave

New description:

 I'm trying to embed some flash to a page on my site, I'm entering the
 correct  &  code into the page, which displays fine.

 However, If I goto edit the page at a later date the code gets mangled,
 wordpress inserts a  before the  and replaces me closing
 /> with >

 This is a real pain, as it means I have to re-edit my flash every time i
 alter the page.

 Is there a tag to prevent wordpress altering html, or should this be
 reported as a bug? - I'm guessing the html tidy process doesn't like
  & 

 The HTML i'm adding to the code window can be seen here:

 {{{
 
 
 
 
 
 }}}

 I know that as a wordaround I could probably disable the TinyMCE editor,
 but 95% of the time it's fine.

 Dave

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 19:24:23 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 19:24:34 2007
Subject: [wp-trac] [WordPress Trac] #5345: Post Pending problems
Message-ID: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>

#5345: Post Pending problems
----------------------------+-----------------------------------------------
 Reporter:  angelic007      |       Owner:  anonymous                   
     Type:  defect          |      Status:  new                         
 Priority:  normal          |   Milestone:  2.5                         
Component:  Administration  |     Version:  2.3.1                       
 Severity:  normal          |    Keywords:  pending, write, content lost
----------------------------+-----------------------------------------------
 I'm using IE7 and WP 2.3.1. To reproduce this bug (it's my first one i
 hope i'm doing right) log-in as an author, go to write -> Article, input
 some test content, choose a category and the "post pending" radiobutton.
 I'm sorry I use it in Italian and don't know the exact translation, I
 include a screenshot it should be clear.

 Then I click "Save" and close the browser window. Every sign of the saved
 post is then lost, i can't find it nowhere, neiher as admin nor as the
 normal user who wrote it, not on the top of write page (the review article
 shortcut) neither on the article manager page.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 19:29:08 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 19:29:18 2007
Subject: [wp-trac] Re: [WordPress Trac] #5345: Post Pending problems
In-Reply-To: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
References: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
Message-ID: <057.98f3b53eeeb18a38d36d74198c83a58b@lists.automattic.com>

#5345: Post Pending problems
------------------------------------------+---------------------------------
 Reporter:  angelic007                    |        Owner:  anonymous
     Type:  defect                        |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  Administration                |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:           
 Keywords:  pending, write, content lost  |  
------------------------------------------+---------------------------------
Comment (by angelic007):

 Well, I guess this has something to do with
 [http://trac.wordpress.org/ticket/5329]

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 20:52:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 20:52:42 2007
Subject: [wp-trac] Re: [WordPress Trac] #5335: Performance tweak for
	apply_filters loop
In-Reply-To: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
References: <046.d7053e68ef2707bbd499027c0fdf0f5f@lists.automattic.com>
Message-ID: <055.56db2d06e5d9e5505dc6357ee490e27c@lists.automattic.com>

#5335: Performance tweak for apply_filters loop
--------------------------+-------------------------------------------------
 Reporter:  Quandary      |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:  2.3.1    
 Severity:  normal        |   Resolution:           
 Keywords:  has-patch     |  
--------------------------+-------------------------------------------------
Changes (by lloydbudd):

  * version:  2.3 => 2.3.1

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 20:58:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 20:58:25 2007
Subject: [wp-trac] Re: [WordPress Trac] #5341: New
 wp.getCommentModerationCount XML-RPC method
In-Reply-To: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
References: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
Message-ID: <058.ae5f6b9413172a3b764963ccd1aafdb2@lists.automattic.com>

#5341: New wp.getCommentModerationCount XML-RPC method
------------------------------------------+---------------------------------
 Reporter:  josephscott                   |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  XML-RPC                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  has-patch developer-feedback  |  
------------------------------------------+---------------------------------
Changes (by lloydbudd):

  * keywords:  has-patch => has-patch developer-feedback
  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 20:59:59 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 21:00:10 2007
Subject: [wp-trac] Re: [WordPress Trac] #5337: Wrong timezone with
 comment_time and the_time since DST ended
In-Reply-To: <044.ec6079982b1d5f2246907b669df901c7@lists.automattic.com>
References: <044.ec6079982b1d5f2246907b669df901c7@lists.automattic.com>
Message-ID: <053.80f24194dc1bf4ada127fda1f9cdd4d6@lists.automattic.com>

#5337: Wrong timezone with comment_time and the_time since DST ended
----------------------------------------+-----------------------------------
 Reporter:  jrawle                      |        Owner:  anonymous
     Type:  defect                      |       Status:  new      
 Priority:  normal                      |    Milestone:  2.5      
Component:  General                     |      Version:  2.3.1    
 Severity:  normal                      |   Resolution:           
 Keywords:  time date timezone dst utc  |  
----------------------------------------+-----------------------------------
Changes (by lloydbudd):

  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 21:02:24 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 21:02:33 2007
Subject: [wp-trac] Re: [WordPress Trac] #5344: Users without comment
 moderation priv's shouldn't be able to see comments in moderation
In-Reply-To: <051.03cb1f4a02766f1b45a30750eb57bd43@lists.automattic.com>
References: <051.03cb1f4a02766f1b45a30750eb57bd43@lists.automattic.com>
Message-ID: <060.55cdc7eb18ab023c0374a572d9aeb4db@lists.automattic.com>

#5344: Users without comment moderation priv's shouldn't be able to see comments
in moderation
------------------------------------------------+---------------------------
 Reporter:  simonwheatley                       |        Owner:  anonymous
     Type:  enhancement                         |       Status:  new      
 Priority:  normal                              |    Milestone:  2.4      
Component:  Administration                      |      Version:           
 Severity:  normal                              |   Resolution:           
 Keywords:  comments privileges user has-patch  |  
------------------------------------------------+---------------------------
Changes (by lloydbudd):

  * keywords:  comments privileges user => comments privileges user has-
               patch
  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 22:11:59 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 22:12:08 2007
Subject: [wp-trac] Re: [WordPress Trac] #5330: wxr import inserts tags with
 numbers instead of names
In-Reply-To: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
References: <048.3f00c32426c72beddd02ae67f8a6e6d3@lists.automattic.com>
Message-ID: <057.87feff3286a614234e8c5ea7d326dc96@lists.automattic.com>

#5330: wxr import inserts tags with numbers instead of names
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |        Owner:  anonymous
     Type:  defect      |       Status:  closed   
 Priority:  normal      |    Milestone:  2.4      
Component:  General     |      Version:           
 Severity:  normal      |   Resolution:  fixed    
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 20:57:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 22:25:30 2007
Subject: [wp-trac] Re: [WordPress Trac] #5340: Regex warning in
	convert_smilies
In-Reply-To: <048.7fd2e4fcd0697c1aca188d76a3c8bbd6@lists.automattic.com>
References: <048.7fd2e4fcd0697c1aca188d76a3c8bbd6@lists.automattic.com>
Message-ID: <057.64fbb3a7a4703e48432e97fa5bfa3e56@lists.automattic.com>

#5340: Regex warning in convert_smilies
------------------------+---------------------------------------------------
 Reporter:  tellyworth  |        Owner:  anonymous
     Type:  defect      |       Status:  closed   
 Priority:  normal      |    Milestone:  2.4      
Component:  General     |      Version:           
 Severity:  normal      |   Resolution:  fixed    
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 22:54:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 22:55:05 2007
Subject: [wp-trac] [WordPress Trac] #5346: Cache current theme in options
Message-ID: <042.93b21110fef3081f81a43f4d331ba85d@lists.automattic.com>

#5346: Cache current theme in options
---------------------+------------------------------------------------------
 Reporter:  ryan     |       Owner:  anonymous          
     Type:  defect   |      Status:  new                
 Priority:  normal   |   Milestone:  2.4                
Component:  General  |     Version:                     
 Severity:  normal   |    Keywords:  performances themes
---------------------+------------------------------------------------------
 get_theme_mod() calls get_current_theme() which in turn calls
 get_themes().  get_themes() scans and parses all themes.  This means that
 themes that call get_theme_mod() scan and parse all themes on every page
 load.  This includes themes that use the custom image header library.
 Profiling on my testbed revealed that 10% of the load time for the front
 page was due to get_theme_mod() and friends.  Saving the current theme in
 options eliminates the need to rescan themes on every load.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 12 22:57:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 12 22:58:37 2007
Subject: [wp-trac] Re: [WordPress Trac] #5148: XMLRPC interface should
 support custom fields
In-Reply-To: <048.dde2ecb881a2ed3fb5c3326efcea0887@lists.automattic.com>
References: <048.dde2ecb881a2ed3fb5c3326efcea0887@lists.automattic.com>
Message-ID: <057.e5390cbbc7073c1444968c0652a48fee@lists.automattic.com>

#5148: XMLRPC interface should support custom fields
------------------------+---------------------------------------------------
 Reporter:  redsweater  |        Owner:  anonymous
     Type:  defect      |       Status:  new      
 Priority:  normal      |    Milestone:  2.5      
Component:  XML-RPC     |      Version:  2.3      
 Severity:  normal      |   Resolution:           
 Keywords:              |  
------------------------+---------------------------------------------------
Comment (by josephscott):

 The attached diff exposes custom fields via wp.getPage and
 metaWeblog.getPost (and their friends).  The new field is called
 "custom_fields" and an array of structs, with each struct containing three
 entries: id, key and value.  Something like this:

 {{{
     "custom_fields" = (
         {id = 129; key = city; value = Sacramento; },
         {id = 130; key = city; value = Sandy; }
     )
 }}}

 Custom fields can be added via wp.newPost/editPost and
 metaWeblog.newPost/editPost following the same general format.  If a
 custom field entry included with a post contains an "id" value then an
 update is done.  If there is no "id" then an add is done.  If there is an
 "id" value and no "key" value then the custom field with that id is
 deleted.

 I'm also open to the possibility of a wp.addCustomField(blog_id, post_id,
 key, value) style methods if discussions show that there is an interest
 and a reasonable use for them.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 00:32:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 00:32:30 2007
Subject: [wp-trac] Re: [WordPress Trac] #5341: New
 wp.getCommentModerationCount XML-RPC method
In-Reply-To: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
References: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
Message-ID: <058.781f5202cb662850e0de97ee241fb203@lists.automattic.com>

#5341: New wp.getCommentModerationCount XML-RPC method
------------------------------------------+---------------------------------
 Reporter:  josephscott                   |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  XML-RPC                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  has-patch developer-feedback  |  
------------------------------------------+---------------------------------
Comment (by Viper007Bond):

 If we do decide to add this feature, the code should be cleaned up first.
 The SQL query for example is a little heavier than it could be.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 00:33:55 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 00:34:07 2007
Subject: [wp-trac] Re: [WordPress Trac] #5336: TinyMCE Mangles  tag's
In-Reply-To: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
References: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
Message-ID: <055.8dc6a785cfe2944766a251de587ec7ed@lists.automattic.com>

#5336: TinyMCE Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  TinyMCE   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by Viper007Bond):

 Do you have the correct XHTML thing on?

 And yes, disable TinyMCE. :P

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 00:43:22 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 00:43:34 2007
Subject: [wp-trac] Re: [WordPress Trac] #5341: New
 wp.getCommentModerationCount XML-RPC method
In-Reply-To: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
References: <049.a6ae2cd74365c4fc6a62fddefb4099cc@lists.automattic.com>
Message-ID: <058.cdc016995a7f03fdc31049e55b09c980@lists.automattic.com>

#5341: New wp.getCommentModerationCount XML-RPC method
------------------------------------------+---------------------------------
 Reporter:  josephscott                   |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  XML-RPC                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  has-patch developer-feedback  |  
------------------------------------------+---------------------------------
Comment (by josephscott):

 I poked around to see if we had an existing function call to do this, but
 didn't see anything.  The SQL query used in the patch is the same one used
 to show the number of comment awaiting moderation in wp-admin.

 If I missed something I'd be happy to use something else.  Ideally
 something that kept properly cached results, unless having it constantly
 invalidated is more work than it is worth.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 04:36:07 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 04:36:19 2007
Subject: [wp-trac] [WordPress Trac] #5347: Move export_wp() to an include
	file
Message-ID: <048.4977c73e27de4d5c047332ca84509bde@lists.automattic.com>

#5347: Move export_wp() to an include file
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |       Owner:  anonymous
     Type:  enhancement  |      Status:  new      
 Priority:  normal       |   Milestone:  2.5      
Component:  General      |     Version:           
 Severity:  normal       |    Keywords:           
-------------------------+--------------------------------------------------
 This is a simple refactoring job that makes it possible to call
 export_wp() for unit testing.  The function now lives in an include file,
 and it no longer calls die() at the end.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 05:54:34 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 05:54:45 2007
Subject: [wp-trac] [WordPress Trac] #5348: 
     outside of wrap on comment
	edit page
Message-ID: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>

#5348: 
     outside of wrap on comment edit page
----------------------------+-----------------------------------------------
 Reporter:  rob1n           |       Owner:  ryan     
     Type:  defect          |      Status:  new      
 Priority:  low             |   Milestone:  2.3.2    
Component:  Administration  |     Version:  2.3.1    
 Severity:  minor           |    Keywords:  has-patch
----------------------------+-----------------------------------------------
 Editing a single comment (something like
 `comment.php?action=editcomment&c=526`), the 
     is outside of the wrap,
 which looks very awkward and isn't consistent with the rest of the admin.

 Attached patch fixes for trunk, should work for 2.3 branch too.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 06:01:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 06:02:10 2007
Subject: [wp-trac] Re: [WordPress Trac] #5347: Move export_wp() to an
	include file
In-Reply-To: <048.4977c73e27de4d5c047332ca84509bde@lists.automattic.com>
References: <048.4977c73e27de4d5c047332ca84509bde@lists.automattic.com>
Message-ID: <057.7f8511c57c5effc9cc6913d67801a010@lists.automattic.com>

#5347: Move export_wp() to an include file
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.5      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by ryan):

 How about passing author_id to export_wp() instead of it relying on _GET?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 09:15:33 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 09:15:44 2007
Subject: [wp-trac] [WordPress Trac] #5349: Admin permissions on Manage Posts
	page
Message-ID: <044.19ddff4fc358b2ad64bd94ae11262fcb@lists.automattic.com>

#5349: Admin permissions on Manage Posts page
----------------------------+-----------------------------------------------
 Reporter:  cbandy          |       Owner:  anonymous
     Type:  defect          |      Status:  new      
 Priority:  normal          |   Milestone:           
Component:  Administration  |     Version:  2.3.1    
 Severity:  normal          |    Keywords:           
----------------------------+-----------------------------------------------
 When logged in as admin, the Delete button on the Manage Posts page (wp-
 admin/edit.php) always displays "You don't have permission to do that" and
 does not delete a post.

 Digging, I found that check_ajax_referer compares the current user_login
 to the USER_COOKIE value passed in the request.  The current user_login is
 the plain string "admin" while the value in the request appears encoded in
 some way, and the test ( $current_name != $user ) is always false.

 Commenting out line 367-368 in wp-includes/pluggable.php solved for me.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 09:18:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 09:18:15 2007
Subject: [wp-trac] Re: [WordPress Trac] #5349: Admin permissions on Manage
	Posts page
In-Reply-To: <044.19ddff4fc358b2ad64bd94ae11262fcb@lists.automattic.com>
References: <044.19ddff4fc358b2ad64bd94ae11262fcb@lists.automattic.com>
Message-ID: <053.c8633539efb8e3463677fa5f8a41c5b9@lists.automattic.com>

#5349: Admin permissions on Manage Posts page
----------------------------+-----------------------------------------------
 Reporter:  cbandy          |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:           
Component:  Administration  |      Version:  2.3.1    
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Comment (by cbandy):

 Possibly related to #3720 as commented by miklb on 03/13/07

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 14:55:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 14:56:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #5317: get_posts returns invalid
 data when using category= parameter
In-Reply-To: <046.22c1c51f46953a96d9ace5b5ef4b9684@lists.automattic.com>
References: <046.22c1c51f46953a96d9ace5b5ef4b9684@lists.automattic.com>
Message-ID: <055.ef2f5f2d567ed0e05f970cec1efb1560@lists.automattic.com>

#5317: get_posts returns invalid data when using category= parameter
----------------------+-----------------------------------------------------
 Reporter:  MichaelH  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.4      
Component:  General   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by Kafkaesqui):

 Line #257 in post.php:

 `$query .= empty( $category ) ? '' :`
 `AND ($wpdb->posts.ID = $wpdb->term_relationships.object_id `
 `AND $wpdb->term_relationships.term_taxonomy_id =
 $wpdb->term_taxonomy.term_taxonomy_id `
 `AND $wpdb->term_taxonomy.term_id = " . $category. ") ";`

 This should be:

 `$query .= empty( $category ) ? '' : `
 `"AND ($wpdb->posts.ID = $wpdb->term_relationships.object_id `
 `AND $wpdb->term_relationships.term_taxonomy_id =
 $wpdb->term_taxonomy.term_taxonomy_id `
 `AND $wpdb->term_taxonomy.term_id = " . $category. " `
 `AND $wpdb->term_taxonomy.taxonomy = 'category') ";`

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 16:12:41 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 16:12:52 2007
Subject: [wp-trac] [WordPress Trac] #5350: maximum number characters
Message-ID: <043.84add7a43f5f111389c2d623a03a6221@lists.automattic.com>

#5350: maximum number characters
---------------------+------------------------------------------------------
 Reporter:  Cassy    |       Owner:  anonymous                   
     Type:  defect   |      Status:  new                         
 Priority:  high     |   Milestone:  2.3.2                       
Component:  General  |     Version:  2.3.1                       
 Severity:  major    |    Keywords:  maximum characters page post
---------------------+------------------------------------------------------
 (Text I want to insert as a page, attached to this ticket, pure html)

 - The whole text is not posted and not added to the database
 - Posting a large text without html tags also fails

 - Insert it manually into the database => works fine, no problem with
 database limit, but some characters are not escaped then.
 - Not sure if this is related to TinyMCE

 Link to support forum:
 http://wordpress.org/support/topic/97419?replies=9#post-646467

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 16:21:29 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 16:21:41 2007
Subject: [wp-trac] Re: [WordPress Trac] #4206: Publish button overrides
 Private post status
In-Reply-To: <046.4272ada0916212a189f8768c03c679a6@lists.automattic.com>
References: <046.4272ada0916212a189f8768c03c679a6@lists.automattic.com>
Message-ID: <055.061e3a4e568e120a1e58951f49b184dd@lists.automattic.com>

#4206: Publish button overrides Private post status
----------------------------+-----------------------------------------------
 Reporter:  mattyrob        |        Owner:  rob1n
     Type:  defect          |       Status:  new  
 Priority:  high            |    Milestone:  2.4  
Component:  Administration  |      Version:  2.1.3
 Severity:  major           |   Resolution:       
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * priority:  normal => high
  * severity:  normal => major

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 16:23:31 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 16:23:42 2007
Subject: [wp-trac] Re: [WordPress Trac] #5348: 
     outside of wrap on
 comment edit page
In-Reply-To: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
References: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
Message-ID: <052.60aac2548602373ed358d7a67510ba86@lists.automattic.com>

#5348: 
     outside of wrap on comment edit page
------------------------------+---------------------------------------------
 Reporter:  rob1n             |        Owner:  ryan 
     Type:  defect            |       Status:  new  
 Priority:  low               |    Milestone:  2.4  
Component:  Administration    |      Version:  2.3.1
 Severity:  minor             |   Resolution:       
 Keywords:  has-patch commit  |  
------------------------------+---------------------------------------------
Changes (by lloydbudd):

  * keywords:  has-patch => has-patch commit
  * milestone:  2.3.2 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 16:25:16 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 16:25:28 2007
Subject: [wp-trac] Re: [WordPress Trac] #5349: Admin permissions on Manage
	Posts page
In-Reply-To: <044.19ddff4fc358b2ad64bd94ae11262fcb@lists.automattic.com>
References: <044.19ddff4fc358b2ad64bd94ae11262fcb@lists.automattic.com>
Message-ID: <053.6c29df213fd7c0161c99e973b1ca5df9@lists.automattic.com>

#5349: Admin permissions on Manage Posts page
----------------------------+-----------------------------------------------
 Reporter:  cbandy          |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.3.1    
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * milestone:  => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 16:26:21 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 16:26:33 2007
Subject: [wp-trac] Re: [WordPress Trac] #5350: maximum number characters
In-Reply-To: <043.84add7a43f5f111389c2d623a03a6221@lists.automattic.com>
References: <043.84add7a43f5f111389c2d623a03a6221@lists.automattic.com>
Message-ID: <052.5061ecdc62ca875507fbd2f1fcc2a616@lists.automattic.com>

#5350: maximum number characters
------------------------------------------+---------------------------------
 Reporter:  Cassy                         |        Owner:  anonymous
     Type:  defect                        |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  General                       |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:           
 Keywords:  maximum characters page post  |  
------------------------------------------+---------------------------------
Changes (by lloydbudd):

  * priority:  high => normal
  * severity:  major => normal
  * milestone:  2.3.2 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 18:52:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 18:52:14 2007
Subject: [wp-trac] Re: [WordPress Trac] #5336: TinyMCE Mangles  tag's
In-Reply-To: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
References: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
Message-ID: <055.a5ff8fd74d22f0f15de45d22b5fd1332@lists.automattic.com>

#5336: TinyMCE Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  TinyMCE   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by DaveHope):

 Do you mean am I using the correct DocTag? - If so, yes I am.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 21:46:45 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 21:46:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #5336: TinyMCE Mangles  tag's
In-Reply-To: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
References: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
Message-ID: <055.06e3961a68a7bbb52932112d7fb574e3@lists.automattic.com>

#5336: TinyMCE Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  TinyMCE   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by Viper007Bond):

 Huh? No.

 Options > Writing

 Make sure "WordPress should correct invalidly nested XHTML automatically"
 is unticked.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 22:17:32 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 22:17:57 2007
Subject: [wp-trac] [WordPress Trac] #5351: Drafts aren't listed as
 unpublished if the timestamp is set
Message-ID: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>

#5351: Drafts aren't listed as unpublished if the timestamp is set
---------------------+------------------------------------------------------
 Reporter:  hailin   |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.5      
Component:  General  |     Version:           
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 1. Write a post
 2. Set the timestamp 5 minutes in the future
 3. Save it as a draft
 4. Wait 6 minutes
 5. Visit Manage/Posts

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 22:21:33 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 22:21:44 2007
Subject: [wp-trac] Re: [WordPress Trac] #5351: Drafts aren't listed as
 unpublished if the timestamp is set
In-Reply-To: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
References: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
Message-ID: <053.fa4f1943159bd7b88654a12cf1edbf84@lists.automattic.com>

#5351: Drafts aren't listed as unpublished if the timestamp is set
---------------------+------------------------------------------------------
 Reporter:  hailin   |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:           
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by hailin):

 It's still an issue. See the attached screen capture, taken at 6:11 pm.
 Can you guess which ones are live and which are unpublished?

 Post 19 is a future post. It doesn't explicitly say so but I can see that
 it hasn't been published if I check the date.

 Post 33 is a regular published post - the date is in the past.

 Post 37 is the type I'm referring to in the original report. Its date is
 in the past (1 minute ago), but it hasn't been published because it's a
 draft. However, there's nothing at all on the manage page to distinguish
 between Post 33 (published) and post 37 (unpublished).

 A normal draft (which hasn't had the post timestamp explicitly set) will
 show 'Never' in the date column.

 =======================================
   The problem happends because when we first create a draft, the
 post_modified is saved as 0000-00-00 00:00:00. However, when we assign a
 future date to that draft, it carries that future time, such as 2007-12-25
 10:10:10

 When posts are displayed in Mangage=>posts page, "When" column displays
 drafts time as long as the time is not all zeros. I've changed that logic
 so that all drafts and pending posts are correctly displayed as
 "Unpublished".

 Now, when a filter is selected, as as "Draft" is selected, whatever time
 stamp associated with the draft will be displayed. This is existing
 behavior, and I feel showing something is better than a straight "Never".
 Thus I don't modify that.

 Personally, I felt that we should save the post_modified timestamp even
 for a draft. But Ryan said there is some historic reasons. Thus I am not
 going to introduce drastic changes here. Just fix the bug as it is now.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 22:28:05 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 22:28:16 2007
Subject: [wp-trac] Re: [WordPress Trac] #5351: Drafts aren't listed as
 unpublished if the timestamp is set
In-Reply-To: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
References: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
Message-ID: <053.7719f7f74cef809429956c09cfc9f552@lists.automattic.com>

#5351: Drafts aren't listed as unpublished if the timestamp is set
---------------------+------------------------------------------------------
 Reporter:  hailin   |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:           
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Old description:

> 1. Write a post
> 2. Set the timestamp 5 minutes in the future
> 3. Save it as a draft
> 4. Wait 6 minutes
> 5. Visit Manage/Posts

New description:

 ENV: WP trunk r8178

 1. Write a post [[br]]
 2. Set the timestamp 5 minutes in the future [[br]]
 3. Save it as a draft [[br]]
 4. Wait 6 minutes [[br]]
 5. Visit Manage/Posts

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 22:29:01 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 22:29:10 2007
Subject: [wp-trac] Re: [WordPress Trac] #5351: Drafts aren't listed as
 unpublished if the timestamp is set
In-Reply-To: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
References: <044.ec44d5f66d1771a0a9ed4f6075656297@lists.automattic.com>
Message-ID: <053.aedf50c0cbcbd075581242834f474f21@lists.automattic.com>

#5351: Drafts aren't listed as unpublished if the timestamp is set
----------------------------+-----------------------------------------------
 Reporter:  hailin          |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.4      
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * version:  => 2.4
  * component:  General => Administration
  * milestone:  2.5 => 2.4

Comment:

 setting milestone to 2.4, but waiting on new dashboard UI

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 22:37:47 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 22:37:57 2007
Subject: [wp-trac] Re: [WordPress Trac] #5345: Post Pending problems
In-Reply-To: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
References: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
Message-ID: <057.db990421da54d4c3fc1bbcf5e1cb7aaf@lists.automattic.com>

#5345: Post Pending problems
------------------------------------------+---------------------------------
 Reporter:  angelic007                    |        Owner:  anonymous
     Type:  defect                        |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  Administration                |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:           
 Keywords:  pending, write, content lost  |  
------------------------------------------+---------------------------------
Comment (by lloydbudd):

 ENV: WP trunk r6334

 Works for me. I can't duplicate this problem.

 It isn't expected for a article pending review to be at the top of the
 write page, , because that only currently lists drafts, but logged in as
 the Author (or the Admin) I do find it when I filter Status... Pending
 Review

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 23:17:47 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 23:17:58 2007
Subject: [wp-trac] Re: [WordPress Trac] #5294: $phpmailer->Sender line
 prevents comment notifications from being received
In-Reply-To: <046.ec1d546a66ddb791f5e8c60272ab1b67@lists.automattic.com>
References: <046.ec1d546a66ddb791f5e8c60272ab1b67@lists.automattic.com>
Message-ID: <055.293998ba268f650e5c574180bac4d46e@lists.automattic.com>

#5294: $phpmailer->Sender line prevents comment notifications from being received
----------------------+-----------------------------------------------------
 Reporter:  stitzelj  |        Owner:  westi   
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:  2.3.2   
Component:  General   |      Version:  2.3.1   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by haniobaid):

 I've been running without issues for several months. Stopped getting
 comment notification emails as soon as I upgraded from 2.3 to 2.3.1

 Added wordpress@haniobaid.com email to my bluehost cpanel. it didn't help.

 Tried the plugin above, also didn't help

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 13 23:24:13 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 13 23:24:23 2007
Subject: [wp-trac] Re: [WordPress Trac] #5294: $phpmailer->Sender line
 prevents comment notifications from being received
In-Reply-To: <046.ec1d546a66ddb791f5e8c60272ab1b67@lists.automattic.com>
References: <046.ec1d546a66ddb791f5e8c60272ab1b67@lists.automattic.com>
Message-ID: <055.b042f9ec6d36f9df5ab1e0c4179f97c4@lists.automattic.com>

#5294: $phpmailer->Sender line prevents comment notifications from being received
----------------------+-----------------------------------------------------
 Reporter:  stitzelj  |        Owner:  westi   
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:  2.3.2   
Component:  General   |      Version:  2.3.1   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by haniobaid):

 I removed the line mentioned above from pluggable and now I get the emails

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 04:04:50 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 04:05:00 2007
Subject: [wp-trac] Re: [WordPress Trac] #5348: 
     outside of wrap on
 comment edit page
In-Reply-To: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
References: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
Message-ID: <052.d5bd33be1ff411201834525ee1993b8f@lists.automattic.com>

#5348: 
     outside of wrap on comment edit page
------------------------------+---------------------------------------------
 Reporter:  rob1n             |        Owner:  ryan 
     Type:  defect            |       Status:  new  
 Priority:  low               |    Milestone:  2.4  
Component:  Administration    |      Version:  2.3.1
 Severity:  minor             |   Resolution:       
 Keywords:  has-patch commit  |  
------------------------------+---------------------------------------------
Comment (by rob1n):

 Why not 2.3.2? It's a minor change and really should be fixed for the 2.3
 branch -- it just looks weird and reports are likely to come in.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 08:54:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 08:55:03 2007
Subject: [wp-trac] Re: [WordPress Trac] #5162: Extract additional image
 metadata from EXIF/IPTC
In-Reply-To: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com>
References: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com>
Message-ID: <057.3cb3b1a337ea09275251dbc456585cb9@lists.automattic.com>

#5162: Extract additional image metadata from EXIF/IPTC
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |        Owner:  ryan    
     Type:  enhancement  |       Status:  reopened
 Priority:  normal       |    Milestone:  2.4     
Component:  General      |      Version:          
 Severity:  normal       |   Resolution:          
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by remotesensingtools):

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

Comment:

 Request to extend EXIF parser to include GPS metadata keys stored in
 EXIF/IPTC.

 Reference projects are available in relation to PHP, the
 [http://us3.php.net/manual/en/ref.exif.php PHP EXIF Library], and use with
 WordPress (and web mapping applications).

 One example of such project that appears to already have dealt with
 various camera models' approach to GPS in metadata is the following. This
 project appears to be as a WordPress related development.:
 [http://notions.okuda.ca/mg2-hacks/exif-parser/ PHP Exif-Parser]

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 09:17:41 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 09:17:51 2007
Subject: [wp-trac] Re: [WordPress Trac] #5350: Large pages cannot be saved
 (limit maximum number characters)
In-Reply-To: <043.84add7a43f5f111389c2d623a03a6221@lists.automattic.com>
References: <043.84add7a43f5f111389c2d623a03a6221@lists.automattic.com>
Message-ID: <052.4f8987af322469b6376575308fd4cddf@lists.automattic.com>

#5350: Large pages cannot be saved (limit maximum number characters)
------------------------------------------+---------------------------------
 Reporter:  Cassy                         |        Owner:  anonymous
     Type:  defect                        |       Status:  new      
 Priority:  normal                        |    Milestone:  2.5      
Component:  General                       |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:           
 Keywords:  maximum characters page post  |  
------------------------------------------+---------------------------------
Changes (by Cassy):

  * summary:  maximum number characters => Large pages cannot be saved
              (limit maximum number characters)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 10:05:25 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 10:05:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #5162: Extract additional image
 metadata from EXIF/IPTC
In-Reply-To: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com>
References: <048.167ac8101c240703239b04ac9b19f27f@lists.automattic.com>
Message-ID: <057.ede3feceae33db3df9eab920c31f4ff1@lists.automattic.com>

#5162: Extract additional image metadata from EXIF/IPTC
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |        Owner:  ryan  
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:  2.4   
Component:  General      |      Version:        
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by Viper007Bond):

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

Comment:

 Please open a new ticket rather than reopening this one. ;)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 12:47:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 12:48:08 2007
Subject: [wp-trac] [WordPress Trac] #5352: register_sidebars does not handle
 names or multiple calls correctly
Message-ID: <044.aa464416be1d1e75468156eed763c741@lists.automattic.com>

#5352: register_sidebars does not handle names or multiple calls correctly
---------------------+------------------------------------------------------
 Reporter:  watson   |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.5      
Component:  General  |     Version:  2.3.1    
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 In the function `register_sidebars()` in `wp-includes/widgets.php` the
 `$args['name']` attribute is not filtered through `sprintf()`. This means
 that the following call to `register_sidebars()` will have unexpected
 results:

 {{{
 register_sidebars(2, array('name' => 'Foobar %d'));
 }}}

 Instead of producing two sidebars with the names ''Foobar 1'' and ''Foobar
 2'' it will produce two sidebars with the same name: ''Foobar %d''.

 Secondly, multiple calls to `register_sidebars()` will fail if you do not
 specifically supply the `$args['id']` attribute. This is because
 `register_sidebars()` maintains an internal counter that auto-generates an
 id for the specific sidebar (if one is not given as an argument). This
 counter re-starts at `1` on each call to `register_sidebars()`,
 effectively overwriting previously created sidebars on subsequent calls.

 Example:
 {{{
 register_sidebars(2, array('name' => 'Foo %d'));
 register_sidebars(2, array('name' => 'Bar %d'));
 }}}

 This will only create 2 sidebars - not 4. The two sidebars that will be
 created will be the ones from the last call: `Bar %d`

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 14:18:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 14:19:04 2007
Subject: [wp-trac] Re: [WordPress Trac] #5352: register_sidebars does not
 handle names or multiple calls correctly
In-Reply-To: <044.aa464416be1d1e75468156eed763c741@lists.automattic.com>
References: <044.aa464416be1d1e75468156eed763c741@lists.automattic.com>
Message-ID: <053.f1cad94acd493660dc679e6a924a2c3f@lists.automattic.com>

#5352: register_sidebars does not handle names or multiple calls correctly
---------------------+------------------------------------------------------
 Reporter:  watson   |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:  2.3.1    
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by watson):

 Ups... there where an error in the patch. It has been fixed now and the
 patch file have been replaced.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 14:43:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 14:43:16 2007
Subject: [wp-trac] [WordPress Trac] #5353: Extend EXIF parser to include GPS
 metadata keys
Message-ID: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>

#5353: Extend EXIF parser to include GPS metadata keys
--------------------------------+-------------------------------------------
 Reporter:  remotesensingtools  |       Owner:  anonymous
     Type:  enhancement         |      Status:  new      
 Priority:  normal              |   Milestone:  2.4      
Component:  General             |     Version:           
 Severity:  normal              |    Keywords:           
--------------------------------+-------------------------------------------
 Request to extend EXIF parser to include GPS metadata keys stored in
 EXIF/IPTC.

 Reference projects are available in relation to PHP, the
 [http://us3.php.net/manual/en/ref.exif.php PHP EXIF Library], and use with
 WordPress (and web mapping applications).

 One example of such project that appears to already have dealt with
 various camera models' approach to GPS in metadata is the following. This
 project appears to be a WordPress related development.:
 [http://notions.okuda.ca/mg2-hacks/exif-parser/ PHP Exif-Parser] (A
 request has been sent to that developer to participate and add value in
 this development, but you may wish to contact him personally to encourage
 his support and participation.)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 16:53:32 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 16:53:42 2007
Subject: [wp-trac] [WordPress Trac] #5354: Implement dashboard content as an
 action, so it can be replaced/added to
Message-ID: <051.d04f91763eaa60a1ac1dddc0524d2f6e@lists.automattic.com>

#5354: Implement dashboard content as an action, so it can be replaced/added to
----------------------------+-----------------------------------------------
 Reporter:  simonwheatley   |       Owner:  anonymous                              
     Type:  enhancement     |      Status:  new                                    
 Priority:  normal          |   Milestone:  2.4                                    
Component:  Administration  |     Version:  2.3.1                                  
 Severity:  normal          |    Keywords:  has-patch needs-testing dashboard admin
----------------------------+-----------------------------------------------
 The proposed patch implements the list of possible actions on the
 dashboard (e.g. Write a post, Add a link to your blogroll, etc) as an
 action, do_action('dashboard_content'), rather than "hard" coded into the
 page. This allows to additional material to be added or removed on a per-
 blog basis, through plugins and/or themes.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 17:03:33 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 17:03:41 2007
Subject: [wp-trac] Re: [WordPress Trac] #5354: Implement dashboard content
 as an action, so it can be replaced/added to
In-Reply-To: <051.d04f91763eaa60a1ac1dddc0524d2f6e@lists.automattic.com>
References: <051.d04f91763eaa60a1ac1dddc0524d2f6e@lists.automattic.com>
Message-ID: <060.c568c2ee1f7efa7ab5b6f830c6b0a725@lists.automattic.com>

#5354: Implement dashboard content as an action, so it can be replaced/added to
-----------------------------------------------------+----------------------
 Reporter:  simonwheatley                            |        Owner:  anonymous
     Type:  enhancement                              |       Status:  new      
 Priority:  normal                                   |    Milestone:  2.4      
Component:  Administration                           |      Version:  2.3.1    
 Severity:  normal                                   |   Resolution:           
 Keywords:  has-patch needs-testing dashboard admin  |  
-----------------------------------------------------+----------------------
Comment (by simonwheatley):

 My need for this is through wanting to tailor the welcome/help content
 according to the role of the user viewing the dashboard. I have some help
 links for various actions show there, and there's no point in telling the
 students how to moderate comments if they haven't got the privileges (for
 example).

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 17:04:03 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 17:04:11 2007
Subject: [wp-trac] Re: [WordPress Trac] #5348: 
     outside of wrap on
 comment edit page
In-Reply-To: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
References: <043.905cda5ea6380fe3eaceccb6893315f5@lists.automattic.com>
Message-ID: <052.c3ffc3db9d06b467caba0697b36e2d19@lists.automattic.com>

#5348: 
     outside of wrap on comment edit page
------------------------------+---------------------------------------------
 Reporter:  rob1n             |        Owner:  ryan 
     Type:  defect            |       Status:  new  
 Priority:  low               |    Milestone:  2.4  
Component:  Administration    |      Version:  2.3.1
 Severity:  minor             |   Resolution:       
 Keywords:  has-patch commit  |  
------------------------------+---------------------------------------------
Comment (by lloydbudd):

 Applying to trunk first is always a good idea. The first for inclusion in
 maint. is severity and pervasiveness of the problem. You say reports are
 likely to come in, but this is also the first report of it. And
 discovering a bug that is already fixed on trunk (with our regular release
 cycles) is a great opportunity to learn more about WP development.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 17:56:38 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 17:56:47 2007
Subject: [wp-trac] Re: [WordPress Trac] #5336: TinyMCE Mangles  tag's
In-Reply-To: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
References: <046.3da48a062596f515853f5eba3f98c11a@lists.automattic.com>
Message-ID: <055.c98c9606382141b872519b537a493bc1@lists.automattic.com>

#5336: TinyMCE Mangles  tag's
----------------------+-----------------------------------------------------
 Reporter:  DaveHope  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  TinyMCE   |      Version:  2.3.1    
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by DaveHope):

 Alas, that option is already un-ticked.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 19:41:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 19:41:30 2007
Subject: [wp-trac] [WordPress Trac] #5355: get_the_tag_feed() in Wordpress
	2.4
Message-ID: <047.a5815c40aa939285020e2b1d4602b8a6@lists.automattic.com>

#5355: get_the_tag_feed() in Wordpress 2.4
-----------------------+----------------------------------------------------
 Reporter:  nickbohle  |       Owner:  anonymous
     Type:  task       |      Status:  new      
 Priority:  normal     |   Milestone:           
Component:  General    |     Version:  2.4      
 Severity:  normal     |    Keywords:           
-----------------------+----------------------------------------------------
 I just read on Peter's weekly digest that a new get_category_feed_link()
 template tag is going to be included in Wordpress 2.4.

 It would be great, if you could create the same function for "tags":
 get_the_tag_feed()

 Or does this function already exist? I haven't seen any "get feed for tag"
 function inside the template tags index on Wordpress.org.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 20:19:44 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 20:19:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #5355: get_the_tag_feed() in
	Wordpress 2.4
In-Reply-To: <047.a5815c40aa939285020e2b1d4602b8a6@lists.automattic.com>
References: <047.a5815c40aa939285020e2b1d4602b8a6@lists.automattic.com>
Message-ID: <056.a4e1986cb533a1b36707a741dc32dc1e@lists.automattic.com>

#5355: get_the_tag_feed() in Wordpress 2.4
-----------------------+----------------------------------------------------
 Reporter:  nickbohle  |        Owner:  anonymous
     Type:  task       |       Status:  new      
 Priority:  normal     |    Milestone:  2.5      
Component:  General    |      Version:  2.4      
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by lloydbudd):

  * milestone:  => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 20:22:01 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 20:22:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #4595: Format of feed (RSS,
 Atom) should be an option
In-Reply-To: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
References: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
Message-ID: <055.3e926a61e4f3397fe7d47c8c1879aae6@lists.automattic.com>

#4595: Format of feed (RSS, Atom) should be an option
----------------------------+-----------------------------------------------
 Reporter:  terraces        |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * summary:  Allow users to choose type of RSS feeds => Format of feed
              (RSS, Atom) should be an option

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 20:37:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 20:38:00 2007
Subject: [wp-trac] Re: [WordPress Trac] #5065: Unify User-Agent strings
In-Reply-To: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
References: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
Message-ID: <054.9db9316023c3554e0286af2a1b8354f9@lists.automattic.com>

#5065: Unify User-Agent strings
------------------------------------------+---------------------------------
 Reporter:  docwhat                       |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.4      
Component:  General                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  privacy user-agent has-patch  |  
------------------------------------------+---------------------------------
Comment (by docwhat):

 Update:

 I've been running this patch (with the plugin) for over a month with no
 problems.

 Ciao!

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 20:37:56 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 20:38:04 2007
Subject: [wp-trac] Re: [WordPress Trac] #4595: Format of feed (RSS,
 Atom) should be an option
In-Reply-To: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
References: <046.3944c8e0e242a968e27665eb1e6faaf1@lists.automattic.com>
Message-ID: <055.2bdf7e0ab956a65cd92ff430c1ac8263@lists.automattic.com>

#4595: Format of feed (RSS, Atom) should be an option
----------------------------+-----------------------------------------------
 Reporter:  terraces        |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------
Comment (by lloydbudd):

 I understand the naming used by Otto42, it's consistent with other options
 that begin rss, but time to move fwd ;-) And 'default' seems unnecessary
 in option name, particularly when sometime it means can be over written by
 post specific options.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 21:50:37 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 21:54:23 2007
Subject: [wp-trac] Re: [WordPress Trac] #5355: get_the_tag_feed() in
	Wordpress 2.4
In-Reply-To: <047.a5815c40aa939285020e2b1d4602b8a6@lists.automattic.com>
References: <047.a5815c40aa939285020e2b1d4602b8a6@lists.automattic.com>
Message-ID: <056.f509f187b3aef8722e42a642aa3c9269@lists.automattic.com>

#5355: get_the_tag_feed() in Wordpress 2.4
-----------------------+----------------------------------------------------
 Reporter:  nickbohle  |        Owner:  anonymous
     Type:  task       |       Status:  closed   
 Priority:  normal     |    Milestone:           
Component:  General    |      Version:  2.4      
 Severity:  normal     |   Resolution:  invalid  
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by ionfish):

  * status:  new => closed
  * resolution:  => invalid
  * milestone:  2.5 =>

Comment:

 get_tag_feed_link() is already in 2.3. Have a look in wp-
 includes/feed.php.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 22:37:37 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 22:37:47 2007
Subject: [wp-trac] [WordPress Trac] #5356: gettext cannot parse mo files on
 64bit systems
Message-ID: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>

#5356: gettext cannot parse mo files on 64bit systems
--------------------+-------------------------------------------------------
 Reporter:  nyuwec  |       Owner:  anonymous     
     Type:  defect  |      Status:  new           
 Priority:  normal  |   Milestone:  2.3.2         
Component:  i18n    |     Version:  2.3.1         
 Severity:  normal  |    Keywords:  gettext, 64bit
--------------------+-------------------------------------------------------
 I was trying to use a hungarian localization on WP 2.3.1, but it does
 nothing. After some research I had found that If I overwrite the wp-
 includes/gettext.php and the wp-includes/streams.php with those in the
 latest PHP-gettext package, everything starts to work again.
 Only a minor effect occured in the Dashboard among the news results.
 Probably something that is needed the modified gettext.php version
 included in the WP install pack.

 I think the problem is in connection with ticket #1727, but it seems that
 in revisions [4003] and [4004] the PHP gettext is updated, so currently
 i'm clueless.

 Sadly, I can't provide any description how to reproduce the error. The
 only thing I can describe is the server:
 {{{
 Linux version 2.6.18-gentoo-r6-JiM-2 (root@localhost) (gcc version 4.1.1
 (Gentoo 4.1.1-r1))
 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02
 PHP:
 './configure' '--prefix=....' '--host=x86_64-pc-linux-gnu' '--mandir=....'
 '--infodir=....' '--sysconfdir=/etc' '--cache-file=./config.cache'
 '--with-libdir=lib64' '--disable-cli' '--with-apxs2=....' '--with-config-
 file-path=....' '--with-config-file-scan-dir=....' '--without-pear'
 '--disable-bcmath' '--without-bz2' '--disable-calendar' '--with-curl'
 '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-
 fbsql' '--without-fdftk' '--disable-filter' '--disable-ftp' '--with-
 gettext' '--without-gmp' '--disable-hash' '--disable-ipv6' '--disable-
 json' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-
 mhash' '--without-msql' '--without-mssql' '--with-ncurses' '--with-
 openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--disable-pdo'
 '--with-pgsql' '--disable-posix' '--without-pspell' '--without-recode'
 '--disable-shmop' '--without-snmp' '--enable-soap' '--disable-sockets'
 '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-
 sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer'
 '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-
 xmlrpc' '--without-xsl' '--enable-zip' '--with-zlib' '--disable-debug'
 '--enable-dba' '--without-cdb' '--with-db4' '--without-flatfile' '--with-
 gdbm' '--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr'
 '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr'
 '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-mysql=/usr'
 '--with-mysql-sock=....' '--without-mysqli' '--with-readline' '--without-
 libedit' '--without-mm' '--without-sqlite'
 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 22:58:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 22:58:29 2007
Subject: [wp-trac] [WordPress Trac] #5357: wxr import: don't load the whole
 file at once
Message-ID: <048.0bc4095bc51ef7c644845375b88181c2@lists.automattic.com>

#5357: wxr import: don't load the whole file at once
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |       Owner:  anonymous
     Type:  enhancement  |      Status:  new      
 Priority:  normal       |   Milestone:  2.5      
Component:  General      |     Version:           
 Severity:  normal       |    Keywords:           
-------------------------+--------------------------------------------------
 The wxr importer currently loads all posts into a large array before
 processing them.  That makes large imports impossible on servers with a
 small memory limit.

 The enclosed patch refactors import/wordpress.php to keep only one post at
 a time in memory.  I've keep most of the original code intact to minimize
 breakage.  It's no faster or slower than before.  There are other
 optimizations that could be made but this is a necessary first step.

 Unit tests are in http://svn.automattic.com/wordpress-tests/wp-
 testcase/test_import_wp.php

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 14 23:06:33 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 14 23:06:44 2007
Subject: [wp-trac] Re: [WordPress Trac] #5356: gettext cannot parse mo files
 on 64bit systems
In-Reply-To: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
References: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
Message-ID: <053.a978082381eb83cd753ec974ebf2db37@lists.automattic.com>

#5356: gettext cannot parse mo files on 64bit systems
----------------------------+-----------------------------------------------
 Reporter:  nyuwec          |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.3.2    
Component:  i18n            |      Version:  2.3.1    
 Severity:  normal          |   Resolution:           
 Keywords:  gettext, 64bit  |  
----------------------------+-----------------------------------------------
Comment (by ryan):

 see #3780

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 02:38:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 02:38:41 2007
Subject: [wp-trac] Re: [WordPress Trac] #5357: wxr import: don't load the
 whole file at once
In-Reply-To: <048.0bc4095bc51ef7c644845375b88181c2@lists.automattic.com>
References: <048.0bc4095bc51ef7c644845375b88181c2@lists.automattic.com>
Message-ID: <057.decd4fe0cdc32a9245cff5f467c2220c@lists.automattic.com>

#5357: wxr import: don't load the whole file at once
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.5      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by tellyworth):

 The sample export files used for unit testing are here if anyone wants to
 confirm those tests by hand: http://svn.automattic.com/wordpress-tests/wp-
 testdata/export/

 big-export.xml has 500 posts with comments.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 04:32:46 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 04:32:55 2007
Subject: [wp-trac] Re: [WordPress Trac] #5353: Extend EXIF parser to include
 GPS metadata keys
In-Reply-To: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
References: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
Message-ID: <065.2ea9cfb64e056f4e9396ad9a517b045e@lists.automattic.com>

#5353: Extend EXIF parser to include GPS metadata keys
--------------------------------+-------------------------------------------
 Reporter:  remotesensingtools  |        Owner:  anonymous
     Type:  enhancement         |       Status:  new      
 Priority:  normal              |    Milestone:  2.4      
Component:  General             |      Version:           
 Severity:  normal              |   Resolution:           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Comment (by tellyworth):

 This sounds like a job for a plugin.  The image metadata code has a hook
 just for that purpose.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:13:44 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:13:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #5163: add_filter's inline docs says
 it works on strings only
In-Reply-To: <048.10d6787f70866760b87a2174ab127caf@lists.automattic.com>
References: <048.10d6787f70866760b87a2174ab127caf@lists.automattic.com>
Message-ID: <057.1154320ab4bad86a8722aa42ca36a0b2@lists.automattic.com>

#5163: add_filter's inline docs says it works on strings only
-----------------------------------+----------------------------------------
 Reporter:  nbachiyski             |        Owner:  anonymous
     Type:  defect                 |       Status:  new      
 Priority:  lowest                 |    Milestone:  2.4      
Component:  General                |      Version:  2.3      
 Severity:  trivial                |   Resolution:           
 Keywords:  docs has-patch phpdoc  |  
-----------------------------------+----------------------------------------
Changes (by darkdragon):

  * keywords:  docs has-patch => docs has-patch phpdoc

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:17:21 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:17:31 2007
Subject: [wp-trac] [WordPress Trac] #5358: Queried object on multiple tag
 query holds only first tag
Message-ID: <048.12a6d403eb7094d0e951218637f89c09@lists.automattic.com>

#5358: Queried object on multiple tag query holds only first tag
------------------------+---------------------------------------------------
 Reporter:  Kafkaesqui  |       Owner:  anonymous    
     Type:  defect      |      Status:  new          
 Priority:  normal      |   Milestone:  2.4          
Component:  General     |     Version:  2.3.1        
 Severity:  normal      |    Keywords:  tags wp_query
------------------------+---------------------------------------------------
 On tag page results when two or more tags are queried ('''/tags/foo,bar'''
 -or- '''/tags/foo+bar'''), only the first tag is in the queried object. So
 a simple:

 {{{ print_r($wp_query->get_queried_object());  }}}

 outputs a single associative array of the first tag referenced in the
 query. One would expect to find an array of all tags in the queried
 object.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:22:27 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:22:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API, plugin.php
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.90bab5a21b15328c5eb6c70d8375f597@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
--------------------------------------------------------+-------------------
 Reporter:  darkdragon                                  |        Owner:  anonymous
     Type:  enhancement                                 |       Status:  new      
 Priority:  normal                                      |    Milestone:  2.5      
Component:  Optimization                                |      Version:  2.4      
 Severity:  normal                                      |   Resolution:           
 Keywords:  plugins.php phpdoc has-patch needs-testing  |  
--------------------------------------------------------+-------------------
Changes (by darkdragon):

  * keywords:  plugins.php phpdoc needs-patch => plugins.php phpdoc has-
               patch needs-testing

Comment:

 I don't know if you want the PHPDoc stuff, I'll remove it, but it does
 improve upon some of the stuff from the other bugs (#5163 and #5225).
 Unintentionally, since I've used the one for the PHPdoc checkout instead
 of the other checkout (I've so many now, I can't keep track of which ones
 are broken and what I've used them for).

 Basically, it is important since there is a merged filters bug in the
 do_actions (the $merged_filters isn't being set to global, therefore the
 test will always fail and decrease performance. Won't break anything, but
 could slow things down by sorting the array each time.)

 I've removed the '@' from the current filter assignment, which should
 speed things up, since '@' is slow until latest PHP 5.2 version (5.2.3 or
 5.2.4 has the performance improvement).

 I moved the all tag call to its own function and updated all functions to
 call it instead. The function has PHPDoc info. You will notice that the
 hook is not part of the call, I figure using the current_filter function
 is better.

  * I did not use Foreach instead of the do while.
  * I did not remove merged_filters
  * I did not move current_filters assignment.

 All in all, I've only did two of the five things in the WP-Hackers post.
 The rest were premature.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:23:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:23:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Preformance Tweaks for
 WordPress Trunk Plugin API
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.2f828ca83e10476dfd50760da4dea4ff@lists.automattic.com>

#5338: Preformance Tweaks for WordPress Trunk Plugin API
--------------------------------------------------------+-------------------
 Reporter:  darkdragon                                  |        Owner:  anonymous
     Type:  enhancement                                 |       Status:  new      
 Priority:  normal                                      |    Milestone:  2.5      
Component:  Optimization                                |      Version:  2.4      
 Severity:  normal                                      |   Resolution:           
 Keywords:  plugins.php phpdoc has-patch needs-testing  |  
--------------------------------------------------------+-------------------
Changes (by darkdragon):

  * summary:  Preformance Tweaks for WordPress Trunk Plugin API, plugin.php
              => Preformance Tweaks for WordPress Trunk
              Plugin API

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:23:42 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:23:52 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Performance Tweaks for
 WordPress Trunk Plugin API
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.065057ef3070d813aff4318dc5b4224e@lists.automattic.com>

#5338: Performance Tweaks for WordPress Trunk Plugin API
--------------------------------------------------------+-------------------
 Reporter:  darkdragon                                  |        Owner:  anonymous
     Type:  enhancement                                 |       Status:  new      
 Priority:  normal                                      |    Milestone:  2.5      
Component:  Optimization                                |      Version:  2.4      
 Severity:  normal                                      |   Resolution:           
 Keywords:  plugins.php phpdoc has-patch needs-testing  |  
--------------------------------------------------------+-------------------
Changes (by darkdragon):

  * summary:  Preformance Tweaks for WordPress Trunk Plugin API =>
              Performance Tweaks for WordPress Trunk Plugin
              API

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 05:26:07 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 05:26:16 2007
Subject: [wp-trac] Re: [WordPress Trac] #5338: Performance Tweaks for
 WordPress Trunk Plugin API
In-Reply-To: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
References: <048.f87260690716bc3815e9088494a45190@lists.automattic.com>
Message-ID: <057.06e688d295b8e51f3762ceb5842bf20e@lists.automattic.com>

#5338: Performance Tweaks for WordPress Trunk Plugin API
--------------------------------------------------------+-------------------
 Reporter:  darkdragon                                  |        Owner:  anonymous
     Type:  enhancement                                 |       Status:  new      
 Priority:  normal                                      |    Milestone:  2.5      
Component:  Optimization                                |      Version:  2.4      
 Severity:  normal                                      |   Resolution:           
 Keywords:  plugins.php phpdoc has-patch needs-testing  |  
--------------------------------------------------------+-------------------
Comment (by darkdragon):

 Oh yeah, I use ksort instead of uksort to speed things up a bit (might be
 premature). I figure it is an edge case that plugin authors will use
 strings instead of numbers and anyway, it is unknown anyway based on that.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 08:52:46 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 08:52:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #5065: Unify User-Agent strings
In-Reply-To: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
References: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
Message-ID: <054.70caeef4f3238e4bc6197023f429e844@lists.automattic.com>

#5065: Unify User-Agent strings
------------------------------------------+---------------------------------
 Reporter:  docwhat                       |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.4      
Component:  General                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  privacy user-agent has-patch  |  
------------------------------------------+---------------------------------
Comment (by DD32):

 I'm thinking a better method might be to wrap all outgoing http requests
 into a WP function. Currently theres a fair few fsockopen() scattered
 around the place, and theres Snoopy too, What would be better is a
 function such as:

 {{{
 function wp_get_remote($url,$headers=false){
 ...
 $userAgent = apply_filters('useragent',get_the_useragent());
 ...
 fsockopen()...
 if(!$headers)
 return $html;
 else
 return array($html,$headers);
 }
 }}}
 (Similar to {{{wp_get_http_headers()}}})

 Just makes more sense than changing the user agents in all these different
 locations to me, Why change the code in so many places when it could all
 just be consolidated in one swoop?, It would also help in adding Global
 Proxy support in.

 (Probably new ticket material, infact, i swear there is one, i just cant
 find it).

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 09:05:35 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 09:05:46 2007
Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine
 byteorder on 64bit systems with php5.2.1
In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
Message-ID: <053.2879a051624e63030859c32448876f45@lists.automattic.com>

#3780: gettext fails to determine byteorder on 64bit systems with php5.2.1
---------------------------------------------+------------------------------
 Reporter:  abtime                           |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  normal                           |    Milestone:  2.4      
Component:  i18n                             |      Version:  2.2      
 Severity:  critical                         |   Resolution:           
 Keywords:  i18n has-patch 2nd-opition test  |  
---------------------------------------------+------------------------------
Comment (by nyuwec):

 Replying to [comment:21 nbachiyski]:
 > Could everybody, please, try the both patches and report if any is
 working.

 I have a gentoo linux on a 64 bit AMD processor, described in: #5356,
 fighting with the above described problem. PHP using PHP_INT_SIZE=8.

 Apply 3780.diff: FAILS.
 Apply gettext-64-without-bitwise-ops.diff: WORKS!

 As I can see the gettext-64-without-bitwise-ops.diff patches the gettext
 to the format described in: http://wordpress.org/support/topic/63038 That
 patch also works on both 64bit and on 32 bit systems I can test!

 If only the 3780.diff applied to a 32 bit system it still works, applying
 the gettext-64-without-bitwise-ops.diff: still works!

 So this code in the gettext.php (starting at line 105) works for me on
 both 32 and 64 bit systems:
 {{{
                 // Caching can be turned off
                 $this->enable_cache = $enable_cache;

                 // $MAGIC1 = (int)0x950412de; //bug in PHP 5.0.2, see
 https://savannah.nongnu.org/bugs/?func=detailitem&item_id=10565
                 $MAGIC1 = (int) - 1794895138;
                 // $MAGIC2 = (int)0xde120495; //bug
                 $MAGIC2 = (int) - 569244523;
                 // 64-bit fix
                 $MAGIC3 = (int) 2500072158;

                 $this->STREAM = $Reader;
                 $magic = $this->readint();
                 if ($magic == $MAGIC1 || $magic == $MAGIC3) { // to make
 sure it works for 64-bit platforms
                         $this->BYTEORDER = 0;
                 } elseif ($magic == ($MAGIC2 & 0xFFFFFFFF)) {
                         $this->BYTEORDER = 1;
                 } else {
                         $this->error = 1; // not MO file
                         return false;
                 }

 }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 09:08:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 09:08:17 2007
Subject: [wp-trac] Re: [WordPress Trac] #5356: gettext cannot parse mo files
 on 64bit systems
In-Reply-To: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
References: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
Message-ID: <053.530c9598aa4b66ee356e61af6577322b@lists.automattic.com>

#5356: gettext cannot parse mo files on 64bit systems
----------------------------+-----------------------------------------------
 Reporter:  nyuwec          |        Owner:  anonymous
     Type:  defect          |       Status:  closed   
 Priority:  normal          |    Milestone:  2.3.2    
Component:  i18n            |      Version:  2.3.1    
 Severity:  normal          |   Resolution:  duplicate
 Keywords:  gettext, 64bit  |  
----------------------------+-----------------------------------------------
Changes (by nyuwec):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 Replying to [comment:1 ryan]:
 > see #3780

 Thanks, my search was not good enough, my shame.

 That ticket describes the same problem, so I close this one.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 11:33:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 11:33:19 2007
Subject: [wp-trac] Re: [WordPress Trac] #5345: Post Pending problems
In-Reply-To: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
References: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
Message-ID: <057.c501507ec7dd503ae7a44b342c16b563@lists.automattic.com>

#5345: Post Pending problems
------------------------------------------+---------------------------------
 Reporter:  angelic007                    |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.4      
Component:  Administration                |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:           
 Keywords:  pending, write, content lost  |  
------------------------------------------+---------------------------------
Changes (by angelic007):

  * type:  defect => enhancement
  * milestone:  2.5 => 2.4

Comment:

 Replying to [comment:2 lloydbudd]:

 > It isn't expected for a article pending review to be at the top of the
 write page, , because that only currently lists drafts, but logged in as
 the Author (or the Admin) I do find it when I filter Status... Pending
 Review

 Yes' you're right.
 Anyway, in my humble opinion pending reviews should be more visible to
 admin/editors, because he/she could not see new articles for a long time
 since there aren't notifications about newly inserted contents. As for
 comments moderation, I think there should be a tab under "Manage" section
 (Manage pending articles or something like that)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 14:43:05 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 14:43:15 2007
Subject: [wp-trac] Re: [WordPress Trac] #4779: Proposal for HTTP POST and
	REQUEST API
In-Reply-To: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
References: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
Message-ID: <057.395205b85d6839125147dfcaee9fd6d3@lists.automattic.com>

#4779: Proposal for HTTP POST and REQUEST API
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:           
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by santosj):

 This should not have 2.4 milestone.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 14:57:02 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 14:57:13 2007
Subject: [wp-trac] Re: [WordPress Trac] #5358: Queried object on multiple
 tag query holds only first tag
In-Reply-To: <048.12a6d403eb7094d0e951218637f89c09@lists.automattic.com>
References: <048.12a6d403eb7094d0e951218637f89c09@lists.automattic.com>
Message-ID: <057.e8bdb143faf7eb6c64920751f849971b@lists.automattic.com>

#5358: Queried object on multiple tag query holds only first tag
---------------------------+------------------------------------------------
 Reporter:  Kafkaesqui     |        Owner:  anonymous
     Type:  defect         |       Status:  new      
 Priority:  normal         |    Milestone:  2.4      
Component:  General        |      Version:  2.3.1    
 Severity:  normal         |   Resolution:           
 Keywords:  tags wp_query  |  
---------------------------+------------------------------------------------
Comment (by ionfish):

 Might this question I posted on wp-hackers a while ago be related?

 http://comox.textdrive.com/pipermail/wp-hackers/2007-October/015706.html

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 15:00:44 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 15:00:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #4779: Proposal for HTTP POST and
	REQUEST API
In-Reply-To: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
References: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
Message-ID: <057.017c42488a84fc6124efbf886ae08262@lists.automattic.com>

#4779: Proposal for HTTP POST and REQUEST API
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:           
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by Nazgul):

 Replying to [comment:1 santosj]:
 > This should not have 2.4 milestone.
 Usually we fix/change things in trunk first (which corresponds with the
 current 2.4 milestone) and then backport it to previous releases if that's
 deemed necessary.

 So this issue may end up fixed in a maintenance release for 2.3.x, but for
 now it's first slated for 2.4.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 14:41:38 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 15:09:01 2007
Subject: [wp-trac] Re: [WordPress Trac] #5065: Unify User-Agent strings
In-Reply-To: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
References: <045.c035b5ac6e5d3385adbb9e917e236f98@lists.automattic.com>
Message-ID: <054.2e73fc557a65dcd4e271c42f1b8e7fd1@lists.automattic.com>

#5065: Unify User-Agent strings
------------------------------------------+---------------------------------
 Reporter:  docwhat                       |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.4      
Component:  General                       |      Version:           
 Severity:  normal                        |   Resolution:           
 Keywords:  privacy user-agent has-patch  |  
------------------------------------------+---------------------------------
Comment (by santosj):

 Yeah. Maybe #4779 is what you were looking for DD32?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 15:30:45 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 15:30:59 2007
Subject: [wp-trac] Re: [WordPress Trac] #4779: Proposal for HTTP POST and
	REQUEST API
In-Reply-To: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
References: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
Message-ID: <057.5a8303cb9a63364b81aeae65daaa05f1@lists.automattic.com>

#4779: Proposal for HTTP POST and REQUEST API
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:           
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by santosj):

 I was thinking more that it doesn't have a patch and is non-trival.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 15:58:04 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 15:58:26 2007
Subject: [wp-trac] Re: [WordPress Trac] #4779: Proposal for HTTP POST and
	REQUEST API
In-Reply-To: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
References: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
Message-ID: <057.70085ffa1dd151f0b2e70dbba3c82761@lists.automattic.com>

#4779: Proposal for HTTP POST and REQUEST API
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.4      
Component:  Optimization  |      Version:           
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Comment (by santosj):

 I'll probably bring it up on WP-Hackers and write up some code this
 weekend. I've been thinking about this ticket and the best way to go about
 it. I don't think it should be all in one function, but using classes
 might slow down something that should be made as quick as possible.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 16:27:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 16:27:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #5357: wxr import: don't load the
 whole file at once
In-Reply-To: <048.0bc4095bc51ef7c644845375b88181c2@lists.automattic.com>
References: <048.0bc4095bc51ef7c644845375b88181c2@lists.automattic.com>
Message-ID: <057.7e7b30b7a51ab78b3a43d163596c7f01@lists.automattic.com>

#5357: wxr import: don't load the whole file at once
-------------------------+--------------------------------------------------
 Reporter:  tellyworth   |        Owner:  anonymous
     Type:  enhancement  |       Status:  closed   
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:  fixed    
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 16:28:03 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 16:28:18 2007
Subject: [wp-trac] Re: [WordPress Trac] #5353: Extend EXIF parser to include
 GPS metadata keys
In-Reply-To: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
References: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
Message-ID: <065.9b691527575f81ec4d783618ff5b60b0@lists.automattic.com>

#5353: Extend EXIF parser to include GPS metadata keys
--------------------------------+-------------------------------------------
 Reporter:  remotesensingtools  |        Owner:  anonymous
     Type:  enhancement         |       Status:  closed   
 Priority:  normal              |    Milestone:           
Component:  General             |      Version:           
 Severity:  normal              |   Resolution:  wontfix  
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by lloydbudd):

  * status:  new => closed
  * resolution:  => wontfix
  * milestone:  2.4 =>

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 16:28:59 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 16:29:11 2007
Subject: [wp-trac] Re: [WordPress Trac] #5356: gettext cannot parse mo files
 on 64bit systems
In-Reply-To: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
References: <044.773c5a445f519a53abad8b2f57aa75ce@lists.automattic.com>
Message-ID: <053.a58d15cb57e91c4b07af57e05d2e0a11@lists.automattic.com>

#5356: gettext cannot parse mo files on 64bit systems
----------------------------+-----------------------------------------------
 Reporter:  nyuwec          |        Owner:  anonymous
     Type:  defect          |       Status:  closed   
 Priority:  normal          |    Milestone:           
Component:  i18n            |      Version:  2.3.1    
 Severity:  normal          |   Resolution:  duplicate
 Keywords:  gettext, 64bit  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.3.2 =>

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 16:44:27 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 16:44:38 2007
Subject: [wp-trac] [WordPress Trac] #5359: Auto save doesn't save tags
Message-ID: <043.03691dcc4f532c7c6f27d38d4dcdc280@lists.automattic.com>

#5359: Auto save doesn't save tags
----------------------------+-----------------------------------------------
 Reporter:  chmac           |       Owner:  anonymous
     Type:  defect          |      Status:  new      
 Priority:  normal          |   Milestone:  2.5      
Component:  Administration  |     Version:           
 Severity:  normal          |    Keywords:           
----------------------------+-----------------------------------------------
 I've just noticed (and tested) that the auto-save feature doesn't save
 tags. It saves the other aspects of a post (I haven't verified how much)
 but not the tags. I'll try to look at the code over the next few days and
 add a patch to fix it.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 17:05:43 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 17:05:53 2007
Subject: [wp-trac] Re: [WordPress Trac] #4642: Enhanced wp-mail.php
In-Reply-To: <045.0c2093c9b5d1e7708b22e8b564a9895b@lists.automattic.com>
References: <045.0c2093c9b5d1e7708b22e8b564a9895b@lists.automattic.com>
Message-ID: <054.3c4d62096f0b77bac305b43902a60003@lists.automattic.com>

#4642: Enhanced wp-mail.php
------------------------------+---------------------------------------------
 Reporter:  lexhair           |        Owner:  ryan
     Type:  enhancement       |       Status:  new 
 Priority:  normal            |    Milestone:  2.4 
Component:  Administration    |      Version:  2.3 
 Severity:  normal            |   Resolution:      
 Keywords:  has-patch tested  |  
------------------------------+---------------------------------------------
Changes (by ryan):

  * owner:  Bobcat => ryan

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 21:00:07 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 21:00:17 2007
Subject: [wp-trac] [WordPress Trac] #5360: Comment editing problem
Message-ID: <043.24f9155d6522989c09235fca9cb7e144@lists.automattic.com>

#5360: Comment editing problem
---------------------+------------------------------------------------------
 Reporter:  neoen    |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.3.2    
Component:  General  |     Version:  2.3.1    
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 I was logged as admin and browsing my blog.
 As admin I added comment (reply) to my post
 (http://www.domain.com/category/post-title).
 New comment was added successfully (http://www.domain.com/category/post-
 title#comment-164).
 I wanted to edit it once again, I was automatically redirected to admin
 comment editing page then I edited this comment and in the end I was
 automatically redirected to strange duplicate address
 (http://www.domain.com/category/post-title#comment-164#comment-164).

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 21:53:30 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 21:53:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #5316: Extend options.php to allow
 deletion, Viewing of Serialized, And grouping options
In-Reply-To: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
References: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
Message-ID: <051.4ff40fe7ce995db62e6ed780bda135a2@lists.automattic.com>

#5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping
options
--------------------------------------------+-------------------------------
 Reporter:  DD32                            |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.4      
Component:  Administration                  |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  has-patch options dev-feedback  |  
--------------------------------------------+-------------------------------
Changes (by johnbillion):

  * keywords:  has-patch options => has-patch options dev-feedback

Comment:

 I really, really like this. Very convenient to be able to delete options
 from here (handy for plugin testing etc) and the grouping by prefix is
 very sexy.

 I can see no reason for this going into core, as because of the relative
 obscurity of this options page, it won't affect the majority of people who
 use WordPress, and I'm sure the people who do use this options page from
 time to time will be in favour of these nice changes.

 As its main aim is plugin developers (correct me if I'm wrong), it could
 just as effectively remain as a plugin though, so I'll give it a +0.75 for
 core.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 21:54:58 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 21:55:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #5316: Extend options.php to allow
 deletion, Viewing of Serialized, And grouping options
In-Reply-To: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
References: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
Message-ID: <051.7908c8333a4547d8b62bbafa66d17504@lists.automattic.com>

#5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping
options
--------------------------------------------+-------------------------------
 Reporter:  DD32                            |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.4      
Component:  Administration                  |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  has-patch options dev-feedback  |  
--------------------------------------------+-------------------------------
Comment (by johnbillion):

 Oh also, it would be ace to be able to edit the serialized data. Can't
 imagine that would be too easy to do though.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 22:10:48 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 22:10:57 2007
Subject: [wp-trac] Re: [WordPress Trac] #5316: Extend options.php to allow
 deletion, Viewing of Serialized, And grouping options
In-Reply-To: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
References: <042.6de2ef824eed92866058fae1e4f273af@lists.automattic.com>
Message-ID: <051.76237603b0433ec94847bad51aba15ae@lists.automattic.com>

#5316: Extend options.php to allow deletion, Viewing of Serialized, And grouping
options
--------------------------------------------+-------------------------------
 Reporter:  DD32                            |        Owner:  anonymous
     Type:  enhancement                     |       Status:  new      
 Priority:  normal                          |    Milestone:  2.4      
Component:  Administration                  |      Version:  2.4      
 Severity:  normal                          |   Resolution:           
 Keywords:  has-patch options dev-feedback  |  
--------------------------------------------+-------------------------------
Comment (by DD32):

 Editing serialized data was suggested on wp-hackers, And i've got a idea
 in my mind for how to achieve that thanks to some suggestions. (Well,
 Editing at least for Serialised Arrays, Objects are a bit harder).

 It could effectivly stay as a plugin, which is why i wrapped it up into a
 plugin for this ticket, Since the options page is rather obscure, it
 doesnt affect many users, But most of these are changes which are useful
 to most people who use the options page(for whatever reason), I know some
 people who have a couple of thousand options in their WP installs (from
 playing with plugins over the years) - To them, the ability to delete a
 group of options from a plugin they no longer use would be great.

 Its that reason why i thought as a core feature, It doesnt affect many
 people, But the options page IS there, Why not allow more control over the
 options for people who do tinker with their WP installs? (Thats more than
 just Plugin Developers, Allthough Devs are the main target for these
 changes)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 22:48:45 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 22:48:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #4779: Proposal for HTTP POST and
	REQUEST API
In-Reply-To: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
References: <048.62e284ae6bba224a16f6c118c5b49b6c@lists.automattic.com>
Message-ID: <057.2dcb19c761fe1a50814eccf8c70f2dd6@lists.automattic.com>

#4779: Proposal for HTTP POST and REQUEST API
--------------------------+-------------------------------------------------
 Reporter:  darkdragon    |        Owner:  anonymous
     Type:  enhancement   |       Status:  new      
 Priority:  normal        |    Milestone:  2.5      
Component:  Optimization  |      Version:           
 Severity:  normal        |   Resolution:           
 Keywords:                |  
--------------------------+-------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 22:56:41 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 22:56:51 2007
Subject: [wp-trac] Re: [WordPress Trac] #5345: Post Pending problems
In-Reply-To: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
References: <048.031a791b2060d1d3a00b3b23dd589d5b@lists.automattic.com>
Message-ID: <057.239f7336daf5941501011cb4293181e4@lists.automattic.com>

#5345: Post Pending problems
------------------------------------------+---------------------------------
 Reporter:  angelic007                    |        Owner:  anonymous
     Type:  enhancement                   |       Status:  closed   
 Priority:  normal                        |    Milestone:           
Component:  Administration                |      Version:  2.3.1    
 Severity:  normal                        |   Resolution:  invalid  
 Keywords:  pending, write, content lost  |  
------------------------------------------+---------------------------------
Changes (by lloydbudd):

  * status:  new => closed
  * resolution:  => invalid
  * milestone:  2.4 =>

Comment:

 Closing then as invalid, b/c the current described issue is quite
 different from the original problem that sounded like data loss. The
 dashboard experience is in the process of being worked on, so if you are
 still seeing the issue after 2.4 is released please do open a ticket.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 23:02:41 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 23:02:50 2007
Subject: [wp-trac] Re: [WordPress Trac] #5360: Comment editing problem
In-Reply-To: <043.24f9155d6522989c09235fca9cb7e144@lists.automattic.com>
References: <043.24f9155d6522989c09235fca9cb7e144@lists.automattic.com>
Message-ID: <052.3015cf55b5dc69f585719a821a8e7642@lists.automattic.com>

#5360: Comment editing problem
---------------------+------------------------------------------------------
 Reporter:  neoen    |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:  2.3.1    
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.3.2 => 2.5

Comment:

 Coudn't duplicate this issue on trunk r6336, I'm guessing it relates to
 your less common permalink structure.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 23:29:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 23:29:59 2007
Subject: [wp-trac] Re: [WordPress Trac] #5360: Comment editing problem
In-Reply-To: <043.24f9155d6522989c09235fca9cb7e144@lists.automattic.com>
References: <043.24f9155d6522989c09235fca9cb7e144@lists.automattic.com>
Message-ID: <052.e9dc356a0a5e1ce47a979a6a2d6844c0@lists.automattic.com>

#5360: Comment editing problem
---------------------+------------------------------------------------------
 Reporter:  neoen    |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:  2.3.1    
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by Bobcat):

 I see this problem frequently in 2.3.1 (and previous versions).  I saw it
 with one of the default permalink options.  I'm using the veryplaintxt
 theme, if that matters.  The problem is annoying enough that I wrote a
 plugin filter to strip-out the extra anchor name from the end of the URL.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Thu Nov 15 23:40:58 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Thu Nov 15 23:41:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #5352: register_sidebars does not
 handle names or multiple calls correctly
In-Reply-To: <044.aa464416be1d1e75468156eed763c741@lists.automattic.com>
References: <044.aa464416be1d1e75468156eed763c741@lists.automattic.com>
Message-ID: <053.03c22af2accc4477bad3ad08515fd17d@lists.automattic.com>

#5352: register_sidebars does not handle names or multiple calls correctly
---------------------+------------------------------------------------------
 Reporter:  watson   |        Owner:  ryan 
     Type:  defect   |       Status:  new  
 Priority:  normal   |    Milestone:  2.5  
Component:  General  |      Version:  2.3.1
 Severity:  normal   |   Resolution:       
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by ryan):

  * owner:  anonymous => ryan

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 01:33:39 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 01:33:50 2007
Subject: [wp-trac] [WordPress Trac] #5361: Deleting a set front page should
 then display posts on front page
Message-ID: <044.c8edfb4b3f4d88debaaccfa24d0f9d67@lists.automattic.com>

#5361: Deleting a set front page should then display posts on front page
---------------------+------------------------------------------------------
 Reporter:  hailin   |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.5      
Component:  General  |     Version:           
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 Create a new page.

 Go to Options > reading and set that page as the front page.

 Now delete that new page

 Front of the blog goes blank.

 Expected behaviour: It defaults back to Posts.

 ============================================
 Hailin:
 The root cause is the following: Suppose option show_on_front is
 configured to "page", and page_on_front is set to a specific page_id,
 and/or page_for_posts is set to another page_id.

 Then the user deletes a page from Manage=>Page, which happens to be the
 configured page_on_front. Then the page is gone, but those options still
 hold that deleted page_id. That cause the reported problem.

 The fix is that when we delete a page, we check to see whether the page is
 used in any of those options. If yes, we adjust them as well.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 02:21:03 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 02:24:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #5361: Deleting a set front page
 should then display posts on front page
In-Reply-To: <044.c8edfb4b3f4d88debaaccfa24d0f9d67@lists.automattic.com>
References: <044.c8edfb4b3f4d88debaaccfa24d0f9d67@lists.automattic.com>
Message-ID: <053.bec56be48967f63724e39a55b09c6c87@lists.automattic.com>

#5361: Deleting a set front page should then display posts on front page
-----------------------+----------------------------------------------------
 Reporter:  hailin     |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  General    |      Version:  2.4      
 Severity:  normal     |   Resolution:           
 Keywords:  has-patch  |  
-----------------------+----------------------------------------------------
Changes (by lloydbudd):

  * keywords:  => has-patch
  * version:  => 2.4
  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 09:55:29 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 09:55:38 2007
Subject: [wp-trac] [WordPress Trac] #5362: WordPress Should Not Check
 Intra-Site Permalinks for Spam
Message-ID: <050.0169660fcc1ea764db65bf49ca01f45a@lists.automattic.com>

#5362: WordPress Should Not Check Intra-Site Permalinks for Spam
--------------------------+-------------------------------------------------
 Reporter:  ComputerGuru  |       Owner:  anonymous         
     Type:  defect        |      Status:  new               
 Priority:  normal        |   Milestone:  2.3.2             
Component:  General       |     Version:  2.3.1             
 Severity:  normal        |    Keywords:  pingback trackback
--------------------------+-------------------------------------------------
 WordPress should automatically add pingbacks and trackbacks from the same
 blog without any spam checking.

 Posted to WP-Hackers, haven't heard from anyone as to whether this is by-
 design or not.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 16:02:23 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 16:02:31 2007
Subject: [wp-trac] Re: [WordPress Trac] #5362: WordPress Should Not Check
 Intra-Site Permalinks for Spam
In-Reply-To: <050.0169660fcc1ea764db65bf49ca01f45a@lists.automattic.com>
References: <050.0169660fcc1ea764db65bf49ca01f45a@lists.automattic.com>
Message-ID: <059.e8194eb3d0d7deaacf1ca2c6f53b5929@lists.automattic.com>

#5362: WordPress Should Not Check Intra-Site Permalinks for Spam
--------------------------------+-------------------------------------------
 Reporter:  ComputerGuru        |        Owner:  matt 
     Type:  defect              |       Status:  new  
 Priority:  normal              |    Milestone:  2.5  
Component:  General             |      Version:  2.3.1
 Severity:  normal              |   Resolution:       
 Keywords:  pingback trackback  |  
--------------------------------+-------------------------------------------
Changes (by lloydbudd):

  * owner:  anonymous => matt
  * milestone:  2.3.2 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 16:59:13 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 16:59:21 2007
Subject: [wp-trac] Re: [WordPress Trac] #5353: Extend EXIF parser to include
 GPS metadata keys
In-Reply-To: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
References: <056.0b9e9caa37b0cc3b86fbad324c6e2002@lists.automattic.com>
Message-ID: <065.6f28f550a35661962547a32b1b743b90@lists.automattic.com>

#5353: Extend EXIF parser to include GPS metadata keys
--------------------------------+-------------------------------------------
 Reporter:  remotesensingtools  |        Owner:  anonymous
     Type:  enhancement         |       Status:  closed   
 Priority:  normal              |    Milestone:           
Component:  General             |      Version:           
 Severity:  normal              |   Resolution:  wontfix  
 Keywords:                      |  
--------------------------------+-------------------------------------------
Comment (by remotesensingtools):

 I would contest this thinking, as GPS metadata is becoming intrinsic in
 the practicality of geo-aware position of images and visualization
 (inherent to the reality of the image taken, if metadata coordinates
 exist). To not provide the entirety of what's represented in the metadata
 of an image, is to cut-off the possibilities of developments for future
 development of plug-ins that can or will use that metadata. (You'd be
 making it far easier for plug-in developers to create their own methods
 for using said metadata, making it scalable for all developers.)

 Otherwise, by taking the approach you suggest -- would force two chains of
 metadata sets, limiting methodologies in content and visualization,
 forcing dependencies on more than one plugin, as well as creating overhead
 by applying an additional data-chain and plugins.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 17:17:50 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 17:18:01 2007
Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine
 byteorder on 64bit systems with php5.2.1
In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
Message-ID: <053.a1a093def313f1e8d04ecb9ae97e7987@lists.automattic.com>

#3780: gettext fails to determine byteorder on 64bit systems with php5.2.1
---------------------------------------------+------------------------------
 Reporter:  abtime                           |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  normal                           |    Milestone:  2.4      
Component:  i18n                             |      Version:  2.2      
 Severity:  critical                         |   Resolution:           
 Keywords:  i18n has-patch 2nd-opition test  |  
---------------------------------------------+------------------------------
Comment (by nyuwec):

 To my previous comment, here is a working version of the patched
 gettext.php on a 64bit AMD processor powered Gentoo Linux (jam
 2.6.18-gentoo-r6) server with Apache2 and PHP 5.2.4:
 http://koles.hu/turakraft/

 It uses the hungarian language file, so it is mostly unreadable to the
 most of the world population. :)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 17:17:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 17:18:02 2007
Subject: [wp-trac] Re: [WordPress Trac] #4802: Author can moderate comments
 on their own posts
In-Reply-To: <046.e4844cabed2d0264de190c7812e2d937@lists.automattic.com>
References: <046.e4844cabed2d0264de190c7812e2d937@lists.automattic.com>
Message-ID: <055.17ca134aa66366ff98263bb5e407878a@lists.automattic.com>

#4802: Author can moderate comments on their own posts
----------------------------+-----------------------------------------------
 Reporter:  alakhnor        |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.4      
Component:  Administration  |      Version:  2.2.2    
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by jeremyclarke):

 * cc: jeremyclarke (added)

Comment:

 I think intoxination is on the right path, however based on the existing
 roles, I think that the smoothest and least confusing path would be to
 have the new role be "moderate_others_comments" in the same way that posts
 have "edit_posts" and "edit_others_posts".

 In this scenario, I think it would make sense to have the default roles as
 follows:

 Admin/Editor: moderate_comments AND moderate_others_comments
 Author: moderate_comments (only on their posts)
 Contributor: [nothing, they wait for editors/admins to approve their
 comments]

 This would follow elegantly with Contributor's inability to publish their
 own posts while authors can publish theirs but can't do things like edit
 the posts of other authors.

 I think this change is important because on large sites with lots of
 authors it is a burnout to follow all conversations, and if an author is
 trusted to publish posts independently they are likely trustworthy to sort
 comments on their own posts. This would also of course be changeable
 through the role manager plugin if someone wanted a different setup.

 The big problem I think is the number of places that would need to be
 patched to make this happen, I'm not sure how the comment moderation admin
 views work but it might take awhile to adapt them for this subtle
 difference.

 If nothing else though, having the link to accept a comment present in
 emails and allowing authors to accept comments that way would be a big
 step. I admin a large site and we moderate all comments before they
 appear, so distributing it thinner would really help.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 19:32:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 20:02:29 2007
Subject: [wp-trac] [WordPress Trac] #5363: Canonical redirection broken on
	https://
Message-ID: <048.32097f3864b349536c8ebc27a11f8448@lists.automattic.com>

#5363: Canonical redirection broken on https://
------------------------+---------------------------------------------------
 Reporter:  truthmedia  |       Owner:  anonymous      
     Type:  defect      |      Status:  new            
 Priority:  normal      |   Milestone:                 
Component:  General     |     Version:  2.3.1          
 Severity:  normal      |    Keywords:  https canonical
------------------------+---------------------------------------------------
 On any of our websites running WordPress 2.3 the server gets stuck in an
 infinite redirection loop when using the https:// protocol.

 https://truthmedia.com
 https://sandbox3.wearetm.com

 When disabling the canonical redirection it works fine.

 Both are hosted on MediaTemple, I do not know what type of server they are
 running, or what redirects they are using, so I cannot tell you what is
 conflicting.

 I have opened a support request asking if they can give me any more info
 on what is happening behind the scenes.

 (If you check and https://truthmedia.com seems to work, that is because I
 have disabled the canonical redirection, I will leave
 https://sandbox3.wearetm.com as is for testing though)

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Fri Nov 16 20:34:35 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Fri Nov 16 20:34:48 2007
Subject: [wp-trac] Re: [WordPress Trac] #5363: Canonical redirection broken
	on https://
In-Reply-To: <048.32097f3864b349536c8ebc27a11f8448@lists.automattic.com>
References: <048.32097f3864b349536c8ebc27a11f8448@lists.automattic.com>
Message-ID: <057.0e54d433fcc1c331646ba8f7175ae5c7@lists.automattic.com>

#5363: Canonical redirection broken on https://
-----------------------------+----------------------------------------------
 Reporter:  truthmedia       |        Owner:  markjaquith
     Type:  defect           |       Status:  new        
 Priority:  normal           |    Milestone:  2.4        
Component:  General          |      Version:  2.3.1      
 Severity:  normal           |   Resolution:             
 Keywords:  https canonical  |  
-----------------------------+----------------------------------------------
Changes (by lloydbudd):

  * owner:  anonymous => markjaquith
  * milestone:  => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 00:14:58 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 00:15:12 2007
Subject: [wp-trac] Re: [WordPress Trac] #3934: prev/next links and
	redirected domains
In-Reply-To: <052.7b404a6b657940988e2f37d091d79e7f@lists.automattic.com>
References: <052.7b404a6b657940988e2f37d091d79e7f@lists.automattic.com>
Message-ID: <061.65d1b8d431994dd344bb4d0d346e09fd@lists.automattic.com>

#3934: prev/next links and redirected domains
----------------------------+-----------------------------------------------
 Reporter:  davidmwilliams  |        Owner:  westi     
     Type:  defect          |       Status:  closed    
 Priority:  lowest          |    Milestone:            
Component:  General         |      Version:            
 Severity:  trivial         |   Resolution:  worksforme
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * status:  assigned => closed
  * resolution:  => worksforme
  * milestone:  2.4 =>

Comment:

 Replying to [comment:11 Nazgul]:
 > Is this still a problem after #3930 was fixed?

 No response from bug reporter, closing as works for me w/o verification.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 00:18:41 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 00:18:53 2007
Subject: [wp-trac] Re: [WordPress Trac] #4480: Using two 
    's in more
 text creates invalid markup
In-Reply-To: <050.f3fc3b469ed0d7e3d952ed8c8c858bbc@lists.automattic.com>
References: <050.f3fc3b469ed0d7e3d952ed8c8c858bbc@lists.automattic.com>
Message-ID: <059.b92e933f338927a967cb840a12b178a4@lists.automattic.com>

#4480: Using two 
    's in more text creates invalid markup
--------------------------+-------------------------------------------------
 Reporter:  huesforalice  |        Owner:  anonymous
     Type:  defect        |       Status:  new      
 Priority:  lowest        |    Milestone:  2.5      
Component:  Template      |      Version:  2.2      
 Severity:  minor         |   Resolution:           
 Keywords:  wpauto        |  
--------------------------+-------------------------------------------------
Changes (by lloydbudd):

  * keywords:  => wpauto
  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 00:24:24 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 00:24:37 2007
Subject: [wp-trac] Re: [WordPress Trac] #4491: Quoted text ending in number
 foils "smart" quotes
In-Reply-To: <052.1699a0a1f08e85db41832b90c817e643@lists.automattic.com>
References: <052.1699a0a1f08e85db41832b90c817e643@lists.automattic.com>
Message-ID: <061.a0062ef0eb0740f0be2c8574f606da94@lists.automattic.com>

#4491: Quoted text ending in number foils "smart" quotes
----------------------------+-----------------------------------------------
 Reporter:  cherylontheweb  |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  lowest          |    Milestone:  2.6      
Component:  Administration  |      Version:  2.2      
 Severity:  minor           |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.4 => 2.6

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 11:27:31 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 11:27:43 2007
Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document
 doesn't point to https collections
In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com>
References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com>
Message-ID: <052.9db6370605aa2426d74e01f2baf60ede@lists.automattic.com>

#5298: https atom service document doesn't point to https collections
-----------------------+----------------------------------------------------
 Reporter:  rubys      |        Owner:  westi 
     Type:  defect     |       Status:  closed
 Priority:  normal     |    Milestone:  2.4   
Component:  General    |      Version:  2.3.1 
 Severity:  normal     |   Resolution:  fixed 
 Keywords:  has-patch  |  
-----------------------+----------------------------------------------------
Comment (by westi):

 Didn't work for non-SSL :-( see [6340] for fix.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 12:17:27 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 12:17:39 2007
Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be
 used without including wp-settings.php
In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
Message-ID: <057.5ea3c81e292ef543bb81ac936c5c5161@lists.automattic.com>

#5276: Allow wp-config.php to be used without including wp-settings.php
--------------------------------------+-------------------------------------
 Reporter:  mastermind                |        Owner:  anonymous
     Type:  enhancement               |       Status:  new      
 Priority:  normal                    |    Milestone:  2.5      
Component:  General                   |      Version:  2.4      
 Severity:  normal                    |   Resolution:           
 Keywords:  wp-config.php standalone  |  
--------------------------------------+-------------------------------------
Comment (by mastermind):

 Replying to [comment:12 DD32]:
 > wp-login.php, wp-app.php, wp-atom.php just to name a few kick start WP
 by including wp-config.php. Once i realised others used it i havnt probed
 closer as i was after some direction from more seasoned developers.

 I see. But the cases you mention are then merely a matter of replacing
 calls to {{{wp-config.php}}} with calls to {{{wp-blog-header.php}}}.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 12:22:00 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 12:22:13 2007
Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be
 used without including wp-settings.php
In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
Message-ID: <057.acc274f876a91fd232372bf72eed5d27@lists.automattic.com>

#5276: Allow wp-config.php to be used without including wp-settings.php
--------------------------------------+-------------------------------------
 Reporter:  mastermind                |        Owner:  anonymous
     Type:  enhancement               |       Status:  new      
 Priority:  normal                    |    Milestone:  2.5      
Component:  General                   |      Version:  2.4      
 Severity:  normal                    |   Resolution:           
 Keywords:  wp-config.php standalone  |  
--------------------------------------+-------------------------------------
Comment (by Viper007Bond):

 That may work for internal files, but there are countless plugins and
 scripts that rely on including `wp-config.php` to kickstart WordPress. Not
 saying it'd be a bad thing if we changed it, just saying it'd be a
 breaker.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 12:39:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 12:40:04 2007
Subject: [wp-trac] [WordPress Trac] #5364: Cron not updated correctly when
 deleting a future post
Message-ID: <046.9c98020c835ba280a80151da19d7a737@lists.automattic.com>

#5364: Cron not updated correctly when deleting a future post
----------------------+-----------------------------------------------------
 Reporter:  develish  |       Owner:  anonymous                      
     Type:  defect    |      Status:  new                            
 Priority:  low       |   Milestone:  2.5                            
Component:  General   |     Version:  2.3.1                          
 Severity:  minor     |    Keywords:  cron delete post wp_delete_post
----------------------+-----------------------------------------------------
 Hi,

 my name is Mariano and this is my first bug report so please bear with me
 :D

 When I delete a future post using
 wp_delete_post($post->ID)
 it does not update the cron correctly.


 I use this code to actually manually delete and unschedule the future
 posts


 {{{
 $posts = $wpdb->get_results( "SELECT ID FROM $wpdb->posts where
 post_status = 'future';" );
 foreach ($posts as $post)
   {
     wp_clear_scheduled_hook( 'publish_future_post', $post->ID );
     wp_delete_post($post->ID)<
   }
 }}}



 Maybe a check if the post is of post_status future and then unscheduling
 it in the post deletion process would fix it.

 I was not able to find the unschedule in post.php -> wp_delete_post


 Thanks for consideration


 Mariano

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 17:58:28 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 17:58:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #5298: https atom service document
 doesn't point to https collections
In-Reply-To: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com>
References: <043.116cf70217b5b603829b72ec7fa2a8dd@lists.automattic.com>
Message-ID: <052.475cb574d04598a548820cb61e01efb6@lists.automattic.com>

#5298: https atom service document doesn't point to https collections
-----------------------+----------------------------------------------------
 Reporter:  rubys      |        Owner:  westi 
     Type:  defect     |       Status:  closed
 Priority:  normal     |    Milestone:  2.4   
Component:  General    |      Version:  2.3.1 
 Severity:  normal     |   Resolution:  fixed 
 Keywords:  has-patch  |  
-----------------------+----------------------------------------------------
Comment (by rubys):

 Replying to [comment:11 westi]:
 > Didn't work for non-SSL :-( see [6340] for fix.

 Good catch!  Thanks!

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sat Nov 17 19:57:28 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sat Nov 17 20:28:54 2007
Subject: [wp-trac] Re: [WordPress Trac] #5364: Cron not updated correctly
 when deleting a future post
In-Reply-To: <046.9c98020c835ba280a80151da19d7a737@lists.automattic.com>
References: <046.9c98020c835ba280a80151da19d7a737@lists.automattic.com>
Message-ID: <055.0e556efc207cb0e01fc4b8d41feae3eb@lists.automattic.com>

#5364: Cron not updated correctly when deleting a future post
---------------------------------------------+------------------------------
 Reporter:  develish                         |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  low                              |    Milestone:  2.5      
Component:  General                          |      Version:  2.3.1    
 Severity:  minor                            |   Resolution:           
 Keywords:  cron delete post wp_delete_post  |  
---------------------------------------------+------------------------------
Comment (by tellyworth):

 I've confirmed this in a unit test:

 {{{
 There was 1 failure:

 1) test_delete_future_post_cron(WPTestIncludesPost)
 Failed asserting that  is false.
 /home/zem/projects/wordpress/wordpress-tests/wp-
 testcase/test_includes_post.php:146
 /home/zem/projects/wordpress/wordpress-tests/wp-testlib/base.php:348
 /home/zem/projects/wordpress/wordpress-tests/wp-test.php:92
 }}}

 See test_delete_future_post_cron() in http://svn.automattic.com/wordpress-
 tests/wp-testcase/test_includes_post.php.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Sun Nov 18 10:05:51 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Sun Nov 18 10:06:03 2007
Subject: [wp-trac] Re: [WordPress Trac] #5276: Allow wp-config.php to be
 used without including wp-settings.php
In-Reply-To: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
References: <048.87bfd68531c072d8e2ddfa929c5d04ae@lists.automattic.com>
Message-ID: <057.07359a723f856d79e1e2963a0209e988@lists.automattic.com>

#5276: Allow wp-config.php to be used without including wp-settings.php
--------------------------------------+-------------------------------------
 Reporter:  mastermind                |        Owner:  anonymous
     Type:  enhancement               |       Status:  new      
 Priority:  normal                    |    Milestone:  2.5      
Component:  General                   |      Version:  2.4      
 Severity:  normal                    |   Resolution:           
 Keywords:  wp-config.php standalone  |  
--------------------------------------+-------------------------------------
Comment (by DD32):

 > But the cases you mention are then merely a matter of replacing calls
 ...

 True, Which was why i was asking which was the intended behaviour to be
 included.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 15:44:22 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 15:44:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #3686: index page gives 404 when
 using non-default permalinks
In-Reply-To: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com>
References: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com>
Message-ID: <053.0d3385437bc18aae51684cfe33348f2d@lists.automattic.com>

#3686: index page gives 404 when using non-default permalinks
----------------------------------------+-----------------------------------
 Reporter:  jamesw                      |        Owner:  markjaquith
     Type:  defect                      |       Status:  closed     
 Priority:  low                         |    Milestone:  2.4        
Component:  General                     |      Version:  2.1        
 Severity:  normal                      |   Resolution:  duplicate  
 Keywords:  permalinks pages 404 error  |  
----------------------------------------+-----------------------------------
Changes (by jamesw):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 Looking into this, it appears this problem is due to Squid, much like
 http://trac.wordpress.org/ticket/3820

 Perhaps someone of suita ble authority could merge the tickets?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 15:53:08 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 15:55:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #3686: index page gives 404 when
 using non-default permalinks
In-Reply-To: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com>
References: <044.0c764cc373876ee1b2b89bf320cd3e9e@lists.automattic.com>
Message-ID: <053.945926496d9c9cbc726fa6c15ed02f3d@lists.automattic.com>

#3686: index page gives 404 when using non-default permalinks
----------------------------------------+-----------------------------------
 Reporter:  jamesw                      |        Owner:  markjaquith
     Type:  defect                      |       Status:  closed     
 Priority:  low                         |    Milestone:             
Component:  General                     |      Version:  2.1        
 Severity:  normal                      |   Resolution:  duplicate  
 Keywords:  permalinks pages 404 error  |  
----------------------------------------+-----------------------------------
Changes (by Nazgul):

  * milestone:  2.4 =>

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 15:54:09 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 15:56:16 2007
Subject: [wp-trac] Re: [WordPress Trac] #3820: Squid in accelerator mode;
 Permalink "mod_rewrite" problem.
In-Reply-To: <050.5b660403c3c1c6b82df1d56fa1a03422@lists.automattic.com>
References: <050.5b660403c3c1c6b82df1d56fa1a03422@lists.automattic.com>
Message-ID: <059.2e796f437cb9cf528807e3208dad9868@lists.automattic.com>

#3820: Squid in accelerator mode; Permalink "mod_rewrite" problem.
-------------------------------+--------------------------------------------
 Reporter:  shanefroebel       |        Owner:  anonymous
     Type:  defect             |       Status:  new      
 Priority:  normal             |    Milestone:  2.5      
Component:  General            |      Version:  2.2      
 Severity:  normal             |   Resolution:           
 Keywords:  squid mod_rewrite  |  
-------------------------------+--------------------------------------------
Comment (by Nazgul):

 See also #3686.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 16:20:40 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 16:32:46 2007
Subject: [wp-trac] [WordPress Trac] #5365: Still getting cookie error
	messages
Message-ID: <046.9455e6bb79e0efffd0431bdf613c4862@lists.automattic.com>

#5365: Still getting cookie error messages
----------------------------+-----------------------------------------------
 Reporter:  MichaelH        |       Owner:  anonymous
     Type:  defect          |      Status:  new      
 Priority:  normal          |   Milestone:  2.3.2    
Component:  Administration  |     Version:  2.3.1    
 Severity:  normal          |    Keywords:           
----------------------------+-----------------------------------------------
 Still getting cookie error messages, even after upgrade to 2.3.1.
 WordPress is in sub-folder so the WordPress address (URL) is different
 than Blog address (URL).
 ----
 ERROR: WordPress requires Cookies but your browser does not support them
 or they are blocked.

 ERROR: The username field is empty.

 ERROR: The password field is empty.
 ----
 Also get this after logging out:

 ERROR: The username field is empty.

 ERROR: The password field is empty.

 Successfully logged you out.
 ----
 Apache version  1.3.37 (Unix)
 PHP version     4.4.7
 MySQL version   4.1.22-standard

 Also see http://wordpress.org/support/topic/144079 for a related report.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 18:17:12 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 18:17:24 2007
Subject: [wp-trac] [WordPress Trac] #5366: XMLRPC interface misinterprets
 mt_allow_comments value
Message-ID: <048.a4220894124fd5860d8c15d34de4c72e@lists.automattic.com>

#5366: XMLRPC interface misinterprets mt_allow_comments value
------------------------+---------------------------------------------------
 Reporter:  redsweater  |       Owner:  josephscott
     Type:  defect      |      Status:  new        
 Priority:  normal      |   Milestone:  2.5        
Component:  XML-RPC     |     Version:  2.3.1      
 Severity:  normal      |    Keywords:             
------------------------+---------------------------------------------------
 WordPress's XMLRPC interface makes an understandable mistake when
 interpreting the mt_allow_comments field.

 The field as described and used by MovableType and others is actually a
 ternary value with integer values meaning:

 0 - None - No comments allowed
 1 - Open - Comments can be read and write
 2 - Closed - Comments can be read but not written

 WordPress doesn't have a notion of "read-only comments" but it needs to do
 something accurate when the "2" (closed) value is passed to the XMLRPC
 interface.

 Right now what it does is fail to recognize 2 as a valid input, and
 defaults to the system default comment status.

 I believe it should map "2" -> "closed" so that the expected behavior of
 halting further comments is obtained by the user. The typical scenario now
 is that the blog defaults to "open" comments, so when a user of a client
 application specifies "closed" for the comment status, the server defaults
 it back to "open" ... exactly the opposite of the user's desire.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 19:06:50 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 19:07:02 2007
Subject: [wp-trac] [WordPress Trac] #5367: Wordpress cookie authentication
 vulnerability
Message-ID: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |       Owner:  anonymous
     Type:  defect     |      Status:  new      
 Priority:  normal     |   Milestone:           
Component:  Security   |     Version:  2.3.1    
 Severity:  normal     |    Keywords:           
-----------------------+----------------------------------------------------
 = Wordpress Cookie Authentication Vulnerability =

 Original release date: 2007-11-19[[BR]]
 Last revised: 2007-11-19[[BR]]
 Latest version: http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-
 cookie-auth.txt [[BR]]
 CVE ID: [[BR]]
 Source: Steven J. Murdoch http://www.cl.cam.ac.uk/users/sjm217/ [[BR]]


 == Systems Affected: ==

  Wordpress 1.5 -- 2.3.1 (including current version, as of 2007-11-19)


 == Overview: ==

  With read-only access to the Wordpress database, it is possible to
  generate a valid login cookie for any account, without resorting to a
  brute force attack. This allows a limited SQL injection vulnerability
  to be escalated into administrator access.

  This vulnerability is known to be actively exploited, hence the
  expedited public release.


 == I. Description ==

  For authentication, the Wordpress user database stores the MD5 hash
  of login passwords. A client is permitted access if they can present a
  password whose hash matches the stored one.

 {{{
  $ mysql -u wordpress -p wordpress
    Enter password: ********

    mysql> SELECT ID, user_login, user_pass FROM wp_users;
    +----+-------------+----------------------------------+
    | ID | user_login  | user_pass                        |
    +----+-------------+----------------------------------+
    |  1 | admin       | 4cee2c84f6de6d89a4db4f2894d14e38 |
    ...
 }}}

  Of course, entering your password after each action that requires
  authorization would be exceptionally tedious. So, after logging in,
  Wordpress presents the client with two cookies:

   wordpressuser_6092254072ca971c70b3ff302411aa5f=admin
 wordpresspass_6092254072ca971c70b3ff302411aa5f=813cadd8658c4776afbe5de8f304a684

  The cookie names contains the MD5 hash (6092...1a5f) of the blog URL.
  The value of wordpressuser_... is the login name, and the value of
  wordpresspass is the double-MD5 hash of the user password.

  Wordpress will permit access to a given user account if the
  wordpressuserpass_... cookie matches the hash of the specified user's
  wp_users.user_pass database entry.

  In other words, the database contains MD5(password) and the cookie
  contains MD5(MD5(password)). It is thus trivial to convert a database
  entry into an authentication cookie.

  At this point the vulnerability should be clear. If an attacker can
  gain read access to the wp_user table, for example due to a publicly
  visible backup or SQL injection vulnerability, a valid cookie can be
  generated for any account.

  This applies even if the user's password is sufficiently complex to
  resist brute force and rainbow table attacks. While it should be
  computationally infeasible to go backwards from MD5(password) to
  password, the attacker needs only to go forwards.

  The exploitation steps are therefore:
   1) Find the hash of the blog URL: Either just look at the URL, or
      create an account to get a user cookie
   2) Read the user_pass entry from wp_users table: Look for
      backups, perform SQL injection, etc...
   3) Set the following cookies:
       wordpressuser_=admin
       wordpresspass_=MD5(user_pass)
   4) You have admin access to the blog


 == II. Impact ==

  A remote attacker, with read access to the password database can gain
  administrator rights. This may be used in conjunction with an SQL
  injection attack, or after locating a database backup.

  An attacker who has alternatively compromised the database of one
  Wordpress blog can also gain access to any other whose users have the
  same password on both.


 == III. Solution ==

  No vendor patch is available.
  No timeline for a vendor patch has been announced.

  === Workarounds: ===

  - Protect the Wordpress database, and do not allow backups to be
    released.
  - Keep your Wordpress installation up to date. This should reduce the
    risk that your database will be compromised.
  - Do not share passwords across different sites.
  - If you suspect a database to be compromised, change all passwords
    to different ones. It is not adequate to change the passwords to
    the same ones, since Wordpress does not "salt" ![1] the password
    database.
  - Remove write permissions on the Wordpress files for the system
    account that the webserver runs as. This will disable the theme
    editor, but make it more difficult to escalate Wordpress
    administrator access into the capability to execute arbitrary code
  - Configure the webserver to not execute files in any directory
    writable by the webserver system account (e.g. the upload
    directory).

  === Potential fixes: ===

  The problem occurs because it is easy to go from the password hash
  in the database to a cookie (i.e the application of MD5 is the wrong
  way around). The simplest fix is to store MD5(MD5(password)) in the
  database, and make the cookie MD5(password). This still makes it
  infeasible to retrieve the password from a cookie, but means that it
  is also infeasible to generate a valid cookie from the database
  entry.

  However, there are other vulnerabilities in the Wordpress cookie and
  password handling, which should be resolved too:

   - Passwords are unsalted ![2], leaving them open to brute force, rainbow
     table and other attacks ![3].
   - It is impossible to revoke a cookie without changing the user's
     password.
   - Cookies do not contain an expiry time, so are always valid (until
     the user's password changes)
   - There ought to be an option to limit cookies to a particular
     IP address or range.


 == References: ==

   ![1] http://en.wikipedia.org/wiki/Salt_(cryptography) [[BR]]
   ![2] http://trac.wordpress.org/ticket/2394 [[BR]]
   ![3] http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-
 cracker/ [[BR]]


 == Timeline: ==

  2007-10-29: security@wordpress.org notified; no response [[BR]]
  2007-11-02: security@wordpress.org notified; Confirmation of active
 exploitation requested by Wordpress [[BR]]
  2007-11-02: Confirmation sent; no response [[BR]]
  2007-11-19: Advisory released to full-disclosure and !BugTraq [[BR]]

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 19:23:49 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 19:24:01 2007
Subject: [wp-trac] Re: [WordPress Trac] #4627: Link manager exploit?
In-Reply-To: <046.96072c2a35c2e121ba99fecf5edf8e6e@lists.automattic.com>
References: <046.96072c2a35c2e121ba99fecf5edf8e6e@lists.automattic.com>
Message-ID: <055.8a61d1c0e2317398b9bc355847869143@lists.automattic.com>

#4627: Link manager exploit?
----------------------+-----------------------------------------------------
 Reporter:  cbdilger  |        Owner:  pishmishy
     Type:  defect    |       Status:  reopened 
 Priority:  high      |    Milestone:  2.0.12   
Component:  Security  |      Version:  2.2      
 Severity:  normal    |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by sjmurdoch):

 An attacker used the vulnerability described in #5367 to post spam links
 on my blog. Could that be it?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 20:29:36 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 20:29:48 2007
Subject: [wp-trac] Re: [WordPress Trac] #5364: Cron not updated correctly
 when deleting a future post
In-Reply-To: <046.9c98020c835ba280a80151da19d7a737@lists.automattic.com>
References: <046.9c98020c835ba280a80151da19d7a737@lists.automattic.com>
Message-ID: <055.2cadc331ab5e9f5a5f0864b56ea06bad@lists.automattic.com>

#5364: Cron not updated correctly when deleting a future post
---------------------------------------------+------------------------------
 Reporter:  develish                         |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  low                              |    Milestone:  2.4      
Component:  General                          |      Version:  2.3.1    
 Severity:  minor                            |   Resolution:           
 Keywords:  cron delete post wp_delete_post  |  
---------------------------------------------+------------------------------
Changes (by lloydbudd):

  * milestone:  2.5 => 2.4

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 21:13:07 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 21:13:20 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.93fa04c98565159396b33200135f12b0@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by ryan):

  * milestone:  => 2.4

Comment:

 Would phpass [1] for salting and hashing passwords plus a two-way salted
 encryption (such as [2]) on cookies be good enough?  Are there more
 contemporary libraries to consider that are portable enough for WP's
 needs?

 [1] http://www.openwall.com/phpass/
 [2] http://www.tonymarston.net/php-mysql/encryption.html#2004-08-27

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 21:28:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 21:28:25 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.2c7c824456312df1217d3bc519bd3f79@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by sjmurdoch):

 This vulnerability been assigned the CVE candidate ID
 [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013
 CVE-2007-6013].

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 21:54:17 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 21:54:33 2007
Subject: [wp-trac] [WordPress Trac] #5368: It's not possible to replace the
 RSS parser (MagpieRSS) via a plugin
Message-ID: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>

#5368: It's not possible to replace the RSS parser (MagpieRSS) via a plugin
-------------------------+--------------------------------------------------
 Reporter:  johnbillion  |       Owner:  anonymous
     Type:  defect       |      Status:  new      
 Priority:  normal       |   Milestone:           
Component:  General      |     Version:  2.3.1    
 Severity:  normal       |    Keywords:  magpierss
-------------------------+--------------------------------------------------
 r5845 doesn't do as intended.

 The file `wp-includes/rss.php` is loaded before plugins are loaded,
 therefore a plugin isn't able to replace the `fetch_rss()` function (which
 was the intention of r5845) as it's already been declared in `wp-
 includes/rss.php`.

 Not sure what to do about this one aside from moving `fetch_rss()` into
 `wp-includes/pluggable.php`.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 22:27:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 22:28:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.0ff195e2ae10e29e31183239f640df99@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by sjmurdoch):

 * cc: sjmurdoch (added)

Comment:

 The phpass library looks like a reasonable basis for password hashing.

 That PHP encryption algorithm looks like something from the 19th century,
 and is almost certainly broken. Ignore it.

 Is there really nothing better than MD5 to use? For hashing SHA-1 is
 better and some proper symmetric block ciphers would also be useful.

 The scheme I was thinking of is something along the lines of storing
 salt,H(crypted salted password) in the database and in the cookie storing
 E(user id,crypted salted password,start time) and its HMAC; where H is the
 hash and E, HMAC are encryption and authentication under site-specific
 keys.

 This means that given the contents of the database, the attacker cannot
 create a valid cookie as you can't go from H(crypted salted password) to
 crypted salted password. Also, since the crypted salted password is
 encrypted it is infeasible to brute force the password given only a
 cookie. Setting a start time means that cookies can be expired and this
 timestamp can't be modified due to the HMAC.

 This is just an initial idea and more refinement and analysis are needed,
 but that's a rough outline.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Mon Nov 19 21:18:15 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Mon Nov 19 22:45:42 2007
Subject: [wp-trac] Re: [WordPress Trac] #5365: Still getting cookie error
	messages
In-Reply-To: <046.9455e6bb79e0efffd0431bdf613c4862@lists.automattic.com>
References: <046.9455e6bb79e0efffd0431bdf613c4862@lists.automattic.com>
Message-ID: <055.e36ac25071560e40f399a57aad57909f@lists.automattic.com>

#5365: Still getting cookie error messages
----------------------------+-----------------------------------------------
 Reporter:  MichaelH        |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.3.2    
Component:  Administration  |      Version:  2.3.1    
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Comment (by WCityMike):

 Please note that in thread marked
 http://wordpress.org/support/topic/144079, reporting user has WordPress
 install in main folder; WordPress address (URL) is same as Blog address
 (URL).

 Also user xknown seems to have offered a patch that successfully stops the
 error ...

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 00:10:57 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 00:11:09 2007
Subject: [wp-trac] Re: [WordPress Trac] #5368: It's not possible to replace
 the RSS parser (MagpieRSS) via a plugin
In-Reply-To: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
References: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
Message-ID: <058.847c136c73a4a289d2a59d871a9840d4@lists.automattic.com>

#5368: It's not possible to replace the RSS parser (MagpieRSS) via a plugin
-------------------------+--------------------------------------------------
 Reporter:  johnbillion  |        Owner:  anonymous
     Type:  defect       |       Status:  new      
 Priority:  normal       |    Milestone:  2.5      
Component:  General      |      Version:  2.3.1    
 Severity:  normal       |   Resolution:           
 Keywords:  magpierss    |  
-------------------------+--------------------------------------------------
Changes (by lloydbudd):

  * milestone:  => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 00:18:27 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 00:44:50 2007
Subject: [wp-trac] Re: [WordPress Trac] #5368: It's not possible to replace
 the RSS parser (MagpieRSS) via a plugin
In-Reply-To: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
References: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
Message-ID: <058.2274a2068ebeb13613a9c1fab92ef002@lists.automattic.com>

#5368: It's not possible to replace the RSS parser (MagpieRSS) via a plugin
-------------------------+--------------------------------------------------
 Reporter:  johnbillion  |        Owner:  anonymous
     Type:  defect       |       Status:  new      
 Priority:  normal       |    Milestone:  2.5      
Component:  General      |      Version:  2.3.1    
 Severity:  normal       |   Resolution:           
 Keywords:  magpierss    |  
-------------------------+--------------------------------------------------
Comment (by technosailor):

 On the flip side, I'm using a homemade plugin to replace magpie using the
 load_feed_engine hook perfectly fine...

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 01:04:43 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 01:04:56 2007
Subject: [wp-trac] Re: [WordPress Trac] #5368: It's not possible to replace
 the RSS parser (MagpieRSS) via a plugin
In-Reply-To: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
References: <049.b766b1a1b1b65a26486c6ef6ed630fc5@lists.automattic.com>
Message-ID: <058.1f6593cf28684491a4b53a39a3dd3348@lists.automattic.com>

#5368: It's not possible to replace the RSS parser (MagpieRSS) via a plugin
-------------------------+--------------------------------------------------
 Reporter:  johnbillion  |        Owner:  anonymous
     Type:  defect       |       Status:  closed   
 Priority:  normal       |    Milestone:           
Component:  General      |      Version:  2.3.1    
 Severity:  normal       |   Resolution:  invalid  
 Keywords:  magpierss    |  
-------------------------+--------------------------------------------------
Changes (by johnbillion):

  * status:  new => closed
  * resolution:  => invalid
  * milestone:  2.5 =>

Comment:

 Closing as invalid because you can in fact declare the functions in `wp-
 includes/rss.php` with a plugin by using the `load_feed_engine` hook. I
 was staring right at it but wasn't using it.

 Thanks technosailor!

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 01:07:39 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 01:07:49 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.b4a9cac5c20a80ef2dca58497f88b8c6@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by ryan):

 That scheme sounds good to me, but since we currently support PHP back to
 4.2 we have to be aware of portability problems.  I don't think we can
 count on sha1() or the hash module, for example.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 01:50:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 01:50:31 2007
Subject: [wp-trac] [WordPress Trac] #5369: jQuery should be used to fade
	alerts
Message-ID: <050.b83253b2d1b6020b581b2252c4267d5e@lists.automattic.com>

#5369: jQuery should be used to fade alerts
----------------------------+-----------------------------------------------
 Reporter:  JeremyVisser    |       Owner:  anonymous
     Type:  enhancement     |      Status:  new      
 Priority:  low             |   Milestone:  2.4      
Component:  Administration  |     Version:           
 Severity:  minor           |    Keywords:           
----------------------------+-----------------------------------------------
 jQuery has the ability to perform fades now, I believe. Doing fades with
 jQuery should simplify code, and would also give us the ability to drop
 {{{fat.js}}}.

 Additionally, FAT will only fade an alert if it contains an
 {{{id="something"}}}, not just {{{class="fade alert"}}}, which is a pain
 in the butt for debugging, IMO. jQuery doesn't suffer from that
 limitation.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 10:41:27 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 10:41:40 2007
Subject: [wp-trac] [WordPress Trac] #5370: No confirmation on deleting posts
 in Manage, Posts
Message-ID: <046.4996293e2e2d4e27538173153b9d0baf@lists.automattic.com>

#5370: No confirmation on deleting posts in Manage, Posts
----------------------+-----------------------------------------------------
 Reporter:  demetris  |       Owner:  anonymous
     Type:  defect    |      Status:  new      
 Priority:  normal    |   Milestone:  2.5      
Component:  General   |     Version:  2.3.1    
 Severity:  critical  |    Keywords:           
----------------------+-----------------------------------------------------
 Posts are deleted immediately in Manage, Posts, without any confirmation
 dialog.

 Tried with two different accounts, admin and editor.

 Tested on Windows XP SP2 with Firefox 3, Opera 9.5 and Internet Explorer
 6.

 I don't know what the previous behaviour was, before 2.3.1.

 Greetings,
 Demetris

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 10:59:39 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 10:59:55 2007
Subject: [wp-trac] Re: [WordPress Trac] #5087: WYSIWYG Insert/Edit Image
	button issues
In-Reply-To: <043.09108cc28a2411b7739978841d6745d9@lists.automattic.com>
References: <043.09108cc28a2411b7739978841d6745d9@lists.automattic.com>
Message-ID: <052.78b717d1f0f8913f95f624596a90f9b3@lists.automattic.com>

#5087: WYSIWYG Insert/Edit Image button issues
--------------------------------------------------------------------+-------
 Reporter:  bl968                                                   |        Owner:  anonymous
     Type:  defect                                                  |       Status:  new      
 Priority:  high                                                    |    Milestone:  2.3.2    
Component:  TinyMCE                                                 |      Version:  2.3      
 Severity:  critical                                                |   Resolution:           
 Keywords:  reporter-feedback needs-patch WYSIWYG image properties  |  
--------------------------------------------------------------------+-------
Comment (by mzeecedric):

 Is there any patch or hack to this yet?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 13:50:50 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 14:19:02 2007
Subject: [wp-trac] Re: [WordPress Trac] #5370: No confirmation on deleting
 posts in Manage, Posts
In-Reply-To: <046.4996293e2e2d4e27538173153b9d0baf@lists.automattic.com>
References: <046.4996293e2e2d4e27538173153b9d0baf@lists.automattic.com>
Message-ID: <055.16e57e5835c804dd6d33dfb47175b912@lists.automattic.com>

#5370: No confirmation on deleting posts in Manage, Posts
----------------------+-----------------------------------------------------
 Reporter:  demetris  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  General   |      Version:  2.3.1    
 Severity:  critical  |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by johnbillion):

 Demetris, thanks for the bug report, but I'm unable to reproduce this. I
 get a nice little confirmation dialog. Have you tried disabling all your
 plugins and trying again? A plugin may be interfering.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 14:47:02 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 14:47:16 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.05f4e7749fe08d3b0c53bff4911fcae0@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by santosj):

 If someone is still running PHP 4.2, they have even more security issues
 to worry about than this one. I would suggest not caring for them based on
 that fact, but since I'm not a security expert, I'll leave it at that.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 14:53:23 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 15:25:44 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.bd4645ba6a34e4d882175f3a2fc6355c@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-----------------------+----------------------------------------------------
 Reporter:  sjmurdoch  |        Owner:  anonymous
     Type:  defect     |       Status:  new      
 Priority:  normal     |    Milestone:  2.4      
Component:  Security   |      Version:  2.3.1    
 Severity:  normal     |   Resolution:           
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by santosj):

 Also, the fact that 4.3 totally eclipsed 4.2
 [http://www.nexen.net/chiffres_cles/phpversion/17756-php_stats_evolution_for_october_2007.php
 since 2005], and 4.2 stands at less than 5%.

 I'm just throwing this out there, but is it still worth it?

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 16:00:34 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 16:00:46 2007
Subject: [wp-trac] Re: [WordPress Trac] #5370: No confirmation on deleting
 posts in Manage, Posts
In-Reply-To: <046.4996293e2e2d4e27538173153b9d0baf@lists.automattic.com>
References: <046.4996293e2e2d4e27538173153b9d0baf@lists.automattic.com>
Message-ID: <055.c37684a2af6f4111be4eb8e6694e448b@lists.automattic.com>

#5370: No confirmation on deleting posts in Manage, Posts
----------------------+-----------------------------------------------------
 Reporter:  demetris  |        Owner:  anonymous
     Type:  defect    |       Status:  new      
 Priority:  normal    |    Milestone:  2.5      
Component:  General   |      Version:  2.3.1    
 Severity:  critical  |   Resolution:           
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by demetris):

 Thank you!

 I thought of the plugins just after submitting the "bug". :-)

 I just disabled all of them, I reverted to the default theme, and also re-
 enabled the visual editor, but I'm not seeing any difference. The problem
 persists.

 The blog is this: http://op111.net/

 It is a test site, mostly vanilla, and the only changes I can remember
 making are in index.php:

 {{{
 
 }}}

 and also chaning the name of Blogroll in the database, from Blogroll to
 Links.

 I'll look into it again later.

 Greetings,
 Demetris

 NOTE. The problem only appears when I click Delete in Manage, Posts, i.e.
 in: wp-admin/edit.php

 If I first click Edit (in Manage, Posts or in the post page) and then
 Delete, I DO get the confirmation dialog.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 16:26:32 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 16:26:43 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.7016b279ac8bea3785c04992330703bc@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  anonymous
     Type:  defect                   |       Status:  new      
 Priority:  normal                   |    Milestone:  2.4      
Component:  Security                 |      Version:  2.3.1    
 Severity:  normal                   |   Resolution:           
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Changes (by jhodgdon):

  * keywords:  => security, password, md5

Comment:

 There are some interesting comments on secure hashing on this page:
 http://us.php.net/sha1 ; lots of links to alternatives for old versions of
 PHP, though none of them looks all that great.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 16:32:20 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 16:32:40 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.25ab153ab1d96aa51f2cc019617bc378@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  anonymous
     Type:  defect                   |       Status:  new      
 Priority:  normal                   |    Milestone:  2.4      
Component:  Security                 |      Version:  2.3.1    
 Severity:  normal                   |   Resolution:           
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Comment (by sjmurdoch):

 In case I wasn't clear, I should point out that MD5 is '''not''' the
 problem here. Switching to SHA-1 will leave Wordpress vulnerable to
 precisely the same issues. Although MD5 is vulnerable to collisions from
 carefully crafted input, this is not an issue for Wordpress's use.

 I think the optimum solution would be to use an existing scheme, and
 preferably a well-audited library for handling authentication and cookie
 management. Is there really nothing out these which does the job. I'm not
 a PHP programmer, but it seems that what Wordpress needs is a very common
 requirement.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 16:37:12 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 16:37:27 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.4bee3e8dcf5a21ed88b26cc534509cbf@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  anonymous
     Type:  defect                   |       Status:  new      
 Priority:  normal                   |    Milestone:  2.4      
Component:  Security                 |      Version:  2.3.1    
 Severity:  normal                   |   Resolution:           
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Comment (by santosj):

 Question: Would not having the username and password in the cookie fix
 this and not break anything else?

 I'm not sure why sessions aren't used instead to store this information
 (always confused about this). Which you'll have another problem with
 session hijacking, but there are measures that can easily be used to
 correct that problem.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 17:04:26 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 17:04:38 2007
Subject: [wp-trac] Re: [WordPress Trac] #5308: continued cookie error after
 upgrade to 2.3.1
In-Reply-To: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com>
References: <052.3fcc8555e8279abfcbc42cd6050736c0@lists.automattic.com>
Message-ID: <061.dcaa98860adaaa7df16d7f04d56ac454@lists.automattic.com>

#5308: continued cookie error after upgrade to 2.3.1
----------------------------+-----------------------------------------------
 Reporter:  openlycreative  |        Owner:  anonymous
     Type:  defect          |       Status:  closed   
 Priority:  normal          |    Milestone:           
Component:  General         |      Version:  2.3.1    
 Severity:  normal          |   Resolution:  duplicate
 Keywords:  cookie error    |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * status:  new => closed
  * resolution:  => duplicate
  * milestone:  2.5 =>

Comment:

 Assuming this relates either to #5076 mentioned by pishmishy or #5365.
 Closing as duplicate.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 17:06:55 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 17:07:27 2007
Subject: [wp-trac] [WordPress Trac] #5371: Smart quotes broken when
	surrounding links
Message-ID: <044.a95582acaa61f926f88af0abc5477a54@lists.automattic.com>

#5371: Smart quotes broken when surrounding links
---------------------+------------------------------------------------------
 Reporter:  glesik   |       Owner:  anonymous                     
     Type:  defect   |      Status:  new                           
 Priority:  normal   |   Milestone:  2.3.2                         
Component:  General  |     Version:  2.3.1                         
 Severity:  normal   |    Keywords:  quotes smart magic fancy links
---------------------+------------------------------------------------------
 if I put a link in quotes, e.g.
 {{{
 "mysite"
 }}}
 WordPress doesn't put the proper 'curly' quote after the link text. So the
 result looks like ?mysite? instead of ?mysite?.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 18:49:46 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 18:50:00 2007
Subject: [wp-trac] Re: [WordPress Trac] #5365: Still getting cookie error
	messages
In-Reply-To: <046.9455e6bb79e0efffd0431bdf613c4862@lists.automattic.com>
References: <046.9455e6bb79e0efffd0431bdf613c4862@lists.automattic.com>
Message-ID: <055.97fe6a18500a2d9f4bb9b6b9006c77a2@lists.automattic.com>

#5365: Still getting cookie error messages
----------------------------+-----------------------------------------------
 Reporter:  MichaelH        |        Owner:  westi   
     Type:  defect          |       Status:  assigned
 Priority:  normal          |    Milestone:  2.4     
Component:  Administration  |      Version:  2.3.1   
 Severity:  normal          |   Resolution:          
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by westi):

  * owner:  anonymous => westi
  * status:  new => assigned
  * milestone:  2.3.2 => 2.4

Comment:

 I guess this issue is caused by a plugin but we still need to fix it in
 the core (2.4 first and then backport to branches/2.3).

 I have seen this with Ryan Duff's contact form plugin which sets up stuff
 in $_POST without checking for a POST request.

 Other plugins may do the same.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 21:41:36 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 21:41:50 2007
Subject: [wp-trac] [WordPress Trac] #5372: Wrong category on post insertion
Message-ID: <045.6b1ded814eaee83666c166829526d10c@lists.automattic.com>

#5372: Wrong category on post insertion
---------------------+------------------------------------------------------
 Reporter:  malaiac  |       Owner:  anonymous
     Type:  defect   |      Status:  new      
 Priority:  normal   |   Milestone:  2.5      
Component:  General  |     Version:           
 Severity:  normal   |    Keywords:           
---------------------+------------------------------------------------------
 in wp-includes/taxonomy.php

 function = wp_set_object_terms

 around lines 1013,1014

 

 bug : when $id is not an array, it resets $id to 1 (i can't figure why)...
 and the post is assigned to the wrong (1) category, instead of the legit
 category.

 Happens when the post category is new (has just been created)

 Found when doing a custom import

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 22:00:54 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 22:01:07 2007
Subject: [wp-trac] [WordPress Trac] #5373: wp_list_pages - set
 'hierarchical' to 0 on 'include'
Message-ID: <048.abffd7e80dc2d96d459372c217b5a596@lists.automattic.com>

#5373: wp_list_pages - set 'hierarchical' to 0 on 'include'
------------------------+---------------------------------------------------
 Reporter:  Kafkaesqui  |       Owner:  anonymous                               
     Type:  defect      |      Status:  new                                     
 Priority:  normal      |   Milestone:  2.3.2                                   
Component:  General     |     Version:  2.3.1                                   
 Severity:  normal      |    Keywords:  wp_list_pages include hierarchical child
------------------------+---------------------------------------------------
 Using wp_list_pages() with the 'include' argument, the included Page(s)
 list will not appear if they have been assigned a parent.

 I traced this down to the 'hierarchical'
 parameter, which is set to 1 by default. It should added to the "ignore"
 list of variables in the `if ( !empty($include) )`  statement under the
 get_pages() function (wp-includes/post.php).

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 22:06:44 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 22:09:30 2007
Subject: [wp-trac] Re: [WordPress Trac] #5373: wp_list_pages - set
 'hierarchical' to 0 on 'include'
In-Reply-To: <048.abffd7e80dc2d96d459372c217b5a596@lists.automattic.com>
References: <048.abffd7e80dc2d96d459372c217b5a596@lists.automattic.com>
Message-ID: <057.0abdb45307037cf15d4d2f1946b7aff8@lists.automattic.com>

#5373: wp_list_pages - set 'hierarchical' to 0 on 'include'
------------------------------------------------------+---------------------
 Reporter:  Kafkaesqui                                |        Owner:  anonymous
     Type:  defect                                    |       Status:  new      
 Priority:  normal                                    |    Milestone:  2.3.2    
Component:  General                                   |      Version:  2.3.1    
 Severity:  normal                                    |   Resolution:           
 Keywords:  wp_list_pages include hierarchical child  |  
------------------------------------------------------+---------------------
Comment (by Kafkaesqui):

 Real world ref:
 http://wordpress.org/support/topic/144403#post-651718

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 22:49:52 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 22:50:06 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.3e90e15225f44a9a2573453a9191ed90@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  anonymous
     Type:  defect                   |       Status:  new      
 Priority:  normal                   |    Milestone:  2.4      
Component:  Security                 |      Version:  2.3.1    
 Severity:  normal                   |   Resolution:           
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Comment (by dougal):

 On the one hand, this is yet another case of "Let's take some generic,
 lame, bad security scenario, slap the name 'WordPress' on it (for no
 apparent reason other than the fact that WP is popular), and release a
 security announcement!" As has already been noted, if an attacker already
 has read access to your database, then you've probably lost the battle,
 regardless of anything else.

 On the other hand, we could definitely stand to improve the security of
 the cookie authentication. Things are the way they are now to make it
 convenient for the user. But it's really hard to provide convenient
 persistent authentication in a secure fashion without some external method
 of security (e.g. SSL). We probably need to provide better support for SSL
 (when it's available), or lose the persistence in most cases. There might
 be situations where we can provide persistence more securely, but probably
 not in all server setups.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 23:10:43 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 23:10:57 2007
Subject: [wp-trac] Re: [WordPress Trac] #5369: jQuery should be used to fade
	alerts
In-Reply-To: <050.b83253b2d1b6020b581b2252c4267d5e@lists.automattic.com>
References: <050.b83253b2d1b6020b581b2252c4267d5e@lists.automattic.com>
Message-ID: <059.5f393186f6abc7890f46b60986f3e915@lists.automattic.com>

#5369: jQuery should be used to fade alerts
----------------------------+-----------------------------------------------
 Reporter:  JeremyVisser    |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  low             |    Milestone:  2.5      
Component:  Administration  |      Version:           
 Severity:  minor           |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by lloydbudd):

  * milestone:  2.4 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 23:11:58 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 23:12:13 2007
Subject: [wp-trac] Re: [WordPress Trac] #5371: Smart quotes broken when
 surrounding links
In-Reply-To: <044.a95582acaa61f926f88af0abc5477a54@lists.automattic.com>
References: <044.a95582acaa61f926f88af0abc5477a54@lists.automattic.com>
Message-ID: <053.41fcdd7cb82a5df0fa270a43254c22a1@lists.automattic.com>

#5371: Smart quotes broken when surrounding links
--------------------------------------------+-------------------------------
 Reporter:  glesik                          |        Owner:  anonymous
     Type:  defect                          |       Status:  new      
 Priority:  normal                          |    Milestone:  2.5      
Component:  General                         |      Version:  2.3.1    
 Severity:  normal                          |   Resolution:           
 Keywords:  quotes smart magic fancy links  |  
--------------------------------------------+-------------------------------
Changes (by lloydbudd):

  * milestone:  2.3.2 => 2.5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 23:18:13 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 23:18:29 2007
Subject: [wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie
 authentication vulnerability
In-Reply-To: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
References: <047.cba9789b5639156a3985846929f2ddb5@lists.automattic.com>
Message-ID: <056.75254a79557a4c81649707ebdc2d6fb8@lists.automattic.com>

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  anonymous
     Type:  defect                   |       Status:  new      
 Priority:  normal                   |    Milestone:  2.4      
Component:  Security                 |      Version:  2.3.1    
 Severity:  normal                   |   Resolution:           
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Comment (by sjmurdoch):

 @dougal

 I didn't pick !WordPress arbitrarily, or because it is popular, but rather
 because my !WordPress blog (and probably a large number of others) was
 hacked using precisely this vulnerability.

 And no, just because an attacker has '''had''' read access to your
 database does not mean you've lost the battle. Using security measures
 that have been standard since the 1970s (password hashing and salting), it
 is quite easy to recover from such compromises, by restoring the database.
 Then there is the well established principle of "defence in depth".

 There are a variety of ways an attacker could get read access to the
 database, while not being able to do anything more. For example, certain
 SQL injection flaws can only read but not modify tables, or the attacker
 could simply find a backup. Before I went public with this vulnerability,
 I trawled Google for people who had left database backups online and
 recommended that they remove the files.

 Regarding fixes, I think it is possible to improve the security without
 affecting user convenience at all. Salting passwords and hashing cookies
 in the right direction would be a good start. Protecting data on the wire
 (with SSL or otherwise) is nice, but a much less important issue than the
 one raised here and in #2394.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 23:21:10 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 23:21:24 2007
Subject: [wp-trac] Re: [WordPress Trac] #5372: Wrong category on post
	insertion
In-Reply-To: <045.6b1ded814eaee83666c166829526d10c@lists.automattic.com>
References: <045.6b1ded814eaee83666c166829526d10c@lists.automattic.com>
Message-ID: <054.dd3e3e0d2aa416f0f5d3105db6e2dcff@lists.automattic.com>

#5372: Wrong category on post insertion
---------------------+------------------------------------------------------
 Reporter:  malaiac  |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.5      
Component:  General  |      Version:           
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by ryan):

 Current trunk adds an is_wp_error() check on $id.

 http://trac.wordpress.org/browser/trunk/wp-includes/taxonomy.php#L1141

 2.3.1 lacks this check, which could explain the bad id.

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Tue Nov 20 23:59:05 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Tue Nov 20 23:59:21 2007
Subject: [wp-trac] Re: [WordPress Trac] #3780: gettext fails to determine
 byteorder on 64bit systems with php5.2.1
In-Reply-To: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
References: <044.273f33c6918120e95a3edfe616584dd1@lists.automattic.com>
Message-ID: <053.0d9234d44928f7f0bfd47150aa07f699@lists.automattic.com>

#3780: gettext fails to determine byteorder on 64bit systems with php5.2.1
---------------------------------------------+------------------------------
 Reporter:  abtime                           |        Owner:  anonymous
     Type:  defect                           |       Status:  new      
 Priority:  normal                           |    Milestone:  2.4      
Component:  i18n                             |      Version:  2.2      
 Severity:  critical                         |   Resolution:           
 Keywords:  i18n has-patch 2nd-opition test  |  
---------------------------------------------+------------------------------
Comment (by madsjensen):

 This works !!! thanks ... I have tested many other hacks but only this
 seems to works.

 Apache version  2.0.61
 PHP version     5.2.4
 MySQL version   5.0.45
 Architecture    amd64
 Operating system: FreeBSD

 Danish localization

 cheers mads


 Replying to [comment:23 nyuwec]:
 > Replying to [comment:21 nbachiyski]:
 > > Could everybody, please, try the both patches and report if any is
 working.
 >
 > I have a gentoo linux on a 64 bit AMD processor, described in: #5356,
 fighting with the above described problem. PHP using PHP_INT_SIZE=8.
 >
 > Apply 3780.diff: FAILS.
 > Apply gettext-64-without-bitwise-ops.diff: WORKS!
 >
 > As I can see the gettext-64-without-bitwise-ops.diff patches the gettext
 to the format described in: http://wordpress.org/support/topic/63038 That
 patch also works on both 64bit and on 32 bit systems I can test!
 >
 > If only the 3780.diff applied to a 32 bit system it still works,
 applying the gettext-64-without-bitwise-ops.diff: still works!
 >
 > So this code in the gettext.php (starting at line 105) works for me on
 both 32 and 64 bit systems:
 > {{{
 >               // Caching can be turned off
 >               $this->enable_cache = $enable_cache;
 >
 >               // $MAGIC1 = (int)0x950412de; //bug in PHP 5.0.2, see
 https://savannah.nongnu.org/bugs/?func=detailitem&item_id=10565
 >               $MAGIC1 = (int) - 1794895138;
 >               // $MAGIC2 = (int)0xde120495; //bug
 >               $MAGIC2 = (int) - 569244523;
 >               // 64-bit fix
 >               $MAGIC3 = (int) 2500072158;
 >
 >               $this->STREAM = $Reader;
 >               $magic = $this->readint();
 >               if ($magic == $MAGIC1 || $magic == $MAGIC3) { // to make
 sure it works for 64-bit platforms
 >                       $this->BYTEORDER = 0;
 >               } elseif ($magic == ($MAGIC2 & 0xFFFFFFFF)) {
 >                       $this->BYTEORDER = 1;
 >               } else {
 >                       $this->error = 1; // not MO file
 >                       return false;
 >               }
 >
 > }}}

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 21 00:28:11 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 21 00:30:08 2007
Subject: [wp-trac] Re: [WordPress Trac] #2394: Passwords are stored in an
 insecure un-salted form
In-Reply-To: <047.46593b43158f89062a94e54e14a09e41@lists.automattic.com>
References: <047.46593b43158f89062a94e54e14a09e41@lists.automattic.com>
Message-ID: <056.6040a0f9eed53e7415ef6ab39506cf80@lists.automattic.com>

#2394: Passwords are stored in an insecure un-salted form
-----------------------------------------+----------------------------------
 Reporter:  sjmurdoch                    |        Owner:  pishmishy
     Type:  defect                       |       Status:  assigned 
 Priority:  normal                       |    Milestone:  2.4      
Component:  Security                     |      Version:  2.0      
 Severity:  normal                       |   Resolution:           
 Keywords:  has-patch salt password md5  |  
-----------------------------------------+----------------------------------
Changes (by pishmishy):

  * keywords:  has-patch => has-patch salt password md5

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 21 01:51:19 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 21 01:51:33 2007
Subject: [wp-trac] Re: [WordPress Trac] #5369: jQuery should be used to fade
	alerts
In-Reply-To: <050.b83253b2d1b6020b581b2252c4267d5e@lists.automattic.com>
References: <050.b83253b2d1b6020b581b2252c4267d5e@lists.automattic.com>
Message-ID: <059.bf2bf7387245076c9a57d45d90031273@lists.automattic.com>

#5369: jQuery should be used to fade alerts
----------------------------+-----------------------------------------------
 Reporter:  JeremyVisser    |        Owner:  anonymous
     Type:  enhancement     |       Status:  new      
 Priority:  low             |    Milestone:  2.5      
Component:  Administration  |      Version:           
 Severity:  minor           |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Comment (by Viper007Bond):

 +1

-- 
Ticket URL: 
WordPress Trac 
WordPress blogging software
From wp-trac at lists.automattic.com  Wed Nov 21 02:40:40 2007
From: wp-trac at lists.automattic.com (WordPress Trac)
Date: Wed Nov 21 02:40:52 2007
Subject: [wp-trac] [WordPress Trac] #5374: "Write page/post" > "code"
 textarea is to right
Message-ID: <050.2f9ccc7b2a37e3e2be99f3273f312454@lists.automattic.com>

#5374: "Write page/post" >  "code" textarea is to right
--------------------------+-------------------------------------------------
 Reporter:  cacycleworks  |       Owner:  anonymous
     Type:  defect        |      Status:  new      
 Priority:  normal        |   Milestone:  2.5      
Component:  General       |     Version:  2.3.1    
 Severity:  minor         |    Keywords:           
--------------------------+-------------------------------------------------
 This seems similar to Ticket #s [http://trac.wordpress.org/ticket/3684
 3684] and [http://trac.wordpress.org/ticket/3540 3540] however it's not
 exactly like them.

 On the "Write page/post" the "code" textarea is far to the right of the
 center working pane, so that a portion gets cut off. The box's left edge
 is perfectly aligned to the end of the "code" tool buttons. I thought it
 was a touch odd with the out-of-box install, but the problem made the page
 unusable when I applied a theme.

 I'm certain my methodology goes against the WP coding style/ ethos, as I
 found a quick CSS 
     hack that changed the behavior in wp-includes
 /general-template.php ...

 ''original source:''
 {{{
 wp-includes/general-template.php
 906   
 907   
    \n");
 910   $the_editor_content = apply_filters('the_editor_content', $content);
 911
 912   printf($the_editor, $the_editor_content);
 913
 914   ?>
 915