Hi John, I noticed you regularly delete spam pages in our wiki, which is a very good thing to do. As you and I and hopefully others have noticed, we now get approx. 1-5 spam pages created every day, which have to be deleted manually.
This is even though new pages can be created by users who have been registered for more than x days. However, once you check the RecentChanges with a view mode that shows the new user registrations, we notice that every day there are approx. 50 new users being registered! Some of these will stay silent for a few days, then - after the waiting period is over - create the spam page. This way, the waiting period does nothing more than reducing the spam rate, but it doesn't cut it off completely anymore. This is the same for several months by now. I also don't have a good solution for this. I think I can contribute to a check of the RecentChanges every 1-3 days, so that this spam is deleted manually. (The keyboard shortcuts help a bit: Alt-Shift-D for choosing the page's hyperlink for "Delete this page", then Ctrl-A, Del for deleting the deletion reason, then Tab-Tab-Enter for really pressing the delete button, and all this with many browser tabs in parallel between which I navigate with Ctrl-PgUp/Down.) However, I noticed in your spam deletions that you deleted only the normal pages, but not the user pages of those spammers. Probably you look at the RecentChanges page only with the subset of "Namespace = (Main)". I look at this page with the choice "Namespace = all". The backside of this is that I see those 100 new users every day and the edits scattered in between. The upside is that I see also the newly created spam userpages (in the "User:" namespace), and then I delete those as well. Do you think you can check for those as well, or do we need other solutions for this? Other wikis around have disabled the normal user registration altogether for this very same reason, see e.g. http://elinux.org/Main_Page . Maybe this is a possibility for us as well? The vast majority of edits in the actual content is done by known developers from here. By this, we can argue that an increased restriction of the write access doesn't do much harm, but would make our life a lot easier. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel