Newsletter delete function does not work

Mar 23, 2011 at 5:34 PM
Edited Mar 23, 2011 at 5:35 PM

I login as admin, click on edit for the newsletter, click delete on an address, save it.  Check it though edit again and the address is still there.  It seems the only way to delete an address is to download the newsletter.xml file and then republish it.

Be2.0

 

Mar 24, 2011 at 2:28 PM

Hi Jerry,

Where in in the admin panel can you find the function to edit the newsletter? 

Thanks

Mar 24, 2011 at 2:48 PM

Not in the admin panel, just click edit on the widget.

Mar 24, 2011 at 4:43 PM
Edited Mar 25, 2011 at 10:55 AM

I noticed this as well when first starting to play around with BE, I put it on the back burner since it wasn't an issue for me (nice if it was).

Of course you can still delete users by typing their email back into the widget, but that's not really the point.

Quite curious now as to the reason why it's not saving.

Mar 24, 2011 at 5:45 PM

I hope someone fixes this, I have use for it, I have 2 Newsletter Wiglets on my website and have a need for the delete function, I now have to download, update and republish the xml file weveral times a day, this is still better then typing in email addresses.

Mar 24, 2011 at 9:23 PM
Edited Mar 25, 2011 at 10:56 AM

Curiosity got the better of me.

When you delete an email the row is deleted from the grid, so that's working.

When you close after edit and open it's back, which suggests to me that the list with deleted item was not being saved and you got the original back on load.

You want the list saved after deleting an item, this worked for me. I've not fully tested for side effects but I think it should be good.

In the function private void GridEmailsRowDeleting(object sender, GridViewDeleteEventArgs e) just before the last line you want to insert SaveEmails()

The close of that function will then look like this

 

    	doc.FirstChild.RemoveChild(node);
        SaveEmails();
        this.BindGrid();
     }
Mar 24, 2011 at 10:02 PM

Thanks, I'll try this although after deleting I saved and the address was still there wen opened again.

Mar 24, 2011 at 10:10 PM
Edited Mar 25, 2011 at 11:26 AM

Putting the SaveEmail() here commits the changes to file before anything else happens.

I'm going to browse over the code again, because after looking at the logic for the BE 1.6 version it didn't seem to require this and works, there is likely a better way of sorting it in BE 2.

Mar 24, 2011 at 11:12 PM
Edited Mar 25, 2011 at 11:31 AM

I think I've been looking at this too long, putting the SaveEmails() here means that the save button applys only to additions and edits because delete initiates it's own update processes.

These processes happen before you get to hit that save button.

I'm going with the SaveEmails() solution for now.

Mar 25, 2011 at 1:28 AM
Edited Mar 25, 2011 at 1:40 AM

Stop press, better solution, took a breather and came back to it.

This is more like what were after.

Amend the OnInit function to include post back check.

 

protected override void OnInit(EventArgs e)
        {
            if (!Page.IsPostBack)
            {
                doc = null;
                this.BindGrid();
            }
            this.gridEmails.RowDeleting += this.GridEmailsRowDeleting;
            this.gridEmails.RowDataBound += this.GridEmailsRowDataBound;

            base.OnInit(e);
        }

So you can take the SaveEmails() back out and save and cancel now behave as you would expect them to.

Mar 25, 2011 at 12:25 PM

Thank you but where exactely do I put this code, what file and line number?

Mar 25, 2011 at 12:36 PM

The code goes in the code behind file for the newsletter 'edit' user control (edit.ascx.cs) found in  Widgets > Newsletter > edit.ascx.cs

Code block that needs updating is around line 58

Tried it myself and works a treat!

Nice work Andy!!

Mar 25, 2011 at 1:21 PM

Further testing is showing up some strange behaviour, so I've edited out any superfluous stuff from my previous comments to make clearer the train of thought.

We needed the post back check added to ensure doc is correctly initialized to null because it's value gets queried and affects what happens after that,  end result in this case whether or not items are deleted from file.

To test, add say 3 made up emails and then delete them. Open the widget for edit again and they are gone, open the XML file and they are gone, all seems good.

Shut the browser then open up the widget to edit again (or even shut the computer down), add another made up email and the previously deleted ones appear as well. The same thing happens with the newsletter widget in BE 1.6

Not quite sure what is going on here, anybody any idea where the previously deleted entries are coming from, because they were not showing up on the XML file?

Mar 25, 2011 at 1:35 PM

Nice one max, when I was cleaning up the comments I overdid it and took out the file reference.

Mar 25, 2011 at 2:40 PM

So is the code above finished or is there more to add, thanks for doing this?

Mar 25, 2011 at 3:05 PM

Jerry, I have tested Andy's code snippet at it seems to be working fine.

Cheers again Andy! 

Mar 25, 2011 at 3:19 PM

Yes, it works great, thanks again for working on this.

Mar 25, 2011 at 6:18 PM

Thanks folks, just playing around with what was already there.

Whilst testing I was still getting problems with previously deleted entries resurfacing when adding a new entry, which is strange because all the changes were being saved, I double checked by opening the XML file each time to have a look.

There were no problems however when opening edit just to have a look, everything was as it should be.

When I flushed the cache, no further issues.

I'm not sure why it's only the act of adding a new entry that might cause a cached copy of the list to be fetched, if that is indeed what is happening.

I'm mentioning this in case you do encounter any problems, in the meantime I'll keep plugging away as time permits, any suggestions are more than welcome.

 

 

Mar 25, 2011 at 6:52 PM

Sledge hammer approach, force the cache to clear.

 private static void SaveEmails()
        {
            using (var ms = new MemoryStream())
            using (var fs = File.Open(fileName, FileMode.Create, FileAccess.Write))
            {
                doc.Save(ms);
                ms.WriteTo(fs);
            }
            System.Web.HttpRuntime.Close(); //*************************************************** Added here to clear the cache
        }

Apart from the brute force approach, everything is hunky dory now.

There has to be a less intrusive way of doing it.