Improve DHCP static leases management GUI

[DL6ER]

What does this implement/fix?

See title. This adds a easy accessible table that is kept in sync with the <textarea> which still allows for any advanced configuration.

Please see this movie for a demonstration:

Screencast.From.2025-07-15.12-41-22.webm

You can test all of that even without having the DHCP server enabled. What will be saved in the end is always the content of said <textarea> which is getting stores as dhcp.hosts in pihole.toml.

---

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories development branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.

[smithbill17]

The video looks good to me, but unfortunately I'm not able to test this as I have now stopped using PiHole (partly due to this very issue).

However, two comments based on the video:
a) the 'advanced config' line shows nothing in the easy text grid - can't it still show MAC, IP & name but with an expansion arrow (or some kind of indicator) for the additional fields?
b) in PiHole v5, it didn't seem to matter if MACs were entered with hyphens ('-') rather than colons (':'). Is this the case with v6? And does it matter if IPs fall out-with the DHCP scope?

[DL6ER]

a) the 'advanced config' line shows nothing in the easy text grid - can't it still show MAC, IP & name but with an expansion arrow (or some kind of indicator) for the additional fields?

Yes, this is expected and per design. Advanced config lines may include set and id and other identifiers and it'd be very complicated (= error-prone) to edit the "simple" parts of it without damaging the advanced config. Not trying to edit these lines but instead showing where they are in the text area (where the user initially created them) seems the most straightforward and most robust way

b) in PiHole v5, it didn't seem to matter if MACs were entered with hyphens ('-') rather than colons (':'). Is this the case with v6? And does it matter if IPs fall out-with the DHCP scope?

I did add - as separators now. It doesn't matter if IP addresses are within the set DHCP scope.

[yubiuser]

If something invalid is entered in the advanced box (e.g. 00:20:e0:3b:13:af,8.8.8.8.7,laptop) the corresponding field in the table is empty (IP). Maybe we should show invald instead?

The live-editing is cool but only shown advanced > table, not the other way round. Is this by design?

Advanced settings present in line 3

This could be hard to find if n is big. Could we show line numbers in the advanced text box?

[DL6ER]

Could we show line numbers in the advanced text box?

Yes.

If something invalid is entered in the advanced box (e.g. 00:20:e0:3b:13:af,8.8.8.8.7,laptop) the corresponding field in the table is empty (IP). Maybe we should show invald instead?

The code is written such that it parses the same way dnsmasq parses this line. If the IP address is not valid, it is taken as hostname.

The live-editing is cool but only shown advanced > table, not the other way round. Is this by design?

Yes. First, I implemented it both ways but as soon as you edit the IP address, e.g., 192.168.0. (because you are editing the last digit), it'd immediately be dropped from the IP column as it is now invalid. This prevents further editing. Hence, I decided we let the user finish what they want and then click save.

[yubiuser]

If the IP address is not valid, it is taken as hostname.

Except when a hostname is also given

[rdwebdesign]

I tested using an invalid IP (192.168.0.300) and a hostname:

00:20:e0:3b:13:af,192.168.0.300,laptop

When saved, the invalid IP is ignored, resulting in 00:20:e0:3b:13:af,laptop.

I think this is the correct behavior, but no warning was returned to the user, to inform something was wrong and the entry was "fixed" to fit the valid input fields. Maybe we need a warning/alert for cases like this.

[DL6ER]

Like so?

Screencast.From.2025-07-20.1.webm

[DL6ER]

Screencast.From.2025-07-20.20-39-42.webm

[yubiuser]

I think the colors for invalid IP/MAC need a bit adjustment.
When using the light theme, the white color of the text has low contrast to the rosè background. When using a dark theme, the red color of the cell is almost invisible.

[rdwebdesign]

Quick suggestion just to improve the colors:

Suggested change

	#StaticDHCPTable td.table-danger {
	background-color: #ff000022 !important;
	color: #fff !important;
	}
	#StaticDHCPTable td.table-success {
	background-color: #74c70022 !important;
	color: #fff !important;
	}
	#StaticDHCPTable .table-danger {
	background-color: #d337;
	}
	#StaticDHCPTable .table-success {
	background-color: #2c24;
	}

Still using semi-transparent colors, but now the contrast is good enough when using the original text color, so I think we don't need to change color:.

Also, we should use !important only in cases where we really need it.

[DL6ER]

Oh, I did not see this before. I pushed non-transparent suggestions that should be the same on all variants, otherwise. Not overly pretty but it may suffice. Otherwise, we'll theme-dependent colors and this PR already became a lot more involved than I had hoped initially.

[rdwebdesign]

I added one commit to change the high contrast themes. On these themes the colors are not as important as the contrast/readability.

[rdwebdesign]

Note:

I was testing with DHCP server disabled, so I'm not sure if we need to fix this, but when you use the textearea to enter a line, if there are invalid values on this line, the values are not checked and the API accepts everything, including the invalid values.

The first line contains an invalid IP:

00:20:e0:3b:13:af,192.168.0.300,laptop,infinite
00:20:e0:3b:13:af,192.168.0.123,laptop

[DL6ER]

I was testing with DHCP server disabled, so I'm not sure if we need to fix this, but when you use the textearea to enter a line, if there are invalid values on this line, the values are not checked and the API accepts everything, including the invalid values.

Yes, invalid dhcp-host lines are fine for dnsmasq. It just goes on when no useful content was found (like 0,0,0). Invalid IP addresses, like in your example, will simply be interpreted as host names (just like the table does).

[DL6ER]

The line numbers in the <textarea> have been improved:
Screencast From 2025-07-24 16-41-59.webm

[rdwebdesign]

The line numbers issue is fixed. Note: I'm not sure if I like the idea of removing the textarea resizing, but this is already doing what most users requested. We can think later about a solution for the resize.

I found another small issue:

There is no hostname validation. If you enter a hostname containing spaces (or not allowed characters) the hostname will be saved. I tested using laptop 2 and laptop º 2. Both were saved.
In this case I think we could add a validation function.
What do you think?

[rdwebdesign]

Personally I think the text "Please save this line before editing another or leaving the page, otherwise your changes will be lost." is a little misleading because even if the user saves the line (using the green button), the changes will still be lost if the user leaves the page without clicking on "Save & Apply".

I'm still unsure how to change this.

I had 2 different ideas:

1. we could use a check mark icon instead of a floppy disk icon and change the text to something like "Please confirm the changes made on this line using the green button. Also, remember to click on "Save & Apply" before leaving the page, otherwise your changes will be lost.".
2. we could try to remove the save/confirm button and automatically validate + save the changes (or show a warning) on blur (not tested yet).

[yubiuser]

I agree with rd, it's not clear that the user needs to click "Save & Apply" after they already pressed the save icon

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.