2022-09-13 21:44:24 +00:00
<!DOCTYPE html>
< html >
< head >
< meta charset = "utf-8" >
< meta name = "viewport" content = "width=device-width, initial-scale=1, minimum-scale=1" >
2025-05-11 14:17:17 +00:00
< meta name = "color-scheme" content = "light dark" / >
2022-09-13 21:44:24 +00:00
< title data-i18n = "dashboardName" > < / title >
< link rel = "stylesheet" href = "css/default.css" >
< link rel = "stylesheet" href = "css/common.css" >
< link rel = "stylesheet" href = "css/fa-icons.css" >
< link rel = "stylesheet" href = "css/dashboard.css" >
2023-09-16 15:46:39 +00:00
< link rel = "stylesheet" href = "css/dashboard-common.css" >
< link rel = "stylesheet" href = "css/filtering-mode.css" >
< link rel = "stylesheet" href = "css/settings.css" >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< link rel = "stylesheet" href = "css/develop.css" >
2023-09-16 15:46:39 +00:00
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< link rel = "icon" type = "image/png" href = "img/icon_64.png" / >
2022-09-13 21:44:24 +00:00
< / head >
2024-11-23 18:17:13 +00:00
< body data-pane = "settings" class = "loading" >
2022-09-30 13:18:52 +00:00
<!-- - - - - - - - - -->
2025-08-07 12:56:17 +00:00
< header >
< nav id = "dashboard-nav" >
< span class = "logo" > < img data-i18n-title = "extName" src = "img/ublock.svg" alt = "uBO Lite" > < / span > <!--
-->< button class = "tabButton" type = "button" data-pane = "settings" data-i18n = "settingsPageName" tabindex = "0" > < / button > <!--
-->< button class = "tabButton" type = "button" data-pane = "rulesets" data-i18n = "aboutFilterLists" tabindex = "0" > < / button > <!--
2025-09-24 14:42:18 +00:00
-->< button class = "tabButton" type = "button" data-pane = "filters" data-i18n = "customFiltersPageName" tabindex = "0" > < / button > <!--
2025-08-07 12:56:17 +00:00
-->< button class = "tabButton" type = "button" data-pane = "develop" data-i18n = "developPageName" tabindex = "0" > < / button > <!--
-->< button class = "tabButton" type = "button" data-pane = "about" data-i18n = "aboutPageName" tabindex = "0" > < / button >
< / nav >
<!-- - - - - - - - - -->
< div data-pane-related = "rulesets" >
2025-08-08 16:30:09 +00:00
< p > < span id = "commit-spinner" class = "fa-icon" > spinner< / span > < span id = "listsOfBlockedHostsPrompt" > < / span > < / p >
2025-08-08 14:30:32 +00:00
< p id = "dnrError" > < / p >
2025-08-07 12:56:17 +00:00
< p > < input id = "findInLists" type = "search" spellcheck = "false" placeholder = "findListsPlaceholder" / > < / p >
< / div >
< / header >
2022-09-30 13:18:52 +00:00
<!-- - - - - - - - - -->
2023-09-16 15:46:39 +00:00
< section data-pane = "settings" >
< div >
< h3 data-i18n = "defaultFilteringModeSectionLabel" > < / h3 >
< p data-i18n = "defaultFilteringModeDescription" > < / p >
< div id = "defaultFilteringMode" >
< label class = "filteringModeCard" >
< div >
< span > < span class = "input radio" > < input type = "radio" name = "filteringMode" value = "1" > < svg viewBox = "0 0 24 24" > < path d = "M 12 0 A 12 12 0 0 0 0 12 A 12 12 0 0 0 12 24 A 12 12 0 0 0 24 12 A 12 12 0 0 0 12 0 z M 12 2.5 A 9.5 9.5 0 0 1 21.5 12 A 9.5 9.5 0 0 1 12 21.5 A 9.5 9.5 0 0 1 2.5 12 A 9.5 9.5 0 0 1 12 2.5 z" / > < circle cx = "12" cy = "12" r = "7" / > < / svg > < / span > < span data-i18n = "filteringMode1Name" > _< / span > < / span >
< / div >
< div >
< div class = "filteringModeSlider" data-level = "1" >
< div class = "filteringModeButton" > < div > < / div > < / div >
< span data-level = "0" > < / span >
< span data-level = "1" > < / span >
< span data-level = "2" > < / span >
< span data-level = "3" > < / span >
< / div >
< / div >
< div data-i18n = "basicFilteringModeDescription" > < / div >
< / label >
< label class = "filteringModeCard" >
< div >
< span > < span class = "input radio" > < input type = "radio" name = "filteringMode" value = "2" > < svg viewBox = "0 0 24 24" > < path d = "M 12 0 A 12 12 0 0 0 0 12 A 12 12 0 0 0 12 24 A 12 12 0 0 0 24 12 A 12 12 0 0 0 12 0 z M 12 2.5 A 9.5 9.5 0 0 1 21.5 12 A 9.5 9.5 0 0 1 12 21.5 A 9.5 9.5 0 0 1 2.5 12 A 9.5 9.5 0 0 1 12 2.5 z" / > < circle cx = "12" cy = "12" r = "7" / > < / svg > < / span > < span data-i18n = "filteringMode2Name" > _< / span > < / span >
< / div >
< div >
< div class = "filteringModeSlider" data-level = "2" >
< div class = "filteringModeButton" > < div > < / div > < / div >
< span data-level = "0" > < / span >
< span data-level = "1" > < / span >
< span data-level = "2" > < / span >
< span data-level = "3" > < / span >
< / div >
< / div >
< div data-i18n = "optimalFilteringModeDescription" > < / div >
< / label >
< label class = "filteringModeCard" >
< div >
< span > < span class = "input radio" > < input type = "radio" name = "filteringMode" value = "3" > < svg viewBox = "0 0 24 24" > < path d = "M 12 0 A 12 12 0 0 0 0 12 A 12 12 0 0 0 12 24 A 12 12 0 0 0 24 12 A 12 12 0 0 0 12 0 z M 12 2.5 A 9.5 9.5 0 0 1 21.5 12 A 9.5 9.5 0 0 1 12 21.5 A 9.5 9.5 0 0 1 2.5 12 A 9.5 9.5 0 0 1 12 2.5 z" / > < circle cx = "12" cy = "12" r = "7" / > < / svg > < / span > < span data-i18n = "filteringMode3Name" > _< / span > < / span >
< / div >
< div >
< div class = "filteringModeSlider" data-level = "3" >
< div class = "filteringModeButton" > < div > < / div > < / div >
< span data-level = "0" > < / span >
< span data-level = "1" > < / span >
< span data-level = "2" > < / span >
< span data-level = "3" > < / span >
< / div >
< / div >
< div data-i18n = "completeFilteringModeDescription" > < / div >
< / label >
< / div >
2025-09-27 17:57:00 +00:00
< / div >
< div >
< h3 data-i18n = "behaviorSectionLabel" > < / h3 >
< p > < label id = "autoReload" data-i18n = "autoReloadLabel" > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > _< / label >
< / p >
< p > < label id = "showBlockedCount" data-i18n = "showBlockedCountLabel" > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > _< / label >
2025-09-21 13:43:21 +00:00
< p data-platform-exclude = "safari" > < label id = "strictBlockMode" data-i18n = "enableStrictBlockLabel" > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > _< / label > < legend data-i18n = "enableStrictBlockLegend" > < / legend >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< p id = "developerMode" > < label data-i18n = "developerModeLabel" > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > _< / label > < legend data-i18n = "developerModeLegend" > < / legend >
2023-09-16 15:46:39 +00:00
< / div >
2025-09-27 16:53:58 +00:00
< div >
< h3 data-i18n = "settingsBackupRestoreLabel" > _< / h3 >
< p data-i18n = "settingsBackupRestoreSummary" > _< / p >
< p >
2025-09-29 16:19:11 +00:00
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > download-alt< / span > < span data-i18n = "backupButton" > _< / span > < span class = "hover" > < / span > < / button >
2025-09-27 16:53:58 +00:00
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > upload-alt< / span > < span data-i18n = "restoreButton" > _< / span > < span class = "hover" > < / span > < / button > < input type = "file" accept = "application/json" >
2025-12-25 21:32:38 +00:00
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > undo< / span > < span data-i18n = "resetToDefaultButton" > _< / span > < span class = "hover" > < / span > < / button > < input type = "file" accept = "application/json" >
2025-09-27 16:53:58 +00:00
< / p >
< / div >
2024-11-17 22:27:27 +00:00
< / section >
<!-- - - - - - - - - -->
< section data-pane = "rulesets" >
< div id = "lists" > < / div >
2022-09-30 13:18:52 +00:00
< / section >
<!-- - - - - - - - - -->
2025-09-24 14:42:18 +00:00
< section data-pane = "filters" >
< ul class = "hostnames" > < / ul >
< aside >
< details class = "importFromText" > < summary data-i18n = "customFiltersImportExportLabel" > _< / summary >
< div > < textarea spellcheck = "false" placeholder = "customFiltersImportTextareaPlaceholder" > < / textarea > < / div >
< p >
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > check< / span > < span data-i18n = "addButton" > _< / span > < span class = "hover" > < / span > < / button >
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > download-alt< / span > < span data-i18n = "importAndAppendButton" > _< / span > < span class = "hover" > < / span > < / button >
< button class = "iconified dontshrink" type = "button" > < span class = "fa-icon" > upload-alt< / span > < span data-i18n = "exportButton" > _< / span > < span class = "hover" > < / span > < / button > < input type = "file" accept = "text/plain" >
< / p >
< / details >
< / aside >
< / section >
<!-- - - - - - - - - -->
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< section data-pane = "develop" >
< div >
< p >
2025-06-13 16:46:05 +00:00
< label for = "editors" data-i18n = "developDropdownLabel" > < / label > < select id = "editors" >
< option value = "modes" selected data-i18n = "developOptionFilteringModeDetails" > < / option >
< option value = "dnr.rw.user" data-i18n = "developOptionCustomDnrRules" > < / option >
< hr >
< optgroup label = "" data-i18n-label = "developOptionDnrRulesOf" >
< option value = "dnr.ro.dynamic" data-i18n = "developOptionDynamicRuleset" > < / option >
< option value = "dnr.ro.session" data-i18n = "developOptionSessionRuleset" > < / option >
< / optgroup >
< / select >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< / p >
2025-06-13 16:46:05 +00:00
< div id = "cm-container" > < / div >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< / div >
< / section >
<!-- - - - - - - - - -->
2023-09-16 15:46:39 +00:00
< section data-pane = "about" >
< div class = "body" >
< div id = "aboutNameVer" class = "li" > < / div >
< div class = "liul" >
< div class = "li" > Copyright (c) Raymond Hill 2014-present< / div >
< / div >
2025-08-08 02:33:45 +00:00
< div class = "li" > < a href = "https://github.com/uBlockOrigin/uBOL-home/wiki/Privacy-policy" data-i18n = "aboutPrivacyPolicy" > < / a > < / div >
2023-09-16 15:46:39 +00:00
< div class = "li" > < a href = "https://github.com/uBlockOrigin/uBOL-home/releases" data-i18n = "aboutChangelog" > < / a > < / div >
< div class = "li" > < a href = "https://github.com/gorhill/uBlock" data-i18n = "aboutCode" > < / a > < / div >
< div class = "li" > < span data-i18n = "aboutContributors" > < / span > < / div >
< div class = "liul" >
< div class = "li" > < a href = "https://github.com/gorhill/uBlock/graphs/contributors" data-i18n = "aboutSourceCode" > < / a > < / div >
< div class = "li" > < a href = "https://crowdin.com/project/ublock" data-i18n = "aboutTranslations" > < / a > < / div >
< div class = "li" > < a href = "https://github.com/uBlockOrigin/uAssets/graphs/contributors" data-i18n = "aboutFilterLists" > < / a > < / div >
< / div >
< div class = "li" > < span data-i18n = "aboutDependencies" > < / span > < / div >
< div class = "liul" >
< div class = "li" > < span > < a href = "https://github.com/rsms/inter" target = "_blank" > Inter font family< / a > by < a href = "https://github.com/rsms" > Rasmus Andersson< / a > < / span > < / div >
< div class = "li" > < span > < a href = "https://fontawesome.com/" target = "_blank" > FontAwesome font family< / a > by < a href = "https://github.com/davegandy" > Dave Gandy< / a > < / span > < / div >
< div class = "li" > < span > < a href = "https://github.com/mathiasbynens/punycode.js" target = "_blank" > Punycode.js< / a > by < a href = "https://github.com/mathiasbynens" > Mathias Bynens< / a > < / span > < / div >
< div class = "li" > < span > < a href = "https://flagpedia.net/" target = "_blank" > Flags of the World< / a > by < a href = "https://www.davidkrmela.com/" > David Krmela< / a > < / span > < / div >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< div class = "li" > < span > < a href = "https://codemirror.net/" target = "_blank" > CodeMirror 6< / a > by < a href = "https://github.com/marijnh" > Marijn Haverbeke< / a > < / span > < / div >
2023-09-16 15:46:39 +00:00
< / div >
2025-06-24 21:19:49 +00:00
< hr >
< details > < summary data-i18n = "supportS5H" > < / summary >
2025-11-21 15:03:24 +00:00
< pre style = "user-select:all; -webkit-user-select:all; direction:ltr;" > < / pre >
2025-06-24 21:19:49 +00:00
< / details >
2023-09-16 15:46:39 +00:00
< / div >
< / section >
2025-12-27 15:12:34 +00:00
<!-- - - - - - - - - -->
< section data-pane = "busy" >
< div >
< span class = "fa-icon" > spinner< / span >
< / div >
< / section >
2022-09-30 13:18:52 +00:00
<!-- - - - - - - - - -->
2025-09-24 14:42:18 +00:00
< template id = "listEntryLeaf" >
2024-11-17 22:27:27 +00:00
< div class = "listEntry" data-role = "leaf" >
< span class = "detailbar" >
< label > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > < span class = "listname forinput" > < / span >
< / label >
< span class = "iconbar" > <!--
-->< a class = "fa-icon support" href = "#" target = "_blank" > home< / a >
< / span >
< / span >
< / div >
2025-09-24 14:42:18 +00:00
< / template >
< template id = "listEntryNode" >
2024-11-17 22:27:27 +00:00
< div class = "listEntry expandable" data-role = "node" >
< span class = "detailbar" >
< label > < span class = "input checkbox" > < input type = "checkbox" > < svg viewBox = "0 0 24 24" > < path d = "M1.73,12.91 8.1,19.28 22.79,4.59" / > < / svg > < / span > < span class = "listname forinput" > < / span > < / label >
< span class = "count" > < / span >
< span class = "fa-icon listExpander" > angle-up< / span >
< / span >
< / div >
2025-09-24 14:42:18 +00:00
< / template >
< template id = "listEntryRoot" >
2024-11-17 22:27:27 +00:00
< div class = "listEntry expandable" data-role = "rootnode" >
2025-06-13 16:46:05 +00:00
< div class = "detailbar" >
2024-11-17 22:27:27 +00:00
< h3 class = "listname" > < / h3 >
< span class = "count" > < / span >
< span class = "fa-icon listExpander" > angle-up< / span >
2025-06-13 16:46:05 +00:00
< / div >
2024-11-17 22:27:27 +00:00
< / div >
2025-09-24 14:42:18 +00:00
< / template >
< template id = "listEntries" >
< div class = "listEntries" > < / div >
< / template >
< template id = "customFiltersHostname" >
< li class = "hostname" > < div > < span class = "hostname" spellcheck = "false" contenteditable = "plaintext-only" data-pretty = "" data-ugly = "" > < / span > < span class = "remove fa-icon" > trash-o< / span > < span class = "undo fa-icon" > undo< / span > < / div >
< ul class = "selectors" > < / ul >
< / li >
< / template >
< template id = "customFiltersSelector" >
< li class = "selector" > < div > < span class = "selector" spellcheck = "false" contenteditable = "plaintext-only" data-pretty = "" data-ugly = "" > < / span > < span class = "remove fa-icon" > trash-o< / span > < span class = "undo fa-icon" > undo< / span > < / div > < / li >
< / template >
2025-06-13 16:46:05 +00:00
< template class = "io-panel" >
< span class = "io-panel" >
< button id = "apply" class = "preferred iconified" type = "button" disabled > < span class = "fa-icon" > save< / span > < span data-i18n = "saveButton" > _< / span > < span class = "hover" > < / span > < / button >
< button id = "revert" class = "iconified" type = "button" disabled > < span class = "fa-icon" > undo< / span > < span data-i18n = "revertButton" > _< / span > < span class = "hover" > < / span > < / button >
< button id = "import" class = "iconified" type = "button" > < span class = "fa-icon" > download-alt< / span > < span data-i18n = "importAndAppendButton" > _< / span > < span class = "hover" > < / span > < / button >
< button id = "export" class = "iconified" type = "button" > < span class = "fa-icon" > upload-alt< / span > < span data-i18n = "exportButton" > _< / span > < span class = "hover" > < / span > < / button > < input type = "file" accept = "json/application" >
< / span >
< / template >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< template class = "summary-panel" >
< div class = "info-panel summary-panel" >
2025-06-13 16:46:05 +00:00
< span class = "info" > < / span > < span class = "warning" data-i18n = "dnrRulesWarning" > < / span >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< / div >
< / template >
< template class = "feedback-panel" >
< div class = "info-panel feedback-panel" >
< div class = "info" > < / div >
< div class = "close" > < / div >
< / div >
< / template >
2025-06-13 16:46:05 +00:00
< template class = "ro-summary-panel" >
< div class = "info-panel summary-panel" >
< / div >
< / template >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< template class = "badmark-tooltip" >
< div class = "badmark-tooltip" >
< / div >
< / template >
2025-05-14 21:20:55 +00:00
< script src = "lib/codemirror/cm6.bundle.ubol.min.js" > < / script >
2022-11-12 14:51:22 +00:00
< script src = "js/theme.js" type = "module" > < / script >
2023-09-16 15:46:39 +00:00
< script src = "js/fa-icons.js" type = "module" > < / script >
2022-09-13 21:44:24 +00:00
< script src = "js/i18n.js" type = "module" > < / script >
< script src = "js/dashboard.js" type = "module" > < / script >
2023-09-16 15:46:39 +00:00
< script src = "js/settings.js" type = "module" > < / script >
2025-09-24 14:42:18 +00:00
< script src = "js/filter-manager-ui.js" type = "module" > < / script >
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
< script src = "js/develop.js" type = "module" > < / script >
2022-09-13 21:44:24 +00:00
< / body >
< / html >
