For PHP 5.3+, use the default mysqlnd driver, rather than the older libmysql

[IT_Architect]

I developed some code that ran perfectly on the development machine with a default installation of PHP 5.3. Oddly, it didn't run on a DA machine that I had recently upgraded from PHP 5.2 to 5.3. I discovered that DA installs libmysql, rather than the new, and default for 5.3+, mysqlnd. (MySQL Native Driver) I'm proposing that mysqlnd be the new default driver for the following reasons:

1. All current PHP development efforts have been in coordination with the mysqlnd driver. libmysql has a license problem. The MySQL-provided library is released under the GPL. The PHP license is not compatible with the GPL, so distributing PHP binaries compiled against GPL code is BIG problem. That's a problem for more than just PHP. It turns libmysql's future into a dead end road.

2. Unlike libmysql, mysqlnd runs under the control of the Zend Engine. There are a thousand tricks the PHP developers can play because of that.

3. One of the new features added in 5.3 is asynchronous queries. This is HUGE! This is where I ran into trouble with the DA configuration. After much hair pulling, traced it down to DA using the older libmysql.

4. Other features that 5.3 + mysqlnd adds is persistent connections under mysqli, read-only variables so it can assign pointers instead of copying buffers, etc.

5. As PHP versions increment, and add features, the expectation on the part of developers will be that those features work. That is already a problem for libmysql, and will grow with each release.

Summary: There may be valid reasons why DA is not using the default mysqlnd. I'd ask if those reasons trump the advantages of using it. Before I post a simple "How To" to switch to mysqlnd, I wanted to see if DA has any plans to change to mysqlnd soon, in which case "How To" visitors would be better served if I didn't post it, and I would be happy to delete this thread as well if the change to msqlnd is imminent.

Thanks!

 

[Richard G]

I understand your request.
But I presume that libmysql is used by DA for backwards compatibility.
Does php 5.2 also run with mysqlnd and also the custom self made scripts which run under php 5.2?
Because DA has to take care of the fact that with minor version updates, all supported systems can keep on running without problem or with minimal adjustmens. I already complement them the way they know to do this.

So I'm curious for the answer of the questions you make, but also for the answer to the arguments I put up here.
I already had soms issues with php 5.3 because open_short_tag is default set to off in the php.ini of version 5.3, which was on in the 5.2 if i'm not mistaken. And this is only a setting, not even a driver.

 

[IT_Architect]

I understand your request.
But I presume that libmysql is used by DA for backwards compatibility.
Does php 5.2 also run with mysqlnd and also the custom self made scripts which run under php 5.2?

I can't think of any.

Because DA has to take care of the fact that with minor version updates, all supported systems can keep on running without problem or with minimal adjustmens.

5.3 is a huge change. I'd say a bigger change than PHP 4 to PHP 5. PHP 5.3 is 6.0 without the Unicode. PHP 6 was released to developers in the spring of 2006, and was to be released that fall. This year they are trying to come up with a Unicode strategy, and have no estimated release date. In the mean time, developers started making their plans to leave PHP because the language was untenable both from a security and maintainability standpoint. Thus we have 5.3. The short-tag was a problem they had parsing XML. The default may again go back to on. 5.4 is another big change. When you look at the changes, it looks small, and mostly removing items that were deprecated in 5.3. Like the old saying goes, "The devil is in the details." It is a major cleanup of the language, and sure to break a lot of code. It changes what existing functions return, and what constitutes and error. If your code runs in 5.4, it's clean code. To make the same code run in 5.4 and <5.4, is going to require a careful strategy because one breaks the other if you don't write code to handle the differences. It's going to be misery at least until 5.4 gains critical mass, and expensive for everyone.

I already complement them the way they know to do this.

No question they have a tough job. If they didn't have to scratch a line of code, and just make the right choices, it would consume a ton of time. Would you really want them to give you something that turned off deprecated function errors, when those functions would be completely gone in the next release, or would you like to know about it now? My point is, both preserving old methods with new versions, or rolling out new methods can cause problems. With 5.2, it wouldn't make sense to use this driver. With 5.3, I'm not aware of an instance where this driver would actually break anything, and not having it breaks 5.3 now. If nobody else has run into a situation where it breaks anything, that's valuable feedback for DA.

 

[smtalk]

I can't think of any.

One of them could be short passwords used by EOL versions of MySQL, but it's a minor issue.

It is a planned feature for CustomBuild 2.0, because it has separate configuration files for PHP 5.2, 5.3 and 5.4 (that's the main reason). If we decide to include it to CustomBuild 1.1/1.2 we will let you know (for that we would need to replace a few lines of configuration.php5 (--with-mysql and --with-mysqli) without letting users know that, and I think it is not a very good practice, or to include an option for mysqlnd (which may be dropped in 2.0)).

 

[Richard G]

5.3 is a huge change. I'd say a bigger change than PHP 4 to PHP 5.

I don't agree. Maybe for developpers, but I've had a look at the differences between php 5.2 and 5.3 and that was not all too much.
I can have a Zen cart installation run on php 4, but it will not run on php 5. But when it runs on php 5.2 it will also run on php 5.3. So in my eyes, 5.2 to 5.3 is a minor change comparing php 4 to 5. But like I say... I don't look at it with developer eyes but with the eyes from an admin and a user.

The short-tag was a problem they had parsing XML.

Yes well... that's a developpers problem imho because the short tag is used for so many years, they could have taken that in consideration when designing xml or whatever can conflict with it now.
We had to put this back on in 5.3 because there are way too many scripts which still use the short tags including numerous plugins and addons for popular cms'ses like Joomla and Wordpress.
Php has to declare some deprecated states for a certain data, so developpers finally stop using the short tag then.

I can't think of any.

I don't quite understand the answer. I asked this:

Does php 5.2 also run with mysqlnd and also the custom self made scripts which run under php 5.2?

So if you say you can't think of any, then this means that there are no self made scripts which run under php 5.2 can run with the mysqlnd driver. So if you are going to use mysqlnd you are obligated to use php 5.3.
That's what your answer says.
If so mysqlnd can't be used as a default driver yet, because custombuild still supports php 5.2 and is even installed by default. Also a lot of servers still have php 5.2 running (in spite of the fact that they should upgrade).

Don't misundertand me. I really appreciate the feedback you give to DA and the great idea's you put in your postings.
It's just that partly, DA also has to keep in mind that there are a lot of people having the old stuff running.

But if it can be made a choice (like when you choose in options.conf to run php5.3 to also rund the mysqlnd driver) that would be great.
Or maybe for custombuild 2.0 because I guess there must be a time that php 5.2 is not supported anymore by DA, mainly because it's declared end of life more then a year ago (december 2010 if i'm not mistaken).

So I'm just putting op some comments and some thoughts to put into consideration. I'm in now way interested to break of your idea's or suggestions, because they are very good. And I like them a lot!

 

[IT_Architect]

when designing xml or whatever can conflict with it now.

They didn't design XML of course, but they did have problems handling it in their compiler. The only reason you have the short-tags as an option is they thought they could handle them now, but weren't totally sure they had the parsing problem licked. They've also said that they think they do now, and that problem may go away. LOL!

I don't look at it with developer eyes but with the eyes from an admin and a user.

The only reason things went as well as they did, is they've been talking about the changes for 6 since 2005 and PHP 6 has been "imminent" for 6 years. LOL! The changes between 5.3 and 5.4 they either didn't mention much or they just didn't get my attention. The IONCube guy that posted here said it caught them by surprise. I'm glad to see the changes, but dread the work involved. After 5.4 it will have evolved into a much better language from where it started. Their OOP is still pretty weak, but beats the stars out of nothing, and they can evolve that without breaking code.

because it has separate configuration files for PHP 5.2, 5.3 and 5.

I didn't know that until now. Then I hope 2.0 is close to ready. My guess is that will make handling the different versions of Apache 2.x better as well.

 

[smtalk]

I didn't know that until now. Then I hope 2.0 is close to ready. My guess is that will make handling the different versions of Apache 2.x better as well.

We decided to support Apache 2.4 only in CustomBuild 2.0 (and Apache 1.3 is dropped completely). EOL versions of PHP and MySQL are not supported anymore too. We will probably do some clean-up for some other EOL products like uebimiau/atmail webmails etc. Yes, everything is almost ready, except the apache+virtualhosts configuration for php-fpm, when we finish php-fpm testing, CB 2.0 will be ready for testing. DA 1.41 release takes most of the DirectAdmin's time now and I think that that CB 2.0 final should be ready this summer.

 

[IT_Architect]

We decided to support Apache 2.4 only in CustomBuild 2.0

That's probably wise. These HUGE dot releases they've been laying on us, like php 5.3, 5.4, and now Apache 2.4, have made it impossible to have one set of configs for each whole number release.

I think that that CB 2.0 final should be ready this summer.

Sounds good

Thanks tons for your feedback!

 

[Richard G]

Maybe a little bit off-topic:

We decided to support Apache 2.4 only in CustomBuild 2.0

What is this doing in todays custombuilds 1.2 options.conf then?

#Possible values - 1.3, 2.0, 2.2 or 2.4
apache_ver=2.2

It would be better to set the possible values back to 1.3, 2.0 or 2.2 if 2.4 is not supported in custombuild 1.2, correct?

 

[DirectAdmin Support]

I believe it happens to work with CB 1.1/1.2, but the focus of our testing for Apache 2.4 is with CB 2.0.
If issues arise from Apache 2.4 in CB 1.1/1.2, we may recommend moving to 2.0 (once it's more tested of course)
Some admins can't wait for CB 2.0, and want 2.4 now, so we made it possible to enable in 1.1/1.2, with the noted risk that 2.4 has no testing under 1.1/1.2. (although, the differences are not huge anyway, likely why we're not getting many reports of issues)

John