On Deleted Posts, and Managing Content
Geoffrey Sneddon
(apparently) being deleted by cron. However, it disappears from the
admin area in this time, but is visible from in the front end without
any visual difference to non-deleted posts (this is issue 354).
However, consider if you post something you didn't mean to, you have
no method of instantly deleting it. Likewise, you have no method of
restoring a post apart from finding it in the front end then editing
it. Having discussed this earlier in IRC, Andrew proposed adding a
"Trash Can" of sorts, from where posts can both be deleted and
restored. Furthermore, if we had a trash can it'd make sense to keep
posts around that have been deleted and not automatically purge them,
thereby meaning that it would either have to be an option, or just
gone with the advent of the "Trash Can".
Going on from deleted posts invisibility in the admin panel, I
brought up the issue of the inaccessibility of more than the first
ten published entries under Habari content. While ideally we'd like
to page these I assume, we really need some sort of solution in the
short-term, even if it is just displaying all on a single page. Oh,
and can we have a list of pages as well (I assume this can be done by
using similar code to that for published entries, just changing the
post type)?
- Geoffrey Sneddon
Andrew da Silva
silverwing
I really don't like the idea of calling them sections. It's a
completely wrong word for it.
On Aug 14, 3:14 pm, "Andrew da Silva" <freak...@gmail.com> wrote:
> About the pagination of admin, I was going to do it, but we could not decide
> on the term to use, since they are admin pages, how do you call the "page
> number" in the rewrite rule or for the template files.. therefore I
> suggested "sections" rather than "pages", but we never came to a decision..
> what's your take?
>
sfong15
You can even consider 'chapters' but not 'sections'.
I hope number of items to be displayed will be selectable at 'option'.
Scott Merrill
> Currently when you delete a post it remains in the database before
> (apparently) being deleted by cron. However, it disappears from the
> admin area in this time, but is visible from in the front end without
> any visual difference to non-deleted posts (this is issue 354).
This is a trivial CSS issue. In my custom theme, I have this:
#content .deleted {
background-color: #933;
text-decoration: line-through;
}
That makes my deleted posts show up in red, with strikes through all the
text. It's very clear they're deleted.
I also have this:
#content .draft { background-color: #ffc; }
Which will show my draft posts in a nice light yellow.
> However, consider if you post something you didn't mean to, you have
> no method of instantly deleting it.
If you've clicked the delete button, does it really matter if it's
immediately purged or not? If it's your blog, and you have no other
authors on the site, setting the post's status to "deleted" as opposed
to deleting it from the database has the same functional result:
visitors to your site can't read the post.
>Likewise, you have no method of
> restoring a post apart from finding it in the front end then editing
> it. Having discussed this earlier in IRC, Andrew proposed adding a
> "Trash Can" of sorts, from where posts can both be deleted and
> restored. Furthermore, if we had a trash can it'd make sense to keep
> posts around that have been deleted and not automatically purge them,
> thereby meaning that it would either have to be an option, or just
> gone with the advent of the "Trash Can".
We talked _at length_ on this list in the early days about ways to
handle this. (Search Google Groups' archive of this group for the words
"undelete" and "trash bin" to review.)
When I committed the basic functionality to change a post's status to
"deleted" rather than actually delete it straightaway, I commented that
there was no mechanism to purge deleted posts. BigJibby's cron
contribution included (I think) a scheduled task to purge deleted posts
older than 10 days. (Looking through the commit logs, though, I don't
see where that was committed...) I'm comfortable with that timeframe,
and I think it's sane default behaviour for Habari. It gives us the
opportunity to "undelete" posts for a period of time, and it also
continually purges stale deleted posts. Now all we need is some admin
UI to actually undelete! :)
If you're not comfortable with that -- because you want explicit manual
deletion, or lengthier undelete windows of opportunity -- then I think a
plugin is what you need. Any number of plugins should easily be
supported to enforce the (un)delete policy you feel is appropriate for
your site.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
sfong15
deleting pages from admin, I got 'danger, will robinson! danger!' see
http://groups.google.com/group/habari-dev/browse_thread/thread/acb467e4753cf3b5/e61d66dec54c1182?lnk=gst&q=page&rnum=2#e61d66dec54c1182
On the front I was supposed to have 17 pages before import from WP but
after import I have only 4 left. I know the pages are there because
I could enter the slug into the url to see them but they just don't
show even in the default K2 theme.
I'm on svn 745. Any clues anyone?
Rich Bowen
On Aug 14, 2007, at 23:53, Scott Merrill wrote:
>
> When I committed the basic functionality to change a post's status to
> "deleted" rather than actually delete it straightaway, I commented
> that
> there was no mechanism to purge deleted posts. BigJibby's cron
> contribution included (I think) a scheduled task to purge deleted
> posts
> older than 10 days. (Looking through the commit logs, though, I don't
> see where that was committed...) I'm comfortable with that timeframe,
> and I think it's sane default behaviour for Habari. It gives us the
> opportunity to "undelete" posts for a period of time, and it also
> continually purges stale deleted posts. Now all we need is some admin
> UI to actually undelete! :)
>
> If you're not comfortable with that -- because you want explicit
> manual
> deletion, or lengthier undelete windows of opportunity -- then I
> think a
> plugin is what you need. Any number of plugins should easily be
> supported to enforce the (un)delete policy you feel is appropriate for
> your site.
I'm uncomfortable with that, but apparently wasn't paying attention
during that conversation. The default should be to NEVER purge
deleted posts. On the one case that someone wants an undelete and
doesn't have it, we become untrusted, unreliable, loses data!!! It is
better to make someone explicitly decide to purge, or explicitly
decide to do a "purge after N days" than to have this as the default
behavior. We should default to not losing data.
However, having missed the original discussion, I'm sure that this
objection was already raised.
--
Happiness isn't something you experience; it's something you remember.
Oscar Levant
Scott Merrill
> While 'pages' in admin is being discussed, I still have trouble
> deleting pages from admin, I got 'danger, will robinson! danger!' see
> http://groups.google.com/group/habari-dev/browse_thread/thread/acb467e4753cf3b5/e61d66dec54c1182?lnk=gst&q=page&rnum=2#e61d66dec54c1182
>
> On the front I was supposed to have 17 pages before import from WP but
> after import I have only 4 left. I know the pages are there because
> I could enter the slug into the url to see them but they just don't
> show even in the default K2 theme.
>
> I'm on svn 745. Any clues anyone?
Can you check the value of "posttype" for your imported posts? It's
possible that the importer isn't properly setting the post type to "entry".
Geoffrey Sneddon
To second this, can anyone find anything else where something
defaults to deleting after a certain time? The principle of least
surprise would say that posts don't unexpectedly vanish!
We need some sort of UI for the restoring/deleting. A "Trash Can" of
sorts seems the most logical solution to it, and the expected one.
- Geoffrey Sneddon
Scott Merrill
> On 15 Aug 2007, at 13:00, Rich Bowen wrote:
>> I'm uncomfortable with that, but apparently wasn't paying attention
>> during that conversation. The default should be to NEVER purge
>> deleted posts. On the one case that someone wants an undelete and
>> doesn't have it, we become untrusted, unreliable, loses data!!! It is
>> better to make someone explicitly decide to purge, or explicitly
>> decide to do a "purge after N days" than to have this as the default
>> behavior. We should default to not losing data.
>
> To second this, can anyone find anything else where something
> defaults to deleting after a certain time?
The trash can in my office empties every day. The trash can in my house
gets emptied every couple of days into a larger bin, which itself gets
emptied once a week by municipal garbage collection.
> The principle of least
> surprise would say that posts don't unexpectedly vanish!
Well, as it stands now people are surprised that deleting their posts
results in the posts _not_ vanishing. :)
If you delete your post, you're saying "I don't want this any more." To
unpublish something is different from deleting it. If you want to
remove a post from public view, but might want to publish it after
significant editing, you ought to mark the post as draft, rather than
deleted.
> We need some sort of UI for the restoring/deleting. A "Trash Can" of
> sorts seems the most logical solution to it, and the expected one.
Should there be one global trash can, or should each user have their own
trash can?
What permission is necessary to be able to undelete someone else's post?
Rich Bowen
>> To second this, can anyone find anything else where something
>> defaults to deleting after a certain time?
>
> The trash can in my office empties every day. The trash can in my
> house
> gets emptied every couple of days into a larger bin, which itself gets
> emptied once a week by municipal garbage collection.
>
>> The principle of least
>> surprise would say that posts don't unexpectedly vanish!
>
> Well, as it stands now people are surprised that deleting their posts
> results in the posts _not_ vanishing. :)
>
> If you delete your post, you're saying "I don't want this any
> more." To
> unpublish something is different from deleting it. If you want to
> remove a post from public view, but might want to publish it after
> significant editing, you ought to mark the post as draft, rather than
> deleted.
The physical trashcan metaphor is broken, as are most metaphors.
People expect one of two behaviors when they delete something in
computer-land. Either it goes away NOW, or it doesn't go away EVER
until I explicitly "empty the trash". This is established by repeated
training, and to delete the trashcan after some arbitrary (to me, as
the user) interval is surprising.
None of the OSes I use do this - they keep deleted items until I
explicitly empty the trash.
The mail client I use doesn't do this - likewise, I must explicitly
empty the trash.
I expect "delete" to either actually delete (ie, gone NOW) or for it
to "move to trash", and leave it there until I say otherwise. This is
how I have been trained by my computer.
--
"She had a pretty gift for quotation, which is a serviceable
substitute for wit."
W. Somerset Maugham
Geoffrey Sneddon
On 15 Aug 2007, at 15:19, Scott Merrill wrote:
> Geoffrey Sneddon wrote:
>> On 15 Aug 2007, at 13:00, Rich Bowen wrote:
>>> I'm uncomfortable with that, but apparently wasn't paying attention
>>> during that conversation. The default should be to NEVER purge
>>> deleted posts. On the one case that someone wants an undelete and
>>> doesn't have it, we become untrusted, unreliable, loses data!!!
>>> It is
>>> better to make someone explicitly decide to purge, or explicitly
>>> decide to do a "purge after N days" than to have this as the default
>>> behavior. We should default to not losing data.
>>
>> To second this, can anyone find anything else where something
>> defaults to deleting after a certain time?
>
> The trash can in my office empties every day. The trash can in my
> house
> gets emptied every couple of days into a larger bin, which itself gets
> emptied once a week by municipal garbage collection.
I was really meaning within computing. If I move something to
~/.Trash on OS X, it'll stay there till I empty it. If I move
something to the Recycle Bin on Windows, it stays there till I empty it.
>> The principle of least
>> surprise would say that posts don't unexpectedly vanish!
>
> Well, as it stands now people are surprised that deleting their posts
> results in the posts _not_ vanishing. :)
I think something needs to go into the default theme (and it can't be
just CSS, as that relies on the user using a UA with CSS support and
the user being able to see such markers).
> If you delete your post, you're saying "I don't want this any
> more." To
> unpublish something is different from deleting it. If you want to
> remove a post from public view, but might want to publish it after
> significant editing, you ought to mark the post as draft, rather than
> deleted.
But what does delete mean in Habari? It currently means delete _at a
later date_. I'd assume deleting to be an instantaneous procedure. We
need a better marker for what we do, such as "Delete at a later
date". If we have some UI for deleted posts, "Move to trash" would be
a better label.
>> We need some sort of UI for the restoring/deleting. A "Trash Can" of
>> sorts seems the most logical solution to it, and the expected one.
>
> Should there be one global trash can, or should each user have
> their own
> trash can?
Users should only see posts that they can delete or restore within
the trash can.
> What permission is necessary to be able to undelete someone else's
> post?
Admins and the original poster can delete/restore?
- Geoffrey Sneddon
Scott Merrill
> I expect "delete" to either actually delete (ie, gone NOW) or for it
> to "move to trash", and leave it there until I say otherwise. This is
> how I have been trained by my computer.
Patches warmly welcomed! :)
Rich Bowen
On Aug 15, 2007, at 10:33, Scott Merrill wrote:
>
> Rich Bowen wrote:
>> I expect "delete" to either actually delete (ie, gone NOW) or for it
>> to "move to trash", and leave it there until I say otherwise. This is
>> how I have been trained by my computer.
>
> Patches warmly welcomed! :)
Perhaps I'm confused. I thought that this was the current behavior,
in the absence of the cron job. Did I misunderstand?
--
Rich Bowen
rbo...@rcbowen.com
Chris J. Davis
In my mind if we say "delete", we should be deleting immediately. On
mac os x, the menu item says "move to trash", this means that we are
not deleting, we are moving it to another holding bin, until we
decide to delete it. If we are wanting to go the route of deleting
at a later date, then we need to say, "move to trash" and not "delete".
I am a fan of the cron powered delete. But I think we need to give
the user the power to turn that functionality off or on. And yes
skippy, I will look at the cron system and try to put together a
pafch that will allow this to happen, when I get some time.
Chris
Owen Winkler
>
> Man, this has become a fairly lively discussion.
It rivals the last one, found here:
http://groups.google.com/group/habari-dev/browse_thread/thread/352aa4d88b1fb6b7
and here:
http://groups.google.com/group/habari-dev/browse_thread/thread/9f4a88c034e71c1d
and here:
http://groups.google.com/group/habari-dev/browse_thread/thread/ad4a14af508b632f
Which included prior (informal) voting on the issue, many other ideas
that this thread hasn't even touched on (like why there is no "delete"
button in habari, and opinions on revisioning), and p-code for
actually doing the purge that is currently missing.
Owen
sfong15
2.
In the posttype table there are 2 entries, id=2, name=page.
Has anyone ever imported this many posts and pages? The weird thing
is that when a new page is created another one is spilled over, i.e.
only 4 or 5 pages can be shown at one time.
On Aug 15, 8:22 pm, Scott Merrill <ski...@skippy.net> wrote:
> sfong15 wrote:
> > While 'pages' in admin is being discussed, I still have trouble
> > deleting pages from admin, I got 'danger, will robinson! danger!' see
> >http://groups.google.com/group/habari-dev/browse_thread/thread/acb467...
Michael Bishop
On Aug 14, 11:53 pm, Scott Merrill <ski...@skippy.net> wrote:
> I also have this:
> #content .draft { background-color: #ffc; }
>
> Which will show my draft posts in a nice light yellow.
>
Is this class added by default? I'm not seeing it when inspecting my
CSS with web dev toolbar, and adding .draft to my style sheet did
nothing.
~miklb
tinyau
class="<?php echo Post::status_name( $post->status ); ?>"
--
tinyau
Michael Bishop
is something in core, there should be a default class set somehow. I
have posts in several locations based on tags, and having to set
dynamic classes all over the place so *I* know what are drafts, and
not confused every time I visit the site shouldn't be on "me". Just
my 2 ¢.
~miklb
For the record, I'm digging through things to see if this is an
option, and will try to provide a patch if I figure it out.
On Aug 16, 11:48 am, tinyau <tinyau.vamp...@gmail.com> wrote:
> No such CSS class in default K2 theme. You can use the following code to
> add post status as CSS class for the post.
>
> class="<?php echo Post::status_name( $post->status ); ?>"
>
> --
> tinyau
>
Michael Bishop
adding echo '<div class="' . Post::status_name( $post->status ) .
'">'; inside the loop appends each status, so in my case, the first
aside is .published, the second is .published .draft, the third
is .published .draft .published.
Adding this before the foreach applies a single .published class.
Obviously I'm missing an important step?
The full code in the sidebar is:
<?php
foreach($asides as $post):
echo '<li><span class="date ">';
echo $post->pubdate_out . ' - ' . '</span>';
echo '<a href="' . $post->permalink .'"/>' . $post-
>title_out . '</a> - '. $post->content_out;
echo '</li>';
?>
Where $asides is defined in theme.php
~miklb
On Aug 16, 11:48 am, tinyau <tinyau.vamp...@gmail.com> wrote:
> No such CSS class in default K2 theme. You can use the following code to
> add post status as CSS class for the post.
>
> class="<?php echo Post::status_name( $post->status ); ?>"
>
> --
> tinyau
>
tinyau
Please see the following modified code, I have added the CSS class to <li> instead.
<?php
foreach( $asides as $post ):
echo '<li class="' . Post::status_name( $post->status ) . '"><span class="date ">';
echo $post->pubdate_out . ' - ' . '</span>';
echo '<a href="' . $post->permalink .'"/>' . $post->title_out . '</a> - '. $post->content_out;
echo '</li>';
?>
--
tinyau
Michael Bishop
the code.
That certainly helps.
I'll add it to the wiki as well, after I mess around with adding it to
posts as well.
~miklb
On Aug 16, 9:48 pm, tinyau <tinyau.vamp...@gmail.com> wrote:
> Have you missed 'endforeach' in your foreach loop? Personally, I like to
> use opening / closing brace instead.
>
> Please see the following modified code, I have added the CSS class to <li>
> instead.
>
> <?php
> foreach( $asides as $post ):
> echo '<li class="' . Post::status_name( $post->status ) . '"><span
> class="date ">';
> echo $post->pubdate_out . ' - ' . '</span>';
> echo '<a href="' . $post->permalink .'"/>' . $post->title_out .
> '</a> - '. $post->content_out;
> echo '</li>';
> endforeach;
> ?>
>
> --
> tinyau
>
Scott Merrill
>> If you're not comfortable with that -- because you want explicit
>> manual
>> deletion, or lengthier undelete windows of opportunity -- then I
>> think a
>> plugin is what you need. Any number of plugins should easily be
>> supported to enforce the (un)delete policy you feel is appropriate for
>> your site.
>
> I'm uncomfortable with that, but apparently wasn't paying attention
> during that conversation. The default should be to NEVER purge
> deleted posts. On the one case that someone wants an undelete and
> doesn't have it, we become untrusted, unreliable, loses data!!! It is
> better to make someone explicitly decide to purge, or explicitly
> decide to do a "purge after N days" than to have this as the default
> behavior. We should default to not losing data.
Without too much difficulty, I think we could easily move the undelete
functionality to a plugin:
* remove the portion of code that sets the status to "deleted"
* change line 422 to invoke Plugins::filter() instead of Plugins::act()
* have the undelete plugin register the "deleted" status, rather than
adminhandler
* register a filter on post_delete to change the status, and return NULL
(or boolean false)
* have Post::delete() check the return value of Plugins::filter(), and
simply return if it gets a NULL (or boolean false)
The plugin could also add UI for undelete functionality. This would be
a nice plugin to demonstrate how plugins can interact with the core of
Habari. It will need attention over time, obviously, as ACL permissions
come into play more.