When running
getenv('HOME');
it just returns false. Therefore some scripts ran by
shell_exec();
don't work, because they are missing the home path.
PHP (5.5) runs on debian, so it should work according to the manual, but why is it empty then?
I guess you must have found some solution to this problem. But in the interest of others who may drop by, in search of solutions to a similar problem:
I also encountered this sort of issue. In my case it happened in Windows, Apache, PHP stack, but only when I configure PHP to run with mod_fcgid. In that case, variables that I knew existed in the OS environment refused to appear with PHP getenv(), with the exception of few.
My solution: I added this to httpd.conf:
PassEnv HOME
Related
Before you continue to read - the issue has been fixed
Well... this is kinda weird.
I'm working on a web app for some friends. I have a working version uploaded to their hosting, and, suddenly, it stopped working a couple of days ago.
I haven't added anything or changed anything on the server. There is no error, simply the app stopped loading and a blank html page is loaded instead.
I've traced the problem until /vendor/composer/autoload_real.php file.
In the end of the static class inside this file, there is a loop where several other files are being included (actually requested), I've checked that when it tries to request /vendor/laravel/framework/src/Illuminate/Foundation/helpers.php, the system stops. Obviously, I've checked that the file is there, and it isn't been touched.
Well, I'm positive I've didn't changed anything on this part of the app (it's core framework, and I usually don't mess up inside), but just of a sudden it stopped working.
The working copy on my computer just works fine. I've uploaded my copy of helpers.php, but nothing changed.
Anyone had experienced similar issues recently? Anyone has any idea about how to fix it?
EDIT: It's been several days since I could check on this for the last time.
Now I've been tracing raw php execution on /vendor/laravel/framework/src/Illuminate/Foundation/helpers.php file. This is, I've started echoing messages and trying to execute just this file, to see where code execution is stopped.
I know this is very crappy debugging, but I haven't access to apache nor I can restart it, and it seems there is no easy way to get an error code without this.
So patiently trying I've reached two points where execution stops on this file:
Creation of factory method
if (! function_exists('factory')) {
/**
* Create a model factory builder for a given class, name, and amount.
*
* #param dynamic class|class,name|class,amount|class,name,amount
* #return \Illuminate\Database\Eloquent\FactoryBuilder
*/
function factory()
{
$factory = app(EloquentFactory::class);
$arguments = func_get_args();
if (isset($arguments[1]) && is_string($arguments[1])) {
return $factory->of($arguments[0], $arguments[1])->times($arguments[2] ?? null);
} elseif (isset($arguments[1])) {
return $factory->of($arguments[0])->times($arguments[1]);
}
return $factory->of($arguments[0]);
}
}
and creation of mix method
if (! function_exists('mix')) {
/**
* Get the path to a versioned Mix file.
*
* #param string $path
* #param string $manifestDirectory
* #return \Illuminate\Support\HtmlString|string
*
* #throws \Exception
*/
function mix($path, $manifestDirectory = '')
{
return app(Mix::class)(...func_get_args());
}
}
In both cases func_get_args is involved... I haven't a specific error, but I have the tingling that the problem is related somewhat to the fact that this function isn't returning anything.
EDIT2: Ok, I tried php artisan and composer commands suggested on answers to no success. The issue is still there.
I've also deleted the logs and checked that no new log was created while trying to load the site.
I've tried a clean laravel install from scriptaculous on a new directory (I've done this when I first uploaded the site, it worked perfectly for several months) and this new install doesn't reach the front page neither. A blank page (on Firefox) or a 500 error (on Chrome) is shown instead.
I forgot to mention an important data. My app is sharing space with a wordpress instance. The wordpress is installed on public_html, and my site on public_html/mySiteDirectory. This hasn't supposed any problem so far more than make me tweak lightly .htaccess file to make routing work fine.
There is also a phpbb forum sharing space on it's own directory inside public_html.
I wonder if any of those could have somewhat been upgraded and produced this strange outcome.
Also... laravel app_debug is enabled on .env file since the beginning, but never showed anything. This seems to be something that fails before laravel framework is fully loaded.
EDIT 3: IT'S FIXED.
Well... first of all, let me thank you all for your help. Actually there wasn't one answer that fixed the problem, but many of you suggested to use phpInfo() to check php version which ultimately led to the true problem.
Yes... surprisingly, although php -v on terminal showed php 7.2 running on server, and cpanel php management tools showed also php 7.2 installed and running, when I used phpInfo(); php 5.6 was showed on the response.
I used the own cpanel tools to make an upgrade/downgrade to 7.3 and again to 7.2 and et voilá phpInfo(); shows 7.2 and the page is again up and running.
I'll try to share the reward between several answers (don't know if something like that is even possible), and will +1 every answer suggesting phpInfo(); as it showed as the key to fixing this problem.
If I cannot share the reward I'll accept as final answer the one from Don't Panic, as it was the one that convinced me that there was a problem with php versions.
If you look at the code in the functions you have traced the problem to, both contain interesting or less-common PHP features:
factory() includes ??, the null coalescing operator. This was introduced in PHP 7.0.
I see in a comment you added to another answer that you are using PHP 7.2. This question describes Laravel failing in factory(), because even after upgrading to PHP 7.2, and phpinfo() showing 7.2, Apache was still using PHP 5.6. This seems unlikely, but when all else fails ... ?
mix() includes ..., the spread or splat operator. This was introduced in PHP 5.6, but there are reports of it failing in Laravel with 7.x due (AFAICT) due to mismatches between the PHP versions Apache and the CLI are using.
Considering you mentioned you uploaded the code from your local machine (rather than using php composer install), and that CPanel tends to update PHP automatically and silently, this seems like a possibility - there are 4 PHP versions in play (CLI/web on your machine, and CLI/web on server), and they all need to be in sync.
As a side note, as you've already discovered you are really working blind without the logs. Either the PHP and/or Apache logs will give you more info, typically describing exactly the problem, and save you having to manually trace things as you've been doing. If those logs aren't showing anything, maybe PHP isn't configured to log errors - try enabling that.
It probably depends on your CPanel version and config, but standard locations for your logfiles are typically:
Apache access log: /usr/local/apache/domlogs/<your-username>/
Apache error log: /usr/local/apache/logs/error_log
PHP error log: /home/<your-username>/public_html/error_log
Start wtih composer dumpautoload. Then run php artisan optimize:clear. Re-upload the whole site and you should be good to go. I have experienced a very similar issue. Do you run a pipeline on the server or are you just FTP-ing the site up? Are you able to run composer on the server and the same for artisan? If you can, you need to those commands there are as your cache is often based on your host computer drives and will fail in prod.
Simply replacing the file might not be helpful. Try enabling the error log or check if you are able to reach this file bootstrap/app.php. If yes it means there is no problem in the composer. Try checking the version of PHP installed and if it is compatible with your Laravel. Try checking PHP Error Log. It might be helpful.
Ok I should mention a few things
1: Go to storage/logs directory and delete all *.log files then you refresh the web page and you'll check out to see for any log file if there is no log file it means it's related to server configuration and etc. if there is a log file you read it and you post it in here
2: Did you pull the code on cpanel by console command using version control system like git or svn or you just uploaded it in a classic way, if you indeed pulled it with VCS you may did a composer update instead of composer install which will updates all packages as possible as defined in composer.json file and you may have got a higher version of vendor than your local and something may broke in there.
3: You may have a different php version on server vs your local which many times casing real problems.
I can't tell for sure until you post your log file here
So here is what i would have done.
If it is possible simply turn0on debugging, this will show you the error in the web browser itself (you can do that from .env file)
You can also read the laravel log file for errors as mentioned earlier.
If you do not want to do this, run the following commands
PHP artisan cache:clear
PHP artisan route:cache
PHP artisan config:cache
PHP artisan clear-compiled
PHP artisan optimize
If you could share more details that would help...
Have you checked permissions and ownership for storage and bootstrap/cache folder?
these permissions need to be set for the app to work
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache
I tried everything and nothing worked. The best solution for me was that I deleted cpanel files and reuploaded all the codes.
Have been using MAMP Pro for a fair while - version 3 primarily, upgraded to 4 a while ago.
I haven't had any unusual issues at all, but today the Apache service failed to start, telling me to check the error logs. The logs were blank unfortunately... I've made no system configuration changes, no changes to MAMP/MAMP Pro. Shut down my system yesterday, started today, it no longer works...
I've tried numerous suggestions found via Stack Overflow and Google without any success.
Even after completely uninstalling and re-installing MAMP Pro I am unable to get the service to start.
Nothing appears in the logs...
When starting it manually on the command line it comes up with a PHP related error:
$ Applications/MAMP/bin/apache2/bin/apachectl start
httpd: Syntax error on line 135 of /Applications/MAMP/conf/apache/httpd.conf: Cannot load /Applications/MAMP/bin/php/php5.2.17/modules/libphp5.so into server: dlopen(/Applications/MAMP/bin/php/php5.2.17/modules/libphp5.so, 10): image not found
The confusing thing is that I don't have PHP 5.2.17 specified anywhere, at all - according to MAMP Pro it should be using PHP 7.0.12.
If I add PHP 5.2.17 to MAMP using the appropriate MAMP Pro dialogs, Apache still fails to start via the MAMP Pro interface. I can now start it manually from the command line however, but none of my virtual hosts/etc seem to be loaded.
apachectl -V tells me it's using /Applications/MAMP/conf/apache/httpd.conf, but there is nothing in that file that has any reference to any of the configs generated in /Library/Application Support/appsolute/MAMP PRO/conf
It also looks like hosts entries aren't added to /etc/hosts.
Even if I tell /Applications/MAMP/conf/apache/httpd.conf to do nothing but include /Library/Application Support/appsolute/MAMP PRO/conf/httpd.conf (and manually add entries to /etc/hosts) it still doesn't seem to work at all...
I and my colleagues are at a complete loss, especially given it was working yesterday...
Has anyone had any issues like this?
I managed to fix the similar issue you had.
My Apache server was working fine and then following updating to 4.0.6 I experienced similar issues.
There were 2 things I did to fix the issue. I was getting the same error where it couldn't find a php file in 5.2.17. After fixing that by adding 5.2.17 to MAMP I experienced an apache error regarding user permissions.
(22)Invalid argument: getpwuid: couldn't determine user name from uid 4294967295, you probably need to modify the User directive
File > Edit Template > Revert ALL Templates to Default Settings.
Save & restarted the servers and all worked finally and all my hosts had retained as well.
I had previously entered a custom line in my httpd.conf file that for countless versions had copied across fine however it looks like the folder structure had changed and so couldn't locate it causing the unusual error about User permissions. I have since re-entered the custom line with the correct structure and all working fine again.
Hope this helps.
I have a local Drupal site running with MAMP on Win 7 with php 5.6.13. My live site has php 5.6.17. I have no problems on the local site, but on the live site I get unexpected T function error with the following code which I downloaded from drupal.org.
function redhen_activity_message_types() {
$message_types = array_keys(message_type_load());
$filtered = array_filter($message_types, function($var) {
return strpos($var, 'redhen_') !== FALSE;
});
return $filtered;
}
The line beginning with $filtered is the one that is pointed to by the error message.
I know little about php, but have been searching the web and found something called anonymous functions not working on older versions of php. Is the slightly different versions of php causing this problem? How do I fix it?
Thanks!
The anonymous function is the function that's defined starting in that line of code:
function($var) {
return strpos($var, 'redhen_') !== FALSE;
}
I don't see anything obviously wrong with that function, and Redhen CRM gets enough use that others are likely to have run into problems already if it were clearly incorrect. And while it's always good to test under the same version as your production environment it's unlikely that there was bug introduced to PHP between 5.6.13 and 5.6.17 that's causing this problem.
To find the root cause try a few things:
Check to make sure the version of PHP you think is running in production is actually running. I've seen several environments recently where people had a different version running under php-cli than on the web server, meaning that running php --version on the command line gave the wrong answer. Use a phpinfo() call to verify the version.
Check the Redhen issue queue for other people with the same problem.
Update your test machine to match production. Once you're sure production is the version you think it is, set your dev environment to match and see if the problem comes back. If it does, try to move forward to a more current minor version and see if the error goes away again.
I have problems after updating Zend FR to 1.11
Mimetype file checking generates:
Warning: string extension `B' invalid
It looks like cause of problems the string in the Zend_Validate_File_MimeType
$finfo = finfo_open(FILEINFO_MIME_TYPE, $file);
I have created simple test case
$finfo = finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic');
echo finfo_file($finfo, PUBLIC_HTML_PATH . '/images/missing.png');
finfo_close($finfo);
And i got same error :(
finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic'); //generates: Warning: string extension `B' invalid.
My OS: Kbuntu 10.10
Where am i wrong?
Ran into the same error message ("Warning: string extension w' invalid in Command") as Mike Purcell, but the fix for it was different.
On our servers we had a /usr/share/misc/magic and a /usr/share/misc/magic.mgc file. The magic.mgc file had been compiled from the magic file, but PHP still wasn't happy talking directly to the /usr/share/misc/magic file (we'd shifted to that file as part of debugging that the magic.mgc file needed updating).
The fix for us was changing our putenv line back to the magic.mgc file:
putenv('MAGIC=/usr/share/misc/magic.mgc');
Then, magic-ally :-) , the whole mime-type detection system started working again.
This may not pertain to your EXACT issue, but it did resolve the issue I was having which resulted in a very similar error message: "Warning: string extension w' invalid in Command".
For us, we have a heterogenous setup where some servers are still running php 5.2 and others running php 5.3. On the 5.2 boxes the magic file resides in /usr/share/file/magic, but on the 5.3 boxes the file resides in the default path of /usr/share/misc/magic. Apparently someone tried to reconcile these path differences by symlinking the 5.2 path so the codebase could be php version agnostic. But according to some comments posted on PHP site regarding symlinks to the magic file, it will result in unexpected behavior, which of course was resulting in the aforementioned error message.
So be sure the path you are passing is to the actual magic file, and not a symlink, and see if that resolves your issue.
Depending on your PHP version the magic format may be updated. This is documented in a note at http://php.net/manual/en/function.finfo-open.php
run php -v to see your version
I got the same error when pointing to an older magic file in our source tree, and resolved it when pointing to a newer magic file from my current linux distro
I had this error in Laravel (minus Zend FR, of course). Running PHP 5.3.21 on a Windows box with IIS.
Finding very little info online I was close to giving up. It worked initially when I followed instructions in the comments on PHP.net, which were basically to add fileinfo.dll to your PHP installation, and to also download the relevant magic files and point an environment variable to them.
There was some initial confusion until I realised I didn't actually have php_fileinfo.dll, so as well as adding it to the php.ini file, I had to download the file itself and add it to my ext directory.
Now what really had me stuck, was that it worked initially. The next day it didn't. To cut a long story short, it didn't need the environment variable, MAGIC. The reason this had me stuck, is because I had tried every possible scenario, but once the environment variable had been set, it had been set. And I had to restart the Windows server after removing it, to unset it. Once I did this it worked perfectly.
UPDATE (5/21/2010) SUCCESS!
So after MUCH $head->desk()'ing, I've solved it.
Remember kids, be wary of the instant client version you use, dependent on the virtualization settings!
I had been installing the generic Instant Client (not aware our ESX servers sit on AMD processors, not Intel) and that worked fine internally (the CentOS install was 32-bit since our internal ESXi servers aren't 64-bit). Well lo-and-behold, even if you have a 32-bit install running on a virtualized server which is sitting on an AMD64, it still matters what instant client you install.
It was the last thing I thought to check but as it appears, everything is running fine now.
I would like to thank everyone who helped me run through every possible test to figure this out but in the end, it was my fault for not realizing the differences in the virtualizations.
UPDATE (5/21/2010)
I thought this bug had escaped me when I installed it on a new VM internally but I have now found a narrowing link.
I was trying to install this on our production server when I posted this. After a week of no progress and in need to get back to development, I outfitted a VM on our internal server with a brand new install of Crap... CentOS, and fresh installs of instant client and oci8.
Worked perfectly.
However we just uploaded an exact copy of the VM to our production servers and it magically no longer works. Tried reinstalling everything, no avail.
So the only things I could narrow it down to is a firewall issue (although I get the same issue when trying 127.0.0.1) or possibly an ESX (our production servers) server issue, internal servers are running ESXi.
Any thoughts?
UPDATE (3/8/2010) I installed Xdebug and have it tracing my code. This is the output I am getting:
TRACE START [2010-03-08 17:53:05]
0.2090 327864 -> {main}() /data/aims3/http/octest.php:0
0.2091 327988 -> ini_set(string(14), string(1)) /data/aims3/http/octest.php:3
0.2093 327920 -> error_reporting(long) /data/aims3/http/octest.php:4
0.2094 328048 -> oci_connect(string(8), string(8), string(25)) /data/aims3/http/octest.php:6
The trace halts at that point.
I have installed everything the same way on a local server and it works fine. To say I am at a complete loss would be putting it lightly.
*NOTE: I ran make test and it returned FAIL on every test. I never ran this on my working machine to see if it reports the same errors. Any idea why make test would report FAIL but make doesn't report any error?
I've installed the Oracle Instantclient with no reported errors along with the OCI8 PECL package and at a loss. Whenever I try to open a connection with oci_connect, it halts my entire PHP script.
EXAMPLE:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
$conn = oci_connect("username", "password", "host");
echo "after";
?>
Returns a complete blank page. The module is loaded (seen in phpinfo) and everything installed with no errors.
I am at a complete loss.
CentOS: 5.4
Apache: 2.2.3
PHP: 5.3.1
InstantClient: 11.2
oci8: 1.4.1
Any thoughts?
NOTES
Apache Error Log reports nothing
Attempted Debugging:
1:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
echo "after";
?>
Returns:
beforeafter
2:
Changing host to //host
Returns:
Same error
Is there anything in Apache's error_log? Is this mod_php or FastCGI or normal CGI PHP? What happens if you run the script via the command line?
You could also try setting PHP's error log and looking in there.
EDIT1: Try:
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
And post the results...
EDIT2: I'm really not sure. My best bet is this info from the PHP manual:
The most common problem with
installing OCI8 is not having the
Oracle environment correctly set. This
typically appears as a problem using
oci_connect() or oci_pconnect(). The
error may be a PHP error such as Call
to undefined function oci_connect(),
an Oracle error such as ORA-12705, or
even an Apache crash. Check the Apache
log files for startup errors and see
the sections above to resolve this
problem.
Anyone else have any ideas to help out Bryan?
Bryan,
I am going to be honest: I tried this two years ago and failed miserably. :) I could not get the OCI functions to work for anything by compiling myself.
But in the interest of getting it done I looked for an alternate solution and found it in Zend Core for Oracle. All I did was download, run the installer, and it was done. It installs Apache/PHP, MySQL (optional), and the InstantClient for you.
Now as Zend Server, it is basically the same product. I realize that this may not be the solution you hoped for, but if it works...
Zend Server
are you connecting to remote or to local db? i think, for localhost you must replace "host" with "false". I hope, this will help you...
edit: i think, you are missing a parameter...my last suggestions are: 1. you must set the port (default 1521) AND/OR 2. You must enter db name AND/OR you must set the instance name (the ORACLE_SID parameter)
You never check the return value of oci_connect() or call oci_error() but it doesn't look relevant to your problem since you seem to be suffering from a PHP crash. There's an open bug for RHEL that may affect you too:
http://pecl.php.net/bugs/bug.php?id=16626
Did you build the oci8 package yourself? Are you using a third-party binary?
It has been fixed. See the top for details but here is the cliff notes: virtualiztion environments matter.