Suggestion for internal hive key to prevent collisions

[tohizma]

I'm trying v4.x-dev and found nasty problem, collision internal F3 hive key with my app param key which cause everything ERROR 500 without any debug info displayed.

I put ENCODING=utf8 in config.ini, which intended to set my database connection params, but actually PHP (and F3) expects ENCODING=utf-8 (utf-8 as default). Pay attention in dash used utf8 vs utf-8.

And tracing from PHP Logs found:

WARNING: [pool www] child 16 said into stderr: "NOTICE: PHP message: htmlspecialchars(): Charset "utf8" is not supported, assuming UTF-8"
WARNING: [pool www] child 16 said into stderr: "NOTICE: PHP message: [/var/www/f3v4/vendor/bcosca/fatfree-core/F3/Base.php:1087] "
WARNING: [pool www] child 16 said into stderr: "NOTICE: PHP message: [/var/www/f3v4/vendor/bcosca/fatfree-core/F3/Base.php:1087] htmlspecialchars()"
WARNING: [pool www] child 16 said into stderr: "NOTICE: PHP message: [/var/www/f3v4/vendor/bcosca/fatfree-core/F3/Base.php:1618] F3\Base->encode()"
WARNING: [pool www] child 16 said into stderr: "NOTICE: PHP message: [/var/www/f3v4/vendor/bcosca/fatfree-core/F3/Base.php:2152] F3\Base->error()"

It is impossible for app developer to know and remember which word is reserved as F3 internal hive key (and for sure the number is always growing from version to version), so collisions with user's param key will always likely happen.

Maybe for 4.x branch start naming internal hive key with F3_ prefix or something.

I know this is may break backward compatibility but will ease user to set their own params hive, collision of param key is hard to detect.

This must be happened with version before 4, but fortunately I have no collisions yet, I'm doing overhaul with F3 v4 and found the problem.

[geniuswebtools]

Read over the Naming Rules in the documentation:
https://fatfreeframework.com/3.8/framework-variables

F3 uses all-caps for internal predefined global variables. Nothing stops you from using variable names consisting of all-caps in your own program, but as a general rule, stick to lowercase (or camelCase) when you set up your own variables so you can avoid any possible conflict with current and future framework releases.

[tohizma]

OK thank you, I will be more careful defining global vars