I use one global AdditionalConfiguration.php for serveral TYPO3 Installation. I just symlink this file.
AdditionalConfiguration.php -> /global/typo3_every_instance/typo3conf/AdditionalConfiguration.php
Now in this AdditionalConfiguration.php I can enforce the use of rsa for every TYPO3 Instance:
$GLOBALS['TYPO3_CONF_VARS']['BE']['loginSecurityLevel'] = 'rsa';
I too have a configuration for maxFileSize there:
$GLOBALS['TYPO3_CONF_VARS']['BE']['maxFileSize'] = '20240'
But on some installation I want to have a bigger maxFileSize, so I have this in my LocalConfiguration.php:
'BE' => array('maxFileSize' => 150000)
Now I changed the AdditionalConfiguration.php to:
/* if not set in LocalConfiguration maxFileSize has default value */
if($GLOBALS['TYPO3_CONF_VARS']['BE']['maxFileSize'] == '10240'){
$GLOBALS['TYPO3_CONF_VARS']['BE']['maxFileSize'] = '20280'; // 10MB
}
What to you think about this?
what happens if the default value changes for some reason?
I do not know whether the AdditionalConfiguration.php is read before or after the
LocalConfiguration.php?
If your LocalConfiguration.php is read after AdditionalConfiguration.php
just set the new value.
if it's the other way round you can try following code
in LocalConfiguration
define("FILESIZE",'150000');
in AdditionalConfiguration
$GLOBALS['TYPO3_CONF_VARS']['BE']['maxFileSize'] = defined("FILESIZE")?FILESIZE:'20240'
Hope it helps
In my opinion the way to go is the TYPO3 Application Context. You can set single values inside an if in your AdditionalConfiguration.php or even just load a specific one for each context, e.g. AdditionalConfigurationTesting.php.
Here is a great article how to set and use this: https://usetypo3.com/application-context.html
In the future in modern docker environments its probably more the way to go with .env files - filled with your local settings.
Related
I'm trying to get rid of the "Config:" prefix added by AddServiceFabricConfiguration with AspNet Core to follow the same naming regardless of configuration source.
According to the documentation you should set IncludePackageName = false which I do like this:
.ConfigureAppConfiguration(builder => {
builder.AddServiceFabricConfiguration(serviceContext.CodePackageActivationContext, options => options.IncludePackageName = false);
})
But when I'm running the application the configuration is populated like this with IncludePackageName set to true anyway.
How can I make this setting work? The ServiceFabricConfigurationProvider which the helper adds is not public so I can't find a suitable workaround.
Update: This seems to have been some issue with my local environment rather than the actual code. Reboot, clean and rebuild fixed the issue.
I need to include a PHP script in my TS template :
page {
10 = USER_INT
10.includeLibs = lib_confidential.php
10.userFunc = MyClass->ConfidentialRequest
}
It works perfectly but I would like to locate the lib_confidential.php outside of my website root directory (and make something like 10.includeLibs = ../lib_confidential.php). Is it possible to secure my PHP script and how to ? I thought about creating a symlink but that doesn't give any solution.
As your installation needs an update you will have to change the mechanism for including php-functions for the future.
since TYPO3 8 you need to have a class for your php functions. So the autoloader can identify the class and execute the function you need to place the class inside of an extension or declare the class to the autoloader.
Best practice would be site extension where you configure your installation, there you can havea class with all the functions you need.
examples can be found in the manual.
In the backend in the sitetree we gave some folders a special style (edit folder -> Behaviour -> Contain Plugin -> News). So that this folders get the class .t3-icon-pages-contains-news and are blue.
Now I copied different typo3 files into that installation, but use the same database. Everything works fine, but this folders dont have the class .t3-icon-pages-contains-news anymore. The Behaviour -> Contain Plugin is still set to news.
Any ideas where this is coming from?
You did not provide any code example so it is hard to figure out what is going wrong in your situation.
However, here a example how it should look like:
typo3conf/ext/myext/ext_tables.php or typo3conf/extTables.php
if (!$TCA['pages']['columns']['module']['config']['items']) {
$TCA['pages']['columns']['module']['config']['items'] = array();
}
$TCA['pages']['columns']['module']['config']['items'][] = array('your label', 'myext', 'EXT:myext/Resources/Public/Icons/FolderIcon.gif');
\TYPO3\CMS\Backend\Sprite\SpriteManager::addTcaTypeIcon('pages', 'contains-myext', '../typo3conf/myext/Resources/Public/Icons/FolderIcon.gif');
I have searched and searched for this but I think my terminology isn't correct as it keeps giving me the application settings for the zend site rather than an application settings for the End User.
I'd like to have a config.ini type file that the end user can edit values in. I'd like it to be ONLY the settings I wish them to see and to be able to create the value names as I think would make sense to them. So it would be something like
[General]
SiteName=MySite
ShowResources=TRUE
[Database]
Server=myServer
databasepath=mydbpath
...
So my two questions.
1. What is this type of file called because when I search application settinsg, I get the ZF application settings not one for an end user (presumably)
What is the best way to handle this type of file?
Thanks
In your bootstrap add:
protected function _initConfig()
{
$config = new Zend_Config_Ini(APPLICATION_PATH.'/configs/config.ini');
Zend_Registry::set('config', $config);
return $config;
}
replace config.ini with whatever you want the filename to be.
You can then access this config object anywhere in your application either as an application resource or through the registry (Zend_Registry::get('config')). So to get the SiteName from your example:
$config = Zend_Registry::get('config');
echo $config->General->SiteName;
For things like database settings, you'll want to access these in the bootstrap so you can use them to setup other resources. I would recommend you don't try and include database settings in your application.ini as well, instead manually setup the DB resource by adding another bootstrap method:
protected function _initDb()
{
$this->bootstrap('config');
$config = $this->getResource('config');
$db = Zend_Db::factory('Pdo_Mysql', array(
'host' => $config->Database->Server,
'username' => $config->Database->Username,
'password' => $config->Database->Password,
'dbname' => $config->Database->Dbname
));
return $db;
}
To explain this some more, $this->bootstrap('config'); ensures the config resource is loaded first. $this->getResource('config'); returns the config resource (the one created by the _initConfig() method). It then uses the data from this object to create the DB connection.
It's an INI file, which you can read and write via Zend_Config.
ZF has no concept of "user settings" -- users are defined by you, not by the framework.
Apps usually store user configs in a database, but that's totally up to you. You could store a directory of INI files instead. Either way, you have to do the implementation yourself.
Edit: Given that you have a ZF app that you're distributing to the customer, and they're only ever going to connect to one database with it, that changes things significantly. (I thought you originally meant that you'd have one instance of the app simultaneously connecting to multiple databases.)
In your case, I would use the standard ZF application/configs/application.ini file for your application's "internal" settings. Then, I'd have a separate local.ini (or whatever) in that same application/configs directory, which contains only those settings that you want the customer editing. Distribute a skeleton local.ini file with the app, that has instructions right in it, something like this:
; Remove the comment from this line.
;configured = 1
; You need to put your database credentials in here.
db_host = "PUT YOUR DATABASE SERVER NAME HERE"
db_user = "PUT YOUR DATABASE USERNAME HERE"
db_pass = "PUT YOUR DATABASE PASSWORD HERE"
Then just load the local.ini file via Zend_Config. I'd also add a check to your index controller's init method that checks to see if you're properly configured:
$localConfig = Zend_Registry::get('local_config'); // or wherever you put it
if (!$localConfig->configured) {
$this->_helper->redirector('config', 'error');
}
And then make a error/config view that says:
You didn't read the instructions. Go do that now.
Note there's nothing stopping the customer from editing anything they want, but this makes a logical separation and makes it harder to accidentally screw something up.
in Zend-Framework, is it possible to save an altered .ini-File?
Because altering the $config-Array is easy, if allowModifications = TRUE in Zend_Config_Ini is enabled.
You can use Zend_Config_Writer to modify your config file
$config = new Zend_Config_Ini('config.ini');
// Modify a value
$config->production->value = 'my_value';
$writer = new Zend_Config_Writer_Ini(array('config' => $config,
'filename' => 'config.ini'));
$writer->write();
You may use Zend_Config_Writer_Ini, it works fine, but has one inconvenience. It doesn't matter that you used inheritance in your *.ini file, if you change something in production dimension, the whole dimension will be copied to its descendants, except entries that overrides production. You will also lost all your comments, so be careful using that.