Restore ability to add blacklists in bulk

With the migration to 5.0 it seems the text box to add a large amount of blacklists is now gone in favor of a one by one with notation. While this is fine for one offs how does one add a bunch at once either via web interface or the command line? Will this be restored as in 4.x or future releases of 5.0?

1 Like

By command line:
sudo nano /etc/pihole/adlists.list

But having it on the web interface would be nice to have back.

This isn't valid in my testing... the reason why I say this while new ones are added those weren't sucked into the gravity command when I tested with "pihole -g" they weren't pulled in. I also have legacy ones not in my current settings accessible via the web interface and those aren't cleaned up.

1 Like

I see that now. I did not test it previously. Sorry about that.

Something concerning notation: With "blacklists" you mean:

  • adlists (lists that contain domains to be blocked, collected by gravity), or
  • blacklist entries (exactly blocked domains)?

I assume the former. Where do you expect to see them? Settings page, new group management page, or...?

For me it is the adlist. On the admin console you can only add one list at a time. This appears to be because of the "comments". I used "sudo nano /etc/pihole/adlists.list" to add some and they did not import to/or shown on the web console.

I'm not sure how often the import trigger happens.

Would it be possible to add a flag (yeah, yet another) to pihole that would import and dedupe /etc/pihole/adlists.list?

Pi-hole v5.0 does not use the lists files anymore, instead, we use a common database (/etc/pihole/gravity.db) as single source of truth. You can always add/edit/delete everything Pi-hole related in here using the SQL editor of your preference.

I will think about how much work restoring the mass-injection (separated by spaces) feature would be. If it is manageable (I think it is), I will add it.

1 Like

Awesome Thank you. For current users it should not be an issue, but for new users or installs it could be something they might use.

Mass-injection of items will be restored by


I just saw your comment for that pull request

Also, we remove the redundant list management from the settings page as this code was only partially migrated to the database backend (it was planed to be replace, anyway) and still uses CLI callbacks in the background. It is not needed any longer. I added a link to the new page so users will not be confused by a sudden absence of the settings tab.

Why not go a step further: remove Whitelist and Blacklist from the side-panel as well? One can do the same configuration (and even more) in Group management/Domains. Its kind of confusing to have two places for setting up white- and blacklists. In the end white/blacklists displaying just filtered information from the Group management/Domain table. You could also combine it with what if suggested here: add the ability to filter the list, not just sorting it. This would "restore" the classical white/blacklist view by only display selected items.

Impression what I mean with filter:

I did something similar now in

Nice work.

Two things: I would still prefer (or in addition) see the above suggested filter.

And: Long regex brake the UI.

I thinks this might be the same issue that was resolved here - is it just due to switching branches or did you remove the patch by accident?

No, this UI is not broken here at all. A horizontal scrolling bar is added and you can reach everything.
What else would you expect to happen if you put in such a lengthy regex?

In the referenced issue, the table exceeded the page and you were not able to reach the other elements. This is not happening here and the table remains fully usable (at least I have not seen anything showing the opposite).

I would expect some line breaks to avoid a horizontal scrolling bar.

Now I get them - I didn't change anything (maybe a browser cache issue?). This is what I would expect in a responsive table. Maybe the line breaks don't work in all circumstances?

Your're right - this was a different problem.

I noticed the order of the entries in the blacklist changed as well... the long entry was #20 in the post above and is now #26. Don't no if this matters... I think the database ID is the same.

Do you see the same in different browsers? Also, there shouldn't be this [object Object] thing where the select list should be... What browser is this?

It is at least strange, the table should be default order by the database ID, did you click any of the column headers for sorting?

Firefox 73.0 (64-Bit)

Chrome 80.0

This was on chrome. Now it's gone

No. It seams like chrome sorts for domain and firefox for database ID.

Cleared chromes cache and now the sorting is by database ID. But I get Object Object again

Clicked again on "Blacklist" (Chrome) and it l looks ok. Seems like the fist time the view got messed up between blacklist and group management/domains.

Steps to reproduce on Chrome:
clear browser cache, restart browser, log in to pihole web UI, click on blacklist --> UI error with Object object --> click again on blacklist --> everything is fine.

Just leaves the missing line breaks in firefox...

Thanks for all your tests, so far! Could you please update once more and check if the situation improved for both issues (long domain/regex wrapping + [object Object] on first visit)?