Correctly use overwritemailurl value when generating absolute urls in CLI
Fix#11500
Rename the config to *cli
Add overwrite.cli.url to the sample config
Revert separator fix, fixes unit test
* use ' instead of " for config option
* place default parameters where useful into sample
* use proper comment block
* limit line size to 80 characters
Remove the second comment which could be confused with suggesting an invalid value: `// 100 MiB`.
To keep the easily readable example value, it has been moved into the comment header for the config item.
This adds some security utilities to core including:
- A library for basic crypto operations (e.g. to encrypt passwords)
- A better library for cryptographic actions which allows you to specify the charset
- A library for secure string comparisions
Remove .htaccess
Remove .htaccess
Fix typo
Add public API
Use timing constant comparision
Remove CBC constant
Adjust code
Remove confusing $this
Hopefully this will stop people from copying the sample config. I'm so annoyed by all those wrong bug reports...
Add some explanation about this switch
Move check to init
* Use "filesystem_cache_readonly" config setting, update comment in config.sample
* Use $this->cacheActive to cache config setting
* Add public Scanner::setCacheActive() to set $cacheActive programmatically
Some people believe that they should copy the sample config to the "real" config. I noticed this several times in IRC and on the bugtracker.
I guess this warning should be enough to avoid this in the future.
Users often ask in IRC or the forum how to add another domain.
Hopefully they will be able to find it out on their own if we have an example with two domains.
It isn't uncommon that admins create a backup file of the config (i.e. `config.php.bak`) before performing any changes. This would allow everybody to read the backup of the configuration file which contain several secret and critical values.
I don't believe this is worth a backport or getting added to the installer. It's just a nice to have. People that create public readable backups of their configuration are the one to blame, not us :-)