Data recovery

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Data recovery

Podz
Right now, if you delete a post or a comment then it really is deleted.
Unrecoverable.
Shouldn't either:
- the warning be beefed up a bit, or
- the data be made recoverable ?

Users are used to a recycle bin, and gearing WP toward multiple users it
would seem a decent option to be able to recover anything deleted within
a timescale set by the blog owner.
As usual I haven't the slightest clue how to do it, but I would imagine
such a feature would be well received.

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery

David House
On 11/02/06, Podz <[hidden email]> wrote:
> Users are used to a recycle bin, and gearing WP toward multiple users it
> would seem a decent option to be able to recover anything deleted within
> a timescale set by the blog owner.
> As usual I haven't the slightest clue how to do it, but I would imagine
> such a feature would be well received.

Another use for an integrated cron. Once a week/month, we could just
garbage-collect on a wp-trash table.

It's worth pointing out MT already has this feature.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery

Kimmo Suominen-3
On Sat, Feb 11, 2006 at 09:37:26PM +0000, David House wrote:
> On 11/02/06, Podz <[hidden email]> wrote:
> > Users are used to a recycle bin, and gearing WP toward multiple users it
> > would seem a decent option to be able to recover anything deleted within
> > a timescale set by the blog owner.
> > As usual I haven't the slightest clue how to do it, but I would imagine
> > such a feature would be well received.
>
> Another use for an integrated cron. Once a week/month, we could just
> garbage-collect on a wp-trash table.

Rather than copy data around in the database, using flag fields would
be more efficient.  Also makes it possible to recover to the same ID,
since the data never leaves the table until garbage collect time.

Best regards,
+ Kimmo
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David Chait
Agreed.  And, with the move to make more things varchar for extensibility,
here's a vote to move post_status away from being an enum.
post_status=='trash' would probably do fine for this.  or ".trash" (would be
nice to have a convention for hiding certain status 'classes' from the
normal view queries without explicitly listing the states to exclude...).

Thoughts?  (esp Ryan?  given the recent status=='future' changes...)

While we're at it, how about making the comment_approved a varchar too... ;)
;)

-d

----- Original Message -----
From: "Kimmo Suominen" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, February 11, 2006 4:44 PM
Subject: Re: [wp-hackers] Data recovery


| On Sat, Feb 11, 2006 at 09:37:26PM +0000, David House wrote:
| > On 11/02/06, Podz <[hidden email]> wrote:
| > > Users are used to a recycle bin, and gearing WP toward multiple users
it
| > > would seem a decent option to be able to recover anything deleted
within
| > > a timescale set by the blog owner.
| > > As usual I haven't the slightest clue how to do it, but I would
imagine
| > > such a feature would be well received.
| >
| > Another use for an integrated cron. Once a week/month, we could just
| > garbage-collect on a wp-trash table.
|
| Rather than copy data around in the database, using flag fields would
| be more efficient.  Also makes it possible to recover to the same ID,
| since the data never leaves the table until garbage collect time.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Mark Jaquith
On Feb 11, 2006, at 5:07 PM, David Chait wrote:

> Agreed.  And, with the move to make more things varchar for  
> extensibility,
> here's a vote to move post_status away from being an enum.
> post_status=='trash' would probably do fine for this.  or  
> ".trash" (would be
> nice to have a convention for hiding certain status 'classes' from the
> normal view queries without explicitly listing the states to  
> exclude...).

+1 on all counts, including making comment_approved a varchar.  Note  
(important one!): we're going to have to sweep through the code and  
make sure that all WP comparisons on post_status or comment_approved  
do == comparisons and not != comparisons.  That is, you should be  
able to add a new status and have WP just ignore it.  WordPress  
should name the statuses it wants to be seeing, not the ones it  
doesn't, because that might accidentally include new "custom" statuses.
--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David Chait
right, or have something like a dot-prefix to denote hidden classes of
objects that the normal interface should ignore...

yes, definitely will need a code sweep.

-d

----- Original Message -----
From: "Mark Jaquith" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, February 11, 2006 5:13 PM
Subject: Re: [wp-hackers] Data recovery (post_status?)


| On Feb 11, 2006, at 5:07 PM, David Chait wrote:
|
| > Agreed.  And, with the move to make more things varchar for
| > extensibility,
| > here's a vote to move post_status away from being an enum.
| > post_status=='trash' would probably do fine for this.  or
| > ".trash" (would be
| > nice to have a convention for hiding certain status 'classes' from the
| > normal view queries without explicitly listing the states to
| > exclude...).
|
| +1 on all counts, including making comment_approved a varchar.  Note
| (important one!): we're going to have to sweep through the code and
| make sure that all WP comparisons on post_status or comment_approved
| do == comparisons and not != comparisons.  That is, you should be
| able to add a new status and have WP just ignore it.  WordPress
| should name the statuses it wants to be seeing, not the ones it
| doesn't, because that might accidentally include new "custom" statuses.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Ryan Boren
In reply to this post by Mark Jaquith
Mark Jaquith wrote:

> On Feb 11, 2006, at 5:07 PM, David Chait wrote:
>
>> Agreed.  And, with the move to make more things varchar for  
>> extensibility,
>> here's a vote to move post_status away from being an enum.
>> post_status=='trash' would probably do fine for this.  or  ".trash"
>> (would be
>> nice to have a convention for hiding certain status 'classes' from the
>> normal view queries without explicitly listing the states to  
>> exclude...).
>
>
> +1 on all counts, including making comment_approved a varchar.  Note  
> (important one!): we're going to have to sweep through the code and  
> make sure that all WP comparisons on post_status or comment_approved  do
> == comparisons and not != comparisons.  That is, you should be  able to
> add a new status and have WP just ignore it.  WordPress  should name the
> statuses it wants to be seeing, not the ones it  doesn't, because that
> might accidentally include new "custom" statuses.

All post_status != comparisons should be gone soon.  I still need to get
rid of the != 'draft' comparison in execute-pings.php.  That one could
be = 'publish' instead.

Ryan

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery

Roy Schestowitz-2
In reply to this post by Podz
_____/ On Sat 11 Feb 2006 21:17:25 GMT, [Podz] wrote : \_____

> Right now, if you delete a post or a comment then it really is deleted.
> Unrecoverable.
> Shouldn't either:
> - the warning be beefed up a bit, or
> - the data be made recoverable ?
>
> Users are used to a recycle bin, and gearing WP toward multiple users it
> would seem a decent option to be able to recover anything deleted within
> a timescale set by the blog owner.
> As usual I haven't the slightest clue how to do it, but I would imagine
> such a feature would be well received.

The idea of garbage collection has been raised already (set status to
"deleted", later purge). It's reminiscent of IMAP handling in most mail
clients.

That said, a few days ago I realised something else was missing. In "Mass
Edit Mode" (comments moderation), there is no indication as to how many
comments get purged until they disappear for good, i.e. deletion is
conformed. I suppose you could trivially percolate the number of marked
items to the JavaScript prompt. That way, the user can double-check the
number of comments to be deleted. This behaviour has not changed since 1.2
(at the least). I still see it in the latest nightly.

With kind regards,

Roy

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David House
In reply to this post by David Chait
On 11/02/06, David Chait <[hidden email]> wrote:
> Agreed.  And, with the move to make more things varchar for extensibility,
> here's a vote to move post_status away from being an enum.
> post_status=='trash' would probably do fine for this.  or ".trash" (would be
> nice to have a convention for hiding certain status 'classes' from the
> normal view queries without explicitly listing the states to exclude...).

Problems here:

* We lose all indication of what the post/comment/user etc was before.
If you delete a draft then restore it it should restore to a draft,
similarily with posts
* post_status only covers posts, we'd need an analoguous column in
wp_comments and wp_users if we were to push ahead.

Personally, I'm a fan of prepending some character that doens't
normally appear in slugs, like a period.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Mark Jaquith
On Feb 12, 2006, at 5:11 AM, David House wrote:

> * We lose all indication of what the post/comment/user etc was before.
> If you delete a draft then restore it it should restore to a draft,
> similarily with posts

Could use postmeta to store the old value.

> Personally, I'm a fan of prepending some character that doens't
> normally appear in slugs, like a period.

You mean, like going from `post_status` = 'draft' to `post_status` =  
'.draft' ?  That way you could imply "trash" and "where was it  
originally" in one go.

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David House
On 12/02/06, Mark Jaquith <[hidden email]> wrote:
> Could use postmeta to store the old value.

We could indeed. +1.

> You mean, like going from `post_status` = 'draft' to `post_status` =
> '.draft' ?  That way you could imply "trash" and "where was it
> originally" in one go.

I was thinking we prepend it to the slug, actually.

Anyway, we need to decide whether to use post_status (in which case
we'd need a comment_status, user_status, link_status, etc. for
everywhere else you want this recycle bin to happen) or whether to
prepend something like a period to the respective objects' slugs.
(Note that we currently don't allow periods in slugs so there's no
danger of breakage)

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Scott Merrill
David House wrote:
> Anyway, we need to decide whether to use post_status (in which case
> we'd need a comment_status, user_status, link_status, etc. for
> everywhere else you want this recycle bin to happen) or whether to
> prepend something like a period to the respective objects' slugs.

Do we need  a "recycle bin" for _all_ aspects of the site?  That'll get
kind of annoying.  When I delete something, I do so because I want it to
be gone.  A two step delete process (delete, then purge) will become
cumbersome.

Has anyone asked on the forums whether this is a desirable thing?  I
understand the benefit of recovering posts, and possibly even recovering
users.  Beyond that, though, can't someone write up a fancy plugin to
read in a SQL dump created by wp-db-backup.php and provide a list of
what's different between the dump and the current system, with some
facility to reconcile the current system with the backup?

--
[hidden email] | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Sam Angove
On 2/13/06, Scott Merrill <[hidden email]> wrote:
>
> When I delete something, I do so because I want it to
> be gone.  A two step delete process (delete, then purge) will become
> cumbersome.

How often do you ever need it to be instantly, irrevocably gone? A
recycle bin hooked to daily/weekly/monthly wp-cron would be no
hardship at all.

There was a story recently about a high-profile blogger (Scott Adams?)
who accidentally deleted a ton of comments over some misunderstanding
of how the software worked. He'd have liked a recycle bin.

Honestly, I think it'd be used far more for comments than posts (I
regularly read of comment-deletion accidents), so extending it to
other types is a good idea.

David House wrote:
> Anyway, we need to decide whether to use post_status (in which case
> we'd need a comment_status, user_status, link_status, etc. for
> everywhere else you want this recycle bin to happen) or whether to
> prepend something like a period to the respective objects' slugs.

How are you going to query a period-prepended post slug? Better to use
post_status.

Published posts could be safely reverted to drafts if restored:
there's a pretty strong chance they're going to want to edit it.

That said, might as well keep the status in a separate trashed items
table -- something like `trash_id`, `item_type`, `item_status`,
`item_id`, `purge_when`.

A separate table is needed anyway, since individual "date
trashed"/"purge at this time" timestamps are needed if automatic
purging can happen in an intelligent way. And it's a lot cleaner than
querying 5 separate tables for trashed objects.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David Chait
In reply to this post by Scott Merrill
Why not?  It helps the non-technical users a ton, it makes accidents quickly
recoverable, and you could have a single 'recycle bin' page that shows all
the different deleted items and purges them all with one click.

There's a trash can on the desktop for a reason.  Not just because it makes
drag-and-drop actions possible, but also because it adds a step before you
nuke something.  (And, even then, you've got Undelete tools, which cache it
one level further hidden, just in case you really didn't mean to purge the
things you did!)

If really needed, you could have an options page that allows you to disable
the recycle bin for each class of objects... but I'm not sure how useful
that is.  One more click, or X days later, everything does disappear...

FYI, I don't believe the forums are really a useful place for asking
questions of users...  It is extremely fragmented (okay, unless you sticky a
post on the homepage), and I'm sure not everyone makes it there.  And
Wordpress.com, et al, users probably don't visit much as they are told to go
elsewhere -- yet that's a growing base of 'usability testing' given it's
limits.

-d

----- Original Message -----
From: "Scott Merrill" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, February 12, 2006 8:34 AM
Subject: Re: [wp-hackers] Data recovery (post_status?)


| David House wrote:
| > Anyway, we need to decide whether to use post_status (in which case
| > we'd need a comment_status, user_status, link_status, etc. for
| > everywhere else you want this recycle bin to happen) or whether to
| > prepend something like a period to the respective objects' slugs.
|
| Do we need  a "recycle bin" for _all_ aspects of the site?  That'll get
| kind of annoying.  When I delete something, I do so because I want it to
| be gone.  A two step delete process (delete, then purge) will become
| cumbersome.
|
| Has anyone asked on the forums whether this is a desirable thing?  I
| understand the benefit of recovering posts, and possibly even recovering
| users.  Beyond that, though, can't someone write up a fancy plugin to
| read in a SQL dump created by wp-db-backup.php and provide a list of
| what's different between the dump and the current system, with some
| facility to reconcile the current system with the backup?

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

David Chait
In reply to this post by David House
I'm happy with any solution that is reasonably quick to query, and takes
minimal-if-any resources to exclude from queries.  If you have to query a
secondary table, or test a character, that'll make it more difficult to
'exclude'.  That's why I proposed post-status==trash, though I admittedly
didn't consider the 'how to put things back' for posts vs comments vs ...  I
think the period-prefix thing is a potential query bottleneck...

do we simply need a 'trash' flag on all major object tables?  that just
seems overkill in one sense, in another it simplifies stuff greatly.

-d

----- Original Message -----
From: "David House" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, February 12, 2006 7:26 AM
Subject: Re: [wp-hackers] Data recovery (post_status?)


On 12/02/06, Mark Jaquith <[hidden email]> wrote:
> Could use postmeta to store the old value.

We could indeed. +1.

> You mean, like going from `post_status` = 'draft' to `post_status` =
> '.draft' ?  That way you could imply "trash" and "where was it
> originally" in one go.

I was thinking we prepend it to the slug, actually.

Anyway, we need to decide whether to use post_status (in which case
we'd need a comment_status, user_status, link_status, etc. for
everywhere else you want this recycle bin to happen) or whether to
prepend something like a period to the respective objects' slugs.
(Note that we currently don't allow periods in slugs so there's no
danger of breakage)

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Kimmo Suominen-3
On Sun, Feb 12, 2006 at 10:44:49AM -0500, David Chait wrote:
> do we simply need a 'trash' flag on all major object tables?  that just
> seems overkill in one sense, in another it simplifies stuff greatly.

I would vote for having a trash flag in all tables that will support
the "trash can" idea.  I think it would simplify life in the long run,
as you don't have to recall different column names and different magic
values for them.

Personally I'd only want a trash can for posts and comments.  (I'm not
against having it for "everything," though.)

Best regards,
+ Kimmo
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Stefano-10
In reply to this post by David Chait
Il Sun, 12 Feb 2006 10:44:49 -0500, "David Chait"
<[hidden email]> scrive:

>didn't consider the 'how to put things back' for posts vs comments vs ...  I
>think the period-prefix thing is a potential query bottleneck...
>
>do we simply need a 'trash' flag on all major object tables?  that just
>seems overkill in one sense, in another it simplifies stuff greatly.

I'm for the trash flag too instead that prepending chars to other
fields.

What about the comments marked spam by plugin like askimet? WHen it
deletes them automatically thy will be gone forever or change status
to deleted?

Another not full related problem, actually navigtion in post/comments
it's a pain, a paged system would be necesary in case you get 300
comments deleted and 10 are deleted by mystakes. Maybe the
implementation fo the trashbin panel screen could introduce a sort of
paging system used in alla pages that present large amounts of data

--

Stefano Aglietti - StallonIt on IRCnet - ICQ#: 2078431
Email: [hidden email] [hidden email]
Sites: http://www.40annibuttati.it (personal blog)
       http://www.wordpress-it.it (WordPress Italia)
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Owen Winkler
In reply to this post by David Chait
David Chait wrote:
> I'm happy with any solution that is reasonably quick to query, and takes
> minimal-if-any resources to exclude from queries.  If you have to query a
> secondary table, or test a character, that'll make it more difficult to
> 'exclude'.  That's why I proposed post-status==trash, though I admittedly
> didn't consider the 'how to put things back' for posts vs comments vs ...  I
> think the period-prefix thing is a potential query bottleneck...
>
> do we simply need a 'trash' flag on all major object tables?  that just
> seems overkill in one sense, in another it simplifies stuff greatly.

When did "delete" come to mean "possibly store it somewhere for
convenient for later retrieval, just in case you didn't really want to
actually, you know, delete it"?  I never saw any delete buttons labeled
"Throw this away, but put it somewhere I can get it later if I made a
mistake".  I can see the advantage of letting users recover from their
mistakes, but geez.

In any case, using a separate trash table to hold all of this data seems
silly when the affected tables have a status column that could be set to
"deleted".  The only thing you lose is the status prior to deletion,
which would be set to the status with the least impact, for example,
"draft" or "0"/"moderate".  Everything else would already be set properly.

Deletion dates (if you want to purge deleted things via cron) could be
stored in postmeta.  For comments, that's a bit trickier.  Are we going
to add the commentmeta table?  If so, there's the natural place for it.
  If not, then the purge cron action can simply store (in options) the
comment ids of all of the comments that it didn't purge during the last
purge event.  It will only purge comments that are stored in this list.

If you insist on a new column, then make it a NULL-capable date field.
If the field is NULL, then it's not deleted.  If it is not null, then it
contains the date the record was deleted.  Every query on those tables
will then need to check whether that column is NULL to make sure it's
not returning deleted items.  Since all queries should already be
checking their status fields directly (post_status = 'publish' will
automatically ignore rows using the status of 'deleted'), using a flag
field will be more coding work, data storage, and query overhead for not
much more gain.

Owen

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Forum Usefulness (was Data recovery)

Scott Merrill
In reply to this post by David Chait
David Chait wrote:
> FYI, I don't believe the forums are really a useful place for asking
> questions of users...  It is extremely fragmented (okay, unless you sticky a
> post on the homepage), and I'm sure not everyone makes it there.  

No wonder so many people feel that WordPress development is driven from
on high, and is largely removed from what users actually want.

Sure, the forums can be noisy.  Sure, people may ask for (or even
demand) the moon without realizing the scope of their requests.

A new forum section could easily be made to consolidate these sorts of
questions from the development team.  Users who are casually interested
in the development of WordPress, but not interested in enough in
following this mailing list, could be encouraged to participate in the
threads opened in this new section.  For all the talk about "what users
want", this seems like a pretty easy way to collect some real, publicly
verifiable information on what (at least some) users want.

> Wordpress.com, et al, users probably don't visit much as they are told to go
> elsewhere -- yet that's a growing base of 'usability testing' given it's
> limits.

Yeah, it's a darn shame that so few people participating in this list
see any kind of overview of common support / feature requests submitted
directly to the wordpress.com power structure.  Maybe a lot of these
arguments would be averted if this information were made (more) public,
or summarized in some meaningful way (a la the Google zietgeists, or
Sifry's quarterly summaries).

--
[hidden email] | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Data recovery (post_status?)

Michael E. Hancock
In reply to this post by David Chait
From: "David Chait" <[hidden email]>
> FYI, I don't believe the forums are really a useful place for asking
> questions of users...

There's some irony here because it was an accidental deletion of a post in
the Forums by one of the ops that seemed to get this whole thread started.

Michael E. Hancock

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
123