Make WordPress Core

Opened 15 years ago

Closed 14 years ago

#10317 closed task (blessed) (fixed)

Add features to export

Reported by: wpmuguru's profile wpmuguru Owned by: westi's profile westi
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.8
Component: Export Keywords: has-patch needs-testing ux-feedback
Focuses: Cc:

Description

The attached path will add optional date range, post category, content type & post status to the export function.

Attachments (8)

export.diff (7.0 KB) - added by wpmuguru 15 years ago.
export patch
export.2.diff (7.1 KB) - added by wpmuguru 15 years ago.
checks for nested query support
export3.diff (7.0 KB) - added by jshreve 14 years ago.
10317.diff (8.1 KB) - added by nacin 14 years ago.
Untested. Whole feature needs urgent massaging to bring it up to par.
10317-2.diff (30.3 KB) - added by blepoxp 14 years ago.
First revision of nacin's latest diff - more will be needed.
10317-3.diff (31.6 KB) - added by blepoxp 14 years ago.
Improved dropdowns for start and end dates
10317-4.diff (1.2 KB) - added by michaelh 14 years ago.
Change to $monthyears to include all post_types and stati and return in ASC order
t10317-export-filters-explanation.diff (576 bytes) - added by demetris 14 years ago.
Short explanation for the filters section

Download all attachments as: .zip

Change History (52)

@wpmuguru
15 years ago

export patch

#1 @janeforshort
15 years ago

  • Keywords has-patch needs-testing added
  • Milestone changed from 2.8.2 to 2.9
  • Type changed from enhancement to feature request

Moving to 2.9 since this is a new feature, not just an enhancement and should be in a full release, not a point release (which generally fix bugs and security issues).

#2 @dd32
15 years ago

attachment export.diff added

  • I'd like to see the use of and replaces with &&
  • I'm not sure subselects are supported by WP's minimum MySQL version yet.. But it will in time.

I think a better exporter is needed by WordPress, and this is a start.

See Also: #10476

#3 @wpmuguru
15 years ago

The nested queries are supported by MySQL versions 3.23 and newer.

#4 @dd32
15 years ago

The nested queries are supported by MySQL versions 3.23 and newer.

That link (And my memory) say its 4.1+, WordPress still requires MySQL 4.0+ - http://core.trac.wordpress.org/browser/trunk/wp-includes/wp-db.php#L1021

I do believe there is already something else using subselects (Taxonomy under very very certain case which would only ever be triggered by a certain use by a plugin), And that has raised the idea of requiring MySQL 4.1+ for WordPress 2.9.. So it might not be a point to care about right now.

#5 @wpmuguru
15 years ago

I could modify the patch to check mysql version and remove the category select on 4.0.

@wpmuguru
15 years ago

checks for nested query support

#6 @scribu
15 years ago

WordPress 2.9 officially requires MySQL 4.1, so export.diff should do.

#7 @westi
15 years ago

  • Milestone changed from 2.9 to 3.0

As 2.9 is pretty much feature frozen now I am going to move this to the 3.0 milestone for consideration next time round.

#8 @janeforshort
14 years ago

Have asked lead devs to review this one to decide on inclusion before we hit freeze.

#9 @westi
14 years ago

  • Owner set to westi
  • Status changed from new to accepted

This patch looks generally sound.

Doesn't apply fully at the moment so needs a little merge love.

Will commit soon once I have a working test install to check it out on.

#10 @WraithKenny
14 years ago

Would it be hard to add custom Nav Menu data in the export while refreshing the patch? (enhancement request for 3.0)

@jshreve
14 years ago

#11 @jshreve
14 years ago

  • Cc justin.shreve@… added

westi:

I couldn't get it to apply either because of some minor changes made to wp-admin/includes/export.php since the time the patch was written. export3 applies cleanly against revision r13420.

Once I got it running I tried out wpmuguru's changes. It adds some nice options to make the export tool better. I had no problems with it in my test so +1 here

#12 @Denis-de-Bernardy
14 years ago

the current patch isn't custom post type friendly, but it would be a good first step if we want to go this path.

#13 @Denis-de-Bernardy
14 years ago

also, the pending status is missing.

#14 @wpmuguru
14 years ago

Downloaded the patch. If I have time tonight I'll give it a run.

#15 @wpmuguru
14 years ago

(In [13573]) add features to export, see #10317

#17 @nacin
14 years ago

  • Type changed from feature request to task (blessed)

#12501 closed as a duplicate.

#18 follow-up: @dd32
14 years ago

After [13573] what other changes are needed here for 3.0?

#19 in reply to: ↑ 18 @nacin
14 years ago

Replying to dd32:

After [13573] what other changes are needed here for 3.0?

Use the API to retrieve public post types, taxonomies, and registered post statuses.

#20 @mikeschinkel
14 years ago

  • Cc mikeschinkel@… added

@nacin
14 years ago

Untested. Whole feature needs urgent massaging to bring it up to par.

#21 @nacin
14 years ago

I've posted a new patch here that needs some testing and probably serious massaging. Anyone up for it?

It attempts to leverage the post types, taxonomies and stati API as much as possible, though that may require a new export flag or something (for cases when 'all' is selected), as I don't think we'd want to show "Trash" or "Menu Item" in the drop-downs, or as it is now, not show them and then export them when "All" is left selected.

Anyway, could use someone to pick this up and run with it.

#22 @nacin
14 years ago

I'm checking in a small part of this patch, an enhancement for the authors drop-down.

Currently, it loops through a distinct array of post author ids, calling get_userdata on each one (thus a new query for each if the user isn't cached), when all it needs is the user ID and the display name.

Commit changes it to a single query joining posts and users, which also provides the added benefit of an alpha sort on the display name, versus an order based on their first appearance in the posts table.

#23 @nacin
14 years ago

(In [14153]) Optimize the Authors drop-down in export.php. Makes it one query, also orders authors by display name. see #10317.

#24 @nacin
14 years ago

  • Keywords ux-feedback added

@blepoxp
14 years ago

First revision of nacin's latest diff - more will be needed.

#25 @blepoxp
14 years ago

I downloaded nacins diff and brought it up to latest revision of trunk, fixed several errors (his was untested) that happened on export. At this point XML file gets created successfully w/o any errors. I had a custom taxonomy defined with several posts added to two different terms in that taxonomy.

At this point, on import to a different blog running same version of trunk, the custom taxonomy and terms are imported, but the posts are not successfully associated with them.

Additionally, we'll probably need to think through error situations and prevent export, show notice. One instance I know of is it currently allows you to select an export with november 2009 as start and february 2009 as end. There are probably more as well.

I'll look into why its associating posts with custom taxonomies on input. Let me know if you see anything else.

#26 @nacin
14 years ago

Thanks for this!

At first I thought about using wp_list_archives() to spit out a drop-down by month/year combos, but it was too much to hack to do so, so I left it as is. I would much prefer two drop-downs indicating a start and an end (less need for poka yoke), and it shouldn't be too difficult to do probably by starting with code in wp_list_archives().

Also, I added ux-feedback here for two reasons -- one, the UI (such as date limiting), and two, things like how we want to handle private statuses and post types (see my above comment for more).

#27 @blepoxp
14 years ago

Still hunting down the reason posts aren't associated with their custom taxonomies. I think the loop isn't printing custom taxonomy elements for each post on export (although it does in the taxonomies block).

Also, I noticed that the export is grabbing auto drafts, menu items, and menu taxonomies. It seems like we should either exclude them or add GUI options to the export screen. Thoughts?

#28 @nacin
14 years ago

Also, I noticed that the export is grabbing auto drafts, menu items, and menu taxonomies. It seems like we should either exclude them or add GUI options to the export screen. Thoughts?

I thus like the idea of an export flag for post types, taxonomies, and post stati. I imagine it should default to the value of the public flag for PTs and tax. (That however would not export revisions by default, so those would need export=>true manually.) For stati, export should probably be true when internal=>false.

#29 @blepoxp
14 years ago

Sound's good. What about menu items?

Also, I think I've narrowed the association problem to the /wp-admin/import/wordpress.php script.

Lines 445-461 do some regex parsing to grab all the tags and categories associated with that post. There is nothing there to grab custom taxonomies.

Additionally, lines 515-558 then add the post to the above captured tags/cats... there is not addition of the custom taxonomies (which haven't been captured anyway) in this block.

RegEx is my weakest link and I'm about done for the day. If anyone wants to take a look at that, feel free to go for it. Otherwise, I'll check in tomorrow.

#30 @nacin
14 years ago

Let's just stick to the export. As long as the export is solid, the importer can be improved separately. (That might be something we can do during the code sprint, if this is solid by then.)

Menu items are a post type, so those would be set to export=>false manually.

@blepoxp
14 years ago

Improved dropdowns for start and end dates

#31 @blepoxp
14 years ago

The above patch modifies the dropdowns for start_date and end_date. Right direction? Still need to add validation.

#32 @wpmuguru
14 years ago

(In [14441]) add export property to post types, see #10317

#33 @wpmuguru
14 years ago

(In [14444]) export improvements, props blepoxp, see #10317

#34 @johnonolan
14 years ago

Possible to add screenshots for UI/UX feedback, or note whether it's something that definitely required applying the patch to test? I can apply patches, but I'm not particularly quick or good at it so if screenshots are possible then this would be a massive help!

#35 follow-up: @blepoxp
14 years ago

It's in trunk so no need to patch technically. If you don't have trunk though, you can check out this 3 minute screencast: http://screenr.com/PtC

#36 in reply to: ↑ 35 @johnonolan
14 years ago

Replying to blepoxp:

It's in trunk so no need to patch technically. If you don't have trunk though, you can check out this 3 minute screencast: http://screenr.com/PtC

Ah sorry, total brainmelt, I didn't even notice the changesets or I would've just take a look at trunk! I think this looks fine from a UI/UX point of view, no complaints.

@michaelh
14 years ago

Change to $monthyears to include all post_types and stati and return in ASC order

#37 @wpmuguru
14 years ago

(In [14506]) include dates from all post types/stati. props michaelh, see #10317

#38 @wpmuguru
14 years ago

(In [14509]) make end month in export inclusive, see #10317

#39 @ryan
14 years ago

Anything else to do here for 3.0?

#40 @nacin
14 years ago

Nope, I think it just needs some testing. We can highlight that further in the RC.

In the end, it's a huge improvement. If there's a bug in how perhaps two options clash, we'll get it.

#41 @nacin
14 years ago

(In [14794]) Less clunky export UI. see #10317

#42 @demetris
14 years ago

@nacin: Thanks. That part is much better now.

I was working on it earlier today but did not got around to submitting the patch.

My changes were about the same as yours. I also added a short explanation, which I am attaching now for consideration. (I am not absolutely certain an explanation is necessary there, but I thought I would just add one to see how it looked.)

@demetris
14 years ago

Short explanation for the filters section

#43 @nacin
14 years ago

:-)

This ticket is already marked for ux-feedback, but I think it's clear without the explanation at this point.

#44 @ryan
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.