I am getting ready to upgrade a Debian server from PHP 5.6 to 7.0 via the dotdeb repositories. The Dotdeb repos do not have the (old) Memcache package, but they do have the (new) Memcached package. A third-party module I use relies on Memcache. Looking at the APIs, it appears that Memcached library should be fully backward compatible with Memcache, so that I can just do this:
if (!class_exists('Memcache') && class_exists('Memcached')) {
class Memcache extends Memcached
{
}
}
In testing it seems to work. The comments on the memcached documentation mention at least one gotcha, but since I am not looking to run them both at the same time, this one is not a problem.
However, I can't find anything else that talks about compatability. Is this a safe way to ensure backwards compatability between Memcached and Memcache or do I need a more sophisiticated adapter?
I'm not sure what has been going on with the PECL Memcache project, but the base Github project was updated to support PHP7, and yet remains unreleased in any official capacity (I need this as well so I've been keeping tabs on it).
A few weeks ago the Remi repo (CentOS/Fedora) published a PECL package based on these updates and it appears to be stable. If you are in need of this I would suggest you pull the Github repo and build the PECL extension. Without an official release it's the only thing I can suggest to you. This way you don't have to hack the older class to work with your existing code.
https://github.com/websupport-sk/pecl-memcache (unofficial)
https://github.com/php/pecl-caching-memcache (offical)
To answer my own question, no the two are not compatible. For anybody who may run into this issue, I wrote a small shim that replicates parts of the Memcache API and passes it through to Memcached. It is available for download on SourceForge.
Related
Previously, I used package managers (i.e. YUM) to install and configure PHP. However, I would like to upgrade to PHP 7 and the package manager(s) available do not yet have PHP 7 available natively.
The plan is to use Chef to compile PHP on the server (during Setup) from original source. With that said, this process can take ~15 minutes on our server and will severely impact boot time.
Are there any techniques for increasing the speed at which the PHP
is compiled?
Can I create a tarball of final binaries and simply
download these to my servers?
There are some online resources that suggest adding the "webtatic" repo to YUM to access PHP 7. Is this safe/secure + reliable?
I am looking for freedom to upgrade my PHP version independent of when the package manager supports the version I am interested in
We ended up waiting for Ubuntu 16.04 which brings in PHP 7 via apt-get. Compiling PHP from scratch didn't turn out to be an efficient nor maintainable process
I am running a web server with Debian and I'm hosting a ZF1 project.
The PHP process crashes from time to time without any reason, so my hosting provider suggests that I should switch from APC to APCu caching. I'm not very familiar with PHP caching and I can't really find any documentation on the topic, but I read a few similar questions here.
As far as I understand the APCu caches only user data (whatever that means) and it's not the full features of the APC. Considering this, my question is will APCu increase the load of the server and will the PHP extension work out of the box without touching the ZF1 code?
http://zend-framework-community.634137.n4.nabble.com/Does-ZF-1-12-support-PHP-5-5-td4661902.html
You should upgrade to the latest PHP on a test environment, if it works well (most likely scenario), you can switch. PHP 5.5 has built-in opcode cache (http://php.net/manual/en/intro.opcache.php), so you won't lose performance. Very little difference can be between the performance of APCu and APC.
Also, function names are not identical (apcu_fetch for instance), so you have to modify the code to reflect this.
Laravel works fine local, but on the server I get the following:
Laravel requires the Mcrypt PHP extension.
However I can't install mcrypt on my server because i have no admin rights. The process for installing the module at the server in my corporation would be to painful, it would be better to just go with another framework instead. But Laravel seems so modern and beautiful that I can't let it go without asking this question: Is it somehow possible to run Laravel without php-mcrypt?
No, Laravel really requires the MCrypt Extension.
You could, however, ask your hosting provider to install the MCrypt extension.
If you decide not to use Laravel, instead take a look at Symfony.
Symfony is another very powerful framework and Laravel makes use of quite some of Symfony's features.
Link: http://symfony.com/
Symfony doesn't require this plugin to be installed, however it requires the following plugins (but I assume those are installed at every hosting provider):
PHP >= 5.3.3
JSON enabled
ctype needs to be installed
The php.ini needs the date.timezone setting
I hope I helped you further :)
EDIT: Newer versions of Laravel don't need to have Mcrypt!
Yes, the Laravel composer.json file states that your application requires ext-mcrypt which can be faked by installing another package which states that it provides ext-mcrypt.
One you've gotten past the composer install, by default Laravel will still try to call mcrypt functions for encryption. But this can be prevented by creating your own encryption service provider that not require crypt.
I've created the package https://github.com/thomaswelton/laravel-mcrypt-faker.
You can use this to disable encryption for Laravel, or by using openssl encryption that you may already have available.
Note that disabling encryption is not at all advised for production applications. But the package may be useful when you just want to play around with Laravel without installing the mcrypt extension, or where you have the openssl extension available.
Installing dependencies on the wrong environment is now possible
The new --ignore-platform-reqs flag for the install and update commands lets you install dependencies even if you have the wrong php version or are missing one of the required php extensions. It's not really recommended but it can be useful sometimes if you want to run composer outside a VM for example and you only have the right extensions installed in the VM where you run the code.
After compiling PHP from source are the devel libraries still needed?
For example, I am building a newer version of PHP from source than is on our dev servers. I installed alot of [extension i.e. mysql, postgresql, curl, etc]-devel packages in order for the configure from the dev server setup to work. Do i still need these after php has compiled? For example could I make a distro and then distribute the PHP distro to another server without needing these devel dependencies?
I am a bit of a noob to this.
You don't need to ship the devel-libraries.
But my advice is to take some time and learn how the build system of your linux distribution works. And then build a new php package that can be installed by the package manager.
Take a look at how the "original" php packages were built for the distribution. Most likely you can simply copy and edit the existing rule file(s) and then make a new version of that package. This way you take advantage of the dependency mechanisms and the package manager will not remove/overwrite your version so easily when an update shows up in the "official" repositories.
What is the simplest way to install memcached on CentOS for someone new to the world of Linux? What is the best way to enable it for Apache and PHP
Unless Apache and PHP have some option to utilize memcached for internal workings (of which I am unaware of), you typically don't "enable" it for such apps. Instead, you would get a client library to use memcached from within your application, then start up memcached on whatever servers you want to provide memory with, then just use the client library API to store and retrieve cached data across multiple servers.
The easiest way is to find a reilable source of the RPM's needed to install memcached and memcached for PHP. There is a blog post which addresses this concern:
http://blog.gahooa.com/2009/02/08/update-on-fedora-vs-redhat-enterprise-linux/
We have been using EPEL (Extra Packages for Enterprise Linux) for exactly that on RedHat Enterprise 5.3. I believe it is a stated goal of EPEL to support Centos.
http://fedoraproject.org/wiki/EPEL
Essentially, it is a YUM repository which contains lots of extra packages from Fedora that were compiled for RHEL. Super easy to use.