I am running PHP on Windows. PHP plugins on Windows are just DLL's in an extensions folder, and I can do little to configure these plugins.
For example, the ADAP plugin (which is OpenLDAP itself) has settings that I can't change on runtime. Luckily, OpenLDAP allows me to change some of these settings by messing with the environment variables. I tried setting them up on runtime by adding both:
// this apparently works on Linux
putenv('VARIABLE=value');
// tried this one as well
$_ENV['VARIABLE'] = 'value';
But that didn't work. I had to add that to Windows' environment variables (and that did work), but that's too much of a pain in the rear and will break the code when I move it. Is there a better way to do this or I'll have just to deal with it?
Thanks
Try to set the environment variables before the dll extension is loaded. That is, don't load the dll via php.ini, but use putenv() and afterwards dl(). Usually a DLL should share the environment variables with the main process, but you never know.
Alternatively set any required options from within .htaccess using SetEnv. This is at least portable for Apache webservers. Come to think of it, you should also try apache_setenv() if you are running mod_php and not the FastCGI version.
Btw, there have always been PHP bugs for putenv, http://bugs.php.net/50690, might be the case here.
Related
this is not a bug in my program but a general doubt. I've heard and read that in Windows people uncomment extension names in PHP.ini to enable them. Does this works in Ubuntu too?
Actually I've tried it in my Ubuntu and it didn't work, just want to be sure it doesn't works like this in Ubuntu or it was my fault somewhere (which doesn't matters now ).
In my case I didn't even touched the ini file but just recompiled the php from source with passing extension arguments. Why didn't I have to enable them?
Tried searching SO but didn't find any questions related to this.
With Windows, pretty much all the extensions are already compiled as DLLs. So when you uncomment the line in the ini file and restart the service, it simply loads the file.
When you compile from source in Linux, you aren't building all the extensions by default. You usually have to explicitly specify which extensions you want to enable and they are compiled along with PHP. So the extension has to be compiled successfully and be accessible to be used. The ini file is simply the instruction of whether or not to TRY loading that extension when PHP starts.
Also, there are some basic extensions that are part of the typical PHP build / configure / make process. You can consult the docs to figure out which ones are default but a good practice is to explicitly enable those that you want.
Don't build EVERY extension if you don't need them though. The more extensions that get loaded, the more memory that PHP needs/uses when starting up.
the simple answer is yes it works but if only the extension is in your ubuntu.
I know this may be a long and general question but I am struggling with it for the past two days and have achieved nothing.
I am a C# .net developer and I use Visual Studio IDE for my development which does all the back-end work for me when creating projects, setting virtual hosts, publishing the project and etc.
Now for some reasons I have to do a project in PHP and I chose PhpStorm as my IDE. I installed XAMPP and the Apache server is working ok, and I set its' php executable as an php interpreter in PhpStorm.
I don't want all my projects to be in xampp/htpdocs so I choose another location (d:\projects\phpStorm\<name of the project>) as my working space when I first created a project.
I installed xdebug using the tutorial it gave me:
Download php_xdebug-2.4.0rc4-5.6-vc11.dll
Move the downloaded file to C:\xampp\php\ext
Edit C:\xampp\php\php.ini and add the line
zend_extension = C:\xampp\php\ext\php_xdebug-2.4.0rc4-5.6-vc11.dll
Restart the webserver
And I can confirm that it is installed using phpinfo() in a php file located in xampp/htpdocs.
My problem is with the debugging. When I click Run->Run in an opened php file in PhpStorm, it uses a free port and opens the php file with a url like this: localhost:port_number/<name of the project> and everything is ok.
Now I followed this tutorial to configure the xdebug. In step two, when I go to Run->Web Server debug validation, fill the Path to create validation script with d:\projects\phpStorm\<name of the project> and Url to validation script with localhost:port_number/<name of the project> (as mentioned above) and click validate I get this information (and an error in the last line):
Server Name: PhpStorm 10.0.3
Loaded php.ini: C:\xampp\php\php.ini
No debug extension is loaded
Follow this links to configure Xdebug or Zend Debugger. If you have
already configured debug extension in php.ini file check possible
reasons why it was not loaded:
You forgot to reload web server after changes in php.ini file.
You are configuring debug extension in the wrong php.ini (see the
loaded php.ini files below).
There are errors on attempt to load debug extension, e.g. version
incompatibility.
I want to know what should I do?
I really really want to set my projects in another location other than xampp/htpdocs to organize them properly, just like I do it in Visual Studio. So please don't suggest solutions involving me changing my working directory.
Thanks in advance.
P.S.: In JetBrain's tutorial, I see that the xdebug's IDKEY is PHPSTORM whereas mine is my pc's username, it it ok?
I really really want to set my projects in another location other than xampp/htpdocs to organize them properly, just like I do it in Visual Studio. So please don't suggest solutions involving me changing my working directory.
Well you're really going to hate this then, but unfortunately Apache (which is what php runs on) only recognizes htdocs (or public_html, or www, depending on what specific server you are running, but anyhow in your case only htdocs) as a valid directory for php execution. Sooooo...
That doesn't really mean this is hopeless, but you might have to jump through some silly hoops to get it to work this way.
Option 1
You may have some luck creating a symbolic link from .htdocs to your projects folder from the command line:
ln -s C:xampp/htpdocs d:/projects/phpStorm
If you're on windows, this probably won't work. It also likely won't work between drives. It also may not work depending on your Apache configuration in XAAMP.
PROS: If it works, will do exactly what you want.
CONS: Probably won't work, if it does, will require nightmarish levels of config fiddling
Option 2
Use a remote development server, and sync over FTP with your IDE. I'm not super familiar with PhpStorm, but I can pretty easily do this in Netbeans or Eclipse. This is a good option when you need a local archive of a project retained. You might be able to set up an FTP server on your machine and accomplish this, however you are going to wind up with two copies of your project; one in your projects folder and the other in htdocs.
PROS: Your projects stay organized where you want them without much issue.
CONS: File duplication, they will have to be in htdocs anyhow for Apache to run php
Option 3
Accept that the technology is not designed to work this way and just put everything in htdocs where it belongs. Resisting the way technology works because you are used to a different workflow is how design flaws and really bad bugs happen. Use it the way it was meant to work and don't be scared of learning new things.
PROS: No conflicts with the XAAMP stack whatsoever
CONS: You specifically stated you don't want to do it this way, but this is really the best way
Option 4 (Don't do this)
Install PHP as a globally accessible command line utility across your entire system, and consequently get all kinds of crazy viruses and errors that you may not be able to fix ever.
PROS: Minor alleviation of aggravation with foreign workflows
CONS: All of the things. The worst things.
Option 5 (probably not going to work)
Try using VirtualHosts. There's a bunch of caveats with this though. First, doing this between different drives is nearly impossible to configure correctly due to security policies in your operating system that are difficult to overrule. Second, if you're on Windows (I assume you are if you are using XAAMP), you need to do all of the following:
-In apache.conf, you need to enable your hosts file.
-In the vhosts file, you need to create a new vhost.
-In the windows hosts file, you also need to create a host, because for whatever reason windows likes to arbitrarily add redundant steps. On every other OS, this step is not neccessary. Also, you need to run your text editor as administrator to even do this at all.
-Restart apache when it's all set up
-Pray your machine will let you do this between drives (C: -> D:), or not take a million years to enable.
We have a web-app that we have modified a number of the default php.ini values for; short_open_tag = Off, expose_php = Off, memory_limit = 128M, etc, etc. Our current deployment strategy when we need to scale and bring another app server online involves cloning our app onto a 'new' server that has the latest version of php.ini, along with the distribution-specific (in our case, Debian) php.ini file.
We are currently storing our customized php.ini file in our repo and deploying that when we clone, but ran into a problem recently relating to deprecated config values when a new cloned app server fired up with PHP 5.4+ on it. This resulted in us having a broken config file, and got me thinking about how to best handle this. We'd like to use the default latest php.ini that would contain potentially new directives, and would have deprecated ones removed, and then be able to 'locally' override the settings we need.
Solutions we've considered include using .htaccess files and ini_set(), but three drawbacks here relate to the fact that some settings can only be adjusted in php.ini, that .htaccess will not be used by our cli scripts, and that for each user visiting the site via Apache, we have to process the .htaccess or make calls to ini_set() resulting in unneeded overhead. We've also looked at freezing the version of PHP we use so that there are no updates and changes to php.ini once deployed, but I am not sure if this strategy works best, given we would miss out on minor updates that could be related to security, etc.
Have we missed an option as it relates to portably deploying PHP engine settings?
Per the direction provided by #PeeHaa above, we've decided to lock our application to a specific PHP version (via Composer), taken that PHP version's default php.ini file for both Apache2 and the CLI, and added in our settings. This has then been pushed to our repo, and is copied as needed on deployment and on any git changes to the files.
FYI, in our Debian environment, we've followed the strategy outlined here in terms of installing a specific version of PHP other than latest.
I've set up my own Apache server; with MySQL, PHP and PHPMyadmin.
It used to work previously when I did it before on various computers; but that was the older versions I dealt with, not the latest. However, it's been a while since I've updated my PHP version, so that's why I'm asking this.
What configuration changes do I need to make to get 5.36 to work properly with Apache?
Currently any .htm files can display properly in http://localhost, but no .php ones.
All I see is a text file, so what's gone wrong with this?
The server is not public - in fact, it's on a Windows Vista Home Edition install, and it's a development one. I don't need to worry about anything else just yet, as this is a totally new install.
What config changes do I need to make?
I tried:
# mod_php5
Include conf/extra/suite-php5.conf
but that didn't work, so what's the solution with PHP 5.36?
Should I re-enable the above line (it's currently commented out with the # symbol).
So far the server works; but it's not serving up PHP pages, which is strange.
Anyone got any ideas why? I would gladly appreciate your help!
Won't post the httpd.conf since it's being developed right now though.
No more VC6 versions of PHP 5.3.x?
From the release announcement:
Windows users: please mind that we do no longer provide builds
created with Visual Studio C++ 6. It
is impossible to maintain a high
quality and safe build of PHP for
Windows using this unmaintained
compiler.
For Apache SAPIs (php5_apache2_2.dll), be sure that you
use a Visual Studio C++ 9 version of
Apache. We recommend the PHP builds as
provided by ApacheLounge. For any
other SAPI (CLI, FastCGI via mod_fcgi,
FastCGI with IIS or other FastCGI
capable server), everything works as
before. Third party extension
providers must rebuild their
extensions to make them compatible and
loadable with the Visual Studio C++9
builds that we no longer provide.
Check your config files for http and php. I haven't done this in a while, but you need to add the file type .php to list of files types that you want Apache to serve. READ the config file carefully.
Also, inside your http config file there should be some additional lines that tell Apache where to find php, vis-a-vis the php.ini file. You need to set up your path information inside the config file and in the environment/system variables section of your Microsoft OS.
I'm running IIS 6.0.
Is it possible to set the interpreter path (somewhat like the PHP shebang line) in a PHP File rather in the config-file?
Example:
Let's say I have two version installed (PHP4 and PHP5) the default is set to PHP4. Can I set the files individually to use another interpreter (in that case PHP5) than the default one?
I don't know about IIS, but this is usually handled in Apache-land using mod_php for one one version, and fast-cgi mode for the other, and then setting the handler for php files in a .htaccess file (if you need granular control)
How about different file extensions, like php4 and php for the current version. That should be no problem. Never did it, but that can be configured for sure, b/c your server-application then can decide which interpreter to invoke.