I have followed the instructions here: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-php-create-web-role/#CustomizePHP for adding an extension but can not get the web role to recognize the extension.
Are you able to load other extensions? There was a bug in the past, see this post: http://social.msdn.microsoft.com/Forums/windowsazure/en-US/cd547ad3-c892-4ba4-82f4-c83690d18966/problem-with-loading-php-extensions
Also note that in order to load the php_ldap extension, it requires the following files: libeay32.dll and ssleay32.dll
Sorry for not coming back to you earlier. How are you getting along?
Since I never used a PHP based Cloud Service I did some testing for you. I followed the link you mentioned in your post with one exception: I did not add the php_ldap.dll to my Cloud Service.
After deploying the Cloud Service I verified a statement I remember about newer PHP installers for Windows:
They come with the required .dll files, like these for LDAP
They add the PHP folder containing the .dll files to your path variable
And this was indeed true. All required files are available and in the correct location.
This is the result I get when verifying LDAP from PHPInfo:
All seems to be ok. Can you try this and let me know how it goes.
Related
When try to do the following
$xsl = new XSLTProcessor();
I am getting this error
Fatal error: Class 'XSLTProcessor' not found in
I've seen this question about this exact same error (and this one) but I think this is different. Am I right in saying (I've tested it and appear to be) that because the extension details are shown in phpinfo() it is indeed installed correctly?
Is that the case, or would it always show in phpinfo() regardless of it being installed successfully? And do you know what might be causing the error if it is successfully installed?
I've tried several versions of PHP and for what it is worth I am hosted on Azure and have followed and checked the instructions here which further leads me to believe the extension is installed correctly.
How did you enable the php_xsl extension on Azure? If you manually upload the DLL library to Azure and config via Configure via ini settings section of How to: Enable extensions in the default PHP runtime. It maybe that the DLL library you configured doesn't match the PHP version or OS version.
However, Azure Web Apps has already contain the php_xsl.dll library in the ext folder of PHP runtime in every available version. But by default Azure PHP runtime doesn't enable it. you can login Kudu console site of your Azure Web App service, and direct to the default ext folder, e.g D:\Program Files (x86)\PHP\v7.0\ext. You can find all the libraries provided by Azure.
So, please delete your old configurations, and try to follow the Configure via ini settings section of How to: Enable extensions in the default PHP runtime, add the configuration in the extensions.ini:
extension=php_xsl.dll
Any further concern, please feel free to let me know.
We are migrating from a Windows SBS 2011 to Windows Server 2012 R2.
We have an internal website that connects to our Oracle database using PHP.
I am trying to migrate this to the new server and so far I have:
Installed IIS Server Role
Installed PHP
Downloaded Oracle Instant Client to C:\instantclient
Added C:\instantclient to PATH System Variable
Added php_oci8.dll to php.ini and checked that PHP is actually using this php.ini
Restarted server
I am still getting error messages like oci_ commands not being recognised etc.
I'm lost. I've searched online and the instructions match what I have done from memory.
I haven't found a single thing online that I haven't done.
Depending on the version of InstantClient you have installed you might need to include the bin folder in the path, like so:
C:\instantclient\bin
To check if the DLL files are available in the path enter where oci*.dll in a command prompt. It should return a list of matching files.
Also, remember that just because your account can see the DLL files doesn't mean IIS/PHP can. That runs under a different account that might not have permission to access the files. Check your IIS error log and PHP php_errors.log file for any specific error messages.
Edit
After a rather lengthy chat, the problem was resolved by:
Updating the InstantClient from 10.1.0.5 to 10.2.0.5 (as mentioned in the module requirements: On Windows, the php_oci8 DLL needs Oracle client libraries from version 10gR2 or greater.)
Adding a copy of msvcr71.dll to the InstantClient folder.
Downloading and manually configuring PHP from php.net instead of using PHP Manager for IIS.
Ensuring the Path environment variable correctly pointed to the InstantClient and PHP folders.
try this:
extension=php_oci8_12c.dll
(instead of php_oci8.dll) - that is what I am using and you probably downloaded the same instant client as I did.
Over the past two days, I have been scouring the web to figure out a way to enable the fileinfo extension for PHP 5.5 on Azure. I am in need of this feature in order to be able to check the type of files uploaded through a form. In my research, I have run into the following information:
First, I have found that, with PHP 5.5 (which I have running on my Azure instance), fileinfo should be enabled by default. That is the first concerning thing - as it is not.
Second, I have run into this resource. I followed the directions and created an App Settings variable entitled PHP_EXTENSIONS with a value of bin\php_fileinfo.dll. To see the structure of the website, visit the production repo here. This did not work.
In addition, I also found in the comments of the above forum that it may work if PHP_EXTENSIONS were changed to PHP_Extensions. I tried this, and still no luck. I also attempted using a backslash rather than a forward slash (as suggested in this forum) for the path to the dll, but that, too, was unhelpful.
Finally, in the event that the extension was present in Azure, but just not activated via php.ini, I used this forum to create a .user.ini to add the following line to php.ini that I assumed was likely commented out on the server:
extension=php_fileinfo.dll
Surprise! This, too, was unsuccessful.
I'm hoping there's someone out there who's had a similar problem with enabling PHP extensions in Azure that may be able to shed some light on this bleak situation. Many thanks!
Probably you are using the wrong php_fileinfo.dll. I had to download the exact same version of PHP that was running on Azure, grab the .dll, upload it and it worked.
I'm attempting to create a PHP extension/wrapper for a C library. I have followed this tutorial Extension Writing Part I very closely and have bought the book "Extending and Embedding PHP" from the same author.
I am working on a MAC and have MAMP installed.
I have downloaded and installed make-3.82, autoconf-2.69, automake-1.9 and libtool-2.4.2 without problems.
I have created a hello folder in the Applications/MAMP/bin/php/php5.4.4/lib/php/extensions folder and have created the files listed in the tutorial above exactly as instructed.
I did these three steps:
$ phpize
$ ./configure --enable-hello
$ make
Again no problem.
But when calling the php -r 'echo hello_world();' I get an 'undefined function hello_world' error.
I know that several of the steps listed above are not the recommended way to do this.
Am I in the wrong folder for extensions? The extensions folder is not the folder recommended but I couldn't find an ext folder anywhere.
Do the more current versions of these additions work the same as the old ones or do I need to go back to the earlier versions?
Is there a more current set of instructions for putting together an extension for PHP that anyone can recommend?
On further research I found that my MAMP install is missing an includes directory tree which contains the ext folder referred to in all of the current documentation. I don't know if that is simply an upgrade or not but I am going to abandon this and switch to a Linux environment for development.
EDIT:
So having fought with the same problem on Linux I discovered a file in etc/php5/apache2/conf.d called the name of the existing extension with the same extension = {extension}.so line that is also in the php.ini. When I duplicated that file with my own extension information the extensions began to function. This file was not anything I saw referred to in any of the documentation I reviewed. I do not know if there is a corresponding file in the MAMP environment that was also causing the issues there.
I am using an open source library ( http://hybridauth.sourceforge.net ) that does not support the PECL OAuth extension of PHP. If you try to run code with it, it says "Exception: Hybridauth Library not compatible with installed PECL OAuth extension. Please disable it."
Easier said than done.
I am hosting my site via Amazon AWS Elastic Beanstalk ( https://aws.amazon.com/elasticbeanstalk/ ). I chose this solution because it allows you to get started quickly with no configuration, no SSH, no custom AMI, ...
Which means I can't easily modify the original php.ini file or delete the extension file.
Is there an easier way? Disabling an extension on the fly? Via a php method? Via an htaccess file? A trick?
No, you cannot disable extensions via PHP method call. In the past you could add it (with dl()), but even then, you was not able to remove any added without playing with ini file.
The short version: No, not in any practical sense.
If you have runkit available you should be able to remove the functions or objects that the module defines, but it really depends on why HybridAuth have trouble working when the PECL OAuth extension is installed. This is not suggested for anything close to a production environment.
You can ssh into your instance very easily if you have your pem key. Just go to the ec2 console, select your instance and click "connect" in the toolbar to get the address. Then you can modify any of the files on the server.