@jiab77 Finally I get it!! Thank you. This front end stuff for me is difficult to get, even just in term of general concepts. Now finally I understand it (I think).
1 Like
@cfusco, I’m glad if I’ve helped you! 
Feel free to ask any questions here or in private and I’ll always reply as best as I can 
1 Like
As promised, I’ve added a new section in the project README that should help you to see if you are running the latest patch version. Sorry again for the mess I’ve created with the broken update feature.
it’s part of the development cycle. Bugs are to be expected, especially if there are so many different variations of setup that can go wrong. No reason to apologize. Thank you for squashing the bugs so quickly.
3 Likes
Hi @roberto, these two reported issues should be now fixed with the latest version I’ve just pushed now.
Hi again @roberto, all the three reported issues should also be fixed with the latest version.
Please let me know if I’ve missed something and I’ll fix it in the next release.
1 Like
Hi @jiab77.
Yes, works ok. Thanks again.
Taking advantage, I have also found problems on the following pages:
Status → WIO.
Services → OpenVPN → Static IP address pools.
Firewall → Intrusion Prevention → Whitelisted Hosts.
I haven’t found more, but regardless, great job. 
1 Like
New version out…
UPDATE FRENZY 
From the Github update section page, GitHub - Jiab77/ipfire-dark-theme: Simple IPFire dark theme patch for the web interface :
Run the patch script with -u, it will then:
Check if git is installed (You can install it with Pakfire)
Get the latest version from github
Compare local and latest versions
Run the removal and install methods if necessary
# cd ipfire-dark-theme
# ./patch.sh -u
You can also use --update if you prefer the long version.
SSH session:
[root@fwipfire ipfire-dark-theme]# ./patch.sh -u
Basic dark mode install/update/remove script for IPFire - v0.3.22
Gathering installed patch version... 0.3.8
Gathering local patch installer version... 0.3.22
Fetching latest version... done
Gathering fetched versions... update available
- New patch version: 0.3.9
- New installer version: 0.3.23
Removing dark mode patch... done
Installing dark mode patch... done
[root@fwipfire ipfire-dark-theme]#
So the only page that was not working for me was Network > DHCP server, and it still don’t.
I think we all should keep in mind that not all have IPFire configured the same. Thus not all pages exist in all configurations… (duh).
@jiab77 I guess that may be an issue for you if you don’t have a test setup with “everything” configured and running?
1 Like
Hi @roberto,
Thanks a lot for the newly reported issues but I’m quite perplex regarding the one in OpenVPN → Static IP address pools as normally it should be fixed already…
About WIO, I’m using it too and I haven’t seen anything that was missing patch but if you can make a screenshot of what you have on your side with sensible details hidden, that would be very helpful.
You might have something I don’t on my side and so I’ve missed it.
For the last one, @sec-con reported it already and was on my todolist for the next release 
Anyway many thanks again for your testing and reported issues!
Hi @sec-con,
Thanks a lot for your post and announcement! It’s nice to see that if I forgot to announce new changes someone else will cover me and do it anyway. It’s much appreciated
So the only page that was not working for me was Network > DHCP server, and it still don’t.
Could you please make a screenshot of the part that is not covered by the patch on your side? (with sensible details hidden)
Normally this page should also be fixed but as you very well said, we all having a different usage and setup of our IPFire boxes so without your help in reporting issues, it’s pretty difficult for me to catch them all 
@jiab77 I guess that may be an issue for you if you don’t have a test setup with “everything” configured and running?
I’m now using a test VM for tracking and debugging all the reported issues as on my side, I’ve patched all the pages that correspond to my needs.
For example, to patch the issue reported by @roberto on the Samba page, I’ve installed the add-on on my test VM and tracked every parts that was not readable with my patch.
To be honest, the pages that are the most difficult to track and patch are those related to add-ons… Their <table> structure is varying a lot from one add-on to another so I can’t create a generic CSS rule to cover them all. Another difficulty with these <table> based pages is that they don’t have any specific classes or ids I could reuse to target them so I must sometimes use some complex CSS selectors to catch them…
Here is an example:
- In OpenVPN page:
.bigbox table.tbl,
.bigbox > #main_inner > .post:nth-of-type(3) > table:not(.tbl) td:not(.boldbase, .base) {
color: #000;
}
- In WIO page:
.bigbox > #main_inner > .post > table:nth-of-type(1),
.bigbox > #main_inner > .post > table:nth-of-type(2),
.bigbox > #main_inner > .post > table:nth-of-type(4),
.bigbox > #main_inner > .post > table:nth-of-type(5),
.bigbox > #main_inner > .post > form > table:nth-of-type(1) tr:first-child td b,
.bigbox > #main_inner > .post > form > table:nth-of-type(4),
.bigbox > #main_inner > .post > form > table:nth-of-type(5),
.bigbox > #main_inner > .post > form > table:nth-of-type(6),
.bigbox > #main_inner > .post > form > table:nth-of-type(7),
.bigbox > #main_inner > .post > form > table:nth-of-type(8),
.bigbox > #main_inner > .post > form > table:nth-of-type(9) {
color: #000;
}
- In IDS page:
.bigbox table.tbl,
.bigbox > #main_inner > .post:nth-of-type(3) table,
.bigbox > #main_inner > .post:last-of-type table tr td:not(.boldbase) b {
color: #000;
}
I’ll not post all the conditional CSS rules here, I think you’ve understood the biggest challenge I’m facing for patching every pages
It would have been much easier if all the tables had something like id="wio-status" or id=ids-whitelisted-host" and so on as I would not have to fight with the CSS selectors to catch them 
There is also the fact that I’ve decided to patch things from client side instead of directly pushing my code to the upstream. It’s easy to criticize how things has been done but much more difficult to do something and if possible make something better.
For the moment, I’ve decided to cover all the pages and so gather all the required CSS rules to then later transpose the same work as an add-on and so as explained yesterday to @cfusco , move from client side to server side but it will take me some time to get more familiar with the Perl programming language than I am currently.
I’d like to add that working from server side is also more error prone and can have a bigger impact in case of failures or critical bugs so for the moment and with my current knowledge, it’s more safe to me to stay on the client side as there is less risks that my current JS code could impact your IPFire boxes as it just targets DOM elements and overrides their defined CSS rules.
I’m still having your reported issues and those reported by @mumpitz to fix and then I’ll focus on installing and testing every add-on that has an integration with the WUI and also increase the security over the whole code itself by isolating things better than they are currently.
I keep you updated! 
Many thanks again to you all for your appreciation of my work and for your time to test it and report every issues you’re finding!
2 Likes
For those who would like to help in targeting DOM elements that are not currently covered by the patch and are not readable when it is enabled, here is how I’m targeting them to later apply the necessary CSS rules:
- Targeting parent
.postDOM elements:
document.getElementsByClassName('post')
- Targeting all
<table>DOM elements:
document.getElementsByTagName('table');
- And finally, to find the right CSS selector:
document.querySelectorAll('.bigbox > #main_inner > .post:nth-of-type(2) table.tbl tr:not(:first-child) td:first-child');
Once that I’ve targeted / isolated the right DOM elements that needs to be patched with document.querySelectorAll(), I can write the corresponding conditional code block for the related page.
It might sound easy to do and it’s right but it’s very time consuming the find the right CSS selector
I’m also not the best to that so if anyone of you finds better CSS selectors, please let me know or make a pull request on GitHub! I’d be pleased to test your code and include it in the project!
1 Like
Thanks a lot for your post and announcement! It’s nice to see that if I forgot to announce new changes someone else will cover me and do it anyway. It’s much appreciated
He, can be a bit risky. It seemed to me you just forgot after the git update so I took the liberty.
Could you please make a screenshot of the part that is not covered by the patch on your side? (with sensible details hidden)
It is actually the entire page. Not even the sun-moon control icon is in place up to the right corner.
Would need it verified from more users?
1 Like
@sec-con, Thanks a lot for the reporting. Sounds like you have an SRI mismatch and so it should be displayed in the web console as an error. I’ll try to implement the reset feature ASAP so that it should fix this kind of issues… Sorry about that.
What you can do for the moment is to do the following:
- Go to
/srv/web/ipfire/html/includeand remove the file calleddarkmode.js - Go to
/srv/web/ipfire/html/themes/ipfire/include/and restore the originalfunctions.plthat way:
# Restore original file
mv -v functions.pl.before-patch functions.pl
# Remove other backup file
rm -v functions.pl.restore-patch
Once done you can run this command to verify that you’ve restored the right file:
grep 'darkmode.js' functions.pl
You should get an empty output. If that’s the case, go back to the project folder and run the install script again:
cd ~/ipfire-dark-theme
./patch.sh
Once done, the patch should load again on your side.
I’m planning to add support for --no-sri argument so that the patch can be (re)installed without the SRI check as apparently it can create some issues… It was not one my high priorities for the project but now it is
Would need it verified from more users?
I don’t think so, I’ll double check on my side maybe I’ve missed something last night…
Hi @tphz , it’s definitely useful as I don’t have the same settings on my side for this add-on so I’ve clearly missed a lot of parts but as your screenshots contains your settings, you can remove them now.
I still don’t get why I can’t fix the OpenVPN page properly but I’ll tackle it for the next release.
Thanks a lot for your reporting!
1 Like
The settings are in a virtual test environment so if you want I can leave it, eg for later comparisons of effects.
Regards
1 Like
I followed those instructions and was able to get to ./patch.sh which installed again with no issues reported.
It did not fix my issue with dhcp page, but don’t worry about it. I can do some additional tests and such if needed, but not really important now. I did also check in Edge.
Another thing, I appreciate very much you take the time to write the cli input needed for each step. I understand that CLI is handy in many situations and use it if absolutely necessary, but overall I just avoid it. With your guidance I am actually accomplishing something, and also learning a bit in the process.
1 Like
