While the particular code and implementation of a feature in PHP may change to Python, the logic and process are more important. Sure there will be a large amount of work involved converting things over but the language is mostly the nuts and bolts of it. We're more focused on 2.3 at the moment, which has another similar issue. Right now there is a significant amount of work that's happened to convert the GUI to bootstrap which itself is quite a distance away from work in master that has had other, parallel fixes. Merging the two together will be an interesting process. Right now I wouldn't worry so much about PHP vs Python as much as worrying about the logic and structure/design of the code being sound and easy to follow. Adding even more documentation than usual in the code would also be nice, especially expected inputs/outputs and/or states when defining new functions.

It's being done to make progress in pushing toward pkg-friendly packages. Had to happen that way since "our" package version is being used in a meta-package which then depends on the actual binary package. Not sure what the plan is on exposing those versions again but I believe it's on the roadmap. [2.3-DEVELOPMENT][root@pfsense.localdomain]/root: pkg search pfsense-pkg pfSense-pkg-Asterisk-0.3.1 pfSense-pkg-AutoConfigBackup-1.28 pfSense-pkg-Avahi-v1.09 pfSense-pkg-Backup-0.1.6 pfSense-pkg-Cron-0.1.9 pfSense-pkg-FTP_Client_Proxy-0.2 pfSense-pkg-Filer-0.60.1 pfSense-pkg-Lightsquid-2.41 pfSense-pkg-Notes-0.2.4 pfSense-pkg-Open-VM-Tools-1280544_10 pfSense-pkg-OpenBGPD-0.9.3_2 pfSense-pkg-Postfix_Forwarder-2.4.2 pfSense-pkg-Quagga_OSPF-0.6.5 pfSense-pkg-RRD_Summary-1.1 pfSense-pkg-Sarg-0.6.4 pfSense-pkg-Service_Watchdog-1.6 pfSense-pkg-Shellcmd-0.6 pfSense-pkg-System_Patches-1.0.3 pfSense-pkg-TFTP-2.1 pfSense-pkg-apache-mod_security-devel-0.43 pfSense-pkg-arping-1.1 pfSense-pkg-bandwidthd-0.5 pfSense-pkg-bind-0.3.9 pfSense-pkg-blinkled-0.4.3 pfSense-pkg-darkstat-3.0.718 pfSense-pkg-diag_new_states-0.2 pfSense-pkg-dns-server-1.0.6.21 pfSense-pkg-freeradius2-1.6.12 pfSense-pkg-gwled-0.2.1 pfSense-pkg-haproxy-0.23 pfSense-pkg-haproxy-devel-0.23 pfSense-pkg-iftop-0.17 pfSense-pkg-imspector-0.3.2 pfSense-pkg-iperf-2.0.5_1 pfSense-pkg-ipguard-0.1 pfSense-pkg-mailreport-2.3 pfSense-pkg-mailscanner-0.2.12 pfSense-pkg-mtr-nox11-0.85_2 pfSense-pkg-netio-1.26 pfSense-pkg-nmap-1.3 pfSense-pkg-ntopng-0.5 pfSense-pkg-nut-2.0.4 pfSense-pkg-olsrd-1.0.2 pfSense-pkg-openvpn-client-export-1.2.16 pfSense-pkg-pfBlockerNG-1.09 pfSense-pkg-pfflowd-1.0.3 pfSense-pkg-routed-1.1 pfSense-pkg-siproxd-1.0.3 pfSense-pkg-snort-3.2.4 pfSense-pkg-softflowd-1.1 pfSense-pkg-spamd-1.1.2 pfSense-pkg-squid-0.2.8 pfSense-pkg-squidGuard-1.9.14 pfSense-pkg-stunnel-5.07 pfSense-pkg-sudo-0.2.5 pfSense-pkg-suricata-2.1.5 pfSense-pkg-varnish-0.2.4 pfSense-pkg-vnstat2-1.12_3 pfSense-pkg-widentd-1.03_2 pfSense-pkg-zabbix-agent-0.8.5 pfSense-pkg-zabbix-proxy-0.8.5 And then [2.3-DEVELOPMENT][root@pfsense.localdomain]/root: pkg install pfSense-pkg-sudo Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: pfSense-pkg-sudo: 0.2.5 sudo: 1.8.13 The process will require 2 MiB more space. 455 KiB to be downloaded. Proceed with this action? [y/N]: y Fetching pfSense-pkg-sudo-0.2.5.txz: 100%    5 KiB  4.6kB/s    00:01    Fetching sudo-1.8.13.txz: 100%  451 KiB 461.8kB/s    00:01    Checking integrity... done (0 conflicting) [1/2] Installing sudo-1.8.13... [1/2] Extracting sudo-1.8.13: 100% [2/2] Installing pfSense-pkg-sudo-0.2.5... [2/2] Extracting pfSense-pkg-sudo-0.2.5: 100% And then some errors because it's not 100% there yet, but you get the idea. All in due time.

Yes that would be good, choosing the site for "what is my IP" would be good, and open to potentially use private sites setup for the job. Nevertheless this Opendns feature 'myip.opendns.com' is very clever. They use a fast service used to discover IPs and respond with the requester IP.

I guess behind this was the need or the PHP code to handle properly the case when the value is not present in the config. There are many values like this which are assumed to some default in the php code in the case the definition is missing from the XML. That requirement makes indeed the programmer to use inverted logic variables. Thank God the inverted logic is suggested by the variable name… I've seen cases where the PHP code explicitly deletes (unsets) the value from the config file for the negative value, and sets it to "true" in the config file for the positive value. There's no possibilty to ever see "false" in the XML config file for that variable, although the parsing code handles that too.

Is a app for captive portal we are trying to develop.   We are working with php-mysql, but we work with php-mysqli on other os like freebsd or centos.   For the reasons we have, some functions that the old driver doesn't have.

On stock FreeBSD, you can't freebsd-update to get fixes that aren't in a stable release yet. The associated commit there is only in 10-STABLE. You'd have to svnup stable and build world and kernel. In our case, we backport fixes along those lines and include them in our releases. 2.2.3 snapshots are available and the fix for 195802 was added today. If you could help test that and report back, it'd be appreciated.

I wonder if there is an official pfsense splash.bmp??? Maybe this sparked his ire. Allow me to rephrase. I wonder if Pfsense has an included image in the theme that would be appropriate.

some cable providers/modems send out private ip's by dhcp when the coax-line goes down … so then pfsense would get a private ip and might think it's gateway is online when it isnt

So, I had another WTF instance… upgraded an i386 install to amd64 (by accident, apparently there's still absolutely no check/confirmation anywhere, sigh). All went well except for the WTF moment and manual hard reset required. Now, some packages reinstalled. Couple of days later, I thought to use nmap. Hmmm. This idiotic PBI thing picked up an i386 stale libpcre.so.3 (mind you - it ships its own bundled PCRE) and refused to do anything. Incredible garbage.

Use the already-connected function described by Gert-Jan in this topic: https://forum.pfsense.org/index.php?topic=77143.0 Add a query for cpentry[4]

Yes, that is a latent issue waiting for some sucker to try and call it with an IPv6 address! subnetv4_expand() is called directly from a couple of places in the base system and works. subnet_expand() is not called by anything in the base system. subnetv6_expand() is only mentioned inside subnet_expand() and yes, I can't imagine anything that would require and handle subnetv6_expand() of a /64 (or bigger)! The only small use for this would be in some places where there are pools. e.g. for V4 it is used in vslb.inc where people can have put a virtual server pool by specifying a "subnet" like 10.11.12.8/29 gives a pool of 8 IP addresses. The front-end GUI code limits it to a maximum size pool of 64 (x.x.x.x/26). I guess the same possibility of having a group of servers with IP addresses in a tiny IPv6 "subnet" would also work. The reference to a non-existent function was introduced in 2012 by: https://github.com/pfsense/pfsense/commit/0917cb214b2bbf7f4b374c901c642987fc4ac63b

Surely pfSense is not the first project to ask that?  Can we learn from someone else (RedHat, FreeBSD, KDE, mozilla, maybe even Cisco…)? The Fedora project had (and probably still does) volunteer translators, with one lead person per language.  I think there was some infrastructure or guidance set up for them, maybe something is there?

Fixed for me also with same snapshot.

https://forum.pfsense.org/index.php?topic=77143.0 will probably need adjustments, but it'll get ya started

@dylanh724: EDIT: Sorry wrong thread! Can someone move me to Development area? Thanks/sorry .. didn't realize there was a section~ Hi, I'm pretty new to php until I started working with PFS. I find myself pretty good at editing, but as for making new files .. not so much: #!/usr/local/bin/php -f Is this above code required for all php files within PFS? This means you can call the file in shell if you give it +x. require("config.inc"); If I put this up top, this means I can use code from config.inc, right? Like imports from .NET? YES you can call functions on that file. I noticed that files are "included" very generally – like 'xx.inc' rather than '/etc/xx/xx.inc' .. does this mean there's a file I need to edit to include any new files for easy importing such as this? pfSene uses PHP and exploits as much as possible its configuration settings. The short way is used since a include path is setup for php where to find things. Finally, can any of these files be called from captive portal files? Can a captiveportal-customupload.php call , say, config.inc? Surely there is nothing preventing that since even the existing page does that.

Much more clear now! [image: jfb6ed.png]