Symphony.

How can I delete an entry via events? Is there any plugin for this purpose?

Thanks.

For obvious security reasons, you can’t. Not without a couple lines of PHP inside your Event however. The reason being that usually you need to authenticate a user first, and be sure that the user is deleting an entry that they are allowed to delete.

What is your user story (requirement)?

A barebones example: customise your Event __trigger function to look like this:

protected function __trigger(){ 
    $entry_id = (int)$_POST['id'];  
    require_once(TOOLKIT . '/class.entrymanager.php');
    $entryManager = new EntryManager($this->_Parent);
    $entryManager->delete($entry_id);
}       

And also modify the allowEditorToParse to return false.

This will allow you to pass a hidden form field “id” of the entry ID to delete. But obviously this is entirely insecure and not recommended. You would also need to do other checks to make sure this isn’t being used maliciously.

You could always just have a “Publish” checkbox field and filter on that. Would mean you can set it to “No” using Events and have a way to rollback deletion if someone makes a mistake.

@nickdunn I need to delete an entry from a section and put the same data on a history section. I did what you told me and it works fine but do you imagine something else?

Makenosound’s suggestion is much better since it is non-destructive. It’s a method I’ve used a million times before, so I don’t know why I didn’t suggest it myself!

I need to delete an entry from a section and put the same data on a history section

So you want to move an entry between two sections? Your History section will need to have exactly the same field structure as your Original section so that the entry migrates cleanly. As such, it would still make sense to keep the entry in the same section but change a “delete” or “published” checkbox flag against it.

I did what you told me and it works fine but do you imagine something else?

The issue with my code sample is that any old Joe can modify the form that’s sent to the event and delete whatever they like from the database. Where is the form that is being posted? Is it already behind some user authentication system? Is it just you who submits it?

To imitate a “History” section you could just have a state that changes and use that for filtering. It’s basically doing the same thing I outline above but perhaps more explicit—i.e. a select box with “Draft, Active, Archived, etc” that determines where things display or don’t.

Yes indeedy. And you could install the Publish Filtering extension to provide an easier way to filter these in the backend too.

@nickdunn Actually I’m using the members extension. I already use the extension that you suggested me. It’s awesome!

@Makenosound In this case, I think that’s not possible to imitate a “History” section because this section has extra fields.

Problem solved. Thanks for helping!

Will Symphony be able to delete entries in future? :-P

Yes, we are looking at it.

First we need to improve the event system so it’s more secure (this we are working on right now), then we need to look at better permission system (membership extension improvements) then we can look at how we can improve the core system’s event system to accommodate for this.

@rainerborene , how are you solve this problem with deletion?

Never use this Delete Entry event on a production site.

However, just for reference, I'm posting an example of a working Delete Entry event. I am using it to quickly demonstrate CRUD for a front end interface using Form Controls and Section Schemas and wanted a quick way to implement the delete functionality for any entry.

<?php

    require_once(TOOLKIT . '/class.event.php');

    Class eventdelete_entry extends Event{

        const ROOTELEMENT = 'delete-entry';

        public $eParamFILTERS = array(

        );

        public static function about(){
            return array(
                'name' => 'Delete Entry',
                'author' => array(
                    'name' => 'Stephen Bau',
                    'website' => 'http://domain7.com/',
                    'email' => 'stephen@domain7.com'),
                'version' => 'Symphony 2.2.5',
                'release-date' => '2011-11-29T00:02:00+00:00',
                'trigger-condition' => 'action[delete-entry]'
            );
        }

        public static function allowEditorToParse(){
            return false;
        }

        public static function documentation(){
            return '
                <h3>Delete an entry</h3>
                <p>This event has not been secured. Use with caution.</p>';
        }

        public function load(){
            if(isset($_POST['action']['delete-entry'])) return $this->__trigger();
        }

        protected function __trigger(){
            $entry_id = (int)$_POST['id'];  
            require_once(TOOLKIT . '/class.entrymanager.php');
            $entryManager = new EntryManager($this->_Parent);
            $entryManager->delete($entry_id);

            if(isset($_POST['redirect'])) redirect($_POST['redirect']);
        }

    }

Usage

Attach this event to a page and call the following template, being sure to return the value for the id of the entry to be deleted as $id. Optionally, you can include a redirect URL:

<xsl:template name="delete-entry">
    <h3>Delete Entry</h3>
    <p>Are you sure you want to delete this entry?</p>
    <form action="" method="post">
        <input name="id" type="hidden" value="{$id}" />
        <input name="redirect" type="hidden" value="{$root}/{$current-page}/" />
        <input name="action[delete-entry]" type="submit" value="Delete" />
    </form>
</xsl:template>

As Nick mentioned earlier, this is completely insecure. Be warned that this event does work on any entry ID. YOU WILL LOSE DATA.

YOU WILL LOSE DATA.

Well... loosing data is kind of the idea when trying to delete an entry :D

The main concern here should be that you can loose arbitrary data due to DOM hacking, HTTP Posts and stupid unfortunate mistakes.

Yes. Losing data is kind of the idea ;P

The main concern here should be that you can loose arbitrary data due to DOM hacking, HTTP Posts and stupid unfortunate mistakes.

Exactly right. Using this extension on a production site will render it wide open to malicious hacking, allowing someone to arbitrarily delete any or all of your entries data. For this to be useful beyond demonstration purposes, it would be necessary to add an access control layer to control when this functionality should be allowed.

For more information on using the Members extension as an access control layer for deleting entries, refer to this thread.

Nickdunn's code didn't work for Symphony 2.3. The events seem to be different.

Does anybody know how to update it?

The Managers in Symphony 2.3 are static. So the code would look like this.

protected function __trigger(){ 
    $entry_id = (int)$_POST['id'];  
    require_once(TOOLKIT . '/class.entrymanager.php');
    EntryManager::delete($entry_id);
}

You can read more about the changes in the Migration Guide for 2.3 Extension Developers or in Updating Extensions for Symphony 2.3

Thank you very much! :D