Hello,
There are some problems with the blogging bundle with Wordpress 2.2. Pings and Comments are always set to off. I know it has been mentioned before and it seems to be a bug in WP. I didn't see a bug report on the WP trac and am not really too familiar with the API, so could you clarify what's causing this and whether it really is a WP bug so I can submit a bug report to the WP guys?
Thanks!
Christoph
On 9. Jun 2007, at 19:53, Christoph Koehler wrote:
There are some problems with the blogging bundle with Wordpress 2.2. Pings and Comments are always set to off.
Did you check your WordPress preferences? You can set the default state for new posts.
I know it has been mentioned before and it seems to be a bug in WP. I didn't see a bug report on the WP trac and am not really too familiar with the API, so could you clarify what's causing this and whether it really is a WP bug so I can submit a bug report to the WP guys?
I haven’t heard about -- personally I am using 2.1.3 and does not have such problems.
On Sun, 10 Jun 2007 03:55:32 -0500, Allan Odgaard throw-away-1@macromates.com wrote:
On 9. Jun 2007, at 19:53, Christoph Koehler wrote:
There are some problems with the blogging bundle with Wordpress 2.2. Pings and Comments are always set to off.
Did you check your WordPress preferences? You can set the default state for new posts.
Yeah, they are enabled by default. Since 2.2, if I just submit it the first time, the defaults kick in and pings and comments are enabled and it shows in TM. Once I submit the post again to change something for example, with the Ping and Comment headers already there, they will be turned off even if they were set to On.
I know it has been mentioned before and it seems to be a bug in WP. I didn't see a bug report on the WP trac and am not really too familiar with the API, so could you clarify what's causing this and whether it really is a WP bug so I can submit a bug report to the WP guys?
I haven’t heard about -- personally I am using 2.1.3 and does not have such problems.
I only heard one other person refer to it, so I am wondering what's wrong; I'd expect a bigger outcry if it were WP, but nothing's impossible. Just trying to make sure where the bug lies.
Christoph
On 10. Jun 2007, at 14:57, Christoph Koehler wrote:
Did you check your WordPress preferences? You can set the default state for new posts.
Yeah, they are enabled by default. Since 2.2, if I just submit it the first time, the defaults kick in and pings and comments are enabled and it shows in TM. Once I submit the post again to change something for example, with the Ping and Comment headers already there, they will be turned off even if they were set to On.
Okay, so the problem is that posts which explicitly sets comments to ‘on’ actually cause them to be turned off.
When you re-post, try remove the comments and pings headers.
Though it does sound like a WP bug.
On Sun, 10 Jun 2007 10:49:50 -0500, Allan Odgaard throw-away-1@macromates.com wrote:
On 10. Jun 2007, at 14:57, Christoph Koehler wrote:
Did you check your WordPress preferences? You can set the default state for new posts.
Yeah, they are enabled by default. Since 2.2, if I just submit it the first time, the defaults kick in and pings and comments are enabled and it shows in TM. Once I submit the post again to change something for example, with the Ping and Comment headers already there, they will be turned off even if they were set to On.
Okay, so the problem is that posts which explicitly sets comments to ‘on’ actually cause them to be turned off.
When you re-post, try remove the comments and pings headers.
Yep that works, thanks!
Though it does sound like a WP bug.
I will post a bug report over at WP, will see if they can fix that. Where can I take a look to see what exactly is being sent to the server? That might help them debug it.
Thanks for your work Allan! You made a great product!
Christoph
On 11. Jun 2007, at 00:35, Christoph Koehler wrote:
[...]
Though it does sound like a WP bug.
I will post a bug report over at WP, will see if they can fix that. Where can I take a look to see what exactly is being sent to the server? That might help them debug it.
In (WordPress/) xmlrpc.php you can set $xmlrpc_logging to 1.
On 11. Jun 2007, at 00:35, Christoph Koehler wrote:
Joseph Scott: For context, the thread starts here: http:// lists.macromates.com/pipermail/textmate/2007-June/020386.html -- I have white-listed your address incase you want to follow-up to the ML address (w/o being subscribed).
Though it does sound like a WP bug.
I will post a bug report over at WP, will see if they can fix that. Where can I take a look to see what exactly is being sent to the server? That might help them debug it.
Looking at the diff of xmlrpc.php between 2.1.3 and 2.2, it does seem they broke it (or made some change I can’t really understand).
Basically when you set comments: on/yes/y/1 in TextMate then we send ‘mt_allow_comments=open’ to WordPress (to all other systems we send ‘mt_allow_comments=1’).
WordPress 2.2 has the following line (and 2.1.3 has something similar):
$allow_comments = ("open" == $page->comment_status) ? 1 : 0;
So it seems they still expect us to send ‘open’ instead of ‘1’. But then they also have this (new for 2.2):
$comment_status = (int) $content_struct["mt_allow_comments"];
So here they basically coerce the ‘open’ string into an integer. They do similar for pings. And just for the records:
% php -r 'echo (int)"open";' 0
I have cc’ed Joseph Scott on this letter, he is involved with the WordPress XML-RPC interface, so he might be able to comment as to whether or not this is a bug.
On Jun 11, 2007, at 2:15 AM, Allan Odgaard wrote:
On 11. Jun 2007, at 00:35, Christoph Koehler wrote:
Joseph Scott: For context, the thread starts here: http:// lists.macromates.com/pipermail/textmate/2007-June/020386.html -- I have white-listed your address incase you want to follow-up to the ML address (w/o being subscribed).
Though it does sound like a WP bug.
I will post a bug report over at WP, will see if they can fix that. Where can I take a look to see what exactly is being sent to the server? That might help them debug it.
Looking at the diff of xmlrpc.php between 2.1.3 and 2.2, it does seem they broke it (or made some change I can’t really understand).
Basically when you set comments: on/yes/y/1 in TextMate then we send ‘mt_allow_comments=open’ to WordPress (to all other systems we send ‘mt_allow_comments=1’).
Ahhh, sending a value of 'open' would certainly be the issue there. Before I go doctoring this up, is there list of all the potential values that are sent for mt_allow_comments? Is it just 'open' and 'closed'?
WordPress 2.2 has the following line (and 2.1.3 has something similar):
$allow_comments = ("open" == $page->comment_status) ? 1 : 0;So it seems they still expect us to send ‘open’ instead of ‘1’. But then they also have this (new for 2.2):
$comment_status = (int) $content_struct["mt_allow_comments"];So here they basically coerce the ‘open’ string into an integer. They do similar for pings. And just for the records:
% php -r 'echo (int)"open";' 0I have cc’ed Joseph Scott on this letter, he is involved with the WordPress XML-RPC interface, so he might be able to comment as to whether or not this is a bug.
The above looks about right. With a little work I'm we'll be able to accommodate non-int values that are being sent, I'd like to know exactly what those are before I start adding more code though.
Thanks for bringing this to my attention. I'm happy to work resolving any WordPress XML-RPC problems, bugs, feature questions, etc.
While I'm here, let me mention some of the basic documentation for the new wp.* XML-RPC methods:
http://codex.wordpress.org/XML-RPC_wp
-- Joseph Scott http://joseph.randomnetworks.com/
On 11. Jun 2007, at 18:40, Joseph Scott wrote:
[...] Looking at the diff of xmlrpc.php between 2.1.3 and 2.2, it does seem they broke it (or made some change I can’t really understand).
Basically when you set comments: on/yes/y/1 in TextMate then we send ‘mt_allow_comments=open’ to WordPress (to all other systems we send ‘mt_allow_comments=1’).
Ahhh, sending a value of 'open' would certainly be the issue there. Before I go doctoring this up, is there list of all the potential values that are sent for mt_allow_comments? Is it just 'open' and 'closed'?
Well, actually the “standard” is 1 or 0 -- but WordPress has been using “open” and “closed” in the past. So ideally you’d change it to accept both values, then long-term (i.e. when users are on WP 2.2+) we can remove the special-casing for WP.
[...] I have cc’ed Joseph Scott on this letter, he is involved with the WordPress XML-RPC interface, so he might be able to comment as to whether or not this is a bug.
The above looks about right. With a little work I'm we'll be able to accommodate non-int values that are being sent, I'd like to know exactly what those are before I start adding more code though.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
As a temporary fix until this is resolved officially,
Removing the (int) cast in if(isset($content_struct["mt_allow_comments"])) { $comment_status = (int) $content_struct["mt_allow_comments"]; } solved the issue of comments.
Adding if(isset($content_struct["mt_allow_pings"])) { $ping_status = $content_struct["mt_allow_pings"]; } just below the above block seems to solve the issue with pings.
This will take care of editing posts.
For taking care of new posts, replace if(isset($content_struct["mt_allow_comments"])) { switch((int) $content_struct["mt_allow_comments"]) { case 0: $comment_status = "closed"; break; case 1: $comment_status = "open"; break; default: $comment_status = get_option("default_comment_status"); break; } }
if(isset($content_struct["mt_allow_pings"])) { switch((int) $content_struct["mt_allow_pings"]) { case 0: $ping_status = "closed"; break; case 1: $ping_status = "open"; break; default: $ping_status = get_option("default_ping_status"); break; } }
with if(isset($content_struct["mt_allow_comments"])) { $comment_status = $content_struct ["mt_allow_comments"]; }
if(isset($content_struct["mt_allow_pings"])) { $ping_status = $content_struct ["mt_allow_pings"]; }
Seems to work okay for me. Could break things for you. Use it at your own risk!! :)
The working file can be accessed at http://www.doe.carleton.ca/~pavan/blog/xmlrpc.txt
Just rename it from .txt to .php and give it a shot.
Pavan
Hi All,
Does anyone know if there's a modified version of TM's "Convert Selection to Entities Excl. Tags" command which does not also convert quotes within a tag?
For example, select this text in a TextMate HTML document:
<p class="subhead">Convert this paragraph’s “curly quotes”.</p>
Then choose Bundles -> HTML -> Entities -> Convert Selection to Entities Excl. Tags. The result is:
<p class="subhead">Convert this paragraph’s “curly quotes”.</p>
Thanks in advance.
--Cliff
On 14. Jun 2007, at 03:50, Cliff Joyce wrote:
Does anyone know if there's a modified version of TM's "Convert Selection to Entities Excl. Tags" command which does not also convert quotes within a tag?
It should spare quotes around attribute values, for me:
<p class="subhead">Convert this paragraph’s “curly quotes”.</p>
↓
<p class="subhead">Convert this paragraph’s “curly quotes”.</p>
Btw: PLEASE remember to use your mailers “New Message” rather than replying to an existing thread. By doing the latter you get an “In- Reply-To: 50EBD632-5AE5-466E-A4D7-D5A7F0189F3A@doe.carleton.ca” header in your letter which makes it appear the wrong place both in the archives and in many mail programs.
There also seems to be new support in the xmlrpc for headers like wp_slug which we may want to incorporate into the blogging bundle (I don't think this existed before, sorry if this comment is poorly researched...).
I have a new version of my UTW-rpc plugin and Autotag bundle for TextMate in the works right now that is compatible with the Simple Tagging plugin as well as the new features in the 2.2 xmlrpc. If anyone is interested in beta testing, let me know.
The suggested changes to fix the comments/pings could be incorporated into the plugin to allow for an external solution to the problem without editing the xmlrpc.php which would be overwritten by upgrades... the plugin overrides the new post and edit post functions in the xmlrpc to incorporate tagging options but functions fine without tagging plugins installed and therefore could fix multiple problems until the problem is fixed in the code itself.
Brett
On Jun 13, 2007, at 3:23 PM, Allan Odgaard wrote:
On 11. Jun 2007, at 18:40, Joseph Scott wrote:
[...] Looking at the diff of xmlrpc.php between 2.1.3 and 2.2, it does seem they broke it (or made some change I can’t really understand).
Basically when you set comments: on/yes/y/1 in TextMate then we send ‘mt_allow_comments=open’ to WordPress (to all other systems we send ‘mt_allow_comments=1’).
Ahhh, sending a value of 'open' would certainly be the issue there. Before I go doctoring this up, is there list of all the potential values that are sent for mt_allow_comments? Is it just 'open' and 'closed'?
Well, actually the “standard” is 1 or 0 -- but WordPress has been using “open” and “closed” in the past. So ideally you’d change it to accept both values, then long-term (i.e. when users are on WP 2.2 +) we can remove the special-casing for WP.
[...] I have cc’ed Joseph Scott on this letter, he is involved with the WordPress XML-RPC interface, so he might be able to comment as to whether or not this is a bug.
The above looks about right. With a little work I'm we'll be able to accommodate non-int values that are being sent, I'd like to know exactly what those are before I start adding more code though.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 14. Jun 2007, at 14:59, Brett Terpstra wrote:
There also seems to be new support in the xmlrpc for headers like wp_slug which we may want to incorporate into the blogging bundle (I don't think this existed before, sorry if this comment is poorly researched...). [...]
This is the post name, right? I.e. what would normally be auto- generated from the title.
Yes, I think we should put this in the blogging bundle, since especially when I use dashes in the title (e.g. plug-in) I want to not have the slash in the permalink.
Does anyone know if this is supported by other blog systems?
Not sure about other platforms, but for Wordpress all that's required in the blogging bundle is:
@post['wp_slug'] = @headers['slug'] if @headers['slug']
and an addition of a slug header to the Language files. If there is support in other blogging platforms, a little more logic would be sensible and a less WP specific title than "Slug". Probably stating the obvious, I suppose.
Brett
On Jun 17, 2007, at 8:06 PM, Allan Odgaard wrote:
On 14. Jun 2007, at 14:59, Brett Terpstra wrote:
There also seems to be new support in the xmlrpc for headers like wp_slug which we may want to incorporate into the blogging bundle (I don't think this existed before, sorry if this comment is poorly researched...). [...]
This is the post name, right? I.e. what would normally be auto- generated from the title.
Yes, I think we should put this in the blogging bundle, since especially when I use dashes in the title (e.g. plug-in) I want to not have the slash in the permalink.
Does anyone know if this is supported by other blog systems?
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Jun 13, 2007, at 1:23 PM, Allan Odgaard wrote:
On 11. Jun 2007, at 18:40, Joseph Scott wrote:
[...] Looking at the diff of xmlrpc.php between 2.1.3 and 2.2, it does seem they broke it (or made some change I can’t really understand).
Basically when you set comments: on/yes/y/1 in TextMate then we send ‘mt_allow_comments=open’ to WordPress (to all other systems we send ‘mt_allow_comments=1’).
Ahhh, sending a value of 'open' would certainly be the issue there. Before I go doctoring this up, is there list of all the potential values that are sent for mt_allow_comments? Is it just 'open' and 'closed'?
Well, actually the “standard” is 1 or 0 -- but WordPress has been using “open” and “closed” in the past. So ideally you’d change it to accept both values, then long-term (i.e. when users are on WP 2.2 +) we can remove the special-casing for WP.
I've got a patch for this that will support 1, open, 0 and closed. I need to run it through some additional tests and then I'll get it to the wordpress.com and submit it to wordpress.org for inclusion.
[...] I have cc’ed Joseph Scott on this letter, he is involved with the WordPress XML-RPC interface, so he might be able to comment as to whether or not this is a bug.
The above looks about right. With a little work I'm we'll be able to accommodate non-int values that are being sent, I'd like to know exactly what those are before I start adding more code though.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
My patch covers this issue as well, the two will be essentially identical.
-- Joseph Scott http://joseph.randomnetworks.com/
I've trimmed the quotes.
On Jun 13, 2007, at 1:23 PM, Allan Odgaard wrote:
Well, actually the “standard” is 1 or 0 -- but WordPress has been using “open” and “closed” in the past. So ideally you’d change it to accept both values, then long-term (i.e. when users are on WP 2.2 +) we can remove the special-casing for WP.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
I've deployed the patch for this to all wordpress.com blogs. There is also a ticket for wordpress.org:
http://trac.wordpress.org/ticket/4469
I'll follow up and make sure the committers there are aware of it.
Thanks for point this out and doesn't hesitate to contact me about any other questions/issues/bugs that come up in XML-RPC for WordPress.
-- Joseph Scott http://joseph.randomnetworks.com/
On Thu, 14 Jun 2007 19:58:46 -0500, Joseph Scott joseph@automattic.com wrote:
I've trimmed the quotes.
On Jun 13, 2007, at 1:23 PM, Allan Odgaard wrote:
Well, actually the “standard” is 1 or 0 -- but WordPress has been using “open” and “closed” in the past. So ideally you’d change it to accept both values, then long-term (i.e. when users are on WP 2.2+) we can remove the special-casing for WP.
Btw: have a look at both NewPost and EditPost -- it seems NewPost sets comment_status to open/closed where EditPost sets it to the value of mt_allow_comments casted to an int. When using comment_status, it is tested against the string value 'open'. So regardless of value sent (for mt_allow_comments) it will always disable comments when editing a post.
I've deployed the patch for this to all wordpress.com blogs. There is also a ticket for wordpress.org:
http://trac.wordpress.org/ticket/4469
I'll follow up and make sure the committers there are aware of it.
Thanks for point this out and doesn't hesitate to contact me about any other questions/issues/bugs that come up in XML-RPC for WordPress.
Thanks for the quick action! That's really amazing! I tested the patch on my local install and comments work fine now, but pings are still always disabled.
Thanks again!
Christoph
-
Allan Odgaard -
Brett Terpstra -
Christoph Koehler -
Cliff Joyce -
Joseph Scott -
Pavan Gunupudi