Switching to remi breaks mvc/yii app on a Centos7 server
I switched over to remi 5.6 from Centos php 5.4 on a centos7 server. Everything worked perfectly before the change over so it would not seem to make sense that there is a code error. I got everything working but an mvc/yii app which is having trouble.
I believe I fixed this once on another server simply by adding a missing package. However, which, I cannot recall at this point.
If memory serves, it was related to the php-mysql package which I replaced with php-mysqlnd since the php-mysql package is deprecated with 5.6.
I believe I fixed this once on another server simply by adding a missing package. However, which, I cannot recall at this point.
If memory serves, it was related to the php-mysql package which I replaced with php-mysqlnd since the php-mysql package is deprecated with 5.6.
PDOException: SQLSTATE[HY000]
General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. (uncaught exception) at /var/www/vhosts/myapp/client_php/src/Service/ClientService.php line 51 {"exception":"[object]
PDOException(code: HY000): SQLSTATE[HY000]
General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. at
/var/www/vhosts/myapp/client_php/src/Service/ClientService.php:51)"} []
# yum list installed | grep "remi"
gd-last.x86_64 2.2.3-1.el7.remi @remi
libzip-last.x86_64 1.1.3-1.el7.remi @remi
memcached.x86_64 1.4.29-1.el7.remi @remi
php.x86_64 5.6.24-1.el7.remi @remi-php56
php-bcmath.x86_64 5.6.24-1.el7.remi @remi-php56
php-cli.x86_64 5.6.24-1.el7.remi @remi-php56
php-common.x86_64 5.6.24-1.el7.remi @remi-php56
php-devel.x86_64 5.6.24-1.el7.remi @remi-php56
php-gd.x86_64 5.6.24-1.el7.remi @remi-php56
php-gmp.x86_64 5.6.24-1.el7.remi @remi-php56
php-intl.x86_64 5.6.24-1.el7.remi @remi-php56
php-mbstring.x86_64 5.6.24-1.el7.remi @remi-php56
php-mysqlnd.x86_64 5.6.24-1.el7.remi @remi-php56
php-opcache.x86_64 5.6.24-1.el7.remi @remi-php56
php-pdo.x86_64 5.6.24-1.el7.remi @remi-php56
php-pear.noarch 1:1.10.1-5.el7.remi @remi
php-pecl-apcu.x86_64 4.0.11-2.el7.remi.5.6 @remi-php56
php-pecl-jsonc.x86_64 1.3.10-1.el7.remi.5.6 @remi-php56
php-pecl-jsonc-devel.x86_64 1.3.10-1.el7.remi.5.6 @remi-php56
php-pecl-memcache.x86_64 3.0.8-4.el7.remi.5.6 @remi-php56
php-pecl-zip.x86_64 1.13.4-1.el7.remi.5.6 @remi-php56
php-php-gettext.noarch 1.0.11-12.el7.remi @remi
php-phpseclib.noarch 2.0.2-1.el7.remi @remi
php-process.x86_64 5.6.24-1.el7.remi @remi-php56
php-recode.x86_64 5.6.24-1.el7.remi @remi-php56
php-symfony-class-loader.noarch 2.8.8-1.el7.remi @remi
php-symfony-common.noarch 2.8.8-1.el7.remi @remi
php-tcpdf.noarch 6.2.12-1.el7.remi @remi
php-tcpdf-dejavu-sans-fonts.noarch 6.2.12-1.el7.remi @remi
php-tidy.x86_64 5.6.24-1.el7.remi @remi-php56
php-xml.x86_64 5.6.24-1.el7.remi @remi-php56
remi-release.noarch 7.2-1.el7.remi @remi
REMI is known to break stuff. That is well documented on REMI and CentOS websites.
The fix is to revert back to working CentOS PHP and experiment with SCL PHP
The fix is to revert back to working CentOS PHP and experiment with SCL PHP
I've held back going to remi to get 5.6 for a long time but now need to because of the security changes in 5.6 so going back isn't really an option otherwise would never have even bothered with this :).
Also, I fixed this before so what ever the issue was, it wasn't all that big but I don't seem to have kept notes on what it was or how to fix it.
I'm not sure what you mean by this is well known. What is? That REMI breaks stuff or that 'what ever you're telling me the error is known as' is well documented somewhere? How well known could it be, I've been trying to find out more about it for hours but mainly am finding programming posts.
This 'PDO::MYSQL_ATTR_USE_BUFFE
BTW, the mvc/yii app is using composer which I suspect is where the problem is related to if memory serves. Last time, I seem to recall having to rebuild the modules or re-install or configure them, something along those lines.
php composer.phar install --prefer-dist -o --no-dev
This won't run because it cannot find composer.phar
Also, I fixed this before so what ever the issue was, it wasn't all that big but I don't seem to have kept notes on what it was or how to fix it.
I'm not sure what you mean by this is well known. What is? That REMI breaks stuff or that 'what ever you're telling me the error is known as' is well documented somewhere? How well known could it be, I've been trying to find out more about it for hours but mainly am finding programming posts.
This 'PDO::MYSQL_ATTR_USE_BUFFE
BTW, the mvc/yii app is using composer which I suspect is where the problem is related to if memory serves. Last time, I seem to recall having to rebuild the modules or re-install or configure them, something along those lines.
php composer.phar install --prefer-dist -o --no-dev
This won't run because it cannot find composer.phar
I gave up and went back to Centos 5.4. It's not worth the headaches. I'll build another server to test this in the near future.
Good luck...
Start with migrating to php-fpm, that way the replacement can be tested on same machine.
Start with migrating to php-fpm, that way the replacement can be tested on same machine.
What ever the reasons are, I don't have time to look for them on a live server. This will have to be done on a dev server.
Take your time, make a new template.
You can have different FPM-s with different PHP versions on your server. https://www.softwarecollections.org/en/scls/?search=php
You can have different FPM-s with different PHP versions on your server. https://www.softwarecollections.org/en/scls/?search=php
Premium Content
You need an Expert Office subscription to comment.Start Free Trial