Opened on 02/02/2015 at 03:44:43 PM

Closed on 08/29/2019 at 05:43:52 PM

#1920 closed change (rejected)

Named domain arrays for filter lists

Reported by: Lain_13 Assignee:
Priority: Unknown Milestone:
Module: Core Keywords: filtersyntax, closed-in-favor-of-gitlab
Cc: greiner, mapx, sergz, hfiguiere Blocked By:
Blocking: Platform: Unknown
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by greiner)


We periodically need to maintain multiple different filters for the same list of domains. One of the best examples is acceptable ads list since more than 90% of it is repeated rules for the same domains. It's done to avoid whitelisting by a wildcard which most certainly will be abused.


Declare named array of domains and use it in the filters.



...and so on for all known Google domains.

Replace with:


Such arrays must be available also in the $domain= lists and for hiding filters.



Replace with:



Such feature will break compatibility with old ABP versions and third-party extensions.


Generate different versions of the filters list. Send filter list syntax version in the download URL. In case of extending syntax in the future number of lists to generate will grow linear.


If version specified - serve list with features available for that version. If not specified - serve maximally compatible version (auto-generated filters from arrays and so on).

We may want to consider maintaining a couple of globally available variables for popular domains to make them useful in all filter lists and user filters.

Attachments (0)

Change History (8)

comment:1 Changed on 02/04/2015 at 01:00:07 PM by Lain_13

Additinally this will allow to maintain large lists of domains for filters with such lists without loosing statistic on them.

For exaple I have following filters:

Each of them have a large list of domains in place of ... and hit statistic is lost every time when domain added or removed.

comment:2 Changed on 03/05/2015 at 11:07:03 AM by greiner

  • Component changed from Unknown to Core
  • Description modified (diff)
  • Keywords filtersyntax added
  • Owner set to trev

If I understand you correctly, you want to have support for filter text variables. Is that correct?

Currently, filters are independent of each other. Whitelisting is a case in which they're not. There a filter can interfer with another but due to whitelisting filters always having a higher priority than other filters, there's no conflict when different filters target the same resource and it also makes them independent of the order they were specified in.

With variables, however, it's unclear which value it should have when it's declared multiple times (e.g. across different filter lists).

comment:3 Changed on 03/05/2015 at 11:07:58 AM by greiner

  • Cc greiner added
  • Owner trev deleted

Not sure why it automatically set the owner to trev so I reverted that.

comment:4 Changed on 03/06/2015 at 08:18:05 PM by Lain_13

Yes, I'd like to have variables of at least array type.

I guess variables with the same name should merge.


Should turn into:

Obviously we shouldn't give them short names to avoid merging unless it's intentional. For example, it could be a good idea for a "##.banner" hiding rule. So, just avoid short generic names as in the example above and there will be no problems. Also, it could be a good idea to give a prefix to variables like [el_varName] for EasyList variables to make sure it won't be accidentally used even if the rest of the name is short and generic.

BTW, probably extending $domain functionality for that is a wrong idea. "[var]=list" should be enough.

Last edited on 03/06/2015 at 08:18:27 PM by Lain_13

comment:5 Changed on 03/25/2015 at 09:37:45 AM by mapx

  • Cc mapx added
  • Verified working unset

comment:6 Changed on 01/04/2018 at 11:14:45 AM by sergz

  • Cc sergz hfiguiere kzar added
  • Tester set to Unknown

comment:7 Changed on 01/05/2018 at 03:54:06 PM by kzar

  • Cc kzar removed

comment:8 Changed on 08/29/2019 at 05:43:52 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.