XMLRPC wp.newPost method ignores dates
-
Hi,
As of a couple of days ago, it appears that a bug has been introduced into the functionality of the XMLRPC method “wp.newPost”.
It doesn’t matter whether an explicit date is set or none at all – it appears that this method will always set the “post_date” to be the Jan 1st 1970. To confirm, setting explicit dates is ignored.
Firstly, I don’t see why it would make sense to default all dates to 1st Jan 1970 – surely it should default to the current date if no explicit date is set? Secondly, if an explicit date is set, it should honour this.
The blog I need help with is: (visible only to logged in users)
-
I’ll tag this thread for a Staff follow-up. Please subscribe to the thread so you are notified when they respond and please be patient while waiting.
-
Hi there,
I just tested this issue with an Offline Editor that uses XML-RPC, and the date I selected was used on my post. Are you using the BlogPad Pro app? It’s possible there’s a bug in the app that needs to be ironed out.
If you need, there are details about the WordPress XML-RPC API on this WordPress.org support page:
http://codex.wordpress.org/XML-RPC_WordPress_API/Posts
You may want to check in on the WordPress.org support forums for more help with that issue: http://wordpress.org/support/
-
Hi rachelmcr,
I am the author of BlogPad Pro and can assure you that this isn’t a bug in BlogPad Pro! ;)
This functionality worked just fine without any changes to the app, and something has changed at WordPress.com that has caused this. The same functionality on a self-hosted blog has absolutely no issues.
Can I ask what offline editor you used to check this, and are you sure that it used the “wp.newPost” method? The “wp.editPost” method is fine, it’s just when creating the new Post.
Thanks for the link to the XMLRPC documentation, but as I said before, whether we set the “post_date_gmt” or “post_date” parameters, they are ignored. Also, why would this default to setting the date to be 1st Jan 1970? That’s 44 years ago! :) Surely the default should be to the current date?
I would appreciate some urgent help here. We are having to deal with quite a few support requests here relating to this issue when the issue is clearly caused by some recent changes on your server.
Thanks for your help.
-
I have been using the BlogPad Pro app for over a year. In the last few days I thought I had lost my “draft” posts that I was working on. I only just found them at the very beginning of my blog dated January 1, 1970. The people at BlogPad Pro have NOT recently updated the app although they are promising to do that soon. It would seem to me that something WordPress has done is leading to this problem.
-
Hi there,
I tested with a couple different editors recommended on our support page here: Offline Editing
However, I’m checking now with our team to investigate the issue on our end. I’ll let you know as soon as I have more information about it.
-
Hi again,
Could you provide the values you’re sending for post_date and post_date_gmt for both wp.newPost and wp.editPost? We can take a look at it to see what might be going wrong. If there is a bug on our end, that’ll help our team investigate it.
-
Hi,
Thanks for looking into this.
When creating a post, we set the post_date_gmt. Here’s a typical value:
<member><name>post_date_gmt</name><value><dateTime.iso8601>20140630T08:46:25</dateTime.iso8601></value></member>
I’ve run some more tests manually, and regardless of whether we set “post_date_gmt” or not when first creating the post using “wp.newPost”, the result is always:
19700101T00:00:00NOTE: In our opinion, if no date is set when creating a new post, the date should default to the current date! We can see no valid reason why this should default to 1st Jan 1970.
Anyway, when editing that same post using “wp.editPost”, if the “post_date_gmt” is not set, then the date is not changed, as would be expected. However, if we set it using the example value above, the date is changed accordingly. Hence why we believe the issue is with creating the post via “wp.newPost”.
If you give me an email address that I can contact you by, I can send you the actual XML that I’m using to test this. One can manually test the XMLRPC API using a tool such as Fiddler.
-
Hi rachelmcr,
I’ve sent over 3 XML files via email and described what is happening and what *should* be happening. The subject line is:
BUG: XMLRPC wp.newPost method ignores dates – FAO “rachelmcr”This might be stating the obvious, but wouldn’t it make sense to look at the last code changes that you guys did relating to creating a new post via XMLRPC? Surely that way you can see why the date is being set to 1st Jan 1970? As I have said a few times now, I see no valid reason why someone would wish to create a post with that date! If no valid date is set, surely it should default to the current GMT date?
-
Thanks for sending over those files. Our team did indeed look over the latest code changes and didn’t see anything that would cause this problem, but we’re hoping that looking at the values you’re sending in combination with the code on our end will clarify what’s going wrong here.
I’ll let you know as soon as we have more details about the issue!
-
Hello,
I can verify that our application has begun experiencing the same issue with in the last few days as well. We are hitting your API via a 3rd party library (RubyPress) that we have integrated into our Rails application. We are submitting valid UTC/GMT times to the api, however, theses values are being ignored upon submission via wp.newPost. My hunch is that it is highly unlikely that two completely separate libraries and / or applications are experiencing the same issue and it not having something to do with a change in the WP API.
For reference, the 0:00:00 01/01/1970 is the beginning of ‘Unix Time’. It seems that it’s ignoring the submitted time and is setup to provide the beginning of “time” if that is missing.
I would appreciate some further investigation because this is definitely a problem for the operation of our business.
-
Hi there,
Our team is investigating some changes that were made to the wp.newPost method, looking for the exact cause of this issue and the best solution to make sure your apps continue working. I apologize for the trouble this caused and will get you an update as soon as I have more details.
-
Hi rachelmcr,
Is this still not resolved? Surely it can’t take this long to investigate and fix such a severe breakage?
-
Hi there,
Sorry about that! One of our developers fixed this yesterday and replied to your email, but I forgot to post the update here for everyone:
The changes were made as part of testing a fix for a different issue – https://core.trac.wordpress.org/ticket/28601
We often run the latest changes from WordPress core before releases are made so that we can catch issues like this before they affect every WordPress release.
We’ve deployed the latest changes on that ticket today too and this should fix the issues you were seeing, can you test again against WordPress.com and let us know how you get on.
If anyone continues to experience trouble with this, please let me know.
-
rachelmcr, I can confirm. I received an email from one of your engineers, and the issue appears to have been fixed now.
I will do more detailed tests later, but for now I know that our functionality is no longer broken.
Thanks!
- The topic ‘XMLRPC wp.newPost method ignores dates’ is closed to new replies.
WordPress.com Forums 