Hello, we’ve been using several custom blacklists created via the blacklist editor in the web interface in IPFire for a long time. We also use the Toulouse blacklist source. These manually created blacklists were always saved under /var/ipfire/urlfilter/blacklists/myblacklist1 … myblacklist2 … and were still there after the Toulouse auto-update. Since the update to version 200, however, these manually created blacklists are deleted every time the Toulouse auto-update occurs. Is this a bug? Even when I create a new custom blacklist in version 200 using the blacklist editor, it also ends up in this same folder and is overwritten again at night. Surely this is a bug, or how can I use multiple manual blacklists in version 200? Moving the blacklists to the custom directory doesn’t help either; if they’re located there, they don’t appear in the web interface and can’t be selected.
Hallo @lrez
Welcome to the IPFire community.
What you are describing was a bug situation. The aim of the URL Filter was that you choose one of the available blocklists or a Custom URL but not have multiple lists selected at the same time. So the Custom URL option should be selected as shown here
when a Custom Blocklist was wanted to be used.
In the past when changing to a different blocklist the previous versions were not removed. This could result in categories that changed name and the old named version still existed in the display but was no longer updated.,
This situation, of the old blocklists not being removed was raised as a bug in Feb 2025 and was fixed in CU200.
https://bugzilla.ipfire.org/show_bug.cgi?id=13820
This now ensures that when you select one of the three options in the Download Source then the blocklists from the previous version are fully removed as was the original intent.
So does this mean it’s no longer possible to use a combination of Toulouse categories and several custom categories simultaneously, as it was possible in versions < 200? For us this was a great feature and not a bug in all the last years……
That is correct.
It was only the fact that a process was missed to remove the old categories when a list source was changed that allowed all the categories ever created by any source to stay in place, even when no longer updated.
I just saw a change in the autoupdate.pl file that looks like it might be leaving any custom lists in place.
This commit is in CU201 Testing.
I don’t use any custom lists so can’t easily test this and don’t currently have the time to set up a custom list to test it.
If you can do a test of CU201 Testing then you might find that it has been made available again.
I had the same “problem” after CU200 update.
So after looking into it i changed the following:
For keeping your custom lists (not only custom block/allow) from main URL filter page as per default, you have to replace line 2593 in /srv/web/ipfire/cgi-bin/urlfilter.cgi:
unless ($category =~ /\bcustom\b/) { push(@categories,$category); }
with:
if ($category =~ m@/custom-[^/]+$@) { push(@categories, $category); }
elsif ($category =~ m@/custom/?$@ || $category =~ m@/custom/@) {}
else { push(@categories, $category); }
This displays all lists beginning with “custom-” as “custom-games”, “custom-anything”, etc in URL filter configuration page while leaving already present custom/allowed and custom/blocked lists hidden.
Then you have to replace line 231 in /var/ipfire/urlfilter/bin/autoupdate.pl under
# Keep custom lists
next if ($item eq "custom");
with:
next if ($item =~ /^custom/);
This doesn’t cleanUP any list that begins with “custom” during lists update. (keepeng in mind that also custom/block and custom/allowed lists from main URL filter page don’t get deleted/removed during scheduled or manual update there must be no “-” sign after “custom” in changed autoupdate.pl line.
You will have to recommit changes every time when pakfire updates urlfilter.cgi and/or autoupdate.pl file.
Of course it would be very nice if Mr. Adolf could test this and add it into distribution…
Regards,
B. Hudina
It would be nice if someone from the users who uses custom lists would create and submit a patch.
I currently don’t have time to do that and don’t use custom lists and so could not test it.
The developers on this project are a very small group of people and most of them also have to do their day jobs to be able to pay the bills.
If more users did donations, especially regular donations so that there is more available than just about paying for the infrastructure costs then more things could get supported but currently that is not the case.