Make WordPress Core

Opened 17 years ago

Closed 16 years ago

Last modified 16 years ago

#4686 closed defect (bug) (duplicate)

WXR need a version

Reported by: foolswisdom's profile foolswisdom Owned by: tellyworth's profile 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.

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

Change History (15)

#1 @foolswisdom
17 years ago

  • Description modified (diff)

#2 @markjaquith
17 years ago

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

#3 follow-up: @westi
17 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.

#4 in reply to: ↑ 3 @foolswisdom
17 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.

#5 @foolswisdom
17 years ago

  • Keywords needs-patch added; removed

rollback on 2.2.x *

#6 @markjaquith
17 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.

#7 @foolswisdom
17 years ago

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

#8 @markjaquith
17 years ago

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

#9 @markjaquith
17 years ago

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

#10 @ryan
16 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#11 @link92
16 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.

#12 @foolswisdom
16 years ago

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


  • 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

#13 @lloydbudd
16 years ago

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

Duplicate of #5454.

#14 @westi
16 years ago

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

#15 @Nazgul
16 years ago

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