I have an .env file containing SOME_IP=127.0.0.1:8080. In a Laravel controller for a certain request I call $foo = getenv('SOME_IP');. About 90% of the time it works fine, I get the string and proceed. But the other 10% of times, getenv returns false, even though the variable is clearly in the .env file. What could be causing this?
Alternatively, Laravel's env returns null.
Observed with vlucas/phpdotenv v2.6.4.
Maybe it's because of caching the config.
It is better to load your env variable in a config file and then retrieve it from the config.
For example you can create a file with the name 'ips' in config directory like this:
<?php
return ['someIp' => env('SOME_IP')];
and then use
$foo = config('ips.someIp')
I have a Joomla website where I have a custom module with mod_myModuleName.php and mod_myModuleName.xml files and a folder where there are several PHP scripts that add special functionality to my module. There is a config.php file in the folder that holds an associative array with variables and their values hard-coded. The module works just fine.
What I want though is to provide administrator area for the values of the variables in the array, so that I can put values in administrator panel and get their values in config.php. In my mod_myModuleName.php I use <?php echo $params->get('param')?> and it works like a charm.
But when I try to use the same technique in the config.php it breaks my code. I tried to get the values in mod_myModuleName.php and then include it in config.php and use the variables but it does not work either. I have not got so much experience in php and cannot understand what can be the reason.
It sometimes gives me an error of something non object and I guess it must be something connected with object oriented php, am I right? And if so is there a way to overcome this without object orientation or how can I solve my problem?
The problem will be with the way you're using your config.php.
When your modules entry point file mod_myModuleName.php is loaded by Joomla the $params object is already available in that context, you need to provide it to your scripts.
If you look at something like the mod_articles_latest module you will notice that the helper class is included with this line:
require_once __DIR__ . '/helper.php';
And then helper class is has it's getList() method called statically with the $params passed into it, so that $params is available to class context:
$list = ModArticlesLatestHelper::getList($params);
Inside the helper class ModArticlesLatestHelper you will notice that the getList() expects the $params to be passed in.
public static function getList(&$params)
{
...
}
I would strongly recommend reading the articles in the Modules section of Developers Portal on the Joomla Doc's.
Try the "Creating a simple module" article.
I am struggling to understand scope and what's preventing my new code from working (assuming it is a scope issue).
The following function is in a file PATH.'/includes/custom-functions.php' that references a class:
function infusion() {
require_once(PATH.'/classes/infusion.php'); //PATH is defined in WordPress from ~/wp-content/themes/theme/
return new infusion();
}
The class is reliant on PATH.'/api/isdk.php' and connection credentials from another file within /api/ directory. From within PATH .'/includes/custom-functions.php', I have many other functions that call $infusion = infusion(); and work perfectly.
PROBLEM
I have created a new file: PATH.'/includes/report.php' which I need to access $infusion = infusion();but can't get to work by either repeating the function infusion() definition from above; using require_once();; or using include();. All 3 of those options simply kill the rest of the code and I can only come to the conclusion - well, I have no conclusion.
Any help would be greatly appreciated.
I'm assuming the code isn't using namespaces, therefore you aren't permitted to redeclare the infusion function (either by redefining the function, or re-including the class).
Your includes/report.php file should simply have:
require_once PATH.'/includes/custom-functions.php';
// your other code here ...
$infusion = infusion();
It may be the case that other files / classes that you're including in your file are already requiring custom-functions.php along the line, so you may be able to skip that entirely. Also note that the PATH constant should have already been defined somewhere (either directly or via an included file) before you attempt to use it. If you set your error_reporting to include E_ALL, you'll get a notification in your error log if that constant doesn't exist.
If that fails, your error log(s) may provide some additional background on what your issue is.
I want to know a clean way of defining Application Constants in Codeigniter. I don't want to change any native file of codeigniter. Hence I don't want to define it in application/config/constants.php as when I need to migrate to newer version of code-igniter I will not be able to copy the native files of codeigniter directly.
I created a file application/config/my_constants.php and defined my constants there. 'define('APP_VERSION', '1.0.0');'
I loaded it using $this->load->config('my_constants');
But I am getting a error
Your application/config/dv_constants.php file does not appear to contain a valid configuration array.
Please suggest me a clean way of defining application level constants in code-igniter.
Not using application/config/constants.php is nonsense! That is the only place you should be putting your constants. Don't change the files in system if you are worried about upgrading.
just a complete answer. (None of the answers show how to use the constants that were declared)
The process is simple:
Defining a constant. Open config/constants.php and add the following line:
define('SITE_CREATOR', 'John Doe')
use this constant in another file using:
$myVar = 'This site was created by '.SITE_CREATOR.' Check out my GitHub Profile'
Instead of using define(), your my_constants.php file should look something like this:
$config['app_version'] = '1.0.0';
Be careful with naming the array key though, you don't want to conflict with anything.
If you need to use define(), I would suggest doing it in the main index.php file, though you will still need to use APP_VERSION to get the value.
config file (system/application/config/config.php) to set configuration related variables.
Or use
constant file (system/application/config/constants.php) to store site preference constants.
=======================
DEFINE WHAT YOU WANT
=======================
$config['index_page'] = 'home';
$config['BASEPATH'] = 'PATH TO YOUR HOST';
Please refer this:
http://ellislab.com/forums/viewthread/56981/
Define variable in to constants & add value on array
$ORDER_STATUS = array('0'=>'In Progress','1'=>'On Hold','2'
=>'Awaiting Review','3'=>'Completed','4'
=>'Refund Requested','5'=>'Refunded');
You can accomplish your goal by adding constants to your own config file, such as my_config.php.
You would save this file in the application/config folder, like this:
application/config/my_config.php.
It is very common to have a separate config file for each application you write, so this would be easy to maintain and be understood by other CI programmers.
You can instruct CI to autoload this file or you can load it manually, as needed. See the CI manual on "Config class".
Let me suggest that you use composer.json to autoload your own Constants.php file, like this:
I am trying to decide on the best way to store my applications configuration settings. There are so many options.
The majority of applications I have seen have used a simple require and a PHP file that contains variables. There seem to be far more advanced techniques out there.
What have you used?
What is most efficient?
What is most secure?
We use a file called Local.php which is excluded from the SCM system. It contains several constants or global variables. For example:
// Local.php
class Setting
{
const URL = 'http://www.foo.com';
const DB_User = 'websmith';
}
And it can be referred to anywhere simply by:
Setting::URL
If you need the settings to be writable at runtime, I suggest you use public static variables instead.
The best thing you can do is the simplest thing that could possibly work (php variables) and wrap it up in a class. That way you can change the implementation later without changing any client code. Create an interface that the configuration class implements and make the client code use the interface methods. If you later decide to store configuration in a database or JSON or whatever, you can simply swap out the existing implementation with a new one. Make sure your configuration class is testable and write unit tests.
Try to use php-arrays config files using technique described here: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays
This method allows you to write app configuration in this way:
app.config.php
<?php
return array(
'appname' => 'My Application Name',
'database' => array(
'type' => 'mysql',
'host' => 'localhost',
'user' => 'root',
'pass' => 'none',
'db' => 'mydb',
),
);
This method is secure, cache-able by opcode cachers (APC, XCACHE).
How about:
; <?php die('Direct access not allowed ;') ?>
; The above is for security, do not remove
[database]
name = testing
host = localhost
user = root
pass =
[soap]
enableCache = 1
cacheTtl = 30
Save as config.php (or something like that, must have php extention), and then just load it with:
parse_ini_file('config.php', true);
And you could use
array_merge_recursive(parse_ini_file('config-default.php', true), parse_ini_file('config.php', true))
to merge a default config file with a more specific config file.
The point here is that you can use the very readable ini format, but still be able to have your config file in a public directory.
When you open the file with your browser, php will parse it first and give you the result, which will just be "; Direct access not allowed ;". When you parse the file directly as an ini file, the php die statement will be commented out according to the ini syntax (;) so it will not have any effect then.
I find Zend_Config to be a good solution. You can load the configuration from a simple array, from an INI style file, or from an XML document. Whichever you choose, the configuration object is the same, so you can switch storage formats freely. Zend_Config objects can also be merged, depending on your application this may be useful (a server config, then a per site/installation config).
As with most (or all) things in the Zend Framework, you can easily use Zend_Config by itself.
Considering efficiency, I'd say the fastest method would be to use an array, since that requires less (in this case no) string parsing. However, a INI/XML format may be easier for some to maintain. Of course some caching would give you the best of both worlds.
Also, using INI files with Zend_Config allow you to define sections of configurations that inherit from each other. The most common use is a 'development' section that inherits from the 'production' section, then redefines the DB/debugging settings.
As for security, keeping the config file out of the web root is the first step. Making it read only and limiting access could make it more secure; however, depending on your hosting/server configuration you may be limited in what can be done there.
Just an example of how to implement a central XML/Xpath configuration.
class Config {
private static $_singleton;
private $xml;
static function getInstance() {
if(is_null (self::$_singleton) ) {
self::$_singleton = new self;
}
return self::$_singleton;
}
function open($xml_file) {
$this->xml = simplexml_load_file($xml_file);
return $this;
}
public function getConfig($path=null) {
if (!is_object($this->xml)) {
return false;
}
if (!$path) {
return $this->xml;
}
$xml = $this->xml->xpath($path);
if (is_array($xml)) {
if (count($xml) == 1) {
return (string)$xml[0];
}
if (count($xml) == 0) {
return false;
}
}
return $xml;
}
}
Example call
Config::getInstance()
->open('settings.xml')
->getConfig('/settings/module/section/item');
In my view good solution would be ini files.
I don't prefer config file using arrays/variables for storing settings; here is why:
What if a user accidently re-named your setting variable?
What if a variable with similar name is defined elsewhere too by the user?
Variables in config file may be overwritten some where deep in the script or even included files.
and possibly more problems....
I like to use ini file for setting of my php apps. Here is why:
It is section based
It is easier
You can set values by friendly names
You don't have to worry about variables being overwritten because there are no ones.
No conflict of variables of course.
It allows more flexibility in specifying the types of values.
Note: You need to use parse_ini_file function to read ini files.
It is best to do any core configuration in PHP itself, but if you are using a database and don't mind the extra overhead - you may find some flexibility in storing some settings in the database with a single extra query (assuming you organize it properly).
Either way, storing this data in JSON, INI, XL, etc is just another unneeded abstraction that is done way too much nowadays on the web. Your best bet is pure PHP, unless you like the flexibility of some settings being in the database.
The only reason I can think of to not use php vars as others are suggesting is if you need to switch between configurations in a controlled manner, so there data/behavior consistency during the switch. For example, if you're switching databases, then the system could write locked until the switch-over occurs (to prevent ghost-writes, but dirty reads are still possible).
If things like this are a concern, then you could write a special admin page in your app(pref local access only for security) that locks the system temporarily, then reads and deploys all your changes before unlocking.
If you're running a high traffic site where consistency matters, this is something you'll want to consider. If you can deploy during off hours when there is little/no traffic, then php vars or other standard text formats will be fine.
I like the idea of having "namespaces" or some kind of tree
so you can have:
db.default.user
or
db.readonly.user
and so on.
now regarding code what I did was an interface for the config readers: so you can have a memory reader, array reader, db reader, etc.
and a config class that uses those readers and allow you have a config from any kind of source