As I needed a way to allow users to add, edit and delete content on a site I’m working on I have had to do some of the legwork myself in the form of an entry deletion plugin. I’ve tested this fairly extensively on a development site without any problems, but would still recommend that anyone using it is very careful to ensure their member group access levels are set correctly and that they test, test and test some more before putting it on a live site.

The plugin itself runs through the same checks as the code that EE itself uses through the control panel (in fact quite a bit is ‘borrowed’ code ) and executes the same queries when removing an entry, so any counters etc should remain just as accurate as if the entry was deleted through the control panel.

The usage details are included in the plugin but are also available on my site. You can see a bit more info and download the plugin from this blog post, no registration necessary.

Let me know if you find this useful. (And if you delete all of your entries with no backup available after 5 minutes of fiddling don’t say I didn’t warn you - be careful!)

Hello,

I certainly find this useful. I do have one question regarding it… Although everything works a charm, I do get 3 ugly errors at the top of the delete page saying:

Notice: Undefined variable: weblog_id in ...serverpath…/system/plugins/pi.delete_entry.php on line 135

Notice: Undefined variable: weblog_id in ...serverpath…/system/plugins/pi.delete_entry.php on line 136

Notice: Undefined variable: weblog_id in ...serverpath…/system/plugins/pi.delete_entry.php on line 137

The lines in question are:

Any ideas on how I can fix this?

Actually, make that 2 questions… The return link goes to styles/css_nostyle for some reason when it actually came from main/looking_for_someone. Where is this set and how can I amend this?

Thanks

Patrick

Hi Patrick,

I’ve no idea how the error didn’t turn up when I was testing this but weblog_id wasn’t even defined. I’ve updated the existing plugin (it’s still here) to reflect this change as well as added a security check to the segment data, so I would recommend that anyone using the plugin updates even if they’re not having any problems.

As far as the return link’s concerned, I would say you want to look at line 148 and the phrase $SESS->tracker[‘1’]. This is an inbuilt EE feature which keeps track of your recently visited pages and $SESS->tracker[‘1’] should be the page that you last visited, it certainly seems odd that a CSS page has been registered as a page. The first thing I’d check would be that your CSS file is specified as such in the template preferences (as opposed to being a web page). If it is then you may want to try $SESS->tracker[‘2’] instead or you could hardcode the $prevpage variable to the desired return page, although this obviously means you lose the dynamic aspect of the feature. If you’re hardcoding you would just need to add the EE path such as “mysite/mypage”.

Hope that helps,
Dom

Hi there,

Thanks for the update. I had a look in the code and couldnt see it defined but I wasnt sure how it all worked so didnt know where I could fix it. I have ended up hard coding the return link to be the php global HTTP_REFERER as it still keeps some kind of dynamicism (cool word - if it is one). Using the $prevpage or the tracker didnt work at all, so not sure why. My stylesheets are defined as such, though I did realise that the stylesheet it links to doesn’t exist - but is referred to in my stylesheet linking (just havent made the sheet yet), so maybe that has something to do with it. I will be trying that too.

In the mean time, thanks heaps for the plugin, I am finding it most useful along with the edit one.

Thanks

Patrick

No problem, glad to hear it’s of use. I initially coded the plugin for an ‘in house’ project which is currently on the backburner, but I intend to have another look at it before that launches so it’s fairly likely there will be an improved version out in the not too distant future, possibly in the form of a module (thanks to some excellent advice from Derek).

The return link issue is still a total mystery to me and I can only assume it’s to do with the way the tracker feature works rather than a specific piece of my code. It could be worth searching for more details on that unless you’re happy with the way you now have it working.

Hi Dom,

I uploaded the new code, but still have the same weblog not defined issue, in the same place… what code did you change? Perhaps I can change it manually to see if it makes a difference… I used the link you provided above to get the plugin.

Thanks

Patrick

I’ve just double checked and I definitely uploaded the right version. The definition of $weblog_id is very simple so I’m surprised there are any problems with it. The line in question is #69:

And the query is:

The ID is definitely being pulled from my database successfully so I would say it’s either a server specific issue or related to your database specifically. At the moment I’m not sure I can offer anything more useful than that.

Hi, Dom.

It would be nice if there was a parameter to cause the delete link to be simply a URL, instead of an HTML tag.  That way, we could make the delete link be the POST action of a form, and thus the delete link could be a button instead of a text link.

It’s good UI practice to make permanent actions (like deleting) be only the product of a POST and not just the destination of a linked URL. There have been problems where link pre-fetchers will “click” all links on a page, and thus cause problems for people who have a page of entries with associated “delete” links. This is especially true because pre-fetchers might not bother looking at associated javascript, and so your confirmation code would be ignored.  Yikes!

Another sometimes-useful solution is to have the destination of the click supplied onclick by a javascript, instead of being in the href of an A tag.  But this only works if folks have javascript turned on, and so excludes some small percent of folks.

TTFN
Travis

Thanks for all the feedback Travis. I’m aware that there are a lot of issues with this plugin currently, but I’m afraid I’m not currently able to devote the time needed for a full rewrite (which is what I feel is necessary). The plugin was initially intended for a project of my own but it’s been shelved for now, sadly.

If people do want to use it then as I’ve said, great care should be taken. As you say, the GET requests are far from ideal.

Dom,

If I had some spare time (ha!) in the next month or so, would you mind if I worked on improving this?

TTFN
Travis

No, not at all. I was thinking of converting it to a module but I’m sure even in plugin form it can be significantly improved. If you can find the time then feel free, I look forward to seeing the changes. :)

I’m subscribing as well, in case there are updates

Quick bump to ask, was this plugin ever update to allow POST requests?