WordPress.org
Get WordPress

Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 10 months ago

#5721 closed defect (bug) (fixed)

Future posts published with Windows Live Writer are scheduled for incorrect time.

Reported by: markjaquith's profile markjaquith Owned by: markjaquith's profile markjaquith
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.3.2
Component: XML-RPC Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

WP GMT Offset: -05

  1. Compose post in Windows Live Writer
  2. Set publish time to 1 hour in the future
  3. Publish
  4. View "Manage > Posts" and verify that publish time is correct (it is).
  5. View "Dashboard" and note that pseudo cron has the post scheduled to "fire" in 6 hours.

Tried with a few other times, and it seems to be [Publish Time] - [GMT Offset].

Tried on WordPress.com and the post failed to publish (can't see the scheduled time on the dashboard).

I couldn't trigger this bug with MarsEdit (which uses a different API). I'm leaning towards this being a WLW bug, but it's strange that the publish time would be right but the cron time wouldn't.

This is also another reason why our pseudo cron implementation needs a re-work... you shouldn't be able to schedule a post to publish at any time other than its publish date!

Attachments (1)

date_created_gmt__TRUNK.diff​ (1.9 KB) - added by markjaquith 17 years ago.
For Trunk

Download all attachments as: .zip

Change History (14)

#1 @lloydbudd
17 years ago

  • Owner changed from anonymous to josephscott

#2 @lloydbudd
17 years ago

  • Owner changed from josephscott to markjaquith

Mark and Joseph discussed this on IRC #wordpress-hackers -- hopefully they summarize it here, but the conclusion is that Mark will work on a patch.

#3 @markjaquith
17 years ago

  • Keywords has-patch added
  • Milestone changed from 2.5 to 2.3.3
  • Status changed from new to assigned

Here's the issue:

Windows Live Writer sends dateCreated without the "Z" designating is as a GMT date. WordPress assumes it is a local time, and post_date_gmt gets offset (by the WP-stored GMT offset).

Two things need to happen:

  1. Windows Live Writer needs to send the "Z" so we know it's GMT
  2. We need to give preference to date_created_gmt (which we can reasonably assume to be GMT even if it lacks the "Z") over dateCreated

Joseph is in contact with the WLW people about the first part, and I've created a patch to do the second part.

@markjaquith
17 years ago

For Trunk

#4 @lloydbudd
17 years ago

  • Milestone changed from 2.3.3 to 2.5

Generally, we leave Milestone as trunk, until after it has 1st been fixed and vented there.

#5 @josephscott
17 years ago

  • Cc josephscott added

#6 @ryan
17 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [6691]) Future post publishing over XML-RPC fixes from markjaquith. fixes #5721

This ticket was mentioned in ​Slack in #core by redsweater. ​View the logs.
9 years ago

This ticket was mentioned in ​PR #5725 on ​WordPress/wordpress-develop by ​@dmsnell.
10 months ago #8

  • Keywords has-unit-tests added

Depends on #5721

Currently the Tag Processor assumes that an input document is a _full_ HTML document. Because of this, if there's lingering content after the last tag match it will treat that content as plaintext and skip over it. This is fine for the Tag Processor because if there is lingering content that isn't a valid tag then there's nothing for next_tag() to match.

However, in order to support a number of feature expansions it is important to recognize that the remaining content _may_ involve partial syntax elements, such as incomplete tags, attributes, or comments.

In this patch we're adding a mode inside the Tag Processor which will flip when we start parsing HTML syntax but the document finishes before the token does. This will provide the ability to:

  • extend the input document
  • avoid misinterpreting syntax as text
  • guess if we have a complete document, know if we have an incomplete document

​@jonsurrell commented on ​PR #5725:
10 months ago #9

I ran the tests from #5794 against this branch and it skips fewer tests, but all of those tests seem to fail. This may be a limitation with #5794 and not this PR. All of the new failures seem to be with test input that add <script> or <title> to the <head>. Were those tags unsupported before this PR? That would explain the problem.

I pulled the test data and the test suite from that branch (no fixes) and ran the tests with these results:

Trunk:

Tests: 1693, Assertions: 306, Errors: 30, Failures: 2, Skipped: 1357.

This branch:

Tests: 1693, Assertions: 423, Errors: 30, Failures: 117, Skipped: 1240.

​@jonsurrell commented on ​PR #5725:
10 months ago #10

I think the problem is that the tag processor always assumes we're in body, but there are tests that add tags to head. So it's a limitation of the way we're using the tests now.

It's not clear to me why those tags were unsupported before this PR but are supported now… was that intentional?

​@dmsnell commented on ​PR #5725:
10 months ago #11

@sirreal those tests need to be setup differently, because the HTML Processor currently only supports the <body> context element inside a fragment parser. that is, if it encounters <html> it's not the document HTML tag but a parse error and we're free to bail.

it's not that it assumes we're IN BODY but rather the default parameter to create_fragment() is <body> and any other context node would cause it to abort. we could setup those tests to handle that.

​@dmsnell commented on ​PR #5725:
10 months ago #12

With the merge of ​1270194 everything is now passing or skipped in the html5lib test suite, thanks again @sirreal.

There were a couple of fixes I incorporated from your work there, and then I updated that branch with some specific test exclusions based on either a design question or a test that tests behaviors we don't currently support (but will probably do so once we support scanning all tokens).

The necessary change to the html5lib tests was to check for $p->paused_at_incomplete_token()

Note: See TracTickets for help on using tickets.