Pi-hole Web Interface: The Next Generation

Pi-hole Web Interface: The Next Generation

2018-01-13 Updates 25

We have been working on a new Web interface for Pi-hole (referenced internally as Next Gen Admin or NGAdmin).  The existing interface built off of AdminLTE has served us well, but we have grown beyond the capabilities of an existing template.  We’re also looking to implement an HTTP API.

This new interface is open source and we welcome your contributions as we have just made the repo public.  Read on to learn more or check out a demo of the new interface here.

Why Are We Developing A New Interface?

This new interface shares a lot of the visual appearance with the existing one, but it has a lot more going on underneath the hood.  One of the biggest benefits is that it removes the need for PHP on the server.

The new interface also:

  • eliminates the reliance on server-side rendering scripts
  • eliminates spaghetti code resulted from heavily modifying the base AdminLTE template
  • reduces attack vectors by using JavaScript’s explicit imports instead of importing entire .php files
  • makes it easier for new developers to figure out the code, which speeds up development
  • makes the split between client and server code much more explicit
  • allows us to easily generate fake data for testing
  • includes all the benefits that come from React (ES6 JavaScript), including automatic DOM manipulations, stateful development, and component-based development

Contributing To This New Repo

If you are interested in helping develop this new interface, head on over to the GitHub repo.  Even if this is your first project, we welcome all contributions.

Notable Replies

  1. Hello,
    interestingly. Such other will be :slight_smile:

    Personally, I would keep these round charts in the new interface.

    Or the user can choose himself as needed :slight_smile:

    But it’s just my opinion. I’d like it to stay that way.

    Thank you

  2. The currently shown demo is much in the works and has been started already when the dashboard query types/forwards charts have been still over time instead of pie charts, clients over time didn’t even exist and as such does not necessarily present the current state of the work. Also we experience a little bottleneck since a few months as all “core developers” are much more busy than they have been before (changing jobs, moving to new places, etc. etc.).

    Currently, the mentioned HTTP API is somewhat higher in priority than the NG web interface as it doesn’t make too much sense to code on the web interface without having the API ready to hand out the requested data.

    One of the major reasons, if not even No. 1 of them, of making it public was the hope to attract people to look at it and contribute. As such we only put up a working demo that is far from completion to also open up the possibility for the community to shape it as they’d like to. The best way to do this, of course, is by submitting pull requests as it will be much easier for us to “just” review changes instead of having to code it ourselves. We have one core developer who is very experienced with React, but the others are still learning it.

    1. Our current PHP code base has grown organically and has made adding features more difficult than we’d like. Faced with rewriting it, we decided that strictly splitting the code into an API and client side code would be the most beneficial. Of course all of this is possible while using PHP, but there is more room for growth with this approach. The number of PHP developers is still large, but PHP is falling in popularity and we haven’t seen a huge amount of people flocking the contribute because it’s in PHP. We’ve also seen performance issues with PHP, mostly around the Query Log due to its need for high data throughput and general page load speeds.
    2. React is far from niche. It rivals Angular and is rapidly growing in popularity (at a higher rate than Angular and certainly PHP). You need JavaScript on the front end, and using React lets us use many open source components which our previous jQuery interface could not. This will let us develop faster and with more modularity.
    3. We are developing an API which will communicate with FTL over a more efficient layer than what PHP was using, and it will be able to do it quicker than what PHP could achieve. PHP was a slow middleman in the process of connecting the web interface to the client, and the API will bring a more modular and flexible development process to the project. The load will not shift from server side to client side as we are not making the client do much more work than it currently does. The amount of traffic should not be much different. Also, most users run Pi-hole on a Pi, and we want to respect their more limited processing power.

    Removing PHP helps remove one of the more troublesome dependencies in terms of support and allows us to create that beautiful and simplistic web interface more easily and quickly. The API will be much nicer and more standard than the current organic one.

  3. The Query Log loads in data from an endpoint here:


    That line calls this function to get the query data from the API:

    If you want to have real-time updates, we should implement that using web sockets. We could use server-side events, but that’s not implemented in IE or Edge whereas web sockets are. Ajax would just mean we have to keep a long or short-poll connection to the server, which is not as nice or clean as the first two solutions.

  4. ironic , web.pi-hole.io is being blocked by my pPiHole which is only using the OOTB supplied lists (+ one manual blacklist entry)

    ho hum, /me adds to whitelist

    Nope whitelisting and restarting DNSserver doesnt help

    pi@Heimdall:~ $ pihole -t | grep -w "web.pi-hole.io"
    23:33:58 dnsmasq[16915]: query[A] web.pi-hole.io.lan from 192.168.1.115
    23:33:58 dnsmasq[16915]: cached web.pi-hole.io.lan is NXDOMAIN
    23:33:58 dnsmasq[16915]: query[AAAA] web.pi-hole.io.lan from 192.168.1.115
    23:33:58 dnsmasq[16915]: cached web.pi-hole.io.lan is NODATA-IPv6
    23:33:58 dnsmasq[16915]: query[A] web.pi-hole.io from 192.168.1.115
    23:33:58 dnsmasq[16915]: cached web.pi-hole.io is NXDOMAIN
    23:33:58 dnsmasq[16915]: query[AAAA] web.pi-hole.io from 192.168.1.115
    23:33:58 dnsmasq[16915]: cached web.pi-hole.io is NODATA-IPv6
    23:34:06 dnsmasq[16915]: query[A] web.pi-hole.io from 192.168.1.115
    23:34:06 dnsmasq[16915]: cached web.pi-hole.io is NXDOMAIN
    23:34:22 dnsmasq[17100]: query[A] web.pi-hole.io.lan from 192.168.1.115
    23:34:22 dnsmasq[17100]: forwarded web.pi-hole.io.lan to 127.0.0.1
    23:34:22 dnsmasq[17100]: reply web.pi-hole.io.lan is NXDOMAIN
    23:34:22 dnsmasq[17100]: query[AAAA] web.pi-hole.io.lan from 192.168.1.115
    23:34:22 dnsmasq[17100]: forwarded web.pi-hole.io.lan to 127.0.0.1
    23:34:22 dnsmasq[17100]: reply web.pi-hole.io.lan is NODATA-IPv6
    23:34:22 dnsmasq[17100]: query[A] web.pi-hole.io from 192.168.1.115
    23:34:22 dnsmasq[17100]: forwarded web.pi-hole.io to 127.0.0.1
    23:34:22 dnsmasq[17100]: reply web.pi-hole.io is NXDOMAIN
    23:34:22 dnsmasq[17100]: query[AAAA] web.pi-hole.io from 192.168.1.115
    23:34:22 dnsmasq[17100]: forwarded web.pi-hole.io to 127.0.0.1
    23:34:22 dnsmasq[17100]: reply web.pi-hole.io is NODATA-IPv6
    
    

Continue the discussion discourse.pi-hole.net

20 more replies

Participants