Not sure if this question belongs here, but it is kinda a programming question.
I'm running xampp 3.2.2 (just Apache and MySQL) with php 7.1.14 on Windows 7 to work on several Symfony (2.8) applications.
Initially I had them hosted with vhosts using different ports and accessed them by http://my-ip:port, but that was a PITA because 1) the browser mixes up the cookies, forcing you to continually log in when switching apps and 2) some php cache (I think, its been a while) mixes up User classes, forcing you to restart Apache.
I then switched to name-based vhosts (nothing fancy, local name resolution using C:\Windows\system32\drivers\etc\hosts) which got rid of the issues.
Not sure if it is related to running several apps, but now I got a new problem: Everything started out fine, but then Symfony sporadically threw this error in my face:
Warning: class_implements(): Class does not exist and could not be loaded
Most of the time there is no class name (note the two spaces), sometimes it says some gibberish like \.php$. I typed this one from memory, but I think it was a less well-formed regex. I also get other stuff that's definitely not a class name.
Over time (a few weeks), "sporadically" changed to "every few minutes/requests", even with just using one app. What helps is restarting Apache, sometimes I also need to delete the Symfony cache.
What is going on here and how can I fix it?
this works for me:
in php.ini file
change this line,
;realpath_cache_size = 4096k
to
realpath_cache_size = 4096k
and restart your Apache or XAMPP.
This error was occurring in my Localserver, i just restarted the Apache and things become fine. So, you can make a try.
Related
I have a stupid problem that is driving me nuts at the moment.
Our web apps are pretty small so we run them on a shared hosting environment. Therefore I don't have a lot of possibilities to change the server configuration. The only thing I can do is edit the php.ini that is used for our domain. Configuration of everything else is out of my reach.
That's why I wanted to set up a local Vagrant server that is as close to the production server as possible by installing the same PHP Version (almost! in Vagrant it is PHP 5.4.43, the production server however runs PHP 5.4.16) and using the same php.ini that is also used online.
Both servers are running Apache 2.4 and PHP via FastCGI using PHP-FPM.
However, when I try to start up PHP-FPM in the Vagrant machine with the php.ini that I have downloaded from the administration panel of our hosting provider, it exits with some fatal errors because some of the directives in the given php.ini are deprecated and have been removed. That made me wonder why the same php.ini refuses to work in Vagrant, but works online without problem.
As phpinfo() on the production server tells me, the downloaded ini file is the only php.ini that is being loaded. However, the file seems to be ignored and instead the default values are applied.
So I figure that particular ini file is a hangover from ancient times of our production server, and it is just as invalid on the production server as it is on my Vagrant machine - the error handling is just different! The production server handles the error gracefully, ignoring the invalid ini file silently, but my Vagrant machine refuses to work.
Ignoring the invalid ini file is obviously no solution to the root of the problem, but curiosity struck me. I thought this should be easy, but after googling for a while, I am still stuck. How and where can I configure PHP-FPM to ignore invalid ini files, instead of exiting with a fatal error?
So, I have been talking to our hoster's support team in the past days and I got an answer to how they achieved this behavior.
The answer is simple and at the same time frustrating: They are running a customized build of PHP. They patched PHP's error handling to ignore ini errors instead of throwing a fatal error and then compiled PHP themselves.
Consequently this is no standard PHP behavior and would be quite time-consuming to implement by oneself. It is definitely not worth the work for my purpose.
I've been setting up PHP deployments with Capistrano on CentOS 6 and have run into an interesting issue. The way capistrano works, it sets up folders like this:
/var/www/myapp.com/
current (symlink to latest release in /releases)
shared
releases
20130826172737
20130826172114
When I look at the "current" symlink, it points to the most recent release. At first, when opening my web app, everything worked fine. After deploying a new release, the current folder correctly points to the new release, but the web application tries to load files from the old release (which has been deleted in a Capistrano cleanup process). Also, the virtual host is configured to point at /var/www/myapp.com/current/Public.
Are symlinks cached in any way?
The specific PHP code that fails (which initializes my framework) is this:
require_once dirname(dirname(__FILE__)) . '/App/App.php';
App\App::run();
That is in index.php currently located at /var/www/app.com/current/Public/index.php.
My Apache error logs show:
PHP Fatal error: require_once(): Failed opening required '/var/www/myapp.com/releases/20130826172237/App/App.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/myapp.com/releases/20130826172237/Public/index.php
And the current symlink shows:
current -> /var/www/zverse/releases/20130826172641
Obviously 20130826172641 != 20130826172237 which the latter was the previous version.
Any ideas or areas I can look at?
I can't verify this, but it seems that there is some unpredictable behaviour with Apache following / caching the old location of symlinks:
Is there a way to mimic symlink behavior with an apache configuration?
Case Against Using Symlinks For Code Promotion
The only thing that would absolutely clear up this issue was to cycle Apache, which we would prefer not to do on every deployment. -- Mike Brittain
He suggests moving the whole directory, instead of updating the symlink.
Have you checked the realpath_cache_size and realpath_cache_ttl directives? By default, php > 5.1 caches the real paths of symlinked files for 120 seconds. This will cause problems with capistrano deployments. The main problems are caching - that even if you clear your cache, your old php files will continue to be served for two minutes, repopulating it with old data - and interaction between php and static files. Static files are served directly by Apache, so will be updated immediately. The php code will still be from the previous release for two minutes after deploying though, so it will be expecting the old versions of any changed static files. That's especially a problem if you use a cache breaking procedure that changes the names of those files; in that case the php code won't be able to find the files it's expecting at all.
Anyway, there are two solutions. The first is to set realpath_cache_size to 0 in php.ini. (Note: setting realpath_cache_ttl to 0 does not disable the cache.) Or, if you want to keep it enabled, you should be able to use the clearstatcache function to clear the realpath cache immediately after deploying your symlink, using a capistrano hook. Be aware though, if you're using mod_php, the php cli and apache runtimes are separate, so you would need to call that function using a php script invoked by apache, similarly to what's done for clearing the APC cache here. I haven't tested that though, as I didn't notice a significant performance impact from simply disabling the cache.
I am working on a PHP web app with another developer. We have 3 total different environments:
Configuration 1: Windows XAMPP, PHP 5.3.5
Configuration 2: Turnkey LAMP, PHP 5.3.X (turnkey-lamp-11.2-lucid-x86) - not sure which ver, running from virtualbox on a mac
Configuration 3: production server, hostgator shared running CentOS, php 5.3.9 fastcgi
Configuration 2 sometimes will not recognize the defines that are handled in our settings.php file which is require_once at the top of any page which uses it. The defines work fine on Configuration 1 and 3 always. There was nothing of interest in the apache logs, other than the errors generated as a result of the define being treated as a string.
I've searched for a while and cannot find anything that describes this issue. Configuration 2 is the other developer, and i do not have access to his machine right now. Looking for suggestions on how to track this issue down. I think we are going to try a new instance of the VM, using an upgraded turnkey-lamp, however i'd really like to root cause this.
Ok, so i figured out what was happening... and as expected, it wasn't PHP or defines. The errors reported were accurrate. We use Eclipse as the IDE, and Subclipse for SVN. Configuration 2 uses a VM running from a mac, and we added a command in eclipse to sync when files are saved. Apparently the syncing only was happening for the main public_html directory, and not our other same-level directory which has the include file with the defines in it. Ultimately, i needed to look at the actual VM to notice it was way out of date on that one file, and was missing the define statement, which results in the error, but Eclipse was showing the HEAD revision from SVN, which is why it was so confusing, but simple.
Lesson: Make sure you plugged in the TV before calling the repairman.
I installed Apache, PHP and Apache to be used with PHP. The Apache server was never pointing to localhost, and the localhost always pointed to IIS instead of Apache.
Interestingly, I had a seperate website (explicitly named with somename.com, running locally with default port 80 and upon firing the Apache server the site was being used (instead of localhost) for displaying the Apache-based folders.
However, both are not able to process PHP and I've been trying to get this to work for almost a day now (I thought it wouldn't be too rough on me initially)
So since no matter what change I've made:
Apache configuration to use specific IP, rather than port 80.
Restricted IIS on specific ports, rather than port 80 and all local ports.
Disabled IIS via 'Services' in Administrative Tools.
Forced restart of 'Apache Service' via 'Services' in Administrative Tools (this threw an error). But restarting it via the Apache Http server menu options seemed to work fine.
Installed XAMPP so it will run directly (not sure if I'm using this wrong though, it did seem to start up but again localhost was never pointing to the Apache's 'htdocs' like it's supposed to.
PHP was added to Apache as well as downloaded (both .MSI, .ZIP installed for BOTH Apache and IIS).
No option seems to make the PHP process, it just displays the source code (like in HTML you have the html, head, body tags displayed on the web site instead of actual HTML ). It's pretty frustrating that:
After different attempts to disable IIS, I've not been able to.
Apache has everything configured to run PHP (I have actually done this on a Macbook once a long time back, don't remember if I missed anything though) but it doesn't work.
No errors are thrown, except that localhost is not displayed (I stopped the sites that were on IIS, and localhost points to IIS, any attempts at accessing either the IIS specific folders, or the Apache sites are not working).
Also, several attempts of getting PHP to work on WINDOWS 7 (yes in capital letters) has failed as well. Please help!!! Let me know if any specific details may help in troubleshooting, and I will be glad to provide them.
Well, firstly, apache is obviously now running as you can see the php source.
If you only see php source, assuming the PHP file is of a .php extension, you can boil it down to almost certainly the mime type hasnt been set.
in your apache config there will be lines such as:
AddType application/x-httpd-php .php
if not, add it.
If that doesnt work it would really seem it hasnt heard of PHP at all.
having not got apache on win7 to hand, theres probably a loadmodule line missing, while this is aimed at vista, this may have some ideas.
http://www.wikihow.com/Install-and-Configure-Php-5.2.5-and-Apache-2.2.8-in-Windows-Vista
Just use some prebuilt solution....
I use WAMP, But there are loads out there.
PHP v5.2.8
Windows Server 2003 SP2 (IIS 6, I believe, though I can't find a version # anywhere in IIS manager)
The full error is:
"CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers."
I installed the WAMP stack from bitnami.org, and the PHP pages work completely fine when visiting via Apache, which I have running on port 8888. However, due to network configuration and firewall reasons, I have to get this working on the IIS server on port 80. There are other websites running on port 80, including a default website that can't be changed. Unfortunately, I also have to have this running as a virtual directory, such as www.myserver.com/phpapp, instead of as it's own website such as phpapp.myserver.com. The reason for this is that the firewall, beyond my control, requires new passthrough rules to allow access on a new subdomain.
This same WAMP stack from Bitnami is working fine on another server when the php app runs as it's own "website" in IIS, since I can add a new PHP ISAPI filter - but that tab/option is not available on virtual directories.
I've installed the php "Web Service Extension" in IIS Manager. I have tried both php-cgi and the php5isapi.dll in the web-service-extensions. Furthermore, I have tried both of those as the "application extension" under the websites "configuration" mappings.
I've also tried mix/match combinations of the php5isapi.dll and php-cgi.exe for the "web service extensions" and the websites "configuration" extension mappings.
I've tried tweaking a few things in php.ini, (including making sure the doc_root is blank). However, as I mentioned before, this website works fine when visited via the Apache port. IIS points to the exact same directory.
What on earth is causing this error? I've spent quite a bit of time searching online, and it seems this error pops up for a few different reasons. If one had a PHP app that did a raw write to the response without writing the headers first would cause this error. Some PHP apps can cause this error when there is a PHP error resulting in some malformed redirect.
My php error logs are missing in action. In my php.ini I have
error_reporting = E_ALL
display_errors = On
log_errors = On
display_startup_errors = On
error_log = "c:\temp\php.error.log"
But there is never a log file in c:\temp. I also tried escaping the slashes, and tried forward slashes in the path, and the log file never shows up.
Again, I feel compelled to mention that this all works fine via apache, so it doesn't seem like PHP itself is bailing due to some strange configuration (even though I can't find the log file) Not to mention this is the same php.ini that I use on the other computer where this is working fine via IIS (where the php app is it's own "website" instead of a virtual directory).
I don't know what other info to provide - but I'm at my wits end after battling this off and on for several days. If I drop an HTML page in, I can visit that just fine via IIS under this virtual directory. What can be causing this?
The app I'm trying to run is vBulletin. Not sure that it matters a whole lot other than to give credence to the correctness of the PHP in the app.
This should have solve all it, takes care of these issues.
IIS Aid PHP Installer
http://www.iis-aid.com/iis_aid_php_installer