I had a little trouble installing the latest svn but did finally get it working. Turned out I didn't have pdo_mysql enabled in php. So I had to recompile php with it enabled.
While googling I noticed that it seems not to be that unusual an occurrence to not have it enabled even when running the latest version of php. In particular servers using the directadmin control panel don't have this enabled by default. Looks like the same thing with at least some versions of the cpanel control panel.
Devs might want to consider a test script for future releases to check compatibility. Even something simple with a custom phpinfo() might save some headaches for upgraders and new users. Recompiling php is non-trivial for the average user and in most cases will probably involve a tech support request, so better to find out before installing/upgrading.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stew
Are we really talking recompiling or simply a change in php.ini to activate the feature? I'm shocked that anyone today would go through the trouble of compiling a modern PHP configuration without PDO support for MySQL. I don't see that anywhere.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MySQL is no longer enabled by default in PHP, this allows those of us who do not use to enable our preferred database instead. sqllite is still included as that is the preferred default.
That said, most linux distributions have the packages for each database available and they just need loading. In windows it is just a matter of selecting the correct extensions in php.ini. The linux distributions all do their own thing on how the php.ini file is updated for extensions but all the one's I've played with do not need you to recompile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes a recompile was needed. pdo_mysql wasn't built in to php but deactivated in the .ini file or anything like that. It isn't a big job to do it but the average PGV user will most likely not have the ability OR the root access needed to do it.
Most servers with control panels built in use a script to compile apache and php and mysql at installation. If it isn't in the script (or isn't set as a default) it doesn't get included when PHP is first compiled. PDO is actually only starting to replace pear::db in a lot of applications. Remember that control panels are well behind the bleeding edge, and are in fact fairly conservative in what they include by default.
So a quick config check script would probably be a useful addition and help weed out help requests before they happen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<For the "average" linux distro, you simply need to type something like this:
apt-get install mysql apache2 php5 phpmyadmin
Easier to get right than get wrong.... >>
That's assuming you have root access :) Average PGV users surely do not have root access. Most have some sort of control panel access only. When you install a control panel to a server you install it BEFORE apache/mysql/php . And then you run a script provided with the control panel and IT installs the amp stack and configures it. If it isn't in the script it doesn't get installed. It's done that way for exactly the reasons you suggest <<If a webhost is providing both PHP and MySQL, it is pretty certain that they will have configured them to work together.>> It makes sure that the installed versions will also work with the control panel.
Just google for php and pdo_mysql and you will find quite a few hits from support forums for various hosting companies.
If you don't think it's worthwhile to have a script to check the config it's fine with me. Just a suggestion :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<If you don't think it's worthwhile to have a script to check the config it's fine with me.>>
I didn't say it wasn't worthwhile. It all depends on the number of people affected.
If it affects 3 people, and each takes 30 minutes to help on a one-to-one basis, then it is more efficient to do that than spend a weekend writing a bullet-proof configuration/upgrade checker....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<If it affects 3 people, and each takes 30 minutes to help on a one-to-one basis, then it is more efficient to do that than spend a weekend writing a bullet-proof configuration/upgrade checker.... >>
There will likely be more than 3 people when the full release is made since there have already been 2 or 3 posts about it from svn users.
Regardless of numbers, I have added a script to the patches tracker. I would hardly call it bulletproof but those who want or need to can use it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<The linux distributions all do their own thing on how the php.ini file is updated for extensions but all the one's I've played with do not need you to recompile. >>
Pdo-mysql isn't controlled by a switch in php.ini like zlib. On windows you just uncomment one of the xxx.dll lines because that's the way windows works. It may not be necessary to re-compile on a normal linux distro, haven't tried it so I don't know for sure. Maybe you can just download a package and edit a config somewhere. BUT...
Servers with control panels do not use apt or rpm to install php in the first place. You run a script, select versions of php, mysql and apache and some parameters for each and the script takes care of downloading sources and compiling and configuring things. If you want to upgrade certain parts you can do so, but you are still limited by the script. Updating PHP with pdo-mysql support took 4 or 5 minutes, so it isn't a huge task. But well beyond what the average user can do because they just don't have root access.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Certainly in all the distributions I've been running there is no need to compile anything, and extensions can be switched on and off as required. You can switch an extension to a test version without changing anything else. This uses .so files in the same way that windows uses .dll, but the Linux distributions (Denbian, SUSE, Mandriva, Ubuntu + others) and ini files for each extension which get scanned as Apache loads PHP. I'm on Mandriva while writing this, and they are located in the directory /etc/php.d/ - SUSE/Ubuntu - /etc/php5/conf.d
Some installations tidy things up by moving the extensions configuration data from php.ini into the extension .ini file and this is another improvement on maintainability.
Much of this is also in parallel with the configuration of Apache itself, which is handled in much the same way, so you can configure complex sites simply by simply enabling and modifying the correct ini files.
Some of the argument for restoring MySQL *IN* PHP was based on the misunderstanding that one has to recompile it in order to enable things, but that is simply the wrong way to manage an installation. It would be useful to know if you are using a distribution that does not use libraries just for reference. I know that some distributions are DESIGNED to work that way, but even those can add extensions via the ini file route. Package driven management will certainly be adding the files and updating the configuration rather than installing a full compilation system on the machine. THAT should only be implemented when one of the development packages is loaded.
One important note here ... PGV could be built as a package and supplied to the repositories, but a number of other web projects have decided that MySQL or Postgres should be a 'required' and for those of us who don't use either it becomes a nightmare.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a little trouble installing the latest svn but did finally get it working. Turned out I didn't have pdo_mysql enabled in php. So I had to recompile php with it enabled.
While googling I noticed that it seems not to be that unusual an occurrence to not have it enabled even when running the latest version of php. In particular servers using the directadmin control panel don't have this enabled by default. Looks like the same thing with at least some versions of the cpanel control panel.
Devs might want to consider a test script for future releases to check compatibility. Even something simple with a custom phpinfo() might save some headaches for upgraders and new users. Recompiling php is non-trivial for the average user and in most cases will probably involve a tech support request, so better to find out before installing/upgrading.
Regards
Stew
Are we really talking recompiling or simply a change in php.ini to activate the feature? I'm shocked that anyone today would go through the trouble of compiling a modern PHP configuration without PDO support for MySQL. I don't see that anywhere.
Stephen
MySQL is no longer enabled by default in PHP, this allows those of us who do not use to enable our preferred database instead. sqllite is still included as that is the preferred default.
That said, most linux distributions have the packages for each database available and they just need loading. In windows it is just a matter of selecting the correct extensions in php.ini. The linux distributions all do their own thing on how the php.ini file is updated for extensions but all the one's I've played with do not need you to recompile.
Yes a recompile was needed. pdo_mysql wasn't built in to php but deactivated in the .ini file or anything like that. It isn't a big job to do it but the average PGV user will most likely not have the ability OR the root access needed to do it.
Most servers with control panels built in use a script to compile apache and php and mysql at installation. If it isn't in the script (or isn't set as a default) it doesn't get included when PHP is first compiled. PDO is actually only starting to replace pear::db in a lot of applications. Remember that control panels are well behind the bleeding edge, and are in fact fairly conservative in what they include by default.
So a quick config check script would probably be a useful addition and help weed out help requests before they happen.
If a webhost is providing both PHP and MySQL, it is pretty certain that they will have configured them to work together.
<<Recompiling php is non-trivial for the average user>>
For the "average" linux distro, you simply need to type something like this:
apt-get install mysql apache2 php5 phpmyadmin
Easier to get right than get wrong....
<<For the "average" linux distro, you simply need to type something like this:
apt-get install mysql apache2 php5 phpmyadmin
Easier to get right than get wrong.... >>
That's assuming you have root access :) Average PGV users surely do not have root access. Most have some sort of control panel access only. When you install a control panel to a server you install it BEFORE apache/mysql/php . And then you run a script provided with the control panel and IT installs the amp stack and configures it. If it isn't in the script it doesn't get installed. It's done that way for exactly the reasons you suggest <<If a webhost is providing both PHP and MySQL, it is pretty certain that they will have configured them to work together.>> It makes sure that the installed versions will also work with the control panel.
Just google for php and pdo_mysql and you will find quite a few hits from support forums for various hosting companies.
If you don't think it's worthwhile to have a script to check the config it's fine with me. Just a suggestion :)
<<If you don't think it's worthwhile to have a script to check the config it's fine with me.>>
I didn't say it wasn't worthwhile. It all depends on the number of people affected.
If it affects 3 people, and each takes 30 minutes to help on a one-to-one basis, then it is more efficient to do that than spend a weekend writing a bullet-proof configuration/upgrade checker....
<<If it affects 3 people, and each takes 30 minutes to help on a one-to-one basis, then it is more efficient to do that than spend a weekend writing a bullet-proof configuration/upgrade checker.... >>
There will likely be more than 3 people when the full release is made since there have already been 2 or 3 posts about it from svn users.
Regardless of numbers, I have added a script to the patches tracker. I would hardly call it bulletproof but those who want or need to can use it.
<<The linux distributions all do their own thing on how the php.ini file is updated for extensions but all the one's I've played with do not need you to recompile. >>
Pdo-mysql isn't controlled by a switch in php.ini like zlib. On windows you just uncomment one of the xxx.dll lines because that's the way windows works. It may not be necessary to re-compile on a normal linux distro, haven't tried it so I don't know for sure. Maybe you can just download a package and edit a config somewhere. BUT...
Servers with control panels do not use apt or rpm to install php in the first place. You run a script, select versions of php, mysql and apache and some parameters for each and the script takes care of downloading sources and compiling and configuring things. If you want to upgrade certain parts you can do so, but you are still limited by the script. Updating PHP with pdo-mysql support took 4 or 5 minutes, so it isn't a huge task. But well beyond what the average user can do because they just don't have root access.
Certainly in all the distributions I've been running there is no need to compile anything, and extensions can be switched on and off as required. You can switch an extension to a test version without changing anything else. This uses .so files in the same way that windows uses .dll, but the Linux distributions (Denbian, SUSE, Mandriva, Ubuntu + others) and ini files for each extension which get scanned as Apache loads PHP. I'm on Mandriva while writing this, and they are located in the directory /etc/php.d/ - SUSE/Ubuntu - /etc/php5/conf.d
Some installations tidy things up by moving the extensions configuration data from php.ini into the extension .ini file and this is another improvement on maintainability.
Much of this is also in parallel with the configuration of Apache itself, which is handled in much the same way, so you can configure complex sites simply by simply enabling and modifying the correct ini files.
Some of the argument for restoring MySQL *IN* PHP was based on the misunderstanding that one has to recompile it in order to enable things, but that is simply the wrong way to manage an installation. It would be useful to know if you are using a distribution that does not use libraries just for reference. I know that some distributions are DESIGNED to work that way, but even those can add extensions via the ini file route. Package driven management will certainly be adding the files and updating the configuration rather than installing a full compilation system on the machine. THAT should only be implemented when one of the development packages is loaded.
One important note here ... PGV could be built as a package and supplied to the repositories, but a number of other web projects have decided that MySQL or Postgres should be a 'required' and for those of us who don't use either it becomes a nightmare.