Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#48886 closed defect (bug) (duplicate)

Posting via XMLRPC (eg. WordPress Android App) causes post_date to have a doubled substitution by timezone

Reported by: noyle's profile noyle Owned by:
Milestone: Priority: normal
Severity: major Version: 5.3
Component: Date/Time Keywords:
Focuses: Cc:

Description

Although the title says XMLRPC, I think the real defect is in other components.

The the following is only observed when posting a post from using a latest WordPress Android App (https://apps.wordpress.com/mobile/), i.e., from XMLRPC. There's no such issue to post from WordPress's own web interface.

I only tried the Android one, but I think the problem is in WordPress not the App. I use NGINX to capture what the App POST and will post the request body in a separated comment.

Set the timezone setting in WordPress as UTC-6. Make a post from web interface and then via XMLRPC (from WordPress Android App), the database contains 4 records of posts:

`ID`	`post_author`	`post_date`	`post_date_gmt`	`post_content`	`post_title`
"41"	"1"	"2019-12-05 11:02:10"	"2019-12-05 17:02:10"	"<!-- wp:paragraph --><p>From web interface.</p><!-- /wp:paragraph -->"	"hello"	""	"publish"	"open"	"open"	""	"hello-2"	""	""	"2019-12-05 11:02:10"	"2019-12-05 17:02:10"	""	"0"	"http://mydev.test/?p=41"	"0"	"post"	""	"0"
"42"	"1"	"2019-12-05 11:02:10"	"2019-12-05 17:02:10"	"<!-- wp:paragraph --><p>From web interface.</p><!-- /wp:paragraph -->"	"hello"	""	"inherit"	"closed"	"closed"	""	"41-revision-v1"	""	""	"2019-12-05 11:02:10"	"2019-12-05 17:02:10"	""	"41"	"http://mydev.test/2019/12/05/1102/41-revision-v1/"	"0"	"revision"	""	"0"
"43"	"1"	"2019-12-05 05:03:11"	"2019-12-05 17:03:11"	"From WordPress Android App."	"hello"	""	"publish"	"open"	"open"	""	"hello-3"	""	""	"2019-12-05 11:03:13"	"2019-12-05 17:03:13"	""	"0"	"http://mydev.test/?p=43"	"0"	"post"	""	"0"
"44"	"1"	"2019-12-05 11:03:13"	"2019-12-05 17:03:13"	"From WordPress Android App."	"hello"	""	"inherit"	"closed"	"closed"	""	"43-revision-v1"	""	""	"2019-12-05 11:03:13"	"2019-12-05 17:03:13"	""	"43"	"http://mydev.test/2019/12/05/1103/43-revision-v1/"	"0"	"revision"	""	"0"
"0"

You'll see the post_data of ID=43 (published one) is 2 x -6 from GMT time.

Now set the timezone setting in WordPress as UTC+9:

`ID`	`post_author`	`post_date`	`post_date_gmt`	`post_content`	`post_title`
"45"	"1"	"2019-12-06 02:06:41"	"2019-12-05 17:06:41"	"<!-- wp:paragraph --><p>From Web.</p><!-- /wp:paragraph -->"	"now +9"	""	"publish"	"open"	"open"	""	"now-9"	""	""	"2019-12-06 02:06:41"	"2019-12-05 17:06:41"	""	"0"	"http://mydev.test/?p=45"	"0"	"post"	""	"0"
"46"	"1"	"2019-12-06 02:06:41"	"2019-12-05 17:06:41"	"<!-- wp:paragraph --><p>From Web.</p><!-- /wp:paragraph -->"	"now +9"	""	"inherit"	"closed"	"closed"	""	"45-revision-v1"	""	""	"2019-12-06 02:06:41"	"2019-12-05 17:06:41"	""	"45"	"http://mydev.test/2019/12/06/0206/45-revision-v1/"	"0"	"revision"	""	"0"
"47"	"1"	"2019-12-06 11:06:58"	"2019-12-05 17:06:58"	"From App."	"Now +9"	""	"publish"	"open"	"open"	""	"now-9-2"	""	""	"2019-12-06 02:06:59"	"2019-12-05 17:06:59"	""	"0"	"http://mydev.test/?p=47"	"0"	"post"	""	"0"
"48"	"1"	"2019-12-06 02:06:59"	"2019-12-05 17:06:59"	"From App."	"Now +9"	""	"inherit"	"closed"	"closed"	""	"47-revision-v1"	""	""	"2019-12-06 02:06:59"	"2019-12-05 17:06:59"	""	"47"	"http://mydev.test/2019/12/06/0206/47-revision-v1/"	"0"	"revision"	""	"0"

You'll see the post_data of ID=47 (published one) is 2 x +9 from GMT time.

There's no such issue when I'm using WordPress 5.2, and also have tested above steps in v5.2.4. I don't know where the problem actually lies. I've compared the code from 5.3 with 5.2.4, XMLRPC looks no major changes. What I found is that the way of determining $post_status is changed. But I'm not sure it's the real culprit.

Change History (7)

#1 @noyle
4 years ago

The request body (password replaced by ...) of the second post (with UTC+9 timezone):

<?xml version='1.0' ?><methodCall><methodName>wp.newPost</methodName><params><param><value><string>1</string></value></param><param><value><string>admin</string></value></param><param><value><string>...</string></value></param><param><value><struct><member><name>post_title</name><value><string>Now +9</string></value></member><member><name>post_content</name><value><string>From App.</string></value></member><member><name>post_date</name><value><dateTime.iso8601>20191205T17:06:58</dateTime.iso8601></value></member><member><name>post_password</name><value><string></string></value></member><member><name>post_thumbnail</name><value><string>0</string></value></member><member><name>post_format</name><value><string>standard</string></value></member><member><name>post_type</name><value><string>post</string></value></member><member><name>post_status</name><value><string>publish</string></value></member><member><name>post_excerpt</name><value><string></string></value></member><member><name>comment_status</name><value><string>open</string></value></member><member><name>post_date_gmt</name><value><dateTime.iso8601>20191205T17:06:58</dateTime.iso8601></value></member></struct></value></param></params></methodCall>

#2 @Rarst
4 years ago

Could you please check that date_default_timezone_get() returns UTC in your install? Changing it is not supported by core and related changes in 5.3 caused some things to break in different ways.

We did work on functions related to XMLRPC, but I don't think we are remotely done there, things are pretty bad there.

Possibly related #30429

#3 @noyle
4 years ago

Yep. I've checked by adding following script in current theme, the page does displays UTC:

<div>
	<?php echo date_default_timezone_get(); ?>
</div>

Looks like the result here is the same in #30429 . However, I've also tested it with 5.2.4, there's no such issue. Both tests are in new installations of 5.3 & 5.2.4 on PHP 7.3 (date.timezone is set to Asia/Hong_Kong, actually leaving it blank did the same result) / Windows 10 (timezone in UTC+8). My own online wp install on a server running PHP 7.0 ubuntu 16.04 also has this defect (massively tested).

Here's the result on 5.2.4:

Set the timezone setting in WordPress as UTC-11. Make a post from web interface and then via XMLRPC (from WordPress Android App), the database contains 4 records of posts:

`ID`	`post_author`	`post_date`	`post_date_gmt`	`post_content`	`post_title`
"15"	"1"	"2019-12-05 22:10:59"	"2019-12-06 09:10:59"	""	"UTC-11 from web"	""	"publish"	"open"	"open"	""	"utc-11-from-web"	""	""	"2019-12-05 22:10:59"	"2019-12-06 09:10:59"	""	"0"	"http://wordpress-52.mydev.test/?p=15"	"0"	"post"	""	"0"
"16"	"1"	"2019-12-05 22:10:59"	"2019-12-06 09:10:59"	""	"UTC-11 from web"	""	"inherit"	"closed"	"closed"	""	"15-revision-v1"	""	""	"2019-12-05 22:10:59"	"2019-12-06 09:10:59"	""	"15"	"http://wordpress-52.mydev.test/2019/12/05/15-revision-v1/"	"0"	"revision"	""	"0"
"17"	"1"	"2019-12-05 22:11:22"	"2019-12-06 09:11:22"	""	"utc-11 from wp Android"	""	"publish"	"open"	"open"	""	"utc-11-from-wp-android"	""	""	"2019-12-05 22:11:28"	"2019-12-06 09:11:28"	""	"0"	"http://wordpress-52.mydev.test/?p=17"	"0"	"post"	""	"0"
"18"	"1"	"2019-12-05 22:11:28"	"2019-12-06 09:11:28"	""	"utc-11 from wp Android"	""	"inherit"	"closed"	"closed"	""	"17-revision-v1"	""	""	"2019-12-05 22:11:28"	"2019-12-06 09:11:28"	""	"17"	"http://wordpress-52.mydev.test/2019/12/05/17-revision-v1/"	"0"	"revision"	""	"0"

You'll see the post_data of ID=17 (published one) is the right timezone-respected time.

Now set the timezone setting in WordPress as UTC+4:

`ID`	`post_author`	`post_date`	`post_date_gmt`	`post_content`	`post_title`
"19"	"1"	"2019-12-06 13:13:59"	"2019-12-06 09:13:59"	""	"UTC+4 from web"	""	"publish"	"open"	"open"	""	"utc4-from-web"	""	""	"2019-12-06 13:13:59"	"2019-12-06 09:13:59"	""	"0"	"http://wordpress-52.mydev.test/?p=19"	"0"	"post"	""	"0"
"20"	"1"	"2019-12-06 13:13:59"	"2019-12-06 09:13:59"	""	"UTC+4 from web"	""	"inherit"	"closed"	"closed"	""	"19-revision-v1"	""	""	"2019-12-06 13:13:59"	"2019-12-06 09:13:59"	""	"19"	"http://wordpress-52.mydev.test/2019/12/06/19-revision-v1/"	"0"	"revision"	""	"0"
"21"	"1"	"2019-12-06 13:14:18"	"2019-12-06 09:14:18"	""	"utc+4 from wp Android"	""	"publish"	"open"	"open"	""	"utc4-from-wp-android"	""	""	"2019-12-06 13:14:20"	"2019-12-06 09:14:20"	""	"0"	"http://wordpress-52.mydev.test/?p=21"	"0"	"post"	""	"0"
"22"	"1"	"2019-12-06 13:14:20"	"2019-12-06 09:14:20"	""	"utc+4 from wp Android"	""	"inherit"	"closed"	"closed"	""	"21-revision-v1"	""	""	"2019-12-06 13:14:20"	"2019-12-06 09:14:20"	""	"21"	"http://wordpress-52.mydev.test/2019/12/06/21-revision-v1/"	"0"	"revision"	""	"0"

You'll see the post_data of ID=21 (published one) is the right timezone-respected time.

The request body (password replaced by ...) of the second post (with UTC+4 timezone):

<?xml version='1.0' ?><methodCall><methodName>wp.newPost</methodName><params><param><value><string>1</string></value></param><param><value><string>admin</string></value></param><param><value><string>...</string></value></param><param><value><struct><member><name>post_title</name><value><string>utc+4 from wp Android</string></value></member><member><name>post_content</name><value><string></string></value></member><member><name>post_date</name><value><dateTime.iso8601>20191206T09:14:18</dateTime.iso8601></value></member><member><name>post_password</name><value><string></string></value></member><member><name>post_thumbnail</name><value><string>0</string></value></member><member><name>post_format</name><value><string>standard</string></value></member><member><name>post_type</name><value><string>post</string></value></member><member><name>post_status</name><value><string>publish</string></value></member><member><name>post_excerpt</name><value><string></string></value></member><member><name>comment_status</name><value><string>open</string></value></member><member><name>post_date_gmt</name><value><dateTime.iso8601>20191206T09:14:18</dateTime.iso8601></value></member></struct></value></param></params></methodCall>

The output of date_default_timezone_get() in 5.2.4 is also UTC.

Edited to add: don't know how WordPress.com works but the issue doesn't occur when I'm posting to a WordPress.com site using WordPress Android App.

Last edited 4 years ago by noyle (previous) (diff)

#4 @Rarst
4 years ago

Looking at this today. Related stuff seems to have been patched in the past in #30429, then reverted in #35053, and so far there doesn't seem to be much clarity on how is this supposed to work at all.

One thing I am confused about in your XML examples is that they contain both post_date and post_date_gmt set to a same time. Is your client set to UTC? Is this supposed to be like this? Is it not?

<member>
    <name>post_date</name>
    <value>
        <dateTime.iso8601>20191206T09:14:18</dateTime.iso8601>
    </value>
</member>
<member>
    <name>post_date_gmt</name>
    <value>
        <dateTime.iso8601>20191206T09:14:18</dateTime.iso8601>
    </value>
</member>

#5 @noyle
4 years ago

Thanks for looking into it.

I've no idea about the code. Maybe the mobile app has defect, too. I just use App from Google Play Store, and the link lists on this page: https://apps.wordpress.com/mobile/. Should I also post a feedback to them?

In the mobile app, I don't find any setting for self-hosted WordPress about date/time. Oh, by the way, I don't have Jetpack installed for any one of my self-hosted sites.

What the mobile app sent is not known to me, but the XML contents were copied from NGINX (local setup) logs. Since it's working differently on WordPress 5.2.4 and WordPress 5.3, there must be something that breaks or changes.

Should I test one more time?

#6 @Rarst
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

From looking at the code it seems post_date_gmt will be prioritized in input so effectively it doesn't matter what app sends for post_date. Probably fine.

Think the place where offset doubles down is indeed the place #30429 was pointing out, so this seems to be a duplicate, I'll continue there.

No idea why it was working in 5.2, likely some (common case) of multiple wrong behaviors cancelling each other out. Some of that got affected by things getting fixed in 5.3.

#7 @noyle
4 years ago

OK. Maybe we could get more from this ticket.

See from the main report, posts of id=44 & id=48, the post_date is correctly set w.r.t. timezone. These two entries should be, IMO, generated within WordPress itself upon receiving posting request from XMLRPC, the time of the two entries are server time.

In contrast, posts of id=43 & id=47, the post_date_gmt is from XMLRPC, but upon publishing a post, the post_date is wrongly calculated. Hope this minor analysis would narrow down the scope of code research.

Thanks again and really hope it could be fixed soon. I rely on the mobile app so much.

Note: See TracTickets for help on using tickets.