I want some of the $GLOBALS['TYPO3_CONF_VARS'] values (namely, those of the Mail API) to be site-specific. After reading Configuration Overview, Site Handling, and GLOBALS - TYPO3_CONF_VARS, I'm still not sure how would it be an idiomatic way to do this.
Also, I'm using helhum/typo3-config-handling for the TYPO3 configuration. The idea is basically having the same functionality that we have with the contexts (i.e having prod.settings.yaml and dev.settings.yaml load different values) but with sites, e.g. I want to have a different $GLOBALS[‘TYPO3_CONF_VARS’]['MAIL']['defaultMailFromAddress'] value wether if I'm in one of my sites or another.
I actually don't know if this is possible to do. Maybe these are thought to be that, just global, and I have to come up with a more ad-hoc solution. E.g. changing the $GLOBALS[‘TYPO3_CONF_VARS’] array beforehand every time some process that accesses it.
Thanks a lot in advance!
You can access Environment variables for domain specific configuration.
Or you use conditions in PHP.
Anyway you need to make your assignments in typo3conf/AdditionalConfiguration.php as all non constant values might get overwritten in typo3conf/LocalConfigurathion.php.
Related
I am new at web development, and I have started to work on a small website just recently. Now the problem is, that since it is my first time, I move my pages a lot on the server, because of which I have to keep updating all the other pages that link to it. So, I was thinking of a dynamic way of linking the pages, so that I don't have to update at several places, but only at one.
How it is going to work is that,
there is going to be a separate database kind of thing that will contain all the webpages' updated address, and a unique key to identify them. eg. page12345 = "/about/us.php"
and anywhere where I want to include a link to the page, instead of typing .., I'll have to type something like .., or something like that
This method will also enable me to assign tags/categories to pages, and, or add other properties to them. And, I'll probably also use it for media files as well later.
Now, the thing is, I can think of only two ways to do so, one is using an array in PHP, and other is using MySQL database. The array will probably be too much to handle when the site grows and there are, like thousands of pages, on ther other hand, MySQL database will probably prove to be slower, and at the same time more of a hassle.
So what is it that you suggest? Which will be more efficient. Or is there a better way, I am open to any other ideas that you may have.
The typical way to manage that is to not worry about URLs manually at all and leave up to a router. In the end, URLs are just a technical implementation detail of the HTTP protocol. What you really want to do is identify specific pages/actions uniquely. Have a look at any reverse-routing capable router; here the Symfony implementation:
blog_show:
path: /blog/{slug}
defaults: { _controller: 'BlogController::showAction' }
Read this blog post.
This is admittedly a very high level abstraction, using YAML for specifying routes and Twig for templating with a custom defined function. However, it hopefully demonstrates the goal: don't worry about URLs much at all in your actual links. You need to have one canonical place where URLs are defined (the path in the above example), everywhere else you just refer to your target page by name (blog_show here). If you need to move URLs around, there's exactly one place where you need to do so. The thing in the middle that makes this work is the router.
When should I use what?
I have the option to define constants in the index.php entry script file like it is recommended in Yii2 guide: constants. Or I could use the params in the configuration - explained in YII2 guide: params. Both are per application and not really global.
Currently, it seems to me that params are a bit less comfortable if I want to combine values like this:
define('SOME_URL', 'http://some.url');
define('SOME_SPECIALIZED_URL', SOME_URL . '/specialized');
Besides, accessing is bit more code (Yii::$app->params['something']) compared to constants.
So when should or could I use what?
Small update: in PHP 7 define() supports arrays as well, so the whole params structure can be configured as a constant. Probably better supported by IDEs.
I tend to use the Yii application parameters. The main reason for this is the values held in these kind of parameters tend to change depending on the environment that the code is run in. So I will have a build system that runs (I use Phing) and pulls in settings from a non-version controlled file such as build.properties.
So any dev database settings, dev domain settings, api sandbox addresses etc will be loaded in in my development environment and the correct production values will be used when a build is run on a live server.
If you were settings these values in some kind of php file, then tracking with version control becomes problematic because each time you build in your dev environment changes would be made to your index.php file. Someone might even end up committing these changes in by mistake.
So in summary, I would say if they are true constants - the same in any environment in which the code runs - they maybe a constant is fine. If these values might change, depending on where the code is run, then my preference is to place them in params and let your build system load them from a non-version controlled file.
The main disadvantage (and advantage at the same time) of constants is that they're... constant. Once you set it, you can't change it. This is the only thing that should matter here. You should use constants for values that should never change during execution, and params for everything else.
Constants may be a real PITA when you start writing tests for your app. It will show you that many things that you considered as constant are not really constant. At this point params are more flexible - you can easily change them or adjust at configuration level using merging of configuration arrays. Using constants may drive you into a trap of unconfigurable application that cannot be installed on different environment without modification of hardcoded constant.
Besides, accessing is bit more code (Yii::$app->params['something']) compared to constants.
This is completely irrelevant. As a programmer you spend less than 5% of your time on actually writing a code. Additional 10 keystrokes will do not make any difference. You should always think about it in terms of readability. You write code once and read it hundreds of times, so it is much more important how much time you will need to read and understand code than the time you spent on writing it. And using known conventions (and Yii::$app->params is one of them) makes your code easier to understand, especially for other programmers.
But if you really want to write less code, you can always create a wrapper function for short access to params.
function p($name) {
return Yii::$app->params[$name];
}
echo p('my-param');
For the most part, the 3 sites for an organization I run have a single MySQL database that they share. This allows them to interact with each other nicely.
I have a bunch of simple parameters that the sites need to know about, and I wasn't sure what the best route to take is:
Make a table with 2 fields (key, value) where I store the params
Store the values in one or many flat files
They each have advantages and disadvantages.
The database allows a single entry to be used for all three sites (however, this doesn't occur often), all the information is centralized, and the interface is already well defined.
The flat files are easier to work with as FTP and a text editor can be used in addition to website administration, the flat files can be written as PHP meaning the site doesn't have to do any parsing (just need to include the file and use the variables), but they can't be shared between sites.
I can go on and on. What do you think is the better route to take?
My opinion is to use a database if you have the chance. It's easier on the long run. You have built the website, with the flat files, but now the customer wants an additional page with slightly other parameters, so you have to add a new file. Now you are done with this and he ask you again.. well, you get the point.
It is not organised at all. So if you have the chance to use a database, use it. There is reason why it is invented.
But just to get my thoughts clear and firmly know what you are talking about, please tell me more about the settings you would like to store. I can imagine that you are talking about some global variables, or maybe even going to use a define(), but it is also possible you want to store strings.
So please define "bunch of simple parameters" for us.
Note: Configuration are being kept in a PHP file, config.php.
I've seen this done differently, here's a short list of examples (I'm storing DB info in these examples):
Constants: global, readonly
define('DB_USER','user12');
define('DB_PASS','21user');
Using GLOBALS array: global, changeable, repetitive, mixed with other globals
$GLOBALS['DB_USER']='user12';
$GLOBALS['DB_PASS']='21user';
Using a non-global array but raised globaly: possibly worse than the 2nd option
$config=array(); ...
$config['DB_USER']='user12';
$config['DB_PASS']='21user';
... global $config;
mysql_connect('localhost',$config['DB_USER'],$config['DB_PASS']);
Defining class properties: (global, enumerable)
class Config {
public $DB_USER='user12';
public $DB_PASS='21user';
}
Criteria/Options/Features:
ease of coding: you wouldn't want to check if the setting exists, or initialize it
ease of modification: a non-programmer/layman could easily modify the settings
stored in a clean place: not mixed with other variables (can be stored in a sub-array)
runtime modification: in some cases, other devs may easily modify existing settings
The configuration might need to be changed some time during the running of the system, so option 1 is already not viable. The third option is not too clean either.
While writing this, I'm getting a big warning on the discussion being subjective and closed. So please keep up to the topic and give valid reasons to your answers.
This is a pretty obvious question, and considering I'm well familiar with different answers, you might ask, why am I making all this fuss? The thing is, I'm developing a framework, and unlike another framework (*ahem* joomla *ahem*) I don't want to pass through their mistake of throwing in a miss-informed solution which ends up having to be changed/re-purposed in the future.
Edit: First of, the location of the config file does not concern me. I'll make sure people can easily change location, if they want to, but this will not be a requirement.
First of, cheap webhosts does not allow doing this, secondly, as far as security goes, this is really not a good option. Why? Because, the framework needs to know where the config is. Really, security through obscurity does not work. I'd rather fix all RFI and XSS (for instance) than be paranoid on hiding the config file under several layers.
Hard-coded data may not be an option where people doing reconfiguration are not code-adept. Consider using parse_ini_file().
Why not use Zend_Config? It creates a common interface for configuration options that can be stored in a confing file or a database (with a proper adapter). And it's lightweight; you don't have to bring in the entire Zend framework to use it.
BTW, since you're building a framework, you should keep pollution of the global namespace to a minimum. Something like your 3rd option, and if you're targeting 5.3 exclusively, look at using proper namespaces.
A bit late, but this might be of interest to you: http://milki.include-once.org/genericplugins/genconfig.html
It provides a simple API to edit PHP config files in-place. It keeps comments and other code in-tact. And it allows for a global $config array/ArrayObject and defining constants. It operates almost automatically if combined with plugin configuration comments. However, it's a lot of code. But maybe worth checking out for the concept. (I'm also using a readable config.php, as it seems the most useful configuration format for me.)
Put in a common file and include it every where you need. The benefit when you go live or move to your test server you just need to edit just this one file and all configs are changed. Method 2 is better as it allows you to change it.
Remember once you connect to mysql if you need to change the user and pass you have to re-connect
I wrote a small PHP application that I'd like to distribute. I'm looking for best practices so that it can be installed on most webhosts with minimal hassle.
Briefly: It's simple tool that lets people download files once they login with a password.
So my questions are:
1) How should I handle configuration values? I'm not using a database, so a configuration file seems appropriate. I know that other php apps (e.g. Wordpress) use defines, but they are global and there is potential that the names will conflict. (Global variables also have the same problem, obviously.) I looked at the "ini" file mechanism built into PHP. It only allows comments at the top - so you can't annotate each setting easily - and you can't validate syntax with "php -f". Other options?
2) How to handle templating? The application needs to pump out a form. Possibly with an error message. (e.g. "Sorry, wrong password.") I've have a class variable with the HTML form, but also allow an external template file to be used instead (specified in the config). I do some trivial search and replace - e.g. %SCRIPT% to the name of the script, %STATUS% to hold the error message. This feels a bit like reinventing the wheel, but including a templating system like Smarty is overkill. (Plus they may already have a templating system.) Other options?
3) i18n - There are only 3 message strings, and gettext doesn't seem to be universally installed. Is it such a bad idea just to make these three strings parameters in the config file?
4) How to best integrate with other frameworks? My app is a single class. So, I thought I could just include a php script that showed how the class was called. It would be a starting point for people who had to integrate it into another framework, but also be fine as-is for those not interested in customizing. Reasonable?
5) GET/POST parameters - Is it bad form for a class to be looking at $_GET and $_POST? Should all values be passed into my class during construction?
Thanks.
Configuration
You can use a php file like this:
<?php
return array(
'option1' => 'foobar',
'option2' => 123,
//and so on...
);
?>
And in the main class just use:
$config = (array) include 'path/to/config/file';
And if you plan to mostly distribute your class as a component in other applications, then simply put config array/object as a parameter in your class' constructor and leave the details to the user.
Templating
For such simple application the method your described should be enough. Remember that one can always extend your class and overload your outputting method with his own.
I10N
As mentioned before, for 3 variables anything more than storing them as config is just overkill.
Integration
Comment each public method (or even better also protected and private ones) with explanations what do they do and what parameters are needed. If you combine that with an example, it should be enough for most users.
GET vs POST
Your class uses passwords and you even think of sending them via GET? ;)
Think of browser history, referer headers etc - your users' passwords would be visible there.
Can config be local to class instances? Or could you create a little class that you could create an instance of to query for config values? Also prepending any global vars with you application's name should go some way to stop clashes.
If your templating is really simple, just write a short templater. It'll be easier than trying to fend off problems people get with any 3rd party templater. It might also simplify licensing issues. If you start worrying about what they already have, you'll never release anything. There are too many combinations.
For 3 strings? Yeah do those the same way you're handling config.
Good comments throughout with an intro explaining how you use the class.
I don't think so. If it bothers you, you could use default arguments to use given arguments first, then search for GET/POST values if none are provided (though that might be a security risk)
There are other things to take into consideration. Lots of people are on shared hosts and as a result, don't have control over their php.ini or their php version. You need to make sure you're only using features that are as commonplace as possible.
One example is that shorttags aren't enabled on some hosts (you have to use <?php ... ?> and <?php echo "..."?> instead of <? ... ?> or <?= "..." ?>) which can be a royal PITA.
In addition to Krzysztof's good advice:
Use <?php only
If you use functions that can be disabled, use function_exists() to ensure they're available. #missing_function() makes PHP die silently without any error logged.
You can't rely on things that can be disabled/changed via php.ini. Use ini_get() to adapt to different settings.
If magic_quotes are enabled, strip slashes only on from your copy of input – don't modify global arrays! Security of some lame code may rely on these slashes being present.
Expect that users will mindlessly copy&paste code from your documentation/website.