Files
NetAlertX/docs
sebingel 71efcd0ba0 fixes PIHOLEAPI's ignored VERIFY_SSL setting and checks setting keys
main() read the setting 'PIHOLEAPI_SSL_VERIFY', but config.json defines
the function VERIFY_SSL, so the real key is PIHOLEAPI_VERIFY_SSL.
get_setting_value() returns "" for a key nobody defined, so every Pi-hole
API request got verify="": certificate checks were always off and the
InsecureRequestWarning was suppressed, even when a user had turned on
"Verify SSL". The login request sends the Pi-hole web password to
api/auth. The plugin README and docs/PIHOLE_GUIDE.md used the wrong name
too. test_plugin_conventions.py did not catch it: it only looks at
get_setting_value("X") or <literal>, and this line had no fallback.

Changes:
- test/plugins/test_plugin_conventions.py: new
  test_own_setting_keys_exist_in_config. Every literal
  get_setting_value('<PREFIX>_X') in a plugin's scripts must name a
  setting its own config.json defines; core settings and other plugins'
  keys are not checked. Before the fix it fails for exactly one of the 54
  plugins: pihole_api_scan.py, get_setting_value('PIHOLEAPI_SSL_VERIFY').
- New test/plugins/test_pihole_api_scan_verify_ssl.py: runs main() with
  VERIFY_SSL true and false and checks the verify= value that reaches
  requests.post() for api/auth. Only the HTTP call is mocked. It fails
  before the fix (verify=None).
- server/plugins/pihole_api_scan/pihole_api_scan.py: main() reads
  PIHOLEAPI_VERIFY_SSL.
- server/plugins/pihole_api_scan/README.md and docs/PIHOLE_GUIDE.md name
  the setting PIHOLEAPI_VERIFY_SSL.
- docs/PLUGINS_DEV.md, Conventions Checklist: read a setting under the
  exact key config.json defines; names the new check.

Impact:
"Verify SSL" now works. The default stays false, so default installs
behave as before. A user who turned it on while Pi-hole uses a
self-signed certificate will now see the login fail, as the setting
description says ("Disable if you are using a self-signed certificate").
Live check against Pi-hole v6.8 behind a proxy with an untrusted
certificate: with "Verify SSL" on the fixed code refused to log in, the
old code logged in and imported 33 entries.
2026-11-01 09:32:55 +00:00
..
2025-02-22 12:56:15 +11:00
2026-07-30 07:38:07 +10:00
2026-07-06 13:03:38 +10:00
2026-09-07 09:44:37 +10:00
2026-06-19 22:39:09 +00:00
2026-07-05 22:38:29 +10:00
2026-06-14 10:35:08 +10:00
2025-08-24 12:57:36 +10:00
2026-09-07 09:44:37 +10:00
2025-08-24 13:12:33 +10:00
2025-08-31 10:23:31 +10:00
2025-08-24 12:57:36 +10:00
2026-02-01 16:39:11 +11:00
2025-10-29 07:32:56 +11:00
2026-01-19 01:12:48 +00:00
2026-01-10 08:46:16 +11:00
2025-11-09 17:03:25 +00:00
2026-07-25 10:25:33 +10:00
2026-07-25 10:25:33 +10:00
2025-09-21 10:41:06 +10:00
2026-07-06 13:03:38 +10:00
2026-03-02 20:54:09 +11:00
2026-06-19 22:39:09 +00:00
2026-06-21 10:45:56 +10:00
2026-07-06 13:03:38 +10:00
2026-06-19 22:39:09 +00:00
2026-08-05 11:15:51 +10:00
2026-09-07 09:44:37 +10:00
2026-09-07 09:44:37 +10:00
2026-02-28 15:58:46 +11:00
2026-02-28 15:58:46 +11:00
2025-03-01 09:44:11 +11:00
2026-07-05 22:38:29 +10:00
2026-02-28 15:58:46 +11:00
2025-11-09 17:03:25 +00:00
2026-08-05 11:15:51 +10:00
2026-09-07 09:44:37 +10:00
2026-09-02 08:43:09 +10:00
2026-01-02 20:36:19 -05:00
2025-02-09 10:57:02 +11:00
2026-09-07 09:44:37 +10:00
2026-07-25 10:25:33 +10:00
2026-09-07 09:44:37 +10:00
2025-07-04 07:41:01 +10:00
2026-02-28 15:58:46 +11:00
2025-11-26 10:02:15 +11:00
2026-09-07 09:44:37 +10:00
2026-09-07 09:44:37 +10:00
2026-09-07 09:44:37 +10:00
2025-11-26 09:52:12 +11:00
2026-06-17 16:04:16 +10:00

Documentation overview

ℹ️ In the app hover over settings or fields/labels or click blue in-app ❔ (question-mark) icons to get to relevant documentation pages.

In-app help

There is also an in-app Help / FAQ section that should be answering frequently asked questions.

📥 Installation

🐳 Docker (Fully supported)

💻 Bare-metal / On-server (Experimental/community supported 🧪)

📚 Table of contents

📥 Initial Setup

🐛 Debugging help & tips

🔝 Popular/Suggested

⚙ System Management

🔎 Examples

♻ Misc

👩‍💻For Developers👨‍💻

Feel free to suggest or submit new docs via a PR.

👨‍💻 Development priorities

Priorities from highest to lowest:

  • 🔼 Fixing core functionality bugs not solvable with workarounds
  • 🔵 New core functionality unlocking other opportunities (e.g.: plugins)
  • 🔵 Refactoring enabling faster implementation of future functionality
  • 🔽 (low) UI functionality & improvements (PRs welcome 😉)

Design philosophy: Focus on core functionality and leverage existing apps and tools to make NetAlertX integrate into other workflows.

Examples:

1. Supporting apprise makes more sense than implementing multiple individual notification gateways
2. Implementing regular expression support across settings for validation makes more sense than validating one setting with a specific expression.

UI-specific requests are a low priority as the framework picked by the original developer is not very extensible (and afaik doesn't support components) and has limited mobile support. Also, I argue the value proposition is smaller than working on something else.

Feel free to submit PRs if interested. try to keep the PRs small/on-topic so they are easier to review and approve.

That being said, I'd reconsider if more people and or recurring sponsors file a request 😉.

🙏 Feature requests

Please be as detailed as possible with workarounds you considered and why a native feature is the better way. This gives me better context and will make it more likely to be implemented. Ideally, a feature request should be in the format "I want to be able to do XYZ so that ZYX. I considered these approaches XYZ".

➕ Pull requests (PRs)

If you submit a PR please:

  1. Check that your changes are backward compatible with existing installations and with a blank setup.
  2. Existing features should always be preserved.
  3. Keep the PR small, on-topic and don't change code that is not necessary for the PR to work
  4. New features code should ideally be re-usable for different purposes, not for a very narrow use case.
  5. New functionality should ideally be implemented via the Plugins system, if possible.

Suggested test cases:

  • Blank setup with no DB or config
  • Existing DB / config
  • Sending a notification (e. g. Delete a device and wait for a scan to run) and testing all notification gateways, especially:
    • Email, Apprise (e.g. via Telegram), webhook (e.g. via Discord), MQTT (e.g. via Home Assistant)
  • Saving settings
  • Test a couple of plugins
  • Check the Error log for anything unusual

Some additional context:

  • Permanent settings/config is stored in the app.conf file
  • Currently temporary (session?) settings are stored in the Parameters DB table as key-value pairs. This table is wiped during a container rebuild/restart and its values are re-initialized from cookies/session data from the browser.

🐛 Submitting an issue or bug

Before submitting a new issue please spend a couple of minutes on research:

⚠ Please follow the pre-defined issue template to resolve your issue faster.