Forum OpenACS Development: Weblogger: Can't delete draft entry

Collapse
1: Weblogger: Can't delete draft entry
Posted by Jason Schock on 11/17/05 04:04 AM
Since upgrading to latest Weblogger version, whenver I try to delete a draft entry using the interface, nothing happens. Page just reloads. No error message, no log message.

If I replace the current code in entry-delete.tcl: 

ad_page_contract {} {
    entry_id:integer
    {return_url "."}
}

ad_form -name confirmation \
    -cancel_url $return_url \
    -form {
    {entry_id:text(hidden)
        {value $entry_id}
    }
    } -on_submit {
    lars_blogger::entry::delete -entry_id $entry_id
    } -after_submit {
    ad_returnredirect $return_url
    ad_script_abort
    } \
    -export {return_url}

set page_title "[_ lars-blogger.Confirm_Delete]"
set context [list $page_title]

ad_return_template

with the code from the older version: 

ad_page_contract {} {
    entry_id:integer
    {return_url "."}
}

lars_blogger::entry::delete -entry_id $entry_id

ad_returnredirect $return_url

it works again. Ran all the the SQL in the updates folder. Installed another instance of Weblogger and duplicated this bug.

I know this is hard to divine without any meaningful error messages, but thought I'd throw it out in case anyone has a clue about where to look to fix this bug. Thanks.

Collapse
2: Re: Weblogger: Can't delete draft entry (response to 1)
Posted by Malte Sussdorff on 11/17/05 08:19 AM
If you ask me, we should get rid of this confirmation message in the first place. After all, we are deleting a *DRAFT*. It would be something different if we were deleting a published item, but for a draft...

Jeff, as you committed this change, what is the rationale behind it and would it be okay to go back to not confirming the deletion of unpublished items? One click more can be pretty annoying 😊.

Collapse
3: Re: Weblogger: Can't delete draft entry (response to 1)
Posted by Jason Schock on 11/17/05 11:09 AM
[Tangent alert]

Well, in order to delete any entry, it has to be toggled to draft mode first. So you could feasibly be deleting what was a published entry, so arguably, the confirmation could stay. Plus, the added overhead of a confirm screen isn't really a big deal if you consider that most people probably aren't deleting entries too frequently.

That said, this delete method isn't an intuitive concept, though I understand the intent behind it. Several times, I've stumbled over deleting entries before hunting around a few minutes and finally remembering how.

A better way might be to have a management screen with a list of both draft and published entries, each with a delete icon, and only for published entries ask for a confirmation.