We’ve installed the couchbase sdk, and couchbase appears in the PHP info screen. But, when we try to instantiate a new cluster, it doesn’t work. And
if(!class_exists('CouchbaseCluster')){
echo "Couchbase extension is not loaded for php";
exit;
}
exits with the error message.
There are no errors, either on startup or run (even though both sets are enabled and producing non-couchbase errors when appropriate).
Can someone provide any guidance?
Thank you,
Rob
Does it work with \CouchbaseCluster or \Couchbase\Cluster instead? Is it your full test script?
Also I’ve noticed your version is 2.3.3snapshot. Any specific reason to use snapshot/master version?
Also, could you check it in CLI mode. You said it exits with error message, could you also paste it here?
Note that often PHP setups use different INI files for different SAPIs. So if you load extension in apache, it might be not loaded in CLI.
Avsej,
I get the same message when running from CLI.
The ‘error message’ I’m referring to is what you see, nothing ‘official’ from PHP or Apache.
It works with \Couchbase\Cluster. Now, can you provide some insight as to why it would and what I might need to do in my code?
Thank you,
Rob
CouchbaseCluster is an alias to \Couchbase\Cluster. It should work in any form. I guess there is something in your environment, which breaks it. Is it your full php script? Could you show how you invoke it? What PHP version do you use?
<?php
echo "CouchbaseCluster: " . class_exists('CouchbaseCluster') . "\n";
echo "\CouchbaseCluster: " . class_exists('\CouchbaseCluster') . "\n";
echo "\Couchbase\Cluster: " . class_exists('\Couchbase\Cluster') . "\n";
This example outputs the following with PHP 7.1.3 on my machine:
CouchbaseCluster: 1
\CouchbaseCluster: 1
\Couchbase\Cluster: 1We’re on php 5.4.16 running on CentOS 7 with Apache 2.4.8.
The output of your example is:
igbinary serializer is not found
CouchbaseCluster:
\CouchbaseCluster:
\Couchbase\Cluster: 1
We aren’t able to get to php 5.6 or 7 due to corporate security restrictions.
Are there other aliases we should be concerned with, or will that be the only one?
Thank you,
Rob
You can find list of aliases here
But also we run the special tests for aliases on all supported versions of interpreter to make sure they are reachable
I opened a ticket PCBC-488 to track this.
Could you also post here output of php -i | head so that fields including Configure Command will be visible. For example:
$ php -i | head
phpinfo()
PHP Version => 7.1.3
System => FreeBSD earth.local 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Build Date => May 1 2017 08:58:42
Configure Command => './configure' '--with-layout=GNU' '--localstatedir=/var' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--enable-mysqlnd' '--with-libxml-dir=/usr/local' '--with-pcre-regex=/usr/local' '--program-prefix=' '--enable-fpm' '--with-fpm-user=www' '--with-fpm-group=www' '--enable-phpdbg' '--enable-phpdbg-debug' '--enable-debug' '--enable-maintainer-zts' '--enable-dtrace' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd11.0' 'build_alias=amd64-portbld-freebsd11.0' 'CFLAGS=-pipe -fno-omit-frame-pointer -g -fstack-protector -fno-strict-aliasing' 'CPPFLAGS=' 'CPP=cpp'
Server API => Command Line Interface
Virtual Directory Support => enabled
Configuration File (php.ini) Path => /usr/local/etc
Loaded Configuration File => /usr/local/etc/php.iniAvsej,
Thank you again for your help.
Here’s the output:
php -i | head
[cb,WARN] (pcbc/ext L:414) igbinary serializer is not found
phpinfo()
PHP Version => 5.4.16
System => Linux atl-fe01.corp.int-xxxxxxxx.com 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64
Build Date => Nov 6 2016 00:28:47
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
This is a clean and very recent installation of php via yum from Centos base.
If it’ll help, we also have the following add-ons:
yum list installed php*
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: centos.mirrors.tds.net
* epel: archive.linux.duke.edu
* extras: bay.uchicago.edu
* updates: centos.eecs.wsu.edu
Installed Packages
php.x86_64 5.4.16-42.el7 @base
php-bcmath.x86_64 5.4.16-42.el7 @base
php-cli.x86_64 5.4.16-42.el7 @base
php-common.x86_64 5.4.16-42.el7 @base
php-dba.x86_64 5.4.16-42.el7 @base
php-devel.x86_64 5.4.16-42.el7 @base
php-ldap.x86_64 5.4.16-42.el7 @base
php-mbstring.x86_64 5.4.16-42.el7 @base
php-mssql.x86_64 5.4.16-7.el7 @epel
php-pdo.x86_64 5.4.16-42.el7 @base
php-pear.noarch 1:1.9.4-21.el7 @base
php-pear-Auth-SASL.noarch 1.0.6-5.el7 @epel
php-pear-Mail.noarch 1.3.0-1.el7 @epel
php-pear-Net-SMTP.noarch 1.7.3-1.el7 @epel
php-pear-Net-Socket.noarch 1.0.14-1.el7 @epel
php-pgsql.x86_64 5.4.16-42.el7 @base
php-process.x86_64 5.4.16-42.el7 @base
php-soap.x86_64 5.4.16-42.el7 @base
php-xml.x86_64 5.4.16-42.el7 @base
Thank you!
Rob
Thank you I’ve managed to reproduce it. I will fix it till the next release. Meanwhile, you’ll better convert applcation to use namespaced classes, as top-level aliases will be deprecated in next major release anyway.