Improve domain list inout fields

On the black/whitelist page one can add an domain and select the type “wildcard black/whitelist”. I think this term is misleading and can be misinterpreted resulting in faulty regex. The term “wildcard” suggests one can enter common wildcard symbols like * or ?

At least two people (see here and here) have used * in conjunction with a domain which caused pihole -q and phole -d to fail (here and here) because of the automatically generated (faulty) regex.

Although it is acknowledged that there should be some kind of regex syntax checker the issue arose from misinterpreting the term “wildcard” - and should be omitted.

As it meant to block subdomains I suggest “subdomain black/whitelist”)

It is a wildcard domain, catching a incorrect formed domain for forming a correct wildcard domain is not that difficult.

1 Like

Certainly open to discussion. Anything that makes the tools we provide for users clearer to use is a bonus.

That said, was/is it not the same thing in v4.x?

1 Like

It is/was the same in v4.x. I just brought it up here because black/whitelist page have been modified with the implementation of the group management pages and this would be an easy and fast fix.

I think we disagree on this. For me these are two issues where one leads to the other. Implementing a regex check is needed but that is not enough. I still think the term “wildcard” is easily misinterpreted and should be renamed.

The term wildcard domain is used with dnsmasq to have also the sub-domains havein the same IP address:

address=/wildcardtest.com/100.100.100.100

If find wildcard is confusing then maybe remove, the easy creating of wildcards and have users put in a correct formed RegEx manually.

This will also encourage users to learn proper usage of RegEx.

It will make Pi-hole easier to maintain and explain because there is only RegEx and exact and not the third form that is stored in RegEx.

I would be OK with that.

Noble thought but uses are not going to learn regex. Wildcard is what is says on the tin.

Yeah, regex can be intimidating to even those that have done it before. Some people might even be totally put off by the idea of having to wrap their heads around learning regex in order to wildcard block/whitelist something.

Hell, I’ve done regex before and I even find it intimidating.

1 Like

The blacklist page is labeled “domain”, with the text “domain to be added”. Domains don’t contain wildcard characters.

Perhaps we could clarify the wording here - if you enter a domain name, you select either exact blacklist or wildcard blacklist as the type; if you enter a regex, you select the regex type.

1 Like

The idea of * throwing a “NO” response is fine with me. It’s an open issue to resolve but it may take more than an instant to get it written.

I think it is not the wording “Domain to be added” that will prevent wrong inputs. As the same input field is used for domains and regex, users might be used to enter special (regex) characters in this field. If you want to prevent that I see two options: rename ‘wildcard’ or reduce the amount of available type options depending on the user’s input (no special characters - only exact and wildcard visible, containing a regex character - only regex available)

How about splitting the entry options into two separate boxes?

Top for a domain name, and the choice there is either to exact blacklist or wildcard blacklist. Basically what we have now, without the regex option. Users enter a domain name here.

Below that, a separate entry line labeled “regular expression” that has only one choice, regex. Users enter a regex here.

No checking, let the user make the correct choice.

1 Like

Have been thinking about this too - but came to the conclusion that this would complicate and destroy the nice interface.

Side note: wildcard type is missing in the group managment/domains page - I see some inconsistency here. By design or accident?

Users won’t make correct choices. They will make mistakes (because they don’t know better) leading to ‘malfunctioning’ and lot of help requests in the forum. You could prevent the effort for all with some kind of check (if you want to educate - pop up a note why the input was wrong).

You want it to be clearer, but you also want to keep the same interface? That seems contradictory.

This is a relatively simple change that doesn’t require additional code for checking, parsing, warning, etc. You enter domain names in one area, regex in another. Domain names don’t include wildcard characters.

Note that we don’t check the user regex for correctness - if they enter something that doesn’t work, it won’t work.

1 Like

Yes, this has been heard and I’ve said a few times that we’ll look at it. Just be patient.

2 Likes

Yes. That’s why I initially suggested to just rename the ‘Wildcard black/whitelist’ to something like ‘Subdomain black/whitelist’ to make it less tempting to enter *. At least to me it wasn’t clear that I should not enter the wildcard symbol * despite it is called ‘wildcard blacklist’.

Sorry for that. It wasn’t meant to push but solely as a reply to jfb’s comment.

@PromoFaux Quick question. How long have we had wildcard capability and how long has the web interface been set up like it is now?

I’ve a different thought all together.

How about we put a box up the top of the form, with some blurb explaining how to use the form, that way it cannot be unclear.

Also, to answer your question, I haven’t actually used the web interface for a long time. In very much in the set and forget camp… But let me check

3 Likes