ticket	time	author	field	oldvalue	newvalue
13110	14:51:30Z	markoheijnen	comment	2	"I didn't had revisions in my supports:
'supports' => array('title', 'editor', 'author', 'revisions')

So there need an change here.
Not autosave my post or no warning when there is one."
13229	08:23:19Z	markoheijnen	comment	1	"I did look at the code and was wondering why there are hard checks on if it is an page or an post.

Files that need to be change
/wp-admin/includes/template.php	find_posts_div	line 3287 - 3290	
/wp-admin/js/media.js		line 34-38
/wp-admin/admin-ajax.php	line 1256


I think the solution is to remove all the hard checks and work with an filter.
Add an variable or an supports option to register_post_type.
Also the message 'No posts found.' should change so posts will be the name of the post_type.
At admin-ajax you check if it allowed to do the action."
13229	21:28:01Z	markoheijnen	comment	3	Patch is ready. Do need to be reviewed. Not happy about my solution at template.php
13110	09:35:27Z	markoheijnen	comment	6	"I think if revision isn't used, autosave should work different. Now you got the same message if you would used it but the link is broken.

If it isn't used by the content type, the revision shouldn't be stored but I can see there should be a newer version when there is one.

Because if it should work the same the option better can removed. The way it works now is confusing."
13306	20:37:53Z	markoheijnen	comment	3	"One useraccount still sees an disabled theme. How do you explain that.
There is something wrong with the handling of themes.

If I create an new user then it is fine."
13306	21:24:03Z	markoheijnen	comment	5	"I did disabled it when I edit the site. The theme was not the current theme.

I expected that when I disable the theme at the super admin panel that the theme get disabled everywhere. That doesn't happen what I can understand somehow but I would love to get an message then which sites still can use the theme."
13229	17:09:45Z	markoheijnen	comment	7	"ryan. I will create an new patch. I still need to look how the add attachment works.
I think when it isn't supported it shouldn't add the image to the media library.


How I did it now it maybe should. This because it is now standard false. In case of standard true then I would say it shouldn't be in support."
13229	21:15:14Z	markoheijnen	comment	10	"Without _builtin you see Media (I think that is wrong). First I did only show_ui and that did do the trick. But I wasn't sure about if that is correct.

"
12821	14:22:04Z	markoheijnen	comment	27	"I looked at the patch and I noticed that the filter for get_pages is removed.
Removing this filter isn't handy since there are plugins that are using that filter.

If it is possible (have no clue) I would recommend to insert it with a deprecated notice."
15098	18:09:41Z	markoheijnen	comment	9	For setting the post thumbnail it probably would be better to use the core function set_post_thumbnail().
18548	20:49:46Z	markoheijnen	comment	11	"The thing what I miss is backward compatibility. Since all the themes still will use wp_title() it now will send twice the <title></title> tag.
"
18548	20:59:46Z	markoheijnen	comment	17	"Ah you are right about that.

Would love to see how Jane proposed it. That it gives you some default way to create the title or you can create custom way of creating the title."
18626	15:03:28Z	markoheijnen	comment	1	"Code sample of user_can_richedit that I use now.

{{{
function user_can_richedit() {
	global $wp_rich_edit, $pagenow, $is_iphone;

	if ( !isset( $wp_rich_edit) ) {
		if ( get_user_option( 'rich_editing' ) == 'true' &&
			( ( preg_match( '!AppleWebKit/(\d+)!', $_SERVER['HTTP_USER_AGENT'], $match ) && intval($match[1]) >= 420 ) ||
				!preg_match( '!opera[ /][2-8]|konqueror|safari!i', $_SERVER['HTTP_USER_AGENT'] ) ) &&
			!( $is_iphone && intval($match[1]) < 534 )
		) {
			$wp_rich_edit = true;
		} else {
			$wp_rich_edit = false;
		}
	}

	return apply_filters('user_can_richedit', $wp_rich_edit);
}
}}}"
18626	18:23:21Z	markoheijnen	comment	4	"You right about that. We can check with javascript for support but you can get false positives with it like on iOS4 and I believe also on Android 2.3.
Since some browsers have some kind of support for contentEditable but it isn't usefull for TineMCE."
18626	21:23:07Z	markoheijnen	comment	9	"All the browser detection in /wp-includes/vars.php is indeed little bit to much.

Writing functions or singleton with all the detection is probably the way to go. Not sure what the way to go is since PHP is our definition and with javascript the browser gives us the information. We only need to check if the browser doesn't lie about the functionality like with contentEditable support"
18626	23:06:33Z	markoheijnen	comment	13	"Sounds great. Current code can be implemented within the new global.

Not sure if plugins use the globals. I do know the core use them wrong like checking if is_iphone to do stuff what should be mobile global.
That is something for another ticket."
18808	21:11:22Z	markoheijnen	comment	3	"I also didn't knew but needed to overwrite it to send it to a page instead.
That is also why I left two line open in wp-login.php

Update the patch to always use network_site_url()"
19055	12:55:21Z	markoheijnen	comment	3	"Also similar with edit-comments.php. Since that completely rely on posts. When that is gone it will break. Same is with the dashboard widgets.

You almost want to make something which enables developer to have more control about accessing wp-admin files.
Maybe this is a little bit to much since most of it you can control with capabilities."
18158	07:30:29Z	markoheijnen	comment	3	"I was playing with it. I am not sure what the solution will be. The query now is pretty hard since it does a INNER JOIN on all meta keys/values. So a WHERE seems not to be possible.

How I see it there should be an join on the post_meta table and join on the meta key. Somehow that looks like an ugly solution to me since you need te keep track on the naming of it.
For a singular meta-query you can do only one join to the post_meta table I guess."
19055	21:12:06Z	markoheijnen	comment	9	"That is what I ment indeed. Didn't had the time to create a nice patch of it since I was at work.
I like the first patch more. If $_GET['post_type'] is used elsewhere it should be changed to $post_type if possible."
15386	21:03:10Z	markoheijnen	comment	13	"What does of means that it is private. This class is a brilliant asset a developer can use since you want the same look in your plugin as WordPress itself. 

Is the code most likely to change? Some information here can be handy for developers who want to use it."
19357	15:38:04Z	markoheijnen	comment	3	"I do need it on the edit page but only when a tab is selected. This due some possible large meta_boxes.
The reason I post it as a bug is due the possibility that in other rare cases this can happen."
12745	22:21:55Z	markoheijnen	comment	11	"I think there should be a real solution for this. If this was just a front-end issue it would be fine with me but it isn't.
When using it in the back-end it also creates the error. I know you can/should check if the theme supports it because you can show a warning to the user."
18242	10:58:34Z	markoheijnen	comment	8	In my opinion opinion this should be fix soon. This will break WordPress functionality since the url can't be access.
13461	00:40:28Z	markoheijnen	comment	6	"What is the status of this ticket? I did apply the patch at one site and it seems to work for the few images that it went wrong.
"
19673	21:59:41Z	markoheijnen	comment	2	To be honest the whole iPhone check should be replaced to a mobile check. Since a lot of the things also will apply for other OS's like Android. It seems that this code should apply to a certain device width.
19836	19:23:49Z	markoheijnen	comment	1	Update mine server also to 5.3.9 and I don't see this issue. Sounds more as a javascript issue since the rest is loaded.
18429	13:04:18Z	markoheijnen	comment	4	" - Should we have a default post_status or do we really need to return an error
 - Should we generate an error if page templates aren't supported
 - Should we generate an error on invalid comment status or ping status
 - Not sure about the implementation of post_more. Shouldn't the client handle this instead of the xml-rpc?
 - Shouldn't the checks after wp_insert_post not be before it. Sounds like it can give weird situation
 - Do we need the ""handle enclosures"" code in the end of the function. Shouldn't this be a separate function?"
18429	09:20:09Z	markoheijnen	comment	7	"I know mw_newPost looked a lot at your patch. With the patch I wrote I tried to make the code as simple as I found needed. To have a discussing about what needs to be checked on the client side and what on the XML-RPC side.

The reason I removed checks on page templates and hierarchical post is because I think the client should check for it.

I did discussed with westi about checking of post_parent. Reason that is removed is because post_parent doesn't have to be of the same post_type. Something that happens with media item. From that point I also removed checking if a post is hierarchical."
18429	00:20:03Z	markoheijnen	comment	8	Should look at the end of the 2 week cycle to ticket #17109 to maybe add the needed code.
18429	12:05:55Z	markoheijnen	comment	10	I will look into the taxonomy code today. It's now on id's. I'm not sure if names will work when the taxonomy is hierarchical. Since you can have the same name when it isn't on the same level.
18429	18:17:53Z	markoheijnen	comment	11	"For readability yet again whole the text

- Method now only can be used for new posts
- Terms now can be added with id or name. Name only works for non-hierarchical taxonomies to avoid confusion where there may be another child with the same name.
- When a term doesn't exists it will get added.
- There is now a hard check if the terms array have integers. Not sure why it is needed since xmlrpc already says the value is an integer"
18429	00:57:52Z	markoheijnen	comment	18	"The password can be given if you are a contributor. How I looked into it was that the user still can't post it so someone else need to publish it. wp backend behaviour should be  mimic indeed. So there should be an cap check over there.

author_id still can be given trough post_author. Not sure if we should mimic mw inputs for that. Don't think so.
My goal for the patch was to create a wrapper around wp_insert_post and that uses post_author as input.

Title and description are allowed to be posted since I think the client should check for it. This is something that should be open for discussion for the next office hour.

The comment and ping status variables probably should be validated. I don't think we should give an error if the status isn't valid but return the default option: default_comment_status / default_ping_status.

About the cap check the validation is on the right spot. Since someone without the cap should also not be have the ability to make a post not sticky. In the current case the else statement will be removed since it is about a new post so it will always be unsticky."
12706	18:41:22Z	markoheijnen	comment	66	When this will be implemented this should also be implemented in xml-rpc. At this moment it is hardcoded.
18429	22:43:59Z	markoheijnen	comment	19	"Submitted a new patch:

 - Added a capability check for password
 - Added comment and ping status validation
 - Changed sticky code. Fix validation for sticky post
 - Date code added
 - Redo the whole taxonomy code
  - Changes variable name from terms to tax_input. I override the default wp_insert_post implementation with an own because of better capability checking
  - Check for the capability to assign or create a term
  - Add taxonomy with names when it is hierarchical and there is no collision


Future:
 - Maybe the error messages should be changes.
 - Possible upload functionality but first need feedback from app developers for how they want it to be. It's probably not handy to have it in one method.
 - Maybe a variable to add images to the gallery"
18429	17:00:36Z	markoheijnen	comment	21	Thanks for the feedback. Update the patch
18429	12:47:35Z	markoheijnen	comment	23	"I hope I got time to put your feedback into a new patch before the office hour. 

About the use of get_default_post_to_edit. I was in a two fight. Now all the code is with each other.
Not needing it was my plan but then you split things like the taxonomy terms. Something that is also ugly in my point of view.

- post_author check can indeed be better. else branch doesn't need absint because of the user variable.
- I don't know if we should give an error. maybe we do. Curious what westi thinks about that point
- I will look into the undefined $terms_needed term.
- I will seperate the complex if statement. I don't think we should give an error when it is invalid.
- Will change blog_ID to blog_id
- I didn't knew at all that there needs to be a spaces around !. Will do that

The filters sounds as a good idea."
18429	17:27:21Z	markoheijnen	comment	24	"Added a new patch. Bigest thing is removing get_default_post_to_edit. So some checks need to go after wp_insert_post.
This isn't a bad thing since I found out that setting the terms for category before wp_insert_post didn't work as aspected. Moving it after wp_insert_post did worked out the issue.

Still need to talk about adding filters"
18429	18:43:05Z	markoheijnen	comment	26	"Also inserted a hackish code for category handling. Need some more testing for other hierarchical taxonomies.
Not sure if it is needed there to do the extra step to make the term names to id's"
18429	18:33:22Z	markoheijnen	comment	29	"We should include it now. That patch doesn't involved in the way we do it. We should use set_post_thumbnail( $post, $thumbnail_id ) and delete_post_thumbnail( $post ) for post thumbnail. The patch at #15098 doesn't use that.

I'm not sure if we should do some extra check on custom_fields. To remove the value _thumbnail_id from there. I do think the client is responsible with it."
18232	18:24:04Z	markoheijnen	comment	3	Is it really necessary to have special arguments for the fallback only for the walker? I rather would create a parameter only for setting the walker for the fallback.
18429	13:14:20Z	markoheijnen	comment	37	"You do have a point with that. Looking at the switch of post_status it even can be simplified little bit more.

The password check is needed to have the same implementation as the backend. There you can only fill in a password when you have the right to publish a post."
18429	14:06:40Z	markoheijnen	comment	41	Do we have to? if we send a post_id with new post that is has the value: null. Shouldn't that work as well?
18438	01:54:37Z	markoheijnen	comment	7	"Was busy with creating unit tests for the patch and I wonder the following things:

wp_newTerm
 - Check if taxonomy is set and is a string
 - Why is there the following line: $taxonomy = (array) taxonomy?
 - return term_id should have strval()

wp_editTerm
 - should the current_user_can check $term_id as second parameter?
 - error check op $parent_term but trying to show the error of $term
 - Error message for parent variable is not the same as newTerm, the same for error code
"
18438	12:54:49Z	markoheijnen	comment	9	"Thanks for the answers. About the taxonomy check if you pass an array it will result in an error since an array can't be a key.
Not sure if this is something that should be checked tho. 

About the error codes is there a page about which codes should apply to an error?"
18438	14:07:01Z	markoheijnen	comment	10	Added some basic unit tests for creating and editing a term. First time I wrote something like this. Love to get some feedback.
18438	14:36:27Z	markoheijnen	comment	12	I thought so but wasn't sure. I think a lot of the 500 error code should be changed since in the XML-RPC we don't know the reason but the function that is given the error does. It returns an error message so error code 500 isn't the right one. 403 makes more sense then.
18438	02:14:52Z	markoheijnen	comment	13	"Added a new patch and new unit tests.

 - return term_id should have strval()
 - error check op $parent_term but trying to show the error of $term
 - Error message for parent variable is not the same as newTerm, the same for error code
 - Changed some of the error messages so it is the same for all the term/taxonomy methods

Did wonder if someone can explain why there is an assign term check for wp_getTerm and wp_getTerms. Same for the edit taxonomy check for wp_getTaxonomy and wp_getTaxonomies. I think those checks can be removed."
18438	12:00:25Z	markoheijnen	comment	17	"Damn, I uploaded the wrong unit test file. Uploaded here again which also include all the other tests.
Do wonder how we should check the data we get back."
18438	23:22:11Z	markoheijnen	comment	19	"For the terms get method don't we need to set the arg hide_empty to false for the function get_terms() ? Or at least the ability to modify it?

Also for get_term() shouldn't we set the output to ARRAY_A and for casting it to an array use get_object_vars()? Like WordPress does if you look into the get_term() function"
18429	21:59:35Z	markoheijnen	comment	61	"Changed the code to use set_post_thumbnail() and delete_post_thumbnail(). 

Couldn't change the get method because of not available when the theme doesn't have post thumbnail support.
Is it possible to move get_post_thumbnail_id() from /wp-includes/post-thumbnail-template.php to /wp-includes/post.php to make this happen?"
18429	23:02:24Z	markoheijnen	comment	63	"Basically the following code is enough and the more get_post calls isn't there anymore.

{{{
		if ( isset ( $post_data['featured_image'] ) ) {
			// empty value deletes, non-empty value adds/updates
			if ( empty( $post_data['featured_image'] ) ) {
				delete_post_thumbnail( $post_ID );
			}
			else {
				if ( set_post_thumbnail( $post_ID, $post_data['featured_image'] ) === false )
					return new IXR_Error( 404, __( ""Invalid attachment ID."" ) );
			}
			unset( $content_struct['featured_image'] );
		}
}}}"
18429	23:21:29Z	markoheijnen	comment	65	"In my eyes better code. When there are WordPress methods what does the work for you, you should use it.

When removing the checks what I did most of the checks happen in set_post_thumbnail().
The only issue know is that it does a get_post on the post ID. I'm curious what the opinion is from westi or any other core contributor."
18429	23:50:13Z	markoheijnen	comment	68	"It's how you look at the problem. You also can say we should check if the theme supports post thumbnail.
And only allowed get/update/remove when the theme does support it."
18429	01:00:00Z	markoheijnen	comment	71	Added a full patch for all the methods that should change get effected by the new date en featured image options. Will test it further tomorrow.
15098	01:02:24Z	markoheijnen	comment	14	"Added a new patch at #18429 that also fixes this issue. I only return the id at this moment. I do wonder if the url should be returned.
If so then we also should do that with the new wp post methods."
19733	01:06:09Z	markoheijnen	comment	6	Added a new patch at #18429 that also fixes this issue. Do need to test it tomorrow if it works as it should.
18436	18:52:52Z	markoheijnen	comment	5	"Created a new patch that combines this ticket with #18437. I also added filter parameter for getPostTypes and fields parameter for both.
I'm not sure how the naming should be. It's most likely it can be better grouped."
13917	22:18:33Z	markoheijnen	comment	9	Patch is fine with me. I only wonder if there should be a check if the post id that is given does exists and it's post type is public (way it works now in the back-end)
17109	22:37:14Z	markoheijnen	comment	8	"To be honest I don't get the patch. Why use filters over actions and not use the data that get returned. I guess that is a mistake.

I think it is better to put in actions like #14283. Changing data that should be returned feels weird to me. Maybe that I can't think of any situation where this would be necessary."
13917	14:48:55Z	markoheijnen	comment	11	"How I see it is that wp_insert_attachment() is a low level API so there are always checks needed. Same as for wp_insert_post.
So checking if it is allowed to do should be in the xmlrpc method. No clue how it got handled in the backend. I do now from the user interface you only can attach an image when the post type is a public one."
13917	15:47:16Z	markoheijnen	comment	13	"I disagree with that. low level API's shouldn't have a lot of checks. Same that wp_insert_post doesn't do a lot of capability checking.

I do have to say I'm not sure if checking if a post type is public is a the good way of doing that.
I guess also in terms of permission checking it also is weird handeld."
18429	11:16:23Z	markoheijnen	comment	73	"Ticket #18436 helps partly with it. You see there all the post type with support.

There should be a value in initialise_blog_option_info() that shows all the post type which has thumbnail support and are supported by the theme. The value can be get by calling: wp_getOptions."
18436	14:42:48Z	markoheijnen	comment	8	"After some discussion in the IRC chat on 2 March I decided only to return the theme support for now. That shows if the WordPress installation supports.

For all post type support you can include a new option that includes all post types with thumbnail support like the following code:
{{{
$posttype_supports = array();
foreach ( get_post_types() as $post_type ) {
	if ( post_type_supports( $post_type, 'thumbnail' ) ) {
		$posttype_supports[] = $post_type;
	}
}
}}}"
20164	15:50:11Z	markoheijnen	comment	2	"Added a first patch that solved all the 5 points.

The default post types doesn't have to be public anymore. I change it to show_ui. It seems more appropriate in this case.
For a more advance choice it would be better to have post type support for it so you can select if a post type really wants this behavior."
17609	13:52:32Z	markoheijnen	comment	12	"Any changes this get in 3.4? I'm fine with the patch of intoxstudio only since that is the real problem.
The messages can be changed with the filter. Something what everyone probably should do."
19733	14:43:18Z	markoheijnen	comment	8	Added a patch that applies the patch of maxcutler to all the methods. I didn't applied the code of the first patch of this ticket. Is that still needed?
18429	01:05:15Z	markoheijnen	comment	79	"Attachment added for featured images.
Patch for dates is added at ticket #19733"
13689	16:31:21Z	markoheijnen	comment	28	"I do believe the functionality is needed but it does need some extra check.

When you have a subdomain install there is a big change you do want to use NOBLOGREDIRECT but you don't want that 404 on the main site will redirect. You want to have a 404 there since the change is to little there would be a subsite.
It's also weird to have different behavior on the main site then the other sites."
19954	20:38:59Z	markoheijnen	comment	5	I don't believe it is xml-rpc related. What I did was adding the category with the metod wp_set_object_terms() on the post ID what you get from get_default_post_to_edit(). I know thisis a rare condition.
20105	10:51:48Z	markoheijnen	comment	2	it should have been get_posts(). I will write a test for it so I can see if I can reproduce it again.
20336	13:41:55Z	markoheijnen	comment	1	Added unit test cases for the method mw_getPost [UT599]
19733	17:52:03Z	markoheijnen	comment	11	"I applied the patch of koke in a way that it only applies for incorrect dates. No matter what the post status is.
I also applied it to all the new XML-RPC methods so everything has the same date handling.

A benefit for this patch is that _convert_date and _convert_date_gmt only return an IXR_Date."
20336	11:54:59Z	markoheijnen	comment	3	wp_getPage does the same: [UT601]
19275	11:55:47Z	markoheijnen	comment	15	Just curious how does this effect #12779 (better support for custom post types in WP_Rewrite).
20014	19:18:55Z	markoheijnen	comment	14	"Understand that there shouldn't be more globals but its weird that $is_iphone does more then that.

Why not using $current_web_browser. And add the functionality to that. Sounds a way better solution to me."
20014	19:31:24Z	markoheijnen	comment	16	"That was my first thing what came up in my mind. But azaozz saying that there was agreed to not create new globals and I can fully understand that.

But why create new globals for it when there is $current_web_browser. I rather have one global that knows everything about the browser then several globals that knows something about the browser. I think we should create some kind of API how we really want it then create globals that plugin can use and can't be removed that easily."
19733	21:20:28Z	markoheijnen	comment	13	Fixed that in patch-core-19733-5.diff
19690	18:32:49Z	markoheijnen	comment	24	"Why this way. why not move clean_page_cache/clean_post_cache above $wpdb->delete() ?

"
20394	19:46:48Z	markoheijnen	comment	3	"Was first thinking about that. Looking into the code I think for all methods it should work. Probably some need discussion.

One issue need to be fixed and that is in wp_editPost. $post_more isn't set what causes a notice"
20394	09:53:55Z	markoheijnen	comment	4	This is a first rough version of the guard condition version. A lot of unit test will fail since they also test if there are nog enough arguments passed.
13910	16:49:04Z	markoheijnen	comment	6	"The patch looks wrong. title shouldn't be an argument and it should have been $menu->name.

Also a function like this should be in core

{{{
<?
function wp_nav_menu_title( $theme_location ) {
	$title = '';
	if ( $theme_location && ( $locations = get_nav_menu_locations() ) && isset( $locations[ $theme_location ] ) ) {
		$menu = wp_get_nav_menu_object( $locations[ $theme_location ] );
			
		if( $menu && $menu->name ) {
			$title = $menu->name;
		}
	}

	return apply_filters( 'wp_nav_menu_title', $title, $theme_location );
}
?>
}}}"
20473	13:45:53Z	markoheijnen	comment	5	Related ticket #20336
20409	17:00:30Z	markoheijnen	comment	3	"What about wp_get_attachment_thumb_url(). Seems like in this case that should work to.

That said wp_get_attachment_image() is a better way since it also can give the possibility to change the size when needed. Maybe not know but for future possibilities. "
20409	19:37:47Z	markoheijnen	comment	5	That does make sense to me.
20409	22:05:02Z	markoheijnen	comment	13	I would prefer moving get_post_thumbnail_id. Would make sense since updating and removing can be done when theme doesn't supports post-thumbnails
20407	15:34:20Z	markoheijnen	comment	3	Yes, that indeed makes more sense.
18710	13:05:21Z	markoheijnen	comment	9	"About the patch, the fallback to post is wrong. This should be to the current messages since someone can remove post from the array.

Also ticket #20898 is not a duplicate ticket but related. It's only duplicated when the current patch will be committed."
18909	08:08:08Z	markoheijnen	comment	54	"I was playing around with removing all the duplicated code because with this css code there are then three places where the ui dialog css are defined. I cloned the Github stuff to my own one https://github.com/markoheijnen/wp-admin-jquery-ui.

With that the TineMCE linking looks like http://cl.ly/0r3P3g1M2F1R240y1b2R. Will need to check later if there are issue with removing the stuff from editor-buttons and wp-jquery-ui-dialog.


Also what I noticed is that the ui-widget-overlay has a darker opacity now. Not sure if that was intended."
18909	07:03:43Z	markoheijnen	comment	55	"About the UI tabs. I'm not sure if it should change that much. I was playing on GIT with making a wp layer over the UI Tabs.

I do wonder if we should remove the default UI style for the link color so it falls back to the admin theme link color."
18909	13:44:06Z	markoheijnen	comment	57	"Uhm, just noticed I apparently changed the milestone of this ticket. Probably we should mark it for 3.5 ;)

I can understand that we can't remove that styling from the editor style. I did it in my repo to test the styling. You still can copy the specific styling to the editor style after all the styling has been done in the plugin.

I do wonder why not enqueue the jQuery UI stylesheet on the editor screen. Having the jQuery UI styling in multiple files is also something that isn't really wanted. You can see it now with the issue with the TinyMCE linking box. It's a decision in do we want to keep the page load low or easy to maintain the CSS code."
21028	20:51:10Z	markoheijnen	comment	5	"I had one site broke because of this ( 2 years old already ). I do have to admit the code was worse since the query part was in the theme.

It seems that the page var get removed when the page does not exists for the main query. Something I fully can understand and does help to do stuff on the right way. If this is true it should be wontfix I guess"
6430	20:00:48Z	markoheijnen	comment	11	"I've added a new patch to benefit from the work that has been done in 3.4.
The deprecated values its a little bit ugly but I guess this is the only way to make things the same trough all wp methods"
10514	20:53:14Z	markoheijnen	comment	9	"I looked at the patch and I do think the current approach is better then do it for additive changes.

I would say change the filter from xmlrpc_apis to rsd_apis because it isn't XML_RPC only. Also passing the XML_RPC url is weird."
10776	21:01:51Z	markoheijnen	comment	11	This has been fixed in #18429 and #18430 for the wp methods
17920	21:33:43Z	markoheijnen	comment	6	"Now there is wp_getPost. I recommend using that instead of wp_getPage. That said I'm not sure how to use post_type_supports. There isn't one for categories, right?

Weird thing is that we expect only categories and not tags or custom taxonomies. I think we should copy the stuff from _prepare_post to _prepare_page and that will solve the issue with a fallback for categories"
18909	12:17:25Z	markoheijnen	comment	59.62	"Replying to [comment:59 helenyhou]:
> I wonder that myself, but seeing as most of the admin stylesheets were combined not long ago, I don't think we'd split one out again and then enqueue it everywhere. If we were to put it into the main stylesheets, the maintenance would still be difficult and perhaps more so than having just a few elements with more specific selectors defined in other places, as colors are in one place and structure in another. It seems that future maintenance is a (the?) sticking point here, but still think it's worth pursuing.

So if I understand it right ""wp-jquery-ui-dialog"" has been combined into ""editor-buttons""? So that is the reason why it is duplicated now for some kind of backwards compatibility?

The reason why I removed the dialog code from ""editor-buttons"" in my fork is to test it out how it looks without it. And I do like how it looks now. That said I'm not a designer ;) You can always duplicate it back to ""editor-buttons"" but thats kind of ugly but I can understand why.

Btw. I also removed the link color of "".ui-state-default a, .ui-state-default a:link, .ui-state-default a:visited"". That the same what stephenh1988 does. Didn't do it for hover since WordPress already overrides that."
10658	20:30:08Z	markoheijnen	comment	4	"It's a interesting idea but I would say close this as wont-fix. The reason is that ""POST requests only"" is a message for developers. A user never should see that where the disable XML-RPC message is for users."
10764	20:39:22Z	markoheijnen	comment	6	"I agree with mdawaffe. The method should be fixed or blogger API should be removed.
The patch does needs a look and unit tests before it get committed"
14452	22:48:28Z	markoheijnen	comment	6	Shouldn't we change the function wp_allow_comment() to not use the function die()/wp_die(). Makes more sense that the function what calles wp_allow_comment() to do that.
16985	00:15:12Z	markoheijnen	comment	25	Just curious. Is this a issue in the new wp methods? We don't use edit_date there so I can see we maybe also have a issue there.
17920	20:22:32Z	markoheijnen	comment	7	Wonder if we can inherit most of the getPost functionality in getPage.
18087	20:42:07Z	markoheijnen	comment	2	the XML-RPC does not use the function media_handle_upload() for inserting the file. The title you can submit to mw_newMediaObject but the caption is not yet used by the XML-RPC
18434	21:10:38Z	markoheijnen	comment	4	Should there be a argument to get only the terms for one taxonomy instead of all of them? I do believe it is needed since you don't know else from which taxonomy the term is from
20662	22:13:17Z	markoheijnen	comment	1	"yes, the logic should be the same. Added dev-feedback to define that the right way is for handling sticky posts.

Wonder if private isn't allowed we should add the check into stick_post()."
20704	22:21:16Z	markoheijnen	comment	2	"Can you explain why you want this? XML-RPC has a certain way it works. Don't get the addition.

Also you can use the filter 'authenticate' for it. "
20705	22:24:50Z	markoheijnen	comment	4	#4794 is the same issue.
20697	21:16:46Z	markoheijnen	comment	9	"mw_newPost does it correct but mw_editPost doesn't. There is still a lot of things happening after wp_update_post in mw_editPost.
Wonder if that should be fixed or not."
18434	21:51:46Z	markoheijnen	comment	6	For getting yes, not needed. For setting I wasn't sure but I have no problem closing both tickets
13461	22:26:11Z	markoheijnen	comment	10	I do wonder if the code should be inside wp_imagecreatetruecolor() since there it goes wrong
21091	09:59:13Z	markoheijnen	comment	2	There is something weird going on. Just tried it myself. When a user doesn't have edit_post(s) capability and does upload a new media item it still breaks for HTML5 uploader. However it doesn't do that for the browser uploader
21098	21:34:19Z	markoheijnen	comment	4	"We really should tweak the memory limit. Curious to see if we can reduce the memory it currently using. Will going to play with that this weekend.

About the multicall. I wouldn't request categories in a multicall. That is something you have no clue about how much data that really is since it just returns all of them.

I don't think if you hit the memory limit you can return something different then 500.
"
21098	11:45:48Z	markoheijnen	comment	11	"How does that idea work for the current code and custom methods added by plugins?

Also I was busy to do some research in how to reduce the memory print. I came across this link: http://php.net/manual/en/features.gc.performance-considerations.php

I do know bluehost is running 5.2 and now I'm curious if the problem can go away if the site will migrate to 5.3/5.4. I'm not a PHP expert but would love to try that out before doing all kinds of things.

I still find in curious to see how this could be an issue because of 3.4. We didn't really changed the code a lot. "
21098	17:05:29Z	markoheijnen	comment	14	I'm curious to see what you want to stripe out since the functionality still needs to be there except functionality for viewing things.
21175	09:31:27Z	markoheijnen	comment	2	"I reopen the ticket because I would love to have a clarification about the usage of {{{^}}} in the strip regex. It seems insecure.

Also wonder the double {{{\\}}} in the clean regex. Can it be that one of them was meant for the minus. This causes Dreamweaver and also Coda to make the rest blue/green"
21175	09:34:40Z	markoheijnen	comment	4	I did look at the dev.js file. I used http://www.jslint.com/ to find a reason why it happen and it was because of {{{\\}}} in the clean regex
21192	17:54:59Z	markoheijnen	comment	1	All methods use wp_insert_post/wp_update_post and from there the action will be called.
16494	11:04:26Z	markoheijnen	comment	39	"I wouldn't change it because of the reasons given. It shouldn't be changed because other developers doing it wrong.
In my opinion when you write code it should always be wrapped in a jQuery function. and as param you can pass $"
4590	13:45:53Z	markoheijnen	comment	5	I believe this ticket can be closed as wont-fix since of all the wp methods and its hard to maintain something like that.
11150	13:57:01Z	markoheijnen	comment	4	Can be closed in favor of editTerm
21085	13:57:52Z	markoheijnen	comment	3	There should also be an method for removing a media item. See #5310
16316	14:00:04Z	markoheijnen	comment	14	Can be closed since it can be done with the wp.getPosts #18433
17156	14:02:13Z	markoheijnen	comment	3	I believe this can be closed now due the work in 3.4 where you now can add terms and there are some extra hooks added
20548	14:08:22Z	markoheijnen	comment	7	"First of all that are two different API's and the implementation is different. Also clients should try to use the wp.* methods.

That said we really can’t change it because things will break. At least from my experience with iOS development."
17156	20:31:22Z	markoheijnen	comment	5	"Only the wp.* methods should be used now. In 3.4 we added wp.newPost and that can handle taxonomies by names or id's.
It uses the function _insert_post inside the XML-RPC class. This has a filter ""xmlrpc_wp_insert_post_data"" what filters the data before it get passed in.

I'm not sure if this is what you wanted or not. Please let me know.


"
6559	07:03:54Z	markoheijnen	comment	7	Closed as duplicate in favor of #21292
21296	12:51:50Z	markoheijnen	comment	2	BTW the patch is incorrect since will be more then that. Any should load all the post types with show_ui == true. Related to that one: #20164
18950	15:36:35Z	markoheijnen	comment	5	"@doodlebee: You shouldn't change the version because you experience it. The version is ment when the bug could have been started.
I'm curious how you registered your post type since all the WordPress code that also uses get_post_types() does work.

The reason Big Bagel is correct. When you register a post type the default public value is false. I mark this as close since it isn't really something to fix."
18950	16:04:08Z	markoheijnen	comment	7	"The public argument is not equal to other arguments. So yes I think it its own self attribute. When you do set that argument others will start with another default value what can be overridden if the argument has been set. It would be weird the other way aroung when setting the show_ui argument to true will mean you can view the post online.

If you look at this ticket #20164 you can see why query on the public argument is wrong and it should have been the show_ui argument."
18950	10:03:52Z	markoheijnen	comment	12	"I didn't confuse the two arguments. The ticket for show_ui was just an example.

I believe public or publicly_queryable can't be removed. I would say that the public argument should be a convenient argument. Reading through #19693 that is not the case. I'm curious how the going to change the functionality.

I do however still believe that the actual result is the correct behavior"
20502	06:51:37Z	markoheijnen	comment	5	Shouldn't we create some kind of guidelines for the value of z-index. Having the need of a z-index of 1000 seems weird to me
20502	15:06:49Z	markoheijnen	comment	9	"I don't know it either but I'm just curious if we can. A z-index of 1000 is default for the jQuery dialog. So given a z-index of 1500 to the count bubble will make this look weird. You can fix this with setting a higher z-index for the dialog. At that point no matter what, you are potentially competing with other CSS code.

Another reason I asked was because of the hugh z-index on the adminbar (99999)."
21358	20:16:53Z	markoheijnen	comment	1	And how does this effect WordPress core? and specially what do you want to be fixed?
21358	20:24:00Z	markoheijnen	comment	3	WordPress does auto redirect. At least for all my installs. It doesn't seems to be a WordPress related issue
20164	19:11:25Z	markoheijnen	comment	4	"Related ticket: option for all post types: #21296.

With ticket #16029 I would love to see it as that instead of selecting the posttypes as now. With an option to filter which post types.
If it is one then don't show which post type it is"
20164	19:34:08Z	markoheijnen	comment	5	The php code should be addressed in 3.5
20057	12:28:38Z	markoheijnen	comment	16	"Ticket #21292 will help this issue. The XML-RPC should use wp_handle_upload() instead of wp_upload_bits().
At this moment there are more issues in it since a lot of error checking is missing."
21380	17:45:33Z	markoheijnen	comment	2	"I find it strange that you are even allowed to change the url.
I would say make the field in the dialog read only. And make a filter for plugins to make the field not read only."
6821	18:14:16Z	markoheijnen	comment	10	"I'm curious in how we should implement this. The implementation would be something like how it is done with the HTTP API.
I'm also curious if this will effect server load like in case of WordPress.com."
21386	18:45:39Z	markoheijnen	comment	2	As an addon on this we should have a way that wp.getPostTypes only returns post types a user can add/edit to.
21386	19:01:32Z	markoheijnen	comment	4	"That almost solves the problem. I do think we should have an option in wp.getPostTypes so it only returns the post types the user can add.
So some of the capability issues will be solved by the XML-RPC server instead of in the app"
21292	19:18:27Z	markoheijnen	comment	4	Finding a way to add https://github.com/daniloercoli/WordPress-streaming-xml-rpc in the new media method. And when it works well in 3.5 also add it in 3.6 for the current one.
21292	22:05:41Z	markoheijnen	comment	5	"Just a weird thought. Would it make sense to fake a $_FILES array to pass through wp_handle_upload(). By using the code of Danilo to store the image localy that would make sense.

Other solution is not using it and fix wp_upload_bits(). Looking again to it and they should both do the same thing. The only difference is the input and how to act on that."
19121	23:06:52Z	markoheijnen	comment	4	I would love to see this in 3.5. I think it's fine to only add a filter for the callback and not on the return value
20057	23:07:30Z	markoheijnen	comment	17	"Looked into the issue more and wp_upload_bits is the right method to use and obvious it doesn't has wp_handle_upload_prefilter. It does has the filter: wp_upload_bits.

#19121 should fix this issue the correct way: add a filter to wp_unique_filename.

Maybe we should remove sanitize_file_name in the mw_newMediaObject. So it doesn't fire up twice."
19358	23:19:36Z	markoheijnen	comment	1	#19658
19658	23:20:18Z	markoheijnen	comment	7	Closed #19358 as duplicate
20057	00:12:00Z	markoheijnen	comment	19	"If you read my comment on #19121 you would see that the filter shouldn't be like that and that there should be a filter to define a default callback for unique_filename_callback.

Most of the functionality is the same. Missing a good filter for wp_unique_filename() is a pain in your case."
21292	01:08:28Z	markoheijnen	comment	6	Uploaded my first try to fix the upload limit
21292	19:54:29Z	markoheijnen	comment	7	Added a new patch that checks if a user can upload any file.
21292	22:50:53Z	markoheijnen	comment	8	"Removed wp_check_filetype in the beginning of wp_upload_bits() and added wp_check_filetype_and_ext in the end.
In this way you can manage the check trough the 4th parameter. (copied and edited the code from #11946)

The only bad part is the need of unlink on error since you need to upload the image."
11946	22:55:00Z	markoheijnen	comment	29	Added a fix for wp_upload_bits at ticket #21292
21398	12:56:04Z	markoheijnen	comment	1	"Can't we just use the current implementation with a parameter to only use get_default_post_to_edit() and not use wp_insert_post.
Because the way you describe will only work for new posts."
21397	12:57:06Z	markoheijnen	comment	1	This would be really awesome to have in 3.5
21397	14:52:43Z	markoheijnen	comment	2	"At this moment most of the stuff can be done with the current methods. We should create new methods that loads the current methods.

We only need to write something for restoring a revision and check if the link is correct so it can be used to review a revision."
21398	14:55:07Z	markoheijnen	comment	3	I believe we can combine this one with #21397. Basically what you want to do is creating a revision for existing posts and for a new one you can create a new post and set the status to draft
21397	15:58:13Z	markoheijnen	comment	5	"That was my first though (but in another way) also but after rethinking it and a talk on IRC with daniloercoli I do believe this should have their own methods.

Revisions aren't obvious a post type and their implementation can change and we get methods like:
- wp.getRevision ( blog_id, username, password, revision_id )
- wp.getRevisions ( blog_id, username, password, post_id, filter )
- wp.newRevision ( blog_id, username, password, post_id, constent_struct )
- wp.restoreRevision ( blog_id, username, password, post_id, revision_id )

The addon for wp.getPost & wp.getPosts is helpful but revision_count should be a array with revision ids."
20767	11:53:32Z	markoheijnen	comment	5	"I really don't see the issue. If you handle category or post_tag as a custom taxonomy you wouldn't have the issue right?
I rather go for something like that then adding code for only category or post_tag "
21403	12:14:42Z	markoheijnen	comment	2	I'm curious how this effect the performance
21038	16:20:27Z	markoheijnen	comment	12	"This ticket should be closed in my opinion. It's defiantly plugin/theme material. However we should make it easier to generate those images.

A lot of people will not even use these images if we create them. What happens is creating a lot of images that will not get used an only will result in the need of more disk space."
21446	05:59:32Z	markoheijnen	comment	2	"If I'm correct this will not allow IPv6 right? so making it default would be temporarily?
If so then this looks like plugin material to me. I do believe you can mange this by using a filter."
6821	06:09:45Z	markoheijnen	comment	26	"I was busy with creating something on github (https://github.com/markoheijnen/WP_Image). Hopefully I can get something working in the next 24 hours. When I'm fine with a first version I will post it here.

I do also work on a WP_Image class since I do believe it's value. Even if it is in the begin a simple layer for using an attachment ID instead of the file path. Since we will toughing a lot of the image generating code I also hope we can get something working that you can do add_image_size with an extra argument if it should be auto generated.

I was thinking if we also should add a way to create @2x images. Since I believe there isn't a good way at this moment to do so if you want to add @2x to the filename."
21446	06:56:35Z	markoheijnen	comment	4	And what happens when servers only have IPv6? You got a problem then with this solution?
20704	19:26:42Z	markoheijnen	comment	4	I still say this ticket should be close as wont-fix. Reason is because you can use the authenticate filter and check if XMLRPC_REQUEST is defined.
16003	19:59:06Z	markoheijnen	comment	9	Resolved it since the wp.* methods now able to handle this
20704	20:15:09Z	markoheijnen	comment	6	"Well, I still don't really get what you really want. I believe with the current authenticate filter is good. You don't want to have a different login for every different login call. So that's a no-go.

Also your do_action is wrong since you don't pass the password."
20058	20:24:26Z	markoheijnen	comment	4	Can't this be closed since the exact code was in [20322]?
21481	23:08:20Z	markoheijnen	comment	2	related to this ticket is all the work done in #6821
6821	05:30:55Z	markoheijnen	comment	35	"I partly agree with it. I can understand why using the extension would make sense but what if running the CLI is way faster?
Also I don't think overload a shared hosting is still the issue when running the extension."
21397	18:43:12Z	markoheijnen	comment	10	"Looked to it and I believe wp.newRevision should use wp.newPost instead of wp.editPost.

Also wp.restoreRevision isn't really working and also the arguments aren't right"
21397	18:55:37Z	markoheijnen	comment	12	"You want to create a new post with the post type revision. Looking further to the code wp.newRevision wil not work correctly.
Also I'm wondering if the add_action there is valid since the change is that it is already loaded"
6821	19:52:43Z	markoheijnen	comment	42	Trying to change some of the WordPress functions to use the WP_Image_Editor class. It still missing methods like save and abstraction of crop.
15401	18:13:06Z	markoheijnen	comment	4	So you say we shouldn't maintain Twenty Ten anymore? If newer default themes have better explanatory text why not using that text also in Twenty Ten?
12706	18:45:19Z	markoheijnen	comment	99	"For this getting in 3.5 it needs a lot of unit tests since the code will be changed a lot.

Looking trough the code I was wondering how the default statuses will get registered to the default post types. I'm probably missing something. Also doesn't it make more sense to create a WP_Post_Status class instead of using a global for that?"
15311	14:48:54Z	markoheijnen	comment	61	"nemor: that is a problem on your local environment.

There is also a change that this ticket will be invalidated/solved because of the work on #6821 to simplify some of the functions for better use cases like this."
21524	15:49:04Z	markoheijnen	comment	3	This is not how you want to do things. You should use the WordPress ajax handlers
21524	15:50:10Z	markoheijnen	comment	3.4	"Replying to [comment:3 markoheijnen]:
> This is not how you want to do things. You should use the WordPress ajax handlers. See [http://codex.wordpress.org/AJAX_in_Plugins]"
21524	16:36:29Z	markoheijnen	comment	6	"I tested it and it works. It seems you do something wrong. I did tested it with the default WordPress language file but it should work with custom ones.

Also you should use WordPress AJAX handlers and not like this. Using wp-blog-header.php is in my opinion always wrong."
21397	15:48:46Z	markoheijnen	comment	15	"About the functionality. We don't want to save a post but we want to create a new revision for a specific post. That can be put live when needed. It's for loading the content into the site without needing it to be saved. A little bit what core does now when you writing a post for a long time and it saves when you are writing.

I will dive into the code later but if I'm correct the hook is already loaded. With your code it's probably getting loaded twice.
"
21398	15:55:28Z	markoheijnen	comment	7	"Hey Daniel, That doesn't make sense to do because of different templates, stylesheets, shortcodes and what a theme loads more. We want an exact copy how it shows on the site.

Also this isn't a major bandwidth it. Unless you reload the screen after every word you type."
21398	16:54:10Z	markoheijnen	comment	9	"Update the preview within a second after the user stops typing is something really unwanted and I can believe it leads to hundreds of refreshed. Specially when you are on a mobile device. That said on a mobile you are not going to do this. Maybe on a tablet

I don't think the API is in a position to do a dry run. We can make it happen but with a lot of time and most likely after that it is still buggy.

About offline, yes I would love to get it in to but being realistic I don't see that happening soon. But if you got the time to get it working really well go for it and I'm happy to look into it and get it in core."
21398	17:36:58Z	markoheijnen	comment	11	"I use API's a lot so I can see your perspective. I do value feature as some kind of live preview but I also see the issues with it.
But the question is do you see how difficult it is to integrate something like this. When you dealing with a CMS a lot of things can change when the content change like with a shortcode. That is hard maybe even impossible to get it right.

Also thinking about future implementations like post types supports doesn't make it easier to handle everything."
21397	17:40:00Z	markoheijnen	comment	17	"I do mean the autosave behavior. For creating a revision it probably make sense to use wp.editPost for doing that. 

For getting revisions I do believe it is better to create new methods for that because when using a API it should be obvious how to use it. It's little bit like the media methods."
20704	18:17:46Z	markoheijnen	comment	8	"I'm fine that you only need a hook that passes only the username. Normally you would also expect the password.

I'm closing this ticket since there is only one type of login. Maybe two if you don't want that XML-RPC uses the same login. This is something that already can be done."
21556	06:04:08Z	markoheijnen	comment	3	I do believe some recent versions of PHP do allow this but as wonderboymusic said this is sure not preferable. 
21560	06:24:49Z	markoheijnen	comment	1	Can you provide us with a code sample. I doubt this is a bug in wp core. It seems more likely it is a bug in your code.
21586	05:54:34Z	markoheijnen	comment	2	"Had this once and inserted the string 'false' as a value what does work since it isn't existing. 

Wouldn't it be better to have array('title', 'editor') in the defaults array. That will remove the if/else check."
21509	18:57:55Z	markoheijnen	comment	4	"Added a patch that removes the option enable_xmlrpc everywhere and removes the option from the database.

I'm not sure if removing the option is the best way. Maybe setting it to 1 on upgrade maybe fits better."
21509	21:08:28Z	markoheijnen	comment	5.7	"Replying to [comment:5 blobaugh]:
> Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

I can see what you mean but I disagree the reasoning. There aren't a lot of plugins adding XML-RPC stuff but the do for other things and plugins are a big cause of security issues. Also if you really want to disable it then just remove the xmlrpc.php file because plugins can add methods that are always accessible even when you put xml-rpc off in your settings."
21607	12:14:12Z	markoheijnen	comment	1	See also: #21606
21608	14:36:04Z	markoheijnen	comment	1	As far as I can tell that is default behaviour. As you can see the number is the term_id
21622	21:53:32Z	markoheijnen	comment	2	"I'm curious if WordPress should do this kind of checking. If someone breaks something when using the editor they ask for it.

Also when changing functions.php and you make a mistake their it would always break wp-admin since functions.php their can be used their. To make it saver for yourself you can create load a file inside functions.php that you only use for the frontend."
21622	22:01:31Z	markoheijnen	comment	4	Thats true but we don't check if we change a plugin. The way of doing [[Image(so)]] is different since you want to check something that is loaded by default.
21626	20:57:09Z	markoheijnen	comment	2	Well this isn't a bug. All the XML-RPC methods don't use the blog id yet. The way of doing it now is to use the XML-RPC url of the blog.
21626	14:27:10Z	markoheijnen	comment	4	Yes that should work like that
21623	21:30:59Z	markoheijnen	comment	5	"I don't agree that this is a low-hanging fruit. I think it is a feature that people aspect.
I also disagree for using WP_Query since wp_get_recent_posts also use get_posts but with another default set of arguments. So it isn't something we need to implement to gain more functionality.

I think we can simplify the checking and use $filter as our default $query and transform number to numberposts if numberposts isn't set."
21623	16:21:42Z	markoheijnen	comment	7	"Yes, I can understand why you want ""search"" instead of ""s"". Can't we just map ""search"" to ""s"" then? and only do that when ""s"" isn't set."
21645	08:24:19Z	markoheijnen	comment	3	"I don't agree with it. Flushing rules isn't something the user should deal with. It is something a developer should handle with care.

The add_feed also handles the call to a function and that is something that can change but flushing rules is a one time action."
2567	19:12:36Z	markoheijnen	comment	10	Is the fix only to add: header( 'Connection: close' );?
21668	07:14:25Z	markoheijnen	comment	4	"I don't think progressive images should be the default. I also don't really believe the images will get smaller or there is an extra lost of quality.

About being responsible and that this update is overdue is not really helpful for this ticket. I would love to get some more insight in progressive images and if/how this can also effect PNGs and GIFs.

That said a filter is indeed needed and hopefully it is possible with a reference instead of copying."
21725	11:53:33Z	markoheijnen	comment	2	This already been taken care of with #21183. What did result in that changeset [21644]
21738	14:29:40Z	markoheijnen	comment	3	Can't this be closed as duplicate of #21074?
21789	12:01:26Z	markoheijnen	comment	2	Added a patch to remove the reference of Twenty Eleven in the Welcome panel and adds a filter to be able the same from inside the theme.
21790	13:55:33Z	markoheijnen	comment	1.2	"Replying to [comment:1 nacin]:
> The notices are?


Notice: Undefined property: WP_Query::$post in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/query.php on line 2986

Notice: Trying to get property of non-object in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/post-template.php on line 1270

Notice: Undefined property: WP_Query::$post in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/query.php on line 2986

Notice: Trying to get property of non-object in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/query.php on line 3349

Notice: Trying to get property of non-object in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/query.php on line 3351

Notice: Trying to get property of non-object in /var/www/vhosts/***/subdomains/***/httpdocs/wp-includes/query.php on line 3353"
21790	22:05:57Z	markoheijnen	comment	3	In my case I'm using is_page_template() and is_front_page() on the filter. How I look in the code this will only work inside the loop but I can be wrong. However I somehow do expect it to work without the need of a loop.
21790	06:52:34Z	markoheijnen	comment	5	"For me to see the notices is to set a static blog and front page. and use a function like is_front_page. I'm going to try if I can write an unit-test to make it visible. Not sure yet how to create this situation and where to check on.

{{{
function some_random_modification( $query ) {
		if( $query->is_main_query() && is_front_page() ) {
		}

		return $query;
}
add_filter( 'pre_get_posts', 'some_random_modification' );
}}}"
21790	10:06:17Z	markoheijnen	comment	7	"Uhm okay, i do think it is wrong tho. 'pre_get_posts' is a place you want to use it since you want to control the main query.

How I can see it now there is no way to do it then. Having said that it does work. I only get some notices."
21790	10:14:50Z	markoheijnen	comment	8	Just a little note what I already said: it only shows the notices when static homepage is set. On all other pages it is fine without any notice.
21790	15:51:47Z	markoheijnen	comment	10	"yes, I know that. I looked through the code to see if I could fix it.

I'm now just curious if it is fixable or how you otherwise modify the query on the front page with the use of WordPress code."
21790	16:00:06Z	markoheijnen	comment	11	"I now solved the issue by using this: 
{{{
( $query->get('page_id') == get_option('page_on_front') || is_front_page() )
}}}

Reason was that is_front_page() doesn't work then in pre_get_posts(). It does work but I'm not a fan of using this."
21830	13:02:49Z	markoheijnen	comment	1	MetaWeblog API will only be used for post/page. You can only get custom post type support by using the wp.* methods
21830	13:19:28Z	markoheijnen	comment	3	"It's won't fix since we only concentrate on the WordPress methods. So most of the times we only do bug fixing for Blogger API, metaWeblog API, Movable Type API. In some rare cases we do add functionality.

I don't see why MetaWeblog is easier to use but that can be me that is used to the WP methods."
6821	08:14:43Z	markoheijnen	comment	64	"I removed the 'wp_editor_use_' . $editor hook. That is almost the same as 'wp_editors'.

I think image_editor_class has it place since that is the only way to change editor when there is one selected."
21025	13:14:34Z	markoheijnen	comment	17.18	"Replying to [comment:17 psophy]:
> Replying to [comment:16 nacin]:
> 
> On WordPress.com works correctly but on Version 3.4.2 not yet work it still remove zero space. I hope on version 3.5 it will work.

You shouldn't test on 3.4.2 but on trunk."
11828	14:03:29Z	markoheijnen	comment	7	The sun has been shinning already with ticket #21663 so closing this one.
21858	20:06:08Z	markoheijnen	comment	6	That doesn't seems as a good way to solve the issue. The code is there for a reason.
18731	15:48:41Z	markoheijnen	comment	9	"I was even thinking even more difficult then this. I was thinking about moving all the code from xmlrpc.php to somewhere else and make xmlrpc.php to call that code. And then create some kind of endpoint system like /index.php?endpoint=xmlrpc. This way you can even use the rewrite API to have it another name as usual.

Most likely my mind is thinking more difficult but with this we can have added some steps for a RESTFUL or JSON API."
6821	20:24:47Z	markoheijnen	comment	65	"'''Just added a new patch with the following GIT commited messages:'''

- getsource	Constructor should be protected. Props scribu.
- kurtpayne	Use instance of instead of is_resource. Deprecate GD specific functions.
- kurtpayne	Implement backward compatible behavior to default to jpeg filenames and jpeg output
- getsource	Don't instantiate WP_Image_Editor_GD directly from image_resize.
- getsource	Load on construct.
- getsource	GD: Make $image protected

- markoheijnen 	Don't say you can use WP_Image_Editor_GD in a deprecated function message
- markoheijnen 	Move make_image to WP_Image_Editor and replaced call_user_func for call_user_func_array
- markoheijnen 	Fix notice by adding destiny filename as required argument for make_image
- markoheijnen 	Use make_image for Imagick"
17604	15:54:50Z	markoheijnen	comment	3	Can we remove this functionality. I don't get why it is in their the first place because it isn't something WordPress does by itself
18671	13:24:25Z	markoheijnen	comment	7	"Several months ago I wrote something this hacky class: https://gist.github.com/3110599. It's a little different approach.

With this code you can register a widget to a sidebar by code. To have a class/function for this you can easily pass settings to a widget. If you do this with register_sidebar() it's getting a mess and complicated."
21983	12:51:21Z	markoheijnen	comment	1	"The error is correct and the plugin doesn't deal with all cases. The reason is that the main query still tries to get all the posts and when there aren't one it will show a 404.

I guess it is better to use something like http://wordpress.org/extend/plugins/google-sitemap-generator/ and then the beta."
19658	05:02:10Z	markoheijnen	comment	16	That was the use case I described at #19358 and probably shouldn't close as duplicate as what Helen also described at comment 8
21397	15:18:00Z	markoheijnen	comment	41	I updated the patch with most of the feedback Nacin said. I need to look into the IXR_Date::getTimestamp() since I'm unsure it works. It also needs more unit tests
20778	19:41:10Z	markoheijnen	comment	21	It seems it is broken on Mac OS since a lot of unit tests are broken now. Somehow /private/ got added.
21397	21:05:53Z	markoheijnen	comment	42	"I checked the code when I was back home and fixed some code issues and updated the unit tests to it. Probably need to add some more.

Weird thing is that $content_struct['only_if_modified_since']->getTimestamp() does work. I do however was thinking to use $this->_convert_date() and check inside there is it is a IXR_Date object or not. Any thoughts about that"
18428	13:19:27Z	markoheijnen	comment	22	"I just added a patch what adds get_userdata() to wp.getUsers since it can't return things like firstname/lastname. I'm not sure if there is a better way to handle it.

I also added the field option 'authors' but didn't change the cap check. I do was wondering if wp.getAuthors isn't broken since there isn't really a check if the returned users are really authors"
17604	13:28:39Z	markoheijnen	comment	6	The patch removes overwrite functionality. Looked in to it more and it was never overwrite. It's more delete and upload a new one.
21977	19:36:14Z	markoheijnen	comment	4	Changed the unit tests and added extra ones to wp.editTerm and wp.newTerm. Also updated the patch of Sam to have it from the root instead of the wp-includes folder.
22080	23:35:50Z	markoheijnen	comment	4	"Third parameter doesn't make sense to me too. You then should be able to do remove_theme_support( 'post-thumbnails', array( 'my-new-post-type' ) );

I can see the usage. I ones needed thumbnail support to a post type because it is used for a mobile app. That isn't really a theme thing."
14244	23:48:57Z	markoheijnen	comment	2	Is this still the case. I would say this is fixed by using Plupload?
13372	23:55:30Z	markoheijnen	comment	6	I think this ticket can be closed since the problem isn't the ability to define a post type to an image size. The problem is that everything is getting created on the fly. And we should find a way to do that. See #15311
16349	00:22:55Z	markoheijnen	comment	14	I also think this is plugin territory. It's something not a lot of people will need and I guess getting external images make sense too in some cases. In that case you do some kind of regex that gets all the images in post_content.
18543	00:49:35Z	markoheijnen	comment	6	Fixed in [22094]
18283	00:52:19Z	markoheijnen	comment	3	I think we can close this ticket after 14 months and the code changed a lot.
18835	01:00:57Z	markoheijnen	comment	6	Is this something that can be addressed for in 3.5? Seems like it fits the focus
19118	01:10:20Z	markoheijnen	comment	7	"The error is intended. You want to resize an image and if that doesn't happend you want an error.
Returning $file implies that the file did got resized."
16349	09:41:59Z	markoheijnen	comment	16	"You just proof yourself even more to close this ticket. The reason is that there are a lot of possibilities how someone wants to retrieve the information. Having categorized array is pretty ugly if you want the images on a certain way. Also post types is a completely other use case then this. 

Something shouldn't be in core because it is hard to build or you really need to know WordPress. Something needs to get in WordPress because a lot of people want to use it."
13372	09:54:07Z	markoheijnen	comment	8	"It seems you go the other direction now at the ticket described. We are talking about generate a certain image size for a certain post type.
Also that is something that can probably be done in WordPress.

I still think #15311 is the way to go. You can select there which images to auto generate and which not. This ticket will need that since it will be a pain in the beginning for adding new sizes for existing content. Since plugins need to build on the demand."
22084	16:27:54Z	markoheijnen	comment	1	It seems you have something else wrong. For me it works on a test site running 3.4.1.
20787	18:14:14Z	markoheijnen	comment	3	I think this is something that should be plugin material. Changing images seems something WordPress shouldn't do by default
22099	14:19:46Z	markoheijnen	comment	1	Related: #20164
6821	19:29:43Z	markoheijnen	comment	82	Added two patches for fixing error handeling and the PHP strict standard notices
16349	23:31:25Z	markoheijnen	comment	20	"oEmbed and WP_Http are used everywhere in core. So don't use my criteria in a wrong way.
The list of all images belonging to a post is most likely being used by less then 1% of all users. The use case is poor and in most cases the user has no control on it.

I'm not even going in discussion about it even more. This is plugin material in my opinion not in yours. We can discuss what ever we want but that is not going to change. The ticket can also be open for years but that doesn't say this will going to be implemented."
22124	22:00:44Z	markoheijnen	comment	1	"Uncaught TypeError: Cannot read property 'width' of undefined mce-view.js:393 [[BR]]
wp.media.string.image mce-view.js:393 [[BR]]
mceview.add.text mce-view.js:432 [[BR]]
(anonymous function) mce-view.js:343 [[BR]]
wp.mce.view.toText mce-view.js:336 [[BR]]
(anonymous function) editor_plugin_src.js:62 [[BR]]
tinymce.create.dispatch tiny_mce.js:1 [[BR]]
(anonymous function) tiny_mce.js:1 [[BR]]
tinymce.create.dispatch tiny_mce.js:1 [[BR]]
serialize tiny_mce.js:1 [[BR]]
k.create.getContent tiny_mce.js:1 [[BR]]
k.create.save tiny_mce.js:1 [[BR]]
(anonymous function) tiny_mce.js:1 [[BR]]
c.each tiny_mce.js:1 [[BR]]
j.EditorManager.d.triggerSave tiny_mce.js:1 [[BR]]
autosave autosave.js:288 [[BR]]
$.schedule.func autosave.js:6 [[BR]]
trampoline jquery.schedule.js:32"
22129	17:14:56Z	markoheijnen	comment	4	The only thing I can imagine is that you can provide an alternative url for the version check as a comment. What calls the url and that url only returns the version number and nothing more.
22120	19:43:02Z	markoheijnen	comment	5	It's exactly the same issue. My bad the other ticket got created.
18731	16:19:57Z	markoheijnen	comment	11	"This is a bug that does need to be fixed. It can result in an enhancement in a better API for new endpoints.
I did punted for now and hopefully this is something that can be discussed on the summit."
21085	16:23:13Z	markoheijnen	comment	15	I punted it for now. It's something that need to be discussed more but way to late for 3.5 since it's an enchantment of the existing API.
22130	22:27:36Z	markoheijnen	comment	5	"What was the decision to have it below the title and not the content? It seems bizarl to me too.

Also the wontfix because of discussing seems weird since the conversation was between 3 people and 3 messages. You apply that is was something really well discussed. "
22181	10:03:19Z	markoheijnen	comment	4	I will now look in to that.
15230	12:04:47Z	markoheijnen	comment	12	The version is where it is implemented and not the latest version it occurs.
22181	16:28:36Z	markoheijnen	comment	5	Created a ticket at the unit test trac for this. It does include a file with four tests. See #UT135
22185	10:37:00Z	markoheijnen	comment	1	"Another issue is that when zooming in/out you can see the normal admin screen. I would say that should be hidden when using DFW.

I think both solutions given are not the best and we should look how we can solve it with touch actions:
 * On press will show the controls
 * When there is a selection always show the controls. It will be hidden when there isn't a selection."
6821	12:35:49Z	markoheijnen	comment	88	Seems I forgot the most important one. WP_Image_Editor::get_instance() should return an error when no implementation could be selected.
21672	20:45:21Z	markoheijnen	comment	4	"I did notice today that the action ""clean_post_cache"" is getting fired on non existing posts too. This happens when I remove a menu item. Most likely it's getting called more then ones but I didn't looked into it."
22220	13:51:29Z	markoheijnen	comment	1	"You are using the build in taxonomy ""Category"" or are you using a custom taxonomy?

Maybe this is related: #19954?"
19954	14:31:27Z	markoheijnen	comment	7	#22220 was marked as a duplicate.
22220	14:31:27Z	markoheijnen	comment	3	"I close this as duplicate. Since it is the same issue as #19954. The patch I wrote doesn't seem to fix it properly then.
I will start writing unit tests for it and hopefully this can be fixed in 3.5"
20787	16:12:03Z	markoheijnen	comment	5	Closing it as wont-fix. Still seems as a weird thing to do and is definitely plugin material
19658	23:42:02Z	markoheijnen	comment	22	Hey logikal16, Helen's patch does work when a post type doesn't have editor support. It just it's still in the post-body-content and that doesn't really matter that much for now. Maybe later.
22308	15:18:30Z	markoheijnen	comment	6	"It wasn't that we do some kind of versioning. The problem relies in documentation and changes that are made in the imagick library. There isn't a clear documentation for that.

Testing of the library is something I work on but that is something that will happen in the next week or so."
7301	16:01:24Z	markoheijnen	comment	8	"Do we really close tickets like this as invalid since AtimPub can be removed from core it doesn't mean we should loose this tickets.
We only shouldn't accept new ones."
22335	17:34:46Z	markoheijnen	comment	1	That doesn't make sense to me. Tried to look into the code but it should always be inherit. There is no post_status change anywhere
22335	17:48:11Z	markoheijnen	comment	3	"The default ""post_status"" isn't draft but inherit. It seems you edit the image through wp.editPost and that this can be the reason of post status change.

Also attach_uploads shouldn't really care about post_status and what it is."
10658	18:03:16Z	markoheijnen	comment	5	This isn't really a problem anymore since the XML-RPC is enabled by default (3.5). Also my previous reason still apply
22335	18:20:17Z	markoheijnen	comment	5	"The status of an image is always inherit. It makes more sense then others.

So the real issue is the change of post status and I can see why that can happen. I will look in what the best solution can be for that.
The best is to create a way to change the media through the API but that isn't something that can be done for 3.5."
22335	18:26:39Z	markoheijnen	comment	7	I do something like that for the wp method. Older methods will stay untouched unless there is a bug and this is an enhancement to make more possible through the existing methods
22335	18:55:26Z	markoheijnen	comment	8	I just uploaded a patch for the wp.* methods. That should fix the case
22335	15:44:46Z	markoheijnen	comment	11	[UT1109]
18435	15:49:47Z	markoheijnen	comment	3	Marked as fixed in 3.4
18434	15:51:51Z	markoheijnen	comment	7	Marked as fixed in 3.4
14037	16:13:44Z	markoheijnen	comment	22	I'm curious if we can close this ticket. In 22 months no traction and we already are a few releases further.
22320	22:02:52Z	markoheijnen	comment	3	That behavior is the same as we would have for others. Can be committed.
22035	22:29:16Z	markoheijnen	comment	5	Tested it and patch works. Not sure if it makes sense to create a unit test for this.
22035	23:01:03Z	markoheijnen	comment	7	Patch on the feedback of nacin. Still works fine
18428	18:52:59Z	markoheijnen	comment	26	Is fine for me. Don't think we need fields = authors support
22320	18:54:37Z	markoheijnen	comment	6	Is it that big of an API change? I don't really mind since in my opinion those methods are deprecated
6821	19:53:28Z	markoheijnen	comment	102	"The latest patch are thechanges that are still open. No caching anymore because of require methods option. The patch isn't tested yet,

The unit tests do need some work and I will trying to get that done tonight if possible. That is the reason why patch isn't tested yet"
19889	14:55:13Z	markoheijnen	comment	11	I think it's better to fix all of these issues in 3.6. I would love to see a better workflow in 3.6 where you can select the images it should apply too.
22308	19:57:44Z	markoheijnen	comment	10	We need to revert it and use a version check since supports_mime_type() need to be static
22308	21:21:42Z	markoheijnen	comment	12	Something like this? I was planning to test it with at least Imagick version 2.2 but installing that seems harder then I thought.
22308	21:37:18Z	markoheijnen	comment	13	We can think about a version check with phpversion( 'imagick' ) but I'm unsure about that.
21292	23:26:07Z	markoheijnen	comment	16	"Well for me this is -1. Totally understand why people don't want to contribute on regular basis because of this.
I tried multiple times to get feedback on my latest patch but never gotten one."
3534	11:44:49Z	markoheijnen	comment	23	So +1 for having that checkbox and default hidden ;)
22479	20:58:23Z	markoheijnen	comment	2	"I had once added on a XML-RPC ticket a fix a lot of notices for non wp.* methods ( #20394 ). Didn't fix this one.
Curious what the policy is for it since then it didn't made it."
22497	15:27:25Z	markoheijnen	comment	4	"I like this way because of the opt in. We can make assumptions but that is the wrong we to do. WordPress should try to do it's job a good as it can. And with this solution someone can allow a certain post type to show up.

Also till now we didn't come up with a good way to deal with custom post types in a good way. This is a first step."
22497	16:35:07Z	markoheijnen	comment	6	This isn't theme logic at all. This is back-end logic. It's the same as 'show_ui'
22497	16:49:04Z	markoheijnen	comment	8	That is somehow the problem. It's also the lack of extensibility of wp-admin. This solution is however a temporarily solution for now since the app can't know if the mobile device can show the post type properly.
22497	17:04:06Z	markoheijnen	comment	12	We can't go from 0 to a perfect solution. We need to take steps and this is one step we need to take. Obviously you want to have custom mete box support but that can take forever and most likely never happens. It's not because we don't want to but it's almost impossible to have a great experience.
22497	17:17:39Z	markoheijnen	comment	17	In this case app maker are your co-contributors. Who work on the mobile apps to make the WordPress (overall) experience better. This ticket is needed for now because of the lack of other possibilities in WordPress core.
22512	07:04:37Z	markoheijnen	comment	6	"I don't think problem 1 is an issue. Since the check inside the editor is needed. The one outside the class I can't remember but if it's there it has it's rights and it shouldn't be combined.

Problem 2 can be considered as an issue inside the editor. Not sure if the editor should care about it as in the code that is calling the editor should care about that. You can change the filename on save. multi_resize is something different in this case. As Scribu said it's not a regression but for me it would be a nice to have it in 3.6

Problem 3: Well documentation is good to have but to already start to complain about it is lame. If you miss them you can create the pages yourself. That why the codex is so awesome, everyone is allowed to write content on it. Eventually there will be blog post(s) about all the changes but that can be even done after the release. Deprecation doesn't mean that it's getting removed fast. Also writing good content costs a lot of time."
22356	16:26:01Z	markoheijnen	comment	13	"I rather don't have functionality of WP_Image_Editor merged with an implementation. It whats Mike said in comment:9.
What happens when an implementation doesn't implement supports(). You get weird things then. And now supports_mime_type() by default return false. So an developer really is forced to implement."
22540	17:27:42Z	markoheijnen	comment	3	"I do know that your first thing isn't going to happen like that. It should support querying on taxonomy. I somehow thought we already implemented it in 3.4.

The second thing is a no for me. If you want you can still use the filter 'xmlrpc_prepare_post' to do so.

So the end of the story this ticket should be to have the possibility to query on taxonomies"
22538	17:33:48Z	markoheijnen	comment	3	"'wp_image_editors' is the primary filter developers should use. 'wp_image_editor_class' was needed till we dropped the caching stuff.

I guess the need for 'wp_image_editor_class' is only there for the unit-tests."
22540	17:46:36Z	markoheijnen	comment	6	"Point 1: Yes it works but only for 1 taxonomy and not for custom ones. It should be a total solution.

Point 2:
This code makes it bulletproof for if the site is used by the mobile.
You do now need to send fifth parameter as: array( 'post', 'terms', 'custom_fields', 'autop' )


{{{
add_filter( 'xmlrpc_prepare_post', 'xmlrpc_prepare_post_autop' );

function xmlrpc_prepare_post_autop( $_post, $post, $fields ) {
	if( in_array( 'autop', $fields ) )
		$post['post_content'] = wpautop( $_post['post_content'] );

	return $_post;
}
}}}

ps: didn't test it ^^"
22538	17:50:03Z	markoheijnen	comment	4.5	"Replying to [comment:4 macbrink]:
> If $args is passed, you could do with just one. 
> 
> Imho the class selection could be more elegant. It seems the reasoning behind this was to select between Imagick en GD, however, if a  plugin developer wants to add or change functionality, he has to extend both WP_Image_Editor_GD and WP_Image_Editor_Imagick. I would rather have one image editor class which internally checks the image library to use. 

I disagree with this. You can't mix GD and Imagick. Or at least you shouldn't so the current way of doing is best. Also there are more then two image libraries like jpegtran and gmagick."
22540	17:54:28Z	markoheijnen	comment	8	"When using WordPress you should do a little more research. A category is a taxonomy just like tags. But you can also write custom ones for custom post type like posts or pages.

You can write your own plugins and the code I passed is code that should go in your own plugin ( or theme )

Rest of the specific question should be asked on the support forums"
22538	17:56:34Z	markoheijnen	comment	7	Yes, so the only thing is left for this ticket is if we do need the filter 'wp_image_editor_class'
22538	18:54:49Z	markoheijnen	comment	12	"If the plugin wants to load an editor itself on a certain place in the code of the plugin then you don't need a filter. The plugin can manipulate 'wp_image_editors'.
The filters don't need args because at that point the factory has the control and not the implementation.

I guess scribu means that the filter will be renamed with a little different way of handeling."
22538	19:01:31Z	markoheijnen	comment	14	The right editor is the first in the array that supports the given mime type and is enabled on the server.
22538	19:08:43Z	markoheijnen	comment	18	You have filter priority and array_unshift()
22538	19:21:14Z	markoheijnen	comment	20	Why do you want to override generate_file_name(). That doesn't make sense for me.
22543	19:24:35Z	markoheijnen	comment	2	"There are two ways of solving this. Will create both patches as we speak.

We use setIteratorIndex() as a fix for when resizing gif animation. Do we still want to use Imagick or do we then go to GD. I would say the first"
22538	19:33:18Z	markoheijnen	comment	22	Thats why you can pass parameters to save(). By default it stores images in the same folder as where the image is in.
22543	19:37:12Z	markoheijnen	comment	3	"Two solution to handle this case. The version of ImageMagick is really old so I would love to see solution 1 that get's committed.

The weird thing is that the version of the TS was release in 2006 but CentOS ( no clue if he is using it) was even updating this version last year: http://pkgs.org/centos-5-rhel-5/centos-rhel-x86_64/ImageMagick-6.2.8.0-12.el5.x86_64.rpm.html. No clue why."
22540	19:39:29Z	markoheijnen	comment	10	I explained because I got worried that you still wanted to change core code. Something you never should do ;)
22543	19:40:24Z	markoheijnen	comment	6	The function set's the frame. If I'm correct it would select the last frame instead of the first. GD also selects the first one and thats why it's there.
22543	19:58:40Z	markoheijnen	comment	8	[attachment:22543-2.diff]​ is the way to go for this. When you have that old version of Imagick then we just should skip it and use GD instead
22543	20:08:37Z	markoheijnen	comment	10	Saw that one but that is just weird. ^^
22543	20:31:34Z	markoheijnen	comment	11	this should help out the second problem better. Instead of callable checking on the version.
21386	20:01:34Z	markoheijnen	comment	12	You can read #18428. Probably something to do with security. From my point of view it doesn't matter that much but you should ask Nacin about this.
22584	18:15:44Z	markoheijnen	comment	3	I'm curious which CSS wasn't loaded then. Can't see anything for that. Also weird to do that spacing with CSS instead of a space
22538	18:31:44Z	markoheijnen	comment	31	Is it an idea to only have the 'wp_image_editors' filter for 3.5 and revisit the needs for 3.6? Specially since we already have our first RC.
22543	18:50:05Z	markoheijnen	comment	15	"The feature detection should be possible but for the second problem we are already doing so. So I added class_exists('Imagick') for that. Maybe extension_loaded() can now be removed.

Second stuff you are right so a check if the mime_type is given or not and when needed check is_callable( $this->image, 'setIteratorIndex' )."
22538	20:25:45Z	markoheijnen	comment	33	"I don't think we need that anymore. And removing it seems the best way for doing.

If unit test needs it we can remove it before release and added after it. What is ugly but it's the best option."
22538	21:18:14Z	markoheijnen	comment	36	"Obviously we suck in that but that is not a reason to try to tackle this 9 days before a release.

Also I would love to have 3.6 for only to be cleaning up those tickets. To much feature creeping instead of making WordPress more robust"
22699	19:17:42Z	markoheijnen	comment	1.2	"Replying to [comment:1 nacin]:
> Rotating a huge image is probably still a major drain.

Why? all the imagick handeling isn't in PHP but on a separate process. So the memory usage will not be that different."
22701	21:31:44Z	markoheijnen	comment	2	"This is why you have a admin network panel. It doesn't make sense to have it in your wp-config.php file.
Also a dynamic constant is ugly way to develop and the admin network panel is the better way to deal with this"
22701	22:02:13Z	markoheijnen	comment	6	"I still think you doing it wrong. You should not move databases this way. If you do try to use a plugin that does this for you.

Also it seems so much easier to use some magic sql queries to change the urls. In the rare cases I need something like that I used that.

Also in my way of thinking the constants are used to make sure the url's can't be changed through the interface. What makes sense when not experienced users have that access."
22704	23:09:53Z	markoheijnen	comment	4	"I don't understand why WordPress core needs this. Seems like a small percentage will use this and this feels like an item that shows how WordPress is all about feature creeping instead of being a robust platform.

In my opinion there isn't a good way and still have an easy to use system. Maybe when we add a lot of black magic to WordPress but for me that just feels wrong to do so."
15636	16:09:44Z	markoheijnen	comment	17	We shouldn't add any sorting to this array at all. By default we give in the order we want and if someone adds a custom role added at the end. And with a filter you still can provide the right order.
22763	21:32:14Z	markoheijnen	comment	2	"I had this once when requesting a part of a template through ajax. WordPress can't really do something with this. It's all to the ajax method to handle this and I guess this is a custom AJAX method.

The only thing you can do is set  $_SERVER['REQUEST_URI'] to the value you want it to be."
22763	22:10:35Z	markoheijnen	comment	4	You can check if DOING_AJAX is defined
22793	18:55:06Z	markoheijnen	comment	1	You don't need to change the minified script. that will happen automatically
22824	16:44:09Z	markoheijnen	comment	2	Looked and tested the patch and it's good
22878	11:57:32Z	markoheijnen	comment	1	"Can you provide the image because I can't reproduce it and it seems image related. If you are using a GIF it happens and that is something that will not be fixed.

It seems you are using GD and the best is to ask your hosting company to install imagick for you. Or gmagick and install a plugin to support that."
22871	15:29:52Z	markoheijnen	comment	2	I do think from an accessibility perspective the opacity  can be to low and we can make it 0.3. It still has the felling the buttons are disabled.
22901	22:20:43Z	markoheijnen	comment	2	This issue is quite interesting. From looking to the code I can't see the reason why it ever worked. Also Codex says it is string only.
22901	22:36:55Z	markoheijnen	comment	4	"That was exactly what how he tries to do it:  user, pwd, {number:1, status: [""approve"", ""hold""]}"
22901	22:57:06Z	markoheijnen	comment	6	"Well it are 2 queries then. One for approve/hold and one for spam.

You do can use the method 'system.MultiCall'. Quick search let me to this page: http://scripts.incutio.com/xmlrpc/advanced-client-construction.php."
20201	12:27:25Z	markoheijnen	comment	6	I would love to see this in 3.6 because I also agree that method B is right
22901	12:49:28Z	markoheijnen	comment	7	"Closing the ticket as invalid since this was never possible. Was thinking about creating a new ticket for having it possible but for me it doesn't make sense if you can't have a custom status.

@stuffmc: For your application I would split approve/hold and spam. It makes no sense to have those combined from an user perspective."
22912	13:18:52Z	markoheijnen	comment	1	"This taxonomy isn't there to scale since it has a default set you can't extend.
The reason it has that prefix is because term slugs are unique to all taxonomy's and not just one when Post Format has been introduced. This will change but you still have all the existing site's using it."
22305	13:27:29Z	markoheijnen	comment	12	We can't. Both times you did mentioned what the fix should be in the ticket and because of that you did got the props in the commit message.
22116	13:38:40Z	markoheijnen	comment	10	"I did move this to the milestone. Indeed an edge case but it should be dealt with.

To current rules you are lucky to be on the credits page. The solutions you have added to the 3.5 tickets are good but it would be better that you also create the patches ;) If you don't know how you can read the handbook: http://make.wordpress.org/core/handbook/"
22944	22:39:21Z	markoheijnen	comment	2	Isn't this then for milestone 3.5.1?
22962	21:46:50Z	markoheijnen	comment	3	"The image in the editor isn't the thumbnail size but the original size but scaled down. So the main issue of this ticket is invalid.

Also I can't reproduce the issue of Adam. I changed the image and what I see is that there is a new thumbnail image and the old one also still exists. I checked this on my drive. If you still have this issue you should create a new ticket with a full description with hosting or server configuration added."
22962	22:10:17Z	markoheijnen	comment	5	"Well the backend can't know what will be showed on the frontend. In your experience it is the thumbnail but there are a lot of examples it showed a medium image or a custom image size. Not sure if there is a filter to change which image will be showed.

Also it shows the original image without crop."
22966	22:31:47Z	markoheijnen	comment	2	#22962 was marked as a duplicate.
22962	22:31:47Z	markoheijnen	comment	7	Duplicate of #22966.
22966	22:33:56Z	markoheijnen	comment	3	"As mentioned at ticket #22962 in 3.5 it isn't a magic crop but the original scaled down. That counts for search results as sidebar result.
The only place where the thumbnail is showed is the media library."
22966	23:22:23Z	markoheijnen	comment	5	"Scaled down has been discussed and it not going to happen. It's nicer that all images have the same size.
Not sure why the thumbnail isn't used. Maybe because of the need for retina images and that doesn't count for thumbnail images.

If you want to change the main view I think you have a special need that the normal user doesn't have and that a plugin should take care of it. But that's me.

I do have to say that it would be cool if there would be a link to open a new model that shows all image sizes that aren't just resized images but where cropped or manipulated in a different way."
22985	11:05:59Z	markoheijnen	comment	3	I will look into this today. I can see the issue with the code lewis send but I need to look into the context of that since for what I think that get called when a new image getting uploaded. So if that is true that code is unrelated
22983	11:07:46Z	markoheijnen	comment	3	This seems as a server issue. Can you put here the server configuration or the host you are using.
22983	15:13:24Z	markoheijnen	comment	6	Confirmed this and it's a bug caused in 3.5
22985	15:40:36Z	markoheijnen	comment	4	#22983 was marked as a duplicate.
22983	15:40:36Z	markoheijnen	comment	7	After playing it's the same issue as #22985. Closing this one since that ticket shows what the issue is.
22985	15:42:24Z	markoheijnen	comment	5	Testing it and yes the multi_resize() call in wp_save_image() is wrong. It will then only put the changed images as meta sizes.
19889	21:44:17Z	markoheijnen	comment	16	The part for every ratio we need multiple versions isn't inside the scope of this ticket and is also something WordPress core shouldn't do. There still a lot of discussions still going and almost no one is using it.
22995	23:53:59Z	markoheijnen	comment	2	Need more feedback. It sounds like you doing something wrong and without any details about errors there isn't something to say. Please test it out what is wrong with WP_DEBUG true.
22995	00:25:29Z	markoheijnen	comment	4	"That is just random code. For what I can guess it seems a conflict with your theme or the plugins you are using.
I think your issue is better to be handled on http://wordpress.org/support/ and not here."
22995	00:52:29Z	markoheijnen	comment	6	"Yeah confirmed that. Only happens when the category can't be found. looking to the code all calls to get_queried_object() are weird since there is no check at all.

That said that shouldn't cause a blank page."
22998	01:02:53Z	markoheijnen	comment	1	"I don't like to have this in core and I also am unsure if this should be discussed here. I rather would close it but thats me.

Also for a side note you should add a patch and not a full WordPress zip file."
22998	01:17:34Z	markoheijnen	comment	3	I don't think the protocol is that important to be a core feature. I believe plugins can do it pretty well.
21394	01:33:17Z	markoheijnen	comment	8	in wp-includes/general-template.php there was also a case where the assumption was made that get_queried_object wasn't null.
22995	01:36:34Z	markoheijnen	comment	7	"Added the patch for that fix to #21394.
Still more feedback of the user is needed on the reason why he gets a blank page. Do you get this where the cat is found or when it isn't found?"
18614	10:02:30Z	markoheijnen	comment	24	Ben, I guess the notices weren't the same and for your notices there is a patch for that in ticket #21394
22878	10:04:17Z	markoheijnen	comment	3	Related to this ticket is #13461 what has issues with GIF but for what I know PNG's should work fine but GIF's not.
13461	10:05:54Z	markoheijnen	comment	18	Can you still add the patch you had. I'm thinking of fixing it for resize/crop only. For me that is enough to fix this ticket and if people have issues that they then need to install IM or GM
21292	10:26:07Z	markoheijnen	comment	18	"Yes, all those issues you can track back to 3.0 since this function didn't changed then.
It is however a high priority ticket since it can effect people badly (no disk space) and it shouldn't matter if no one did reviewed it or had see this issues.

It does has some unit tests but only indirectly through the XML-RPC method unit tests. I will write some more unit tests for it and refresh the patch this week."
19889	15:47:51Z	markoheijnen	comment	19	"This isn't something to discuss on this ticket or on trac. You should discuss this on the hackers mailinglist.
If you are creative you should read http://make.wordpress.org/core/2012/12/06/wp_image_editor-is-incoming/
"
22995	16:34:57Z	markoheijnen	comment	10	"Also that is not the problem. You should be able to send in non existing id's and that the query is going to listen to it.

And I agree with Sergey that it shouldn't cause a blank page. I think it's better you try to solve your problem through the forum and by that closing this ticket."
22993	16:56:01Z	markoheijnen	comment	2	Thats incorrect. You can do it through the interface of WordPress but I'm curious if we should check on it.
22993	18:50:31Z	markoheijnen	comment	8	"Thats shouldn't be a problem since the value is always the same so we can check on the value ""a:0:{}"""
23007	18:58:51Z	markoheijnen	comment	1	"This isn't something that is wrong with WordPress core. It's because of the upgrade of jQuery what breaks jScrollPane plugin. What is basically the mistake of jScrollPane.

See http://stackoverflow.com/questions/11903758/jscrollpane-and-jquery-1-8-0"
19889	20:42:51Z	markoheijnen	comment	21	It did cause disappearance in 3.4 and also in 3.5 because of the bug described in #22985. If that is fixed the data wil exists since we don't unset data anymore at that part of code.
22985	21:06:59Z	markoheijnen	comment	9	For fixing broken metadata I think can use wp_restore_image() on all images that are missing thumbnail, medium or large on upgrade. Will going to play with it this or next week.
22100	14:21:09Z	markoheijnen	comment	26	#23019 was marked as a duplicate.
23019	14:21:09Z	markoheijnen	comment	2	"Please next time use the same ticket instead of creating a new one.

Also I do think your patch is incorrect since you are now merging the functionality all together. But that is something I'm not sure about since I don't know the size array that well.

Since this patch will inflict the changes on ticket #22100 I'm closing this one as duplicate too"
22100	14:24:22Z	markoheijnen	comment	27	"In tickets #23009 and #23019 was brought up that crop isn't always a boolean. This isn't a big thing but would be awesome that this is also taken care of in this ticket.

Also curious if we can mark this for 3.6 or not."
20943	15:49:33Z	markoheijnen	comment	17	Just out of curiosity if what Nacin said wouldn't that make the patch correct. It seems that it only applies for when you do insert paragraphs yourself.
16657	20:48:14Z	markoheijnen	comment	4	Closing as it is. If you want to have a better crop you now can create your own WP_Image_Editor implementation and use that.
22985	22:41:44Z	markoheijnen	comment	11	Was playing to get a script done for hotfixing this issue. The result I have as a gist: https://gist.github.com/4349227
23039	20:05:28Z	markoheijnen	comment	2	It's the same. I guess we can close #22878 as duplicate of this one.
23039	20:16:17Z	markoheijnen	comment	6	Best is to just use wp_imagecreatetruecolor(). We will deprecate it in 3.6 tho and include the code in WP_Image_Editor_GD. We probably should have done that in 3.5
23039	21:16:29Z	markoheijnen	comment	8	Yeah that doesn't make sense. Patch is good but you can remove the is_resource() check. It already happens above it.
22637	16:52:42Z	markoheijnen	comment	13	You are not allowed to re-open a ticket when it is marked as fixed on a finished milestone. I do have to say that the point given is valid if I would read the ticket description. Not sure what is best to do. I guess it is best to create a new ticket.
23063	18:06:42Z	markoheijnen	comment	1	I think it is better to use the filter 'upload_dir' for this case. So I guess this ticket can be closed since there is a (better) way of dealing with this.
23079	20:06:49Z	markoheijnen	comment	1	Argh, my bad. Should be wp_deregister_style obviously
23099	13:53:30Z	markoheijnen	comment	15	If this isn't for 3.6 then I guess this code should be a plugin and that we now start having public discussions about how a REST API in core should look like.
23069	17:36:21Z	markoheijnen	comment	8	Personally I don't think you should remove data on uninstall process. You don't know it a user is expecting it to be removed at all. Settings can make sense but for posts/terms it doesn't. On that note I do agree with dd32 on his answer.
13372	08:01:30Z	markoheijnen	comment	12	"First to temper your expectations. There isn't really said in words that this should be include for 3.6.

My arguments still stands that the problem isn't  in define a post type to an image size but with the ability to generate an image size on-the-fly or just by simpel code. Jkudish also mentioned this in the chat:

""what if the image is uploaded in the media library w/out being attached to a post? or what if it's attached to 2-3 different post types?"".

That is from my point of view a problem that isn't easy to fix or even not fixable. In my cases I never attach an image to a post. That doesn't make sense.

As I mentioned you already can create images with WordPress without the need of add_image_size. It's even more easier now in 3.5 with (WP_Image_Editor) then ever before. I do have some ideas to make it even more easier to generate images with a few lines of code and that it's added to the metadata array of a certain image.

As conclusion is close this ticket in favor of others. Also what is next? Add an image size to a post format, maybe a taxonomy etc."
22985	12:00:10Z	markoheijnen	comment	14	"If I'm correct all the data still exists in get_post_meta( $post_id, '_wp_attachment_backup_sizes', true );
So then it looks like we still can do some kind of merge with the attachment meta data."
22985	00:20:41Z	markoheijnen	comment	15	"Anyone working on fixing the lost data? I was checking if we could used backup sizes but that's a no.

So it seems we need to check if an attachment has a '_edit_lock' and then loop check if the meta data sizes doesn't have an image from get_intermediate_image_sizes(). And this should be done as late as possible since themes do need to add their sizes."
23140	12:13:28Z	markoheijnen	comment	2	The PHP error is that you either have WP_DEBUG on true or server configuration. Showing the database host is something that would always be showed. That is maybe something we should hide.
23140	12:42:55Z	markoheijnen	comment	4	"You shouldn't use WP_Debug set to true on a live server. Then this is warning is probably not the only one. It shows all notices and warnings.

The message still is the same. You can see that in wp-includes/wp-db.php and search on the error text. Also WordPress doesn't know you are logged in when it can't access the database ;)"
19889	17:17:47Z	markoheijnen	comment	23	#23145 was marked as a duplicate.
23145	17:17:47Z	markoheijnen	comment	1	Duplicate of #19889.
23143	06:58:34Z	markoheijnen	comment	3	I think we should close this ticket. Also for me it doesn't make sense to change the field. Doing this because of Google + is just lame.
23143	08:03:06Z	markoheijnen	comment	6	"It still doesn't make sense to me. First of all people already using that field. No clue what people fill in but for example if the majority fills in a twitter url then the new name doesn't make sense. I guess this ticket is created from your point of view. For the things you would use it for but that doesn't have to mean to majority does that too.

Also I don't think your alternative solution will ever be in core. That kind of things is plugin territorium."
23223	08:45:54Z	markoheijnen	comment	4	You probably downloaded to early since I just downloaded 3.1 version. Generating the zip does take time.
23251	15:56:06Z	markoheijnen	comment	1	Please add a patch instead of a link to a pull request. Also related to this ticket is: #14889
23251	16:12:22Z	markoheijnen	comment	5	I say related. If you read the comments you will noticed why it isn't done. Also saying stuff like migrate to Github without knowing anything about the current progress isn't really smart to do.
19889	15:59:41Z	markoheijnen	comment	26	#23274 was marked as a duplicate.
23274	15:59:41Z	markoheijnen	comment	1	Duplicate of #19889.
22663	21:45:36Z	markoheijnen	comment	5	Patch 22663.in_rotate.diff​ is the fix for this ticket.
23300	10:22:33Z	markoheijnen	comment	1	Same happens in trunk too.
13459	10:40:24Z	markoheijnen	comment	7	Seriously, till now we never fixed this. That's quite a shame.
13459	14:46:03Z	markoheijnen	comment	9	#23300 was marked as a duplicate.
23300	14:46:03Z	markoheijnen	comment	4	It's a duplicated ticket so this one is closed. You should comment or/and add patches to #13459
13459	23:42:19Z	markoheijnen	comment	12	"I disagree with leaving this to a plugin. The problem is only for post vs pages when the permalink structure is ""/%postname%/"".

It seems for me that the 2nd option is the way to go. Obviously changing to the structure will ending up with a conflict but that can be plugin territory. "
23306	10:12:32Z	markoheijnen	comment	2	"We can probably do that. Still WP_Image_Editor is a very abstracted class and the default folder is the folder itself.

So you can also see it that the developer should deal with it. Most likely because of you want to call wp_mkdir_p before you even going to load an image. This means that this patch only fixes 50%. What can be good enough.

Put it on the 3.6 milestone for consideration."
23300	18:36:08Z	markoheijnen	comment	7	Alex if you don't have anything meaningful to say you don't have to respond. Makes tickets readable.
23306	21:24:27Z	markoheijnen	comment	3	"btw can you give an example of a plugin. I'm not sure what you mean with replication. Is that image or site based.
Also I'm missing why using that function. Seems like a file system operation without the need of resizing."
23306	15:48:26Z	markoheijnen	comment	5	"I meant wp_crop_image(). WP_Image_Editor is what I partly written myself so I do know that code.

My opinion still stands that it shouldn't be dealt inside WP_Image_Editor. Also if you really want to add it you can do that in the custom WP_Image_Editor you probably already have by now.

Still My questions stands in comment 3."
23306	16:32:22Z	markoheijnen	comment	7	Ah so no WordPress.com related thing. I still don't get the issue when editing an image through WordPress dashboard. Since all those images would be saved on the same directory where the main image is stored.
23070	17:28:03Z	markoheijnen	comment	13	I disagree that we shouldn't add this. It's a simple fix and we should have fix this in 3.5.1. We now only seems to look at Google where this bug exists for a long time. We should also care about other search engines/platforms what also have this issue.
23070	18:34:28Z	markoheijnen	comment	15	After 3 weeks you mailed they still didn't fix it. If you can get them fix asap then I'm fine but we are talking about Google so we probably need to wait for a long time.
23070	19:10:57Z	markoheijnen	comment	17	It's not our bug to fix but it our responsibility to make the experience in WordPress as good as we can. That means we sometimes need to fix stuff what isn't our mistake.
23070	19:17:27Z	markoheijnen	comment	19	Last time I checked there is a way to detect that googles bot is visiting robots.txt. so it's just partly against web standards.
22985	12:16:48Z	markoheijnen	comment	18	Is this fixed and if not what is there to be fixed to close this ticket.
23325	12:42:40Z	markoheijnen	comment	1	That is indeed stupid. Also you should change the PHPDocs. Normally it returned false but thats not anymore the case.
22324	19:12:37Z	markoheijnen	comment	8	"The tests shouldn't be updated. We talking about the XML-RPC here so we probably should update the code then.
I'm looking into it what changed."
22324	19:16:07Z	markoheijnen	comment	9	Looking into it this never should have been committed as it is. Changing the data type is really dangerous and should be tested well and also the external API's should be checked. This since the app can crash now due their strictness of data types.
22324	19:33:32Z	markoheijnen	comment	10	Added the fix for the XML-RPC
23348	22:53:23Z	markoheijnen	comment	4	My opinion is that WordPress core is not the place for a contribute link. However it should be more prominent on WordPress.org and the make websites.
23164	17:23:25Z	markoheijnen	comment	5	Isn't it possible to remove height or width? Will make it future proof then right.
23099	19:23:06Z	markoheijnen	comment	27	Is this something that we really want to include in 3.6? I rather work on getting a RESTfull API for 3.7
23099	13:22:49Z	markoheijnen	comment	31	"For me it doesn't really matter why it is worse. We should not implement this in this way if we will get a RESTfull API in 3.7 or 3.8. We should look how we want stuff in the future instead of looking only to the next release.

We could make the current implementation a little bit different so that it can be extended with a plugin. So don't extend IXR_Server and change serve_request() part that Max has in his patch."
23262	23:17:43Z	markoheijnen	comment	6	Media doesn't work for me on several trunk sites. Reverting this change does work for me.
23262	23:33:32Z	markoheijnen	comment	9	"'''Add media button:'''

{{{

Uncaught TypeError: Cannot read property 'map' of undefined underscore.min.js:5
T.map.T.collect underscore.min.js:5
T.(anonymous function) underscore.min.js:5
media.model.Attachments.Backbone.Collection.extend._changeFilteredProps media-models.js:395
w backbone.min.js:8
g.Events.trigger backbone.min.js:10
f.extend.set backbone.min.js:14
media.model.Attachments.Backbone.Collection.extend.initialize media-models.js:353
media.model.Query.Attachments.extend.initialize media-models.js:661
g.Collection backbone.min.js:18
d backbone.min.js:41
d backbone.min.js:41
media.model.Query.Attachments.extend.get media-models.js:833
media.model.Attachments.Backbone.Collection.extend._requery media-models.js:556
media.model.Attachments.Backbone.Collection.extend._changeQuery media-models.js:383
w backbone.min.js:8
g.Events.trigger backbone.min.js:10
f.extend.set backbone.min.js:13
media.model.Attachments.Backbone.Collection.extend.initialize media-models.js:353
g.Collection backbone.min.js:18
d backbone.min.js:41
media.query media-models.js:642
media.view.MediaFrame.Post.media.view.MediaFrame.Select.extend.createStates media-views.js:1611
media.view.MediaFrame.Select.media.view.MediaFrame.extend.initialize media-views.js:1486
media.view.MediaFrame.Post.media.view.MediaFrame.Select.extend.initialize media-views.js:1595
g.View backbone.min.js:36
media.View.Backbone.View.extend.constructor media-views.js:1190
d backbone.min.js:41
d backbone.min.js:41
d backbone.min.js:41
d backbone.min.js:41
wp.media media-models.js:30
wp.media.editor.add media-editor.js:455
wp.media.editor.open media-editor.js:622
(anonymous function) media-editor.js:641
v.event.dispatch jquery.js:2
o.handle.u jquery.js:2
}}}


'''Featured image'''

{{{
Uncaught TypeError: Cannot call method 'on' of undefined media-views.js:319
media.controller.State.Backbone.Model.extend._updateMenu media-views.js:319
w backbone.min.js:8
g.Events.trigger backbone.min.js:10
f.extend.set backbone.min.js:13
g.Model backbone.min.js:12
media.controller.State.Backbone.Model.extend.constructor media-views.js:229
d backbone.min.js:41
d backbone.min.js:41
wp.media.featuredImage.frame media-editor.js:351
$.on.on.wp.media.view.settings.post.featuredImageId media-editor.js:382
v.event.dispatch jquery.js:2
o.handle.u jquery.js:2

}}}

"
23385	22:23:48Z	markoheijnen	comment	3	Works perfect for me. Not sure what goes wrong for you.
23394	12:43:21Z	markoheijnen	comment	2	All those three reasons are not valid for me. Even the first one. Mainly because there are several other ways to retrieve the version number.
23394	21:07:35Z	markoheijnen	comment	7	"Serious, most of the security plugins do stuff that isn't needed at all. If you believe in fake security you should install the plugin.
The only feature I would say that should be in core is limiting the login amount.

Closing the ticket since this kind of conversation shouldn't happen on trac."
23398	21:57:26Z	markoheijnen	comment	2	Only tested in 3.4 and can reproduce it there as well.
23401	00:56:27Z	markoheijnen	comment	1	Interesting idea. You can't use the filter 'image_resize_dimensions'  because of not knowing the image size and a custom image editor for this seems redundant.
23414	16:36:47Z	markoheijnen	comment	1	"You can already do that. When you look at the ""screen options"" (top right of the page) of the menu page you will see you can check ""Link target"""
13392	17:15:27Z	markoheijnen	comment	9	Currently I'm working on a complete redesign for the image editor. That is something what is still needed in my opinion. I guess with the new media dialog in 3.5 even more. I'm now learning backbone to make the image editing as a dialog and play with that. Will be releasing that as a plugin. What hopefully I can release before 3.6
23434	23:15:29Z	markoheijnen	comment	1	"This is default behavior. The image can only be attached to one post. #16349 is somehow duplicated to this one.
Seems it's not really something we should taken care of in core."
23428	15:56:48Z	markoheijnen	comment	3	Maybe doing_it_wrong message?. A PHP notice isn't really telling something.
23436	18:04:06Z	markoheijnen	comment	1	The bug can be explained in the way that when you crop an image that small the edited full image will be the thumbnail. So no need to have two images. The whole flow of editing images needs to be revisited. There are a lot of weird thing going on.
23451	16:53:04Z	markoheijnen	comment	1	"I have no clue what you are talking about. The title is about organizing/tagging but the example is about getting galleries.
I would say that this ticket is invalid since the gallery is a shortcode and there is no way to use a function for getting a gallery. 

Your last sentence seems the old way of doing gallery. In 3.5 you can have multiple galleries and the media file doesn't have to be associated with the page/post"
23451	18:53:37Z	markoheijnen	comment	5	What you describe seems plugin territorium. You can play with the shortcode and using taxonomies in them and then control the display with the filter 'post_gallery'. But everything you describe till now doesn't seem something that should be in core.
23456	13:02:15Z	markoheijnen	comment	1	"I would say that the first part is something the theme should do. Do you also have this issues with Twenty Twelve?

The second part is really plugin territorium for now. There are still some things to do to make it workable."
23457	16:17:25Z	markoheijnen	comment	1	"This isn't something to put on trac. Since you don't describe any bug. The hackers mailinglist seems more appropriate for this kind of discussions.

Also WordPress isn't probably going to move away from TinyMCE. I do note that the paragraph tags everywhere is most likely not a TineMCE thing."
23446	20:45:27Z	markoheijnen	comment	3	That seems valid except that authenticate would be the wrong name. Also the manifest file doesn't help since it has the same flaw. It's a static file.
23446	20:52:08Z	markoheijnen	comment	5	For now it it. I'm still hoping on a RESTfull API for early next year and who knows then it is different. So I guess the patch is the best way to go. Unless the roadmap is clear for the next couple of years.
15155	17:41:02Z	markoheijnen	comment	23	I think we should.
21569	18:52:27Z	markoheijnen	comment	2	"I think we should do this for 3.6 too. The gallery shortcode is broken as it is. #15155 fixes it in a way. I also think that '<br style=""clear: both"" />' should be an argument. So people can easily clean it out or replace it with something else like a <hr>.

"
23471	20:03:24Z	markoheijnen	comment	2	Till now there is nothing to do for this. So this ticket is created to early. Somehow this ticket is also a duplicate of #19570. If that ticket change something like this it should also taken care of XML-RPC
23473	15:20:15Z	markoheijnen	comment	5	If everything still works as before I don't see any reason why not to commit this. The patch also cleans out the code a bit.
23473	15:35:02Z	markoheijnen	comment	7	We optimize/refactor code pretty often. Like this commit [23410]. I don't say we should pick random code and just change it. That is bad and I can see that. This patch makes the code a little bit more readable too. But that just my opinion. If it gets closed as worksforme I'm fine with that too.
18780	13:22:28Z	markoheijnen	comment	5	"The severity of this ticket isn't major. Also it's an enhancement since the only thing we can do is changing the label.

The real issue is the theme you are using. If you look at Twenty Twelve the issue isn't there. I would maybe even say close this ticket as worksforme because of this."
21569	21:28:44Z	markoheijnen	comment	4	"The gallery_output filter doesn't make sense to me. There is already the filter 'gallery_style'.

Your second point isn't inconsistency. That is how WordPress does it. I also don't like it. You are right if you meant the splitter (<br/>). One is with single and the other with double quotes."
21569	22:54:24Z	markoheijnen	comment	6	"The patch isn't going to happen like this. Everywhere in WordPress they use single quotes for HTML. See enqueueing script and styles. So the splitter (<br/>) as an argument is the solution for this ticket.

The filter still doesn't make sense since the <br/> elements should be an argument. Doing a str_replace or a regex is wrong to do. Then you can better use the filter 'post_gallery'."
21569	23:21:04Z	markoheijnen	comment	7	"I added a patch that creates a splitter argument and uses that. I choose for double quotes since it is better fitting here. I also added a additional class: gallery-link-{$attr['link']}. This gist show the reason why: https://gist.github.com/markoheijnen/4635255

@drywallbmb: About your patch. I also should have said that that kind of escaping isn't really what you will find in WordPress core code. It's then better too change from double quotes to single quotes. Unless it isn't posible what you can see in regex's."
23119	19:53:58Z	markoheijnen	comment	220	"I'm seeing the notice Scribu had too. It's in the selectbox. Most likely because of the existing menu.

There is still going on something weird with that. I had to create a new menu first before I could look at the old one. It was just showing the page to create a new menu."
23119	20:08:24Z	markoheijnen	comment	222	Good question. I don't know. The only thing I know is that it isn't anymore. Setting or unsetting the theme location doesn't make a difference
23119	21:54:59Z	markoheijnen	comment	230	"The most funny part with me was that I did add some menu's before but after removing all menu's I somehow couldn't see it anymore.

I disagree that is would be consistent with other UI screens. Those screens are just overviews so the call to action is completely different."
19570	20:14:27Z	markoheijnen	comment	48	"I still don't like the new UI. It gives the post formats too much control over the UI. So my opinion is unchanged about that this should be a plugin. I'm also curious if there are stats to show how many users do really use post formats.

I think it would be good to make it possible to remove most of the code. Like all the code added for 'post format fields' really should use the action 'edit_form_after_title'."
23488	12:51:02Z	markoheijnen	comment	2	Shouldn't this ticket still be open to consider it for 3.5.2?
20205	17:00:02Z	markoheijnen	comment	18	"If it was me I would close the ticket since that function isn't for that kind functionality. We are talking about attachments and by default they don't have any relationship with something else. I would change some of the logic a different way. Since 3.5 we have Imagick support and hopefully in 3.6 Gmagick support and with that you can create an image from a PDF.

So I guess 20205.patch makes the most sense since that would generate fallback when WordPress can't handle it."
23504	17:02:07Z	markoheijnen	comment	12	It's fine that the theme is not intended to have a sidebar but when there is one it should be dealt better. I guess almost everyone would say it is broken how it is now.
20205	17:21:35Z	markoheijnen	comment	19.20	"Replying to [comment:19 jfarthing84]:
> Replying to [comment:18 markoheijnen]:
> > If it was me I would close the ticket since that function isn't for that kind functionality. We are talking about attachments and by default they don't have any relationship with something else.
> 
> You don't think that serving up thumbnails of a video (attachment) should be possible with this function? I don't understand that logic.

WordPress can't serve a frame from a video. You need software on a server for doing that. I'm not sure if Imagick/Gmagick can do that."
20205	17:26:11Z	markoheijnen	comment	22	So in my first comment I did mentioned that [attachment:20205.patch] is good enough to solve this issue.
20205	18:06:40Z	markoheijnen	comment	29	The problem what I have with filtering wp_get_attachment_image_src() is the array output. I guess we should rewrite the function so you can manipulate the $src. I will give it a try now.
20205	18:31:45Z	markoheijnen	comment	31	"The problem with that is that people will break stuff faster. I was thinking if we can make if safer and easier. They can pass the url and then call getimagesize() on it so you can retrieve the width/height.

I also not sure if we should apply the filter on the result of image_downsize()."
23554	08:53:44Z	markoheijnen	comment	2	"I agree with scribu that this isn't the solution. I think we should rethink the this screen over again. I don't think with the current UI there is a great place to put a delete button/link. I guess the best place now is a delete link underneath the image.

One other thing I noticed was that Uploaded images are connected to a theme. I'm not sure if this is great behavior too."
14485	13:35:53Z	markoheijnen	comment	61	"This bug really irritates be. I'm using the taxonomy hidden to control things and when the option ""{$taxonomy}_children"" is empty there isn't really anything to do. Except manually delete the option. What is kind of ugly.

Is there a change to get this in 3.6? and what needs to happen to get this in core."
19570	20:42:16Z	markoheijnen	comment	67	Handeling galleries is ugly and the UI is laking. An user don't care about the shortcode and we don't even show it anymore in the editor. So why we now show it in the input field. Also what happens when an user just edit it to something else?
19570	21:11:05Z	markoheijnen	comment	70	"I already ported the first init commit you did to a github plugin (https://github.com/markoheijnen/post-format-ui). With my own UI flavor on it. The way I look at the current state is that the UX is there but not how it looks. But basically the UX per post status is also missing for now.

Was planning to work on the gallery part this week. I would love to see the gallery code to an hidden input and maybe showing the first image or all images in the UI."
23295	12:51:18Z	markoheijnen	comment	26	#23655 was marked as a duplicate.
23655	12:51:18Z	markoheijnen	comment	1	Duplicate of #23295 since the issue is created there
23295	12:51:55Z	markoheijnen	comment	27	#23656 was marked as a duplicate.
23656	12:51:55Z	markoheijnen	comment	1	Duplicate of #23295 since the issue is created there.
23216	14:37:30Z	markoheijnen	comment	49	/wp-includes/js/heartbeat.min.js is still missing.
23557	15:30:56Z	markoheijnen	comment	21	Can't we just drop masonry for the footer. We really don't need it there. It can easily be arranged with PHP. It seems we only need to add an additional class every 4th item.
23557	17:20:09Z	markoheijnen	comment	24	Ah didn't noticed that it would also drop in. I thought only lines so without masonry it would drop from 4 to 7.
12706	22:09:57Z	markoheijnen	comment	152	I guess this is future release now? Any change we can move this development to a github repository?
10789	19:00:20Z	markoheijnen	comment	18	Closing this since wouldn't really be used and when you need something you can easily build something
23713	17:13:57Z	markoheijnen	comment	1	"You can't scale up an image with WordPress. We check for that. So when upscaling we change the size to the original.Main reason is that it doesn't make really sense since the quality will not be better when upscalling it in the browser.

You can use the filter 'image_resize_dimensions' when you want different logic but this isn't a support channel for that."
23713	19:57:41Z	markoheijnen	comment	3	Well, the description is weird indeed but the whole editor flow should change. The logic isn't weird. Why upscaling an image that gets a bigger file size when you can easily do it in the browser. Probably the same quality but didn't really test it out.
23711	14:56:24Z	markoheijnen	comment	5	"A function that includes the necessary files is a hack to me and should not be in core. So I agree with Sergey on this.
"
23711	15:07:24Z	markoheijnen	comment	8	"Moving the functions to wp-includes shouldn't break things. People who are now using it in the front end only would load unnecessary files.

You are right that the current way of doing is a hack. I rather would duplicate the code because when you include wp-admin files in the front end and it breaks then it is you to blame and not WordPress. See when WP_Screen was introduced. "
23733	23:22:02Z	markoheijnen	comment	1	I need more information then this. Seems like the image metadata is corrupted but no clue why and what. Seems like a plugin is doing something wrong but hard to tell.
23733	11:46:43Z	markoheijnen	comment	3	If you look at the code you see that the error isn't on that place. The data from wp_get_attachment_metadata() isn't how it should. Maybe a plugin does something wrong or you did a replace query on urls. However last one would most likely not show these errors.
23736	12:09:22Z	markoheijnen	comment	1	"It's most likely a bug in your code. I see the result can be empty what would result in $final = false in the top of your code. So the code can run multiple times within the hour. If you only want once every hour then remove:
{{{
if (empty($final)) $final = false;
}}}

Closing as wont-fix since this seems more a support question that can be ask at http://wordpress.org/support/"
23753	13:29:36Z	markoheijnen	comment	4	"I think we discussed this already a few times. Also saving something you need to play later with is stupid to do. The twitter data has a lot of data you don't use at all. There was a ticket somewhere that discussed the json to transient issue and that was closed as wont-fix if I can remember it correctly.

I would move this discussion to the hacker list. It seems more appropriate over there."
18310	17:42:28Z	markoheijnen	comment	10	"Moving to 3.6 since this issue is causing apps to stop working. the isset wouldn't work. It should just be ! $file->guid ?

Also not sure why wp-includes/post.php should be fixed."
23811	18:00:18Z	markoheijnen	comment	1	Moving to 3.6 for future discussions. 
18310	18:23:06Z	markoheijnen	comment	11	never mind on the post.php fix. Understand it now after reading comment 4.
23815	08:20:03Z	markoheijnen	comment	2	A featured image is just an image. So no text would never be displayed. It would however be used as the title of the image.
23752	16:50:37Z	markoheijnen	comment	4	Minified version is not needed in the patch.
23866	22:29:43Z	markoheijnen	comment	2	"First if statement still using spaces instead of tabs. Also no clue if name also works for pages (pagename).

Also for syncing even the slug isn't save since slug can also not be the same. I'm not sure if we should include it or not."
22212	22:52:38Z	markoheijnen	comment	16	Alex, I disagree with that kind of markup since you have two ways to select role. So what happens when you pass the role__in and role arguments? That can trow confusion.
23331	22:22:04Z	markoheijnen	comment	5	Can we commit this? The code is pretty robust because it's almost the same at imagick. We do need user tests. I'm already running this code before 3.5 was even launched and never had issues.
11394	22:52:20Z	markoheijnen	comment	55	Closing this ticket as wont-fix. No traction in two years and it doesn't make sense. I agree with Otto that a regex should do the trick and for now it seems best that a plugin shows how to do this best.
23713	22:54:47Z	markoheijnen	comment	6	I'm fine with this change. Still plugins can change the behavior and the text is wrong again.
23768	23:16:44Z	markoheijnen	comment	5	"Seems plugin territory to me too. Not sure what you want to see as a slideshow. Just output and let the theme fix it?

If you mean as in a jQuery slideshow, I don't see a way how to make this backwards compatible in a good way. Another thing is that WordPress shouldn't force in using a certain slideshow, specially when there are a lot of them."
23594	23:39:24Z	markoheijnen	comment	6	"I aso agree with ocean90 for closing this. Yes categorizing of media would be cool to have but for now it seems a plugin can deal with that. Terms does really help out but you probably need some extra stuff

Also just saying something global what you do now doesn't help. Also not 95% of the users would see this as an issue. No clue what the percentage would be. To me the new dialog does really help out. And if you can be specific on how to make it better please point out but be specific on it."
23039	23:51:58Z	markoheijnen	comment	15	Yes, please do.
23713	11:54:09Z	markoheijnen	comment	8	"changing in every language will happen. We got a lot of great people helping out with that.

To me you are wrong thinking that image_resize_dimensions also does scaling up. Also the function name doesn't imply if it can or can't do upscaling. So as mentioned, if you want a bigger image then original then do this in the browser."
23880	12:27:53Z	markoheijnen	comment	10	"I don't think we should implement this in core. To me a plugin should work on every WordPress installation. That to me does make a plugin good or not. Obviously stuff added to 5.3 and 5.4 is cool to use.

The migration problem isn't one to fix. The reason is that you would need to check the PHP/MySQL version on every request to really do it well and that is a performance penalty."
23880	12:42:25Z	markoheijnen	comment	11.12	"Replying to [comment:11 TJNowell]:
> Replying to [comment:10 markoheijnen]:
> > I don't think we should implement this in core. To me a plugin should work on every WordPress installation. That to me does make a plugin good or not. Obviously stuff added to 5.3 and 5.4 is cool to use.
> > 
> > The migration problem isn't one to fix. The reason is that you would need to check the PHP/MySQL version on every request to really do it well and that is a performance penalty.
> 
> This is naive, while we'd like this in a perfect world, we don't live in a perfect world. PHP 5.3 offers solutions to problems that aren't fixable in 5.2, name spacing being a major example. They weren't added on a whim.
> 
> What's more, other libraries that a plugin might require weren't built for WordPress. What if I built a plugin that by its very nature required use of a library that was built with 5.3 in mind?

Namespacing isn't something a plugin needs. It's helps you out to structure code. So it's not naive thinking when you can make the plugin working on 5.2 by not using namespacing. It wouldn't work less.

Libraries is indeed an issue and I also sometimes use them. However I would never release the plugin on .org. 
"
23713	15:17:58Z	markoheijnen	comment	10	"Allow upscaling in WordPress is never going be supported in core. There are no benefits for doing so. I hope that is clear to you.
Changing the UI (behavior) in 3.6 is also not going to happen since it's an enhancement and it's to late for it.

So if you have other thing to mention how we can fix it. i'm happy to listen."
23880	23:59:06Z	markoheijnen	comment	16	Yeah, WordPress should make the step but I guess we need to wait at least a year. The high percentage 5.3/5.4 is just to low for now. I would close this ticket as worksforme but thats just me.
23880	12:27:44Z	markoheijnen	comment	21	"And those developers should look bad since they didn't add a nice message on activation what MikeSchinkel describes. I just find that plugins need to solve this them self. PHP and MySQL is one thing but you still can have other server configurations that are needed.

The big problem is that most people don't know the versions they run on. Putting an error can have some users say something to their hosts that they need a newer PHP version but most people will find another plugin. Forcing hosting to upgrade is a good thing but I doubt this ticket will help to that.

I do think that this discussion should move to the hacker list. Since we don't discuss the code but the need of the feature. "
19570	12:43:54Z	markoheijnen	comment	120	"When you add anew post you don't have text for standard post but when you click on a post format and go back you will see ""Add a title and use the editor to compose your post."".

"
19570	16:35:49Z	markoheijnen	comment	123	Why not just removing the text for standard post. Mainly since it's not a post format. I would describe it as no post format so the text seems  unnecessary to me.
23880	23:37:10Z	markoheijnen	comment	32	"Adding this to WordPress doesn't bring us somewhere. Users will find other plugins to solve the same issue they have, developers will make plugins users can't use and hosters don't have a clue it exists and hava a multi year upgrade plan.

I also don't see anything why rmccue is happy to close it. He recommend it and that is fine.


I'm closing this ticket for multiple reasons:
 - more then 60% is running PHP 5.2 and if you want to build something useful try to let it work on PHP 5.2. So in general try to let it work. If it's for clients you know the server so these checks aren't needed.
 - PHP and MySQL aren't the only thing a plugin needs a version for. Do we also need an extra line for all software that need to be installed? Like GD or Imagick is a must. Curl need to be installed. etc.
 - You can easily implement this yourself without performance cost. Maybe even create a central plugin that takes care of it.
 - It's nothing to do with preparation since PHP 5.2 code will work perfectly on 5.3. It's not that it breaks."
21419	12:41:44Z	markoheijnen	comment	3	Doesn't seem to be an issue anymore
21493	12:45:49Z	markoheijnen	comment	3	It's fixed for core trac not for others. Closing as fixed since the ticket was core specific
23880	12:59:22Z	markoheijnen	comment	35	This was probably also a duplicate of #12260
14421	13:38:31Z	markoheijnen	comment	3	Shouldn't this be closed then?
15874	13:41:43Z	markoheijnen	comment	3	Can this be closed? Seems that is was fixed at some point.
23950	17:30:05Z	markoheijnen	comment	5	I do agree with alexvorm2. Also the current situation feels bad. To me at this moment the WordPress development already is controlled by the companies that have their employees contribute a lot to core. I rather first tackle that issue and with that discuss how WordPress can show the appreciation to the companies.
23968	22:16:47Z	markoheijnen	comment	2	The first link you passed was a hosting issue and there is a big change that your issue is also the cause of your hosting company. I guess you better can use the forum and provide the PHP error log over there.
23221	15:09:41Z	markoheijnen	comment	4	Added a patch to solve the problem with the help of site_url what odisant mentioned. Would love to see this in 3.6.
23221	16:59:38Z	markoheijnen	comment	6	Added a patch that does work. I don't think get_site_option() will cost a performance penalty since it does get cached.
23039	11:53:39Z	markoheijnen	comment	19	Can we close this ticket as fixed?
21811	12:02:24Z	markoheijnen	comment	6	#23564 was marked as a duplicate.
23564	12:02:24Z	markoheijnen	comment	3	Duplicate of #21811.
21294	12:14:30Z	markoheijnen	comment	3	What is the question here? What kind of changed do you need?
21294	12:22:35Z	markoheijnen	comment	5	"Ah that way. WordPress doesn't do upscaling. In this case I'm not sure what the right solution would be.

#23713 is related"
21294	12:27:53Z	markoheijnen	comment	7	You can already enable it by using the link mentioned in that ticket: http://wordpress.org/support/topic/wp-351-wp-image-editor-scaling-up-images-does-not-work?replies=3.
21668	12:52:45Z	markoheijnen	comment	13	#19931 was marked as a duplicate.
19931	12:52:45Z	markoheijnen	comment	16	Duplicate of #21668.
19393	13:26:54Z	markoheijnen	comment	37	Remove has patch since the changes of 3.5 but would be cool to add this in 3.7 :)
19118	13:49:50Z	markoheijnen	comment	8	"I'm closing this ticket since my opinion isn't changed on this. Also moving the check from image_resize_dimensions() would allow upscaling when it is used in plugins. Upscale support is fine but it should be consistent.

Also the patch isn't valid anymore since image_resize is deprecated and has been rewritten to use WP_Image_Editor"
21811	14:00:02Z	markoheijnen	comment	8	This isn't going to be fixed in 3.6 since it is a feature. Also it does take a decent amount of time to get it working. So I would love to get it working for 3.7. And you can help out too if you want. It is easy to build a plugin around it.
16435	14:25:02Z	markoheijnen	comment	5	Is this still relevant with the changes of 3.5?
15668	14:34:24Z	markoheijnen	comment	9	Since all the changes of 3.5 this patch isn't valid anymore. Not sure if we can close this ticket in favor of #22100.
15149	14:44:35Z	markoheijnen	comment	9	Any change that you can look at the changes that are made in 3.5 for WP_Image_Editor. We do unset the path in multi_resize since it was causing bugs and wasn't there before.
13411	14:57:16Z	markoheijnen	comment	5	Fixed in #6821. Crappy for GIF's under GD. See #13461
13014	15:03:10Z	markoheijnen	comment	3	Related: #21294
21294	15:03:29Z	markoheijnen	comment	9	Related: #13014
10532	15:20:48Z	markoheijnen	comment	4	The filter can't be used for getting the image resource because of the changes in #6821. Closing this ticket since you now can create your own Image Editor. If there is something I missed please create a new ticket with details how it should now be implemented.
10492	15:59:06Z	markoheijnen	comment	4	If I'm right wp_get_attachment_thumb_file() is missing back compat right?
23066	13:09:05Z	markoheijnen	comment	11	If I seeing ti wrong. Aren't you now always set it as a multisite installation?
24010	19:03:16Z	markoheijnen	comment	1	Not to be rude but since when do we care to work nicely with other plugins? Isn't it the task for plugins developers to build a upgrade strategy?
24010	20:02:59Z	markoheijnen	comment	5	I can be wrong but we didn't really used the code of that plugin and I have seen more plugins creating an UI for post formats. Not saying we shouldn't do it. I'm curious now how we did it with 3.0 for menu's.
24047	19:54:56Z	markoheijnen	comment	3	"I don't see the need of line numbers in WordPress. The use case seems not that bug.

However I do think there is a place in core for keeping the scroll position."
24067	18:36:36Z	markoheijnen	comment	1	It's still in beta so it really depends on when it's going to be released. Who knows it will end up in 3.7 but hard to say.
24067	19:15:16Z	markoheijnen	comment	3	Yes, this ticket will be used to track the changes
23025	16:54:50Z	markoheijnen	comment	3	Why dropping XML-RPC? Why not changing the text a bit by dropping only Atom Interface and adding the mobile apps to it
24013	16:02:30Z	markoheijnen	comment	12	Solution from kovshenin seems fine to me. New post formats can't be created by a developer and only by core. Also in your solution you maybe don't need to write CSS but you do need to write JS.
20787	20:29:59Z	markoheijnen	comment	7	"It depends on the image really. We shouldn't try to auto fix images that aren't broken. Also that image on Mark's site isn't that blurry at all.
Moving to Gmagick or Imagick seems a better thing to do. They resize better."
23331	20:50:14Z	markoheijnen	comment	8	Don't see why it needs to get another flow. Loading the editors isn't something really heavy.
24152	21:02:35Z	markoheijnen	comment	8	+1 for close it too. For dependencies it can be a JSON file but then use a file only for that.
23993	21:20:11Z	markoheijnen	comment	3	"I don't get why we should do this. The admin itself doesn't really work on small devices. So I really think this should be closed.
The only thing that makes sense is what Jake mentioned and that is to make it HiDPI ready."
24164	21:28:26Z	markoheijnen	comment	18	"I don't get why it should be deprecated. get_permalink() isn't a theme function so to me it shouldn't have to follow the pattern.
I use it a lot in plugins for all kinds of things and it has most of the time nothing to do with a theme."
23171	21:31:23Z	markoheijnen	comment	6	I don't know what the rules are for adding oEmbed support but this seems like a rare case someone will use it. So doesn't a plugin makes more sense. Or is the penalty not that high so we can just add it when a platform supports it?
24193	21:46:00Z	markoheijnen	comment	5	"I recommend for closing this ticket. There should be a better way of protecting but what this ticket is about isn't the way.
Having a strong password makes sense and should be encouraged."
24215	22:12:17Z	markoheijnen	comment	2	I really think this is a feature that shouldn't be in core. Also it has dependencies to taxonomie meta data and somewhere an ability to set it for archives.
24215	22:28:25Z	markoheijnen	comment	4	"Taxonomy doesn't have a meta table (yet). So no ability to save this data. For archives there is no representation in wp-admin. So options are missing.

closing it since I don't see why this should be in core. To me this is a rare case and there are plugins doing this."
24215	22:52:33Z	markoheijnen	comment	7	"How many sites with a SEO plugin really using that plugin? ;) Installing a plugin is easy to do but it doesn't make sense to have. WordPress has a 80% rule. When 80% of the user base would use it then the change exists that it will be included. Like on all my clients site I don't install any kind of SEO plugin. I do write some specific logic for the site (theme).

Also it doesn't make sense to have a special thank you page. That seems the mistake and noindex/nofollow is just a bandage on the issue. About archive pages I don't know but it sounds weird."
24251	19:58:52Z	markoheijnen	comment	7	"Let's add this in 3.7 so we can decide how SVG's should be dealt with. Only adding it as a file format is just to limited for me.
If it's an image then we should try to have it including as an image"
24271	15:24:18Z	markoheijnen	comment	1	See #23880. To me this is something bad since it doesn't help a lot for people upgrading to 5.3 or higher. They probably go find another theme/plugin that does the same job.
11895	11:22:54Z	markoheijnen	comment	15	Hopefully in version 3.7 but the patch does work but forget custom image sizes. Also the whole editing experience need to change to make it better.
5809	11:31:27Z	markoheijnen	comment	16	Shouldn't this be punted to 3.7-early? Seems as something we want to deal early in a release.
20201	11:40:54Z	markoheijnen	comment	8	Can we commit this?
23811	11:55:29Z	markoheijnen	comment	4	"That doesn't exactly works the same. Your patch only works when WP_DEBUG is true and my one only works when WP_DEBUG is false.

I guess the issue here is that the server definition is display_errors: 1. So I guess both patches make sense to commit then?"
18310	14:02:45Z	markoheijnen	comment	12	"In [changeset:""1278/tests""]:
{{{
#!CommitTicketReference repository=""tests"" revision=""1278""
Add test to check if guid isn't empty when not provided. See #18310
}}}"
18310	14:08:16Z	markoheijnen	comment	13	It's ready to be committed. Only need a pair of eyes on setting guid when it was empty.
24280	18:19:58Z	markoheijnen	comment	1	"If I look at _insert_post() what is used in the main XML-RPC methods you will see both checks there too.

Guess you mean that with elsewhere? or do you mean somewhere else in core?"
24280	20:35:43Z	markoheijnen	comment	3	wp.* methods are leading to me. So I rather fix blogger_newPost and mw_newPost if needed.
22195	09:03:50Z	markoheijnen	comment	2	I don't see the issue you mentioned for resetting parameters since because it's defined this way no extra ones are getting added. Can you explain what you exactly want to reach?
24336	16:37:43Z	markoheijnen	comment	2	You can't pass array key names through the XML-RPC. See all other methods
24336	18:07:17Z	markoheijnen	comment	4	"It doesn't make sense what you have now. As you can see in the xmlrpc.xml there isn't defined what the key is of the values. So there is no reason that the args should have those args.

I only can see it isn't a core issue. Otherwise the mobile apps also should have issues. No clue how you get those vars."
23221	23:27:44Z	markoheijnen	comment	7	"Closing as invalid. Reason is that the path isn't correctly set.

So check the following
 - PATH_CURRENT_SITE is something like /wp/
 - All rows of wp_blogs don't have the path like /wp/
 - Path of the site in wp_site
 - siteurl in wp_sitemeta
 - siteurl of the single site in wp_options of wp_x_options"
24380	12:07:00Z	markoheijnen	comment	2	I thought we did added it but it was never in core before. Also you need to add a patch and not the whole file.