WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#4686 closed defect (bug) (duplicate)

WXR need a version

Reported by: foolswisdom Owned by: tellyworth
Milestone: Priority: high
Severity: major Version: 2.3
Component: Administration Keywords: export, import, WXR, needs-patch
Focuses: Cc:

Description (last modified by foolswisdom)

WXR need a version

ENV: wp trunk r5819

Quite a few of the WXR bugs relate to older versions of WP not being able to handle newer versions of WP exports.

If WXR included a version # then if the version # of the file was greater than the version that WP knows how to handle then WP could give a warning, and save users some headaches.

ADDITIONAL DETAILS:
The svn revision when it last changed might work as good as anything else.

Change History (15)

comment:1 foolswisdom7 years ago

  • Description modified (diff)

comment:2 markjaquith7 years ago

Need it for 2.2.2 as well, as it uses CDATA for comment_author now.

comment:3 follow-up: westi7 years ago

+1 This is a very good idea.

Some thoughts:

  1. Tie the WXR version down and only change features in full releases not maintenance releases - this means things like the CDATA change in 2.2.2 should not get done as 2.2 should support import and export of it's version of WXR and any earlier versions.
  2. Write up a good spec for the format which highlights the new features in different versions.

comment:4 in reply to: ↑ 3 foolswisdom7 years ago

Seems like a good idea to rollback the importer part of #4452.

westi's bang on comments remind me, that the importer version check should actually be a range bounded on each side, b/c the upgrade process already needs to be robust. Bester for a user to be encouraged to upgrade the origin install than for the importer code to become spaghetti -- though when reasonable the importer should be backwards compat.

comment:5 foolswisdom7 years ago

  • Keywords needs-patch added; removed

rollback on 2.2.x *

comment:6 markjaquith7 years ago

Lloyd, don't you mean roll back the exporter ? If we roll back the importer, WP 2.2.2 won't be able to import its exports. The importer changes should be backwards compat, but the exporter changes are not.

comment:7 foolswisdom7 years ago

Grr, yes, what you said, roll back the exporter not the importer for 2.2.x .

comment:8 markjaquith7 years ago

(In [5846]) Roll back export portion of #4452 for 2.2.x, see #4452, see #4686

comment:9 markjaquith7 years ago

Still need to decide on a versioning system and implement it for trunk.

comment:10 ryan7 years ago

  • Milestone changed from 2.3 to 2.4 (next)

comment:11 link927 years ago

Why on earth does this require versioning? The output of the XML parser should be identical with or without a CDATA section around the commenter name…

Versioning just gives us an excuse to breaks backwards compatibility in a format that most certainly should not ever need backwards compatibility broken.

comment:12 foolswisdom7 years ago

link92, please don't comment if you aren't going to be polite, why on Earth indeed.

Versioning:

  • Helps detection of backwards compatibility issues
  • Makes handling backwards compatibility easier, more graceful
  • Allows an experience wwarning when someone trying to import from a forward version

comment:13 lloydbudd6 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #5454.

comment:14 westi6 years ago

Hmm #5454 gives it a version number but does it have a spec that says what that means yet?

comment:15 Nazgul6 years ago

  • Milestone 2.5 deleted
Note: See TracTickets for help on using tickets.