I don't want to disable Xdebug, I don't care that it's slower, so I see there is an environment variable COMPOSER_DISABLE_XDEBUG_WARN and the docs mention setting it in the config.
So, I opened my global /Users/username/.composer/config.json and add:
{
"config": {
"COMPOSER_DISABLE_XDEBUG_WARN": true
}
}
No change.
Where or how do I set this environment variable to get rid of this damn message?
The PHP CLI inherits the environment variables from your shell. You can add the following line to your .bash_profile (or whatever you use for your shell).
export COMPOSER_DISABLE_XDEBUG_WARN=1
Make sure to close the terminal, and reopen it to load the new variable.
Source: https://stackoverflow.com/a/18098263/58795
Use COMPOSER_DISABLE_XDEBUG_WARN as ENVVAR https://github.com/composer/composer/issues/4622#issuecomment-158678115
As per Composer documentation for this flag, ...
"COMPOSER_DISABLE_XDEBUG_WARN": 1
set it to 1, not true to disable the warning. (Ya, I know, if I was coding this part of Composer I would've accepted any truthy value but what can you do, ask for your money back?)
Related
How can I change the app environment at run time?
I have some classes that only bind in the service provider in production. I'd like to assert with a unit test that they are properly bound. For other environment variables, I can set them with the config helper and then simply call resetApplication in tearDown but for some reason the variable set by APP_ENV doesn't change.
dump(app()->environment()); // "testing"
config(['app.env' => 'production']);
dump(app()->environment()); // "testing"
What can I do to get app()->environment() to return production at run time?
app()->environment() reads directly from the variables specified in your .env file rather than the configuration files.
You could take two approaches to solve your problem.
1. Read the environment variables from the config file rather than the .env file.
dump(config('app.env')); // "testing"
config(['app.env' => 'production']);
dump(config('app.env')); // "production"
2. Change the value of 'env' in the current app instance by changing the value of app()['env'].
dump(app()->environment()); // "testing"
app()['env'] = 'production';
dump(app()->environment()); // "production"
I've noticed that above answer can be a bit dangerous: You might be overwriting the 'env' key, without truly switching environments. Suddenly your app says that you are in testing, while your DB connection is still set to production.
Normally you just want to really stick to the Laravel best practice of defining ONE environment for each literal environment, but for my use case I needed to temporarily & programmatically switch between multiple environments within a single artisan script.
My solution (works in Laravel 5.8+ with DotEnv3) would be to really reboot the application:
<?php
$basepath = app()->basePath();
$env = app()->basePath('.env.alternative');
$boot = app()->basePath('bootstrap/app.php');
// Overwrite webserver env
(new Dotenv($basepath,'.env.alternative'))->overload();
// Reboot the application
(require $boot)
->loadEnvironmentFrom($env)
->make(Kernel::class)
->bootstrap();
// This returns 'mysql_alternative', as defined in .env.alternative
dd(DB::connection()->getName())
Disclaimer: I've only tested this to the extend of my own code.
From a testing point of view, then in the setUp() method:
$this->app['env'] = 'production';
But remember, only do this in a test class, specifically testing production runs. Otherwise, do it at the top of the test method, remembering to set it back to testing at the end.
If you adjust the setUp() method, remember your tearDown() method and change it to testing. By altering the $this->app['env'], you are directly changing the Applications environment, which is why it's so important to remember to set it back as it will produce side effects, also only do this in testing .
Under the authentication section in this link, it is given for Anonymous search and bind: simply set authenticatedBind to false. Could you please tell me how should I do that?
#esyana In GForge 6.3.x and earlier, each of the modules (plugins) in GForge has its own configuration file. They're all located in /etc/gforge, with the core settings in gforge.conf and plugin-specific settings in the appropriate folder under plugins/. You'll find the setting ldap.authenticatedBind in /etc/gforge/plugins/ldap/ldap.conf
If you update the value there, then run cd /opt/gforge/bin && php create_config_cache.php to make the change take effect.
In GForge 6.4 and newer, all settings are stored in the database and accessible using a shell script. Run /opt/gforge/bin/gf-config set "ldap.authenticatedBind" false to make the change. It takes effect immediately.
On my apache instance it is setting an env variable APP_ENV=development. I am trying to change this dynamically on my PHP side (in the instance of firing up test suite) like so:
putenv('APP_ENV=testing')
var_dump(getenv('APP_ENV')); // still returns development
I have tried:
Starting php in safe mode in php.ini
Setting safe_mode_allowed_env_vars = PHP_ APP_ in php.ini
Update:
I am using PHP version 5.4.16 and notice that safe mode has been deprecated. I'm not sure if this means putenv will even work for overwriting or even unsetting existing envs?
You are using an Apache variable, so, you should use apache_setenv() and apache_getenv()
apache_setenv('APP_ENV', 'testing');
To recover it use:
apache_getenv('APP_ENV');
The docs say the list needs to be comma delimited.
try PHP_,APP_
I've recently started using APC cache on our servers. One of the most important parts of our product is a CLI (Cron/scheduled) process, whose performance is critical. Typically the batchjob consists of running some 16-32 processes in parallel for about an hour (they "restart" every few minutes).
By default, using APC cache in CLI is a waste of time due to the opcode cache not being retained between individual calls. But APC also contains apc_bin_dumpfile() and apc_load_dumpfile() functions.
I was thinking these two function might be used to make APC efficient in CLI mode by having it all compiled sometime outside the batchjob, stored in a single dumpfile and having the individual processes load the dumpfile.
Does anybody have any experience with such a scenario or can you give good reasons why it will or will not work? If any significant gains could reasonably be had, either in memory use or performance? What pitfalls are lurking in the shadows?
Disclaimer: As awesome as APC is when it works in CLI, and it is awesome, it can equally be as frustrating. Use with a healthy load of patience, be thorough, step away from the problem if you're spinning, keep in mind you are working with cache that is why it seems like its doing nothing, it is actually doing nothing. Delete dump file, start with just the basics, if that doesn't work forget it try a new machine, new OS, if it is working make a copy, piece by piece expand functionality - there are loads of things that won't work, if it is working commit or make a copy, add another piece and test again, for sanity-check recheck the copies that were working before, cliches or not; if at first you don't succeed try try again, you can't keep doing the same thing expecting new results.
Ready? This is what you've been waiting for:
Enable apc for cli
apc.enable-cli=1
it is not ideal to create, populate and destroy the APC cache on every CLI request
- previous answer by unknown poster since removed.
You're absolutely right that sucks, lets fix it shall we?
If you try and use APC under CLI and it is not enabled you will get warnings.
something like:
PHP Warning: apc_bin_loadfile(): APC is not enabled,
apc_bin_loadfile not available.
PHP Warning: apc_bin_dumpfile(): APC is not enabled,
apc_bin_dumpfile not available.
Warning: I suggest you don't enable cli in php.ini, it is not worth the frustration, you are going to forget you did it and have numerous other headaches with other scripts, trust me its not worth it, use a launcher script instead. (see below)
apc_loadfile and apc_dumpfile in cli
As per the comment by mightye php we need to disable apc.stat or you will get a warnings
something like:
PHP Warning: apc_bin_dumpfile(): Excluding some files from apc_bin_dump[file].
Cached files must be included using full path with apc.stat=0.
launcher script - php-apc.sh
We will use this script to launch our apc enabled scripts (ex. ./php-apc.sh apc-cli.php) instead of changing the properties in php.ini directly.
#/bin/sh
php -d apc.enable_cli=1 -d apc.stat=0 $1
Ready for the basic functionality? Sure you are =)
basic APC persisted - apc-cli.php
<?php
/** check if dump file exists, you don't want to use file_exists */
if (false !== $dump_file = stream_resolve_include_path('apc.dump'))
/** so where were we lets have a look see shall we */
if (false !== apc_bin_loadfile($dump_file))
/** fetch what was stored last run just for fun */
if (false !== $value = apc_fetch('my.awesome.apc.store'))
echo "$value from apc\n";
/** store what gets fetched the next run just for fun */
apc_store('my.awesome.apc.store', 'awesome in cli');
/** what a shlep lets not do that all over again shall we */
apc_bin_dumpfile(array(),null,'apc.dump');
Notice: Why not use file_exists? Because file_exists == stat you see and we want to reap the reward that is apc.stat=0 so; work within the include path; use absolute and not relative paths - as returned by stream_resolve_include_path(); avoid include_once, require_once use the non *_once counterparts; check your stat usage, when not using APC(Muchos important senor), with the help of a StreamWrapper echo for calls to method url_stat; Oops: Fatal scope over-run error! aborting notice thread. see url_stat
message: Error caused by StreamWrapper outside the scope of this discussion.
The smoke test
Using the launcher execute the basic script
./php-apc.sh apc-cli.php
A whole bunch of nothing happened that's what we want right, why else do you want to use cache? If it did output anything then it didn't work, sorry.
There should be a dump file called apc.dump see if you can find it? If you can't find it then it didn't work, sorry.
Good we have the dump file there were no errors lets run it again.
./php-apc.sh apc-cli.php
What you want to see:
awesome in cli from apc
Success! =)
There are few in PHP as satisfying as a working APC implementation.
nJoy!
I would definitely not use it in the CLI as when you restart it, it's almost as if it was never running in the first place!
The better way of using APC is to have it running on the webserver itself all the time, this way with it being active it will actually do what it's supposed to do!
I tryed with curl and APC.it works
use these commands in CLI
curl --data "param1=value2" http://testsite.com/test.php
so it will post data to test.php and you writes the code in it.
I am writing a class that detects whether cURL is available, does one thing if it is, and another if it isn't. I therefore need to know how to disable cURL temporarily to test this class. I do not want to change the PHP INI file. Any ideas much appreciated.
Just wondering, Im writing an alternative for if cURL is unavailble, how likely is this? Am I wasting my time. Is cURL usually available?
Curl is enabled / disabled in your php.ini. You can't enable and disable it any other way.
Open php.ini find the below and put a semi colon before it to comment it out:
extension=php_curl.dll
AFAIK there is no way to do this at run time, because modules are loaded during PHP startup, before any of you code is executed. The only way to do it is by disabling (or rather, not enabling) an extension in php.ini. You probably can't even do that with cURL, as it will probably be compiled in, not dynamically loaded.
Having said that - why not just change the check to test your "if not available" code - presumably you have a block something like this:
if (curl_exists()) { //obviously there is no such function, but you must have some condition that determines this
// Do stuff using curl
} else {
// Do something horrible
}
well, just change it to this temporarily:
if (!curl_exists()) {
// etc etc
I think the best option is to change your detection script to allow disabling it with a manual configuration.
You cannot disable function on the fly. You need to change php.ini for that.
http://www.php.net/manual/en/function.dl.php
dl — Loads a PHP extension at runtime
bool dl ( string $library )
Loads the PHP extension given by the parameter library.
Use extension_loaded() to test whether a given extension is already available or not. This works on both built-in extensions and dynamically loaded ones (either through php.ini or dl()).
Warning:
This function has been removed from some SAPI's in PHP 5.3.
<?php
// Example loading an extension based on OS
if (!extension_loaded('sqlite')) {
if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
dl('php_sqlite.dll');
} else {
dl('sqlite.so');
}
}
//this deals with sqlite but would be easy to figure out how to use it for cURL :)
?>
So you can comment out the loading of cURL extension in php.ini and then "dynamically load" it when needed.
HTH
probably the easiest way is by open file curl.ini, Im use ubuntu 12.04 and file located at
/etc/php5/apache2/conf.d/curl.ini
leave a comment by adding semicolon before extension=curl.so
You can see the location of curl.ini through phpinfo ();
dont forget to restart the Apache
sudo service apache2 restart
Curl is available as long its extension is loaded (which is mostly by default).
You can check what curl extension provides by the following command:
php --re curl
which gives you list of functions, classes and its methods.
To temporary disable curl extension, you can run PHP with -n to simply ignore your php.ini, for example:
$ php -n -r "print_r(curl_version());"
Fatal error: Call to undefined function curl_version() in Command line code on line 1
Here is working example:
$ php -r "print_r(curl_version());"
Array
(
[version_number] => 463623
...