Any pointers to help package maintainers convert to Bootstrap interface?
-
I don't know if this sub-forum is exactly the right place or not for this question (maybe the Developers sub-forum is more appropriate). Mods feel free to move this topic if you wish.
I created a new virtual machine using the October 2nd 2.3-ALPHA snapshot to see the new interface and to test Snort and Suricata. The new Bootstrap interface is neat, but packages (at least my Snort and Suricata ones) look bad in the GUI. I know it's likely caused by the CSS styles in the old HTML code. Is there someplace where we as package maintainers can go and get a quick tutorial on the new interface and what changes are needed for the HTML side of things? Are there any tips and techniques you pfSense guys can share to help us out?
UPDATE: found some info here: https://github.com/sbeaver-netgate/pfsense, but any other tips are welcomed!
Thanks,
Bill Meeks -
+1
-
https://github.com/pfsense/pfsense/blob/master/BOOTSTRAP.md has a lot of info, but working with some of the packages is still a work in progress. The packages that ship their own PHP files are going to be trickier to fix since they will need direct fixes. The XML-based packages are easy by comparison since the code to generate the pages is on the base OS and not in the package.
-
https://github.com/pfsense/pfsense/blob/master/BOOTSTRAP.md has a lot of info, but working with some of the packages is still a work in progress. The packages that ship their own PHP files are going to be trickier to fix since they will need direct fixes. The XML-based packages are easy by comparison since the code to generate the pages is on the base OS and not in the package.
I've been studying the modified pfSense core files and have a pretty decent handle on the process now. Snort and Suricata have their own PHP files, so there is a lot of hand-editing to be done. I am working first on Snort. I have one page converted and working. Now that I'm over the biggest hump of the learning curve doing that first page, I hope the others go a bit faster.
I have found one bug/issue with the way the core files are "including" the Form classes definitions. There is a glob() function used in /usr/local/www/classes/Form.class.php that will likely need a change in order for packages with their own PHP files in their own subdirectory to work.
This is the line in the base code:
foreach (glob('classes/Form/*.class.php') as $file) require_once($file);For Snort, which runs from a snort subdirectory of www, this causes the Form class files to be missed because of the relative path issue. This subsequently leads to "no such class" errors when trying to create a Form_Button or Form_Modal class in the PHP code. Making the change below seems to fix it for Snort and also had no ill effect on pfSense itself:
foreach (glob('/usr/local/www/classes/Form/*.class.php') as $file) require_once($file);After some further testing on my own, I will submit this as a Pull Request.
I will admit that early on I was quite apprehensive about the GUI changes, but I find that it now forces better coding with less "hackiness" for the HTML parts. I am converting Snort (and later Suricata) to use the new Form, Section, Group, etc. objects. This of course means essentially a complete rewrite for many PHP pages, but the end result of the effort should be cleaner and easier to maintain code going forward.
Bill
-
What will happen about package versions for 2.2.* and for 2.3 onwards?
Obviously bootstrap-converted code will not work on a 2.2.* system.
I guess with the change from PBI to PKGNG or the package distribution this will mean that the old PHP/XML that goes with 2.2.* PBIs will be left as it is, and new code for 2.3 onwards will come out built in to each downloaded package?Thus it will soon be time for a branch of pfsense-packages repo so that there will be a maintenance branch for 2.2.*-style package code.
-
The 2.3 packages are built from files in our freebsd-ports repository, not from the current pfsense-packages repository. The pfSense packages have "meta" ports that include the proper dependencies. Right now some manual syncing is happening to make sure the package XML, PHP, and other such things stay up-to-date but eventually the files there will be isolated, so 2.2.x and before pull from pfsense-packages using XMLRPC as they do now, and 2.3 onward will come only from the files in the ports repo using the pkgng mechanisms.
For package maintainers the only real difference will be which repo they sent a PR against and it is slightly more difficult to locate the package among the other ports at first, and having to bump the package version in order to trigger a new package to be built, which will all happen automatically thanks to poudriere.
The meta port version doesn't have to be the same as the underlying software version.
-
I made this topic sticky for now and I have a couple more notes:
1. There are more up-to-date notes about converting PHP files to bootstrap here: https://forum.pfsense.org/index.php?topic=101062.0
2. Some more info about working with pkgng files: https://forum.pfsense.org/index.php?topic=101129.msg564917#msg564917
3. To stop the auto-sync of a single package's files from the old pfsense-packages repo to the new freebsd-ports repo, add this to the package's metadata in pkg_config.10.xml in the old pfsense-packages repo (example):
<maximum_version>2.2.999</maximum_version>4. For an example of a conversion, see some work in progress on the OpenVPN Client Export Package – admittedly it's a bit rough since that package page is rather complex.
So the current process should be close to this:
- Fork and check out a copy of the pfsense/pfsense-packages and pfsense/freebsd-ports repos
- Add the code to stop the package sync for the package you are converting and submit a pull request
- Once merged, start making changes to the package files in pfsense/freebsd-ports
- Be sure to update the version in the port's Makefile as well as files/usr/local/share/pfSense-pkg-<name>/info.xml and in files/usr/local/pkg/<name>.xml
- Submit a pull request to the pfsense/freebsd-ports repo with the updated files.
The package builder will see the version change and automatically build a new copy of the package once the pull request is merged.
As time goes on and this is refined a bit more I'll make a dedicated post for it and/or a wiki doc.</name></name>
-
Jimp,
So any change in the package functionality needs to be pulled to the ports repo then?
I have a fix for a problem with Squid3 URL Rewriter but I was a little lost to where I would do the pull request. I tested the fix in some servers and want to merge that into the package. This would be for current 2.2.6 too. Any advice?
-
The package code for 2.2.* lives in pfsense/pfsense-packages - so make a pull request for changes to fix stuff for a package for 2.2.*
Then make similar changes in a pull request against pfsense/FreeBSD-ports and that will be the version that installs to pfSense 2.3.The hope is that there are no major package code re-engineering efforts to be done in pfsense-packages for 2.2.* - so any changes needed there should be quite minor and then easily be manually ported forward to pfsense/FreeBSD-ports for 2.3.
-
So any change in the package functionality needs to be pulled to the ports repo then?
For 2.3 and later, yes.
I have a fix for a problem with Squid3 URL Rewriter but I was a little lost to where I would do the pull request. I tested the fix in some servers and want to merge that into the package.
If it's for the 2.3 package, it goes in freebsd-ports (and be sure to bump the Makefile version)
This would be for current 2.2.6 too. Any advice?
For changes to 2.2.x and before, they go in the old pfsense-packages repository. There is no automatic link between the two of them, so changes have to be replicated in both places since the code has diverged significantly.
At this point the pfsense-packages repo should only be used for minor maintenance of existing packages, not new items. Any new or significant development should be focused on 2.3.
-
So any change in the package functionality needs to be pulled to the ports repo then?
For 2.3 and later, yes.
I have a fix for a problem with Squid3 URL Rewriter but I was a little lost to where I would do the pull request. I tested the fix in some servers and want to merge that into the package.
If it's for the 2.3 package, it goes in freebsd-ports (and be sure to bump the Makefile version)
This would be for current 2.2.6 too. Any advice?
For changes to 2.2.x and before, they go in the old pfsense-packages repository. There is no automatic link between the two of them, so changes have to be replicated in both places since the code has diverged significantly.
At this point the pfsense-packages repo should only be used for minor maintenance of existing packages, not new items. Any new or significant development should be focused on 2.3.
Thanks.
It's a minor correction. The file I need is not exactly on the packages repo(https://github.com/pfsense/pfsense-packages/tree/master/config/squid3/34), is there any place for the other files?
I'll merge the translation after Christmas but I'll ask Renato o help me with that.
-
It's a minor correction. The file I need is not exactly on the packages repo(https://github.com/pfsense/pfsense-packages/tree/master/config/squid3/34), is there any place for the other files?
What "other files"? The URL you linked is in the old pfsense-packages repo where changes go for 2.2.x and before.
-
LFCavalcanti,
Here is the path to the files for pfSense 2.3 / Squid:
https://github.com/pfsense/FreeBSD-ports/tree/devel/www/pfSense-pkg-squid
