So, bitte testen und ich freue mich über Rückmeldungen:
pihole checkout core new/gravity_adlist_infos
pihole checkout web new/gravity_adlist_infos
Dieser Versuch sollte möglichst Touchscreen-kompatibel sein. Weitere Infos zu den jeweiligen Listen gibt es wenn man auf das farbige Icon klickt:
Ich habe die Listen nun auch zu klickbaren Links umgewandelt, damit man schneller nachschauen kann, wieso eine Liste nicht funktioniert, z.B. in diesem Fall:
Number of invalid domains on this list: 0
wird im Dashboard rot angezeigt. Bei 0 wäre grün schöner.
Es wäre toll, wenn man die Tabelle nach dem "Status" sortieren könnte
Die Links sollten sich in einem neuen Fenster/Tab öffnen
Etwas weiter ausgeholt:
Du verwendest die Formulierung "The list contents were last updated". Das weiß Pihole jedoch streng genommen nur für Listen, die einen entsprechenden http header mitliefern (was z.B. https://raw.githubusercontent.com nicht macht). Ich hatte vor einige Zeit entsprechende Feature Requests geschrieben (z.B. hier und hier) , dass Pihole zusätzlich noch die (falls vorhanden) lokale Kopie der Liste nutzen und vergleichen könnte, um festzustellen, ob sich der Inhalt wirklich geändert hat.
Evt. ist das etwas, dass du aufnehmen möchtest/könntest im Zuge der aktuellen Änderungen.
Das kann ich dem Browser ja nur vorschlagen, was er dann macht obliegt seiner Philosophie.
Ja, hmm, ja. Eigentlich könnten wir das schon machen. Heruntergeladen (= Datenvolumen verbraucht) werden sie ja eh. Stellt sich die Frage, was hat eine höhere Performance? sha1sum, ein bloßes diff oder reicht uns ein Dateigrößenvergleich aus Byteebene (das wäre natürlich instantan und ohne irgendwelche Arbeit auch auf einem RPi). md5sum hat nachweisbare Kollisionen und es wird seit Jahren von MD5-Dateihashing abgeraten.
edit: Ich denke sha1sum ist das Mittel der Wahl in diesem Fall.
Das Optimum wäre sicher, einen wirklichen "Inhaltsvergleich" zu machen, d.h. haben sich die (gültigen) Domains auf der Liste geändert? Aber das ist sicher overkill.
Prinzipiell wäre wahrscheinlich ein diff gut, weil es einem Inhaltsvergleich nahe kommt. Bei sha1sum kenne ich mich nicht aus, inwiefern das schon auf ein einzelnes geändertes Byte reagiert. Das wäre im Zweifelsfall zu sensitiv.
Ja, sha1sum ist byte-orientiert. Ich denke das sollte ausreichen, bei einem einfachen diff wäre es auch nicht anders (eine Änderung ist am Ende eine Änderung). Ich habe das heute morgen schon implementiert und comitted (ich antworte gleich auch in der anderen Diskussion).
Ja, genau das stand da zwischendurch schon, dem Nutzer kann es aber eigentlich egal sein und ich frage mich, ob das mehr Fragen aufwirft. So würde ich diesen Kommentar am liebsten auch einfach weg nehmen. Dennoch ist er wahr. Nur für "neue" (im Sinne von "wurde vorher noch nicht herunter geladen") Listen kommt der Kommentar. Und auch dann nur einmal.
Letzteres. Pi-hole bleibt nach einem Checkout-Befehl auf diesem Entwicklungszweig stehen. Das ist so beabsichtigt. Man kann jederzeit zur "Hauptversion" zurückkehren, indem man
Zuerst wird der Zweig von den anderen Entwicklern geprüft und für die Aufnahme in den "allgemeinen" Entwicklungszweig freigegeben. Darin sammeln sich alle Änderungen, die für die nächste Pihole Version vorgesehen sind. Irgendwann wird dann ein Abbild des aktuellen, allgemeinen Entwicklungszweig in den Master übernommen.
Dann wären da auch diese Änderungen dabei.
Good catch! This should work when you yousing a browser locally on your Pi-hole. From other computers, this will not work. I will look at disabling a link in this case.
They are checksums on the files they refer to (filename without the extra .sha1). This is expected and useful IMO. This is also the natural way to use sha1sum as we can just use sha1sum --check $filename. When storing in the database, we'd need extra parsing of the output of the sha1sum command to extract the relevant part only and verify there was no error. And then the save from the database back into the command. I'd say the way we have right now is better. But I'm always open for suggestions/discussions.
Danke für den Vorschlag, aber wir wollte ja eigentlich weg von Tooltips um die Diskriminierung von Touchscreen-Nutzern zu reduzieren Ich habe dennoch einen (generischen) hinzugefügt.
Eine Tabelle am Ende der Seite erschiene mir für diesen Zweck dienlicher, am Ende ist es aber vermutlich nur vergeudeter Platz, da jeder die Bedeutung der Icons schnell erkennen können wird.
(außerdem wäre es ein Ort, den man bei Änderung/Hinzufügen neuer Status-Icons vergessen könnte, da dies in einer anderen Quellcodedatei passieren müsste)