FAQ
Hello developers,

The thread about dropping support for PHP4 gave me a new idea, having
multiple PHP versions to be loaded by the Apache2handler SAPI.

The idea:
I was thinking about something like the shebang(#!) line used in
bash/perl/python and even PHP scripts. But this time not for the
program to be executed, but for which PHP version to load. This could
be used like this:
<?php // PHP4 ?>
for PHP4, and so it could be
<?php // PHP5 ?> or <?php // PHP6 ?>
for resp. PHP5 or PHP6.
This way can scripts define which PHP version they require, as it is a
normal comment line, other PHP version can simply ignore the line.

The implementation:
The Apache2handler SAPI should be loaded first, and read the very
first line of the PHP script to determine if a version is specified
there. If not, the handler needs to load its default PHP version. If
it is specified, it should try to load that version, and if it
couldn't find or load that version, fall back to the default version
and issue a warning.

What needs to change:
Currently, PHP is one big module for Apache, which will load a full
PHP version at once. For this, we require a very small handler, that
will use dlopen() to load the appropriate version and continue with
the execution of the PHP script.
Some kind of mini parser is also required to read the very first line
of a PHP script, because that needs to be done before any PHP version
is loaded. And maybe also a parser for the php.ini file, as php.ini
needs an extra option for the default PHP version to be loaded, and
one or more settings for configuring the different PHP versions and
their path to the library.

Some extra ideas, not sure if they need to be implemented:
* Support for sub versions of PHP, like this:
<?php // PHP4.3 ?>
<?php // PHP5.2.1 ?>
* Support for multiple possible PHP versions, like this:
<?php // PHP4 || PHP5 ?>
Where the first one is the preferred one, which can also be combined
with the first one of course, like this:
<?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
* Support for <, > and && signs in the version, like this:
<?php // PHP > 5.2 && PHP < 5.3 ?>
So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
preferred one, if 5.3 should be the preferred one, it should be
written like this:
<?php // PHP < 5.3 && PHP > 5.2 ?>
* Support for this in other handlers, like FastCGI, ISAPI, etc.


It seems to be the perfect solution for shared hosting providers to
me, as it will allow the user to select which PHP version he wants to
use, and shared hosts can just install all three versions of PHP and
use the one they need for their admin panels etc. (One of the reasons
against upgrading to PHP5), and users can use another version.
I don't know too much about PHP core, and nearly nothing about the
apache2handler, so if it's not possible, please excuse me for wasting
your time.
But, if it is possible, I will definitely go deeper inside the core
and SAPI code to get it working.

Now, the reason I'm sending this to the list is that I need to know if
*) it is possible?
*) it is not yet done
*) it is wanted
*) it will have any negative effect on something?

I'd like to hear all your comments and objections on this, and of
course, if you have any question, feel free to ask.

Regards,

Tijnema

Search Discussions

  • Jani Taskinen at Jul 11, 2007 at 11:08 pm
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define the
    required PHP version by the file suffix..

    --Jani

    Tijnema kirjoitti:
    Hello developers,

    The thread about dropping support for PHP4 gave me a new idea, having
    multiple PHP versions to be loaded by the Apache2handler SAPI.

    The idea:
    I was thinking about something like the shebang(#!) line used in
    bash/perl/python and even PHP scripts. But this time not for the
    program to be executed, but for which PHP version to load. This could
    be used like this:
    <?php // PHP4 ?>
    for PHP4, and so it could be
    <?php // PHP5 ?> or <?php // PHP6 ?>
    for resp. PHP5 or PHP6.
    This way can scripts define which PHP version they require, as it is a
    normal comment line, other PHP version can simply ignore the line.

    The implementation:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.

    What needs to change:
    Currently, PHP is one big module for Apache, which will load a full
    PHP version at once. For this, we require a very small handler, that
    will use dlopen() to load the appropriate version and continue with
    the execution of the PHP script.
    Some kind of mini parser is also required to read the very first line
    of a PHP script, because that needs to be done before any PHP version
    is loaded. And maybe also a parser for the php.ini file, as php.ini
    needs an extra option for the default PHP version to be loaded, and
    one or more settings for configuring the different PHP versions and
    their path to the library.

    Some extra ideas, not sure if they need to be implemented:
    * Support for sub versions of PHP, like this:
    <?php // PHP4.3 ?>
    <?php // PHP5.2.1 ?>
    * Support for multiple possible PHP versions, like this:
    <?php // PHP4 || PHP5 ?>
    Where the first one is the preferred one, which can also be combined
    with the first one of course, like this:
    <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
    * Support for <, > and && signs in the version, like this:
    <?php // PHP > 5.2 && PHP < 5.3 ?>
    So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
    preferred one, if 5.3 should be the preferred one, it should be
    written like this:
    <?php // PHP < 5.3 && PHP > 5.2 ?>
    * Support for this in other handlers, like FastCGI, ISAPI, etc.


    It seems to be the perfect solution for shared hosting providers to
    me, as it will allow the user to select which PHP version he wants to
    use, and shared hosts can just install all three versions of PHP and
    use the one they need for their admin panels etc. (One of the reasons
    against upgrading to PHP5), and users can use another version.
    I don't know too much about PHP core, and nearly nothing about the
    apache2handler, so if it's not possible, please excuse me for wasting
    your time.
    But, if it is possible, I will definitely go deeper inside the core
    and SAPI code to get it working.

    Now, the reason I'm sending this to the list is that I need to know if
    *) it is possible?
    *) it is not yet done
    *) it is wanted
    *) it will have any negative effect on something?

    I'd like to hear all your comments and objections on this, and of
    course, if you have any question, feel free to ask.

    Regards,

    Tijnema
  • Tijnema at Jul 11, 2007 at 11:13 pm

    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.

    Regards,

    Tijnema
    Tijnema kirjoitti:
    Hello developers,

    The thread about dropping support for PHP4 gave me a new idea, having
    multiple PHP versions to be loaded by the Apache2handler SAPI.

    The idea:
    I was thinking about something like the shebang(#!) line used in
    bash/perl/python and even PHP scripts. But this time not for the
    program to be executed, but for which PHP version to load. This could
    be used like this:
    <?php // PHP4 ?>
    for PHP4, and so it could be
    <?php // PHP5 ?> or <?php // PHP6 ?>
    for resp. PHP5 or PHP6.
    This way can scripts define which PHP version they require, as it is a
    normal comment line, other PHP version can simply ignore the line.

    The implementation:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.

    What needs to change:
    Currently, PHP is one big module for Apache, which will load a full
    PHP version at once. For this, we require a very small handler, that
    will use dlopen() to load the appropriate version and continue with
    the execution of the PHP script.
    Some kind of mini parser is also required to read the very first line
    of a PHP script, because that needs to be done before any PHP version
    is loaded. And maybe also a parser for the php.ini file, as php.ini
    needs an extra option for the default PHP version to be loaded, and
    one or more settings for configuring the different PHP versions and
    their path to the library.

    Some extra ideas, not sure if they need to be implemented:
    * Support for sub versions of PHP, like this:
    <?php // PHP4.3 ?>
    <?php // PHP5.2.1 ?>
    * Support for multiple possible PHP versions, like this:
    <?php // PHP4 || PHP5 ?>
    Where the first one is the preferred one, which can also be combined
    with the first one of course, like this:
    <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
    * Support for <, > and && signs in the version, like this:
    <?php // PHP > 5.2 && PHP < 5.3 ?>
    So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
    preferred one, if 5.3 should be the preferred one, it should be
    written like this:
    <?php // PHP < 5.3 && PHP > 5.2 ?>
    * Support for this in other handlers, like FastCGI, ISAPI, etc.


    It seems to be the perfect solution for shared hosting providers to
    me, as it will allow the user to select which PHP version he wants to
    use, and shared hosts can just install all three versions of PHP and
    use the one they need for their admin panels etc. (One of the reasons
    against upgrading to PHP5), and users can use another version.
    I don't know too much about PHP core, and nearly nothing about the
    apache2handler, so if it's not possible, please excuse me for wasting
    your time.
    But, if it is possible, I will definitely go deeper inside the core
    and SAPI code to get it working.

    Now, the reason I'm sending this to the list is that I need to know if
    *) it is possible?
    *) it is not yet done
    *) it is wanted
    *) it will have any negative effect on something?

    I'd like to hear all your comments and objections on this, and of
    course, if you have any question, feel free to ask.

    Regards,

    Tijnema

    --
    Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info
  • Guilherme Blanco at Jul 12, 2007 at 12:13 am
    Hi Tijnema,

    I think here is something that might interest you:

    http://www.phpclasses.org/browse/package/3472.html


    Regards,
    On 7/11/07, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.

    Regards,

    Tijnema
    Tijnema kirjoitti:
    Hello developers,

    The thread about dropping support for PHP4 gave me a new idea, having
    multiple PHP versions to be loaded by the Apache2handler SAPI.

    The idea:
    I was thinking about something like the shebang(#!) line used in
    bash/perl/python and even PHP scripts. But this time not for the
    program to be executed, but for which PHP version to load. This could
    be used like this:
    <?php // PHP4 ?>
    for PHP4, and so it could be
    <?php // PHP5 ?> or <?php // PHP6 ?>
    for resp. PHP5 or PHP6.
    This way can scripts define which PHP version they require, as it is a
    normal comment line, other PHP version can simply ignore the line.

    The implementation:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.

    What needs to change:
    Currently, PHP is one big module for Apache, which will load a full
    PHP version at once. For this, we require a very small handler, that
    will use dlopen() to load the appropriate version and continue with
    the execution of the PHP script.
    Some kind of mini parser is also required to read the very first line
    of a PHP script, because that needs to be done before any PHP version
    is loaded. And maybe also a parser for the php.ini file, as php.ini
    needs an extra option for the default PHP version to be loaded, and
    one or more settings for configuring the different PHP versions and
    their path to the library.

    Some extra ideas, not sure if they need to be implemented:
    * Support for sub versions of PHP, like this:
    <?php // PHP4.3 ?>
    <?php // PHP5.2.1 ?>
    * Support for multiple possible PHP versions, like this:
    <?php // PHP4 || PHP5 ?>
    Where the first one is the preferred one, which can also be combined
    with the first one of course, like this:
    <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
    * Support for <, > and && signs in the version, like this:
    <?php // PHP > 5.2 && PHP < 5.3 ?>
    So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
    preferred one, if 5.3 should be the preferred one, it should be
    written like this:
    <?php // PHP < 5.3 && PHP > 5.2 ?>
    * Support for this in other handlers, like FastCGI, ISAPI, etc.


    It seems to be the perfect solution for shared hosting providers to
    me, as it will allow the user to select which PHP version he wants to
    use, and shared hosts can just install all three versions of PHP and
    use the one they need for their admin panels etc. (One of the reasons
    against upgrading to PHP5), and users can use another version.
    I don't know too much about PHP core, and nearly nothing about the
    apache2handler, so if it's not possible, please excuse me for wasting
    your time.
    But, if it is possible, I will definitely go deeper inside the core
    and SAPI code to get it working.

    Now, the reason I'm sending this to the list is that I need to know if
    *) it is possible?
    *) it is not yet done
    *) it is wanted
    *) it will have any negative effect on something?

    I'd like to hear all your comments and objections on this, and of
    course, if you have any question, feel free to ask.

    Regards,

    Tijnema

    --
    Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    --
    Guilherme Blanco - Web Developer
    CBC - Certified Bindows Consultant
    Cell Phone: +55 (16) 9166-6902
    MSN: guilhermeblanco@hotmail.com
    URL: http://blog.bisna.com
    São Carlos - SP/Brazil
  • Tijnema at Jul 12, 2007 at 9:45 am

    On 7/12/07, Guilherme Blanco wrote:
    Hi Tijnema,

    I think here is something that might interest you:

    http://www.phpclasses.org/browse/package/3472.html


    Regards,
    Hello Guilherme,

    This comes quite close to my idea, except that this does only
    uncomment specfic sections that are for specific versions. This means
    that as a coder, you still need to write all of those bypasses for
    specific versions.

    Regards,

    Tijnema
    On 7/11/07, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.

    Regards,

    Tijnema
    Tijnema kirjoitti:
    Hello developers,

    The thread about dropping support for PHP4 gave me a new idea, having
    multiple PHP versions to be loaded by the Apache2handler SAPI.

    The idea:
    I was thinking about something like the shebang(#!) line used in
    bash/perl/python and even PHP scripts. But this time not for the
    program to be executed, but for which PHP version to load. This could
    be used like this:
    <?php // PHP4 ?>
    for PHP4, and so it could be
    <?php // PHP5 ?> or <?php // PHP6 ?>
    for resp. PHP5 or PHP6.
    This way can scripts define which PHP version they require, as it is a
    normal comment line, other PHP version can simply ignore the line.

    The implementation:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.

    What needs to change:
    Currently, PHP is one big module for Apache, which will load a full
    PHP version at once. For this, we require a very small handler, that
    will use dlopen() to load the appropriate version and continue with
    the execution of the PHP script.
    Some kind of mini parser is also required to read the very first line
    of a PHP script, because that needs to be done before any PHP version
    is loaded. And maybe also a parser for the php.ini file, as php.ini
    needs an extra option for the default PHP version to be loaded, and
    one or more settings for configuring the different PHP versions and
    their path to the library.

    Some extra ideas, not sure if they need to be implemented:
    * Support for sub versions of PHP, like this:
    <?php // PHP4.3 ?>
    <?php // PHP5.2.1 ?>
    * Support for multiple possible PHP versions, like this:
    <?php // PHP4 || PHP5 ?>
    Where the first one is the preferred one, which can also be combined
    with the first one of course, like this:
    <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
    * Support for <, > and && signs in the version, like this:
    <?php // PHP > 5.2 && PHP < 5.3 ?>
    So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
    preferred one, if 5.3 should be the preferred one, it should be
    written like this:
    <?php // PHP < 5.3 && PHP > 5.2 ?>
    * Support for this in other handlers, like FastCGI, ISAPI, etc.


    It seems to be the perfect solution for shared hosting providers to
    me, as it will allow the user to select which PHP version he wants to
    use, and shared hosts can just install all three versions of PHP and
    use the one they need for their admin panels etc. (One of the reasons
    against upgrading to PHP5), and users can use another version.
    I don't know too much about PHP core, and nearly nothing about the
    apache2handler, so if it's not possible, please excuse me for wasting
    your time.
    But, if it is possible, I will definitely go deeper inside the core
    and SAPI code to get it working.

    Now, the reason I'm sending this to the list is that I need to know if
    *) it is possible?
    *) it is not yet done
    *) it is wanted
    *) it will have any negative effect on something?

    I'd like to hear all your comments and objections on this, and of
    course, if you have any question, feel free to ask.

    Regards,

    Tijnema

    --
    Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    --
    Guilherme Blanco - Web Developer
    CBC - Certified Bindows Consultant
    Cell Phone: +55 (16) 9166-6902
    MSN: guilhermeblanco@hotmail.com
    URL: http://blog.bisna.com
    São Carlos - SP/Brazil
  • Johannes Schlüter at Jul 12, 2007 at 12:16 am
    Hi
    On Thu, 2007-07-12 at 01:13 +0200, Tijnema wrote:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    Then setup a VirtualHost or use an .htaccess file or something like that
    where you bind the .php extension to the relevant Handler...

    johannes
  • Richard Lynch at Jul 12, 2007 at 12:25 am

    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>

    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...

    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?

    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?
  • Chris# at Jul 12, 2007 at 2:03 am

    On Wed, 11 Jul 2007 19:25:32 -0500 (CDT), "Richard Lynch" wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>

    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...

    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    /////////////////////////////////////////////////////
    Service provided by hitOmeter.NET internet messaging!
    .
  • Rasmus Lerdorf at Jul 12, 2007 at 3:44 am

    chris# wrote:
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    This wasn't supported on all platforms in 4 either because it relied on
    the ability to created versioned shared libs. It was a hassle to
    maintain and frankly none of the people who understood it had any need
    for it. As popular as PHP is, it is still driven by the needs of the
    people who do the bulk of the work. The fact that we don't have great
    support for ISPs and shared environments is a reflection of the fact
    that no core developer has ever had a serious need for it. Or put
    another way, no serious developer from an ISP has ever contributed
    enough to PHP to move the ship on this stuff.

    -Rasmus
  • Jani Taskinen at Jul 12, 2007 at 9:47 am

    On Wed, 2007-07-11 at 20:43 -0700, Rasmus Lerdorf wrote:
    chris# wrote:
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    This wasn't supported on all platforms in 4 either because it relied on
    the ability to created versioned shared libs. It was a hassle to
    maintain and frankly none of the people who understood it had any need
    for it. As popular as PHP is, it is still driven by the needs of the
    people who do the bulk of the work. The fact that we don't have great
    support for ISPs and shared environments is a reflection of the fact
    that no core developer has ever had a serious need for it. Or put
    another way, no serious developer from an ISP has ever contributed
    enough to PHP to move the ship on this stuff.
    And the fact that it doesn't work properly with shared extensions made
    me to remove it altogether. The option only caused trouble when people
    used it when they didn't even know what it does (--enable-versioning)

    Also, the apache options we have are same between PHP 4 and 5 so it
    never could have worked without patching the Apache SAPI sources. :)

    Manual states that it's only for PHP 3 which is quite correct..

    --Jani
  • Chris# at Jul 12, 2007 at 10:10 am

    On Wed, 11 Jul 2007 20:43:06 -0700, Rasmus Lerdorf wrote:
    chris# wrote:
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    This wasn't supported on all platforms in 4 either because it relied on
    the ability to created versioned shared libs. It was a hassle to
    maintain and frankly none of the people who understood it had any need
    for it. As popular as PHP is, it is still driven by the needs of the
    people who do the bulk of the work. The fact that we don't have great
    support for ISPs and shared environments is a reflection of the fact
    that no core developer has ever had a serious need for it. Or put
    another way, no serious developer from an ISP has ever contributed
    enough to PHP to move the ship on this stuff.
    Count me in!
    And thank you very much for such an informative response.
    So tell me please. Is it uncommon to run more than one version of PHP
    on one box - where the developers are concerned? I ask this because
    I've been developing in many languages for about 30 yrs. and I frequently
    run more than one version of a language on the same (DEV boxen) during
    the languages /transitional/ period - when it's changing from one ver.
    to another; for regression testing. So somehow, I assumed that the PHP
    DEV team probably did the same. Maybe I'm just odd that way. Anyway, I
    meant what I said - count me in. I'll start preparing the addition of
    another server to dedicate to an experimental parallel PHP install.
    But given that I'm already managing 50 some boxen already, I'd /really/
    appreciate a little insight from those whom have already accomplished
    something at least similar. As my time is /very/ thin already. I'd also
    be willing to provide access to all the PHP developers. So they can
    experiment on it, if they want. I'll use CVS to keep a versioning system
    of the boxen. Thereby allowing the recreation of any state of the boxen.
    That should prove quite helpful.
    Hell, if this is successful, I'd even consider offering free hosting for
    a period of time. Just to show off the ability (and hopeful convenience)
    of running multiple PHP versions. This could be the "crown jewel" for
    the willing adoption of PHP5. :)

    Thanks again for taking the time to respond.
    -Rasmus

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    /////////////////////////////////////////////////////
    Service provided by hitOmeter.NET internet messaging!
    .
  • Richard Lynch at Jul 14, 2007 at 7:36 am

    On Wed, July 11, 2007 9:02 pm, chris# wrote:
    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...

    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    I think it's more of a systemic thing than a single developer breaking
    a feature...

    I'm not quite sure how they got all the symbols (read: internal PHP
    function names) to be "different" between PHP3 and PHP4, but I suspect
    it was a butt-load of work for not much benefit.

    You can run as many versions as you want in FastCGI pretty trivially.

    Oh, and to answer another question in this thread:

    I don't know how many shared webhosts offer the ability to change PHP
    version with ForceType in .htaccess

    I only know that mine has offered that for quite some time, to easy
    any problems with clients who need to install niche software.

    I also know that another webhost of one of my clients' does it.

    So from a tiny non-representative sample, I'm looking at about 2 out
    of 6 webhosts I've experienced.

    YMMV

    --
    Some people have a "gift" link here.
    Know what I want?
    I want you to buy a CD from some indie artist.
    http://cdbaby.com/browse/from/lynch
    Yeah, I get a buck. So?
  • Tijnema at Jul 14, 2007 at 1:47 pm

    On 7/14/07, Richard Lynch wrote:
    On Wed, July 11, 2007 9:02 pm, chris# wrote:
    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...

    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    So which one of the developers broke this /feature/ in 5? ;)
    I think it's more of a systemic thing than a single developer breaking
    a feature...

    I'm not quite sure how they got all the symbols (read: internal PHP
    function names) to be "different" between PHP3 and PHP4, but I suspect
    it was a butt-load of work for not much benefit.

    You can run as many versions as you want in FastCGI pretty trivially.

    Oh, and to answer another question in this thread:

    I don't know how many shared webhosts offer the ability to change PHP
    version with ForceType in .htaccess

    I only know that mine has offered that for quite some time, to easy
    any problems with clients who need to install niche software.

    I also know that another webhost of one of my clients' does it.

    So from a tiny non-representative sample, I'm looking at about 2 out
    of 6 webhosts I've experienced.

    YMMV
    I never saw a shared host with more than one PHP version installed
    actually, probably becaues they were all with Apache and not with
    FastCGI. So, for me it would be 0 out of 9...

    Tijnema
  • Larry Garfield at Jul 14, 2007 at 5:06 pm

    On Saturday 14 July 2007, Tijnema wrote:

    So from a tiny non-representative sample, I'm looking at about 2 out
    of 6 webhosts I've experienced.

    YMMV
    I never saw a shared host with more than one PHP version installed
    actually, probably becaues they were all with Apache and not with
    FastCGI. So, for me it would be 0 out of 9...

    Tijnema
    In my processing of hosts applying to GoPHP5.org, I've seen a whole lot of
    them. I don't have a ratio (I've not been counting), but it seems to be a
    lot more than I expected.

    --
    Larry Garfield AIM: LOLG42
    larry@garfieldtech.com ICQ: 6817012

    "If nature has made any one thing less susceptible than all others of
    exclusive property, it is the action of the thinking power called an idea,
    which an individual may exclusively possess as long as he keeps it to
    himself; but the moment it is divulged, it forces itself into the possession
    of every one, and the receiver cannot dispossess himself of it." -- Thomas
    Jefferson
  • Tijnema at Jul 12, 2007 at 9:38 am
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    That was nice :)
    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...
    I did, I think it should generate an error message,
    E_RECOVERABLE_ERROR maybe? And then the default PHP version should
    just give the code a try, just like it does when it is installed on a
    host that has the wrong PHP version installed.

    Regards,

    Tijnema
  • Derick Rethans at Jul 12, 2007 at 9:50 am

    On Thu, 12 Jul 2007, Tijnema wrote:
    On 7/12/07, Richard Lynch wrote:

    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    You forget that the symbol names in both shared objects are still the
    same. If you have that you get *major* issues when running the code. So
    no, it does not work fine.

    Derick
  • Chris# at Jul 12, 2007 at 10:49 am

    On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema wrote:
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    This is no more unusual that adding/eliminating directory access.
    Which is pretty common stuff for users on a hosting companies box.
    Extremely simple too. The hosting outfit will /surely/ indicate
    any changes they need to make to provide them with the /added/
    functionality. Maybe even add an applet in the Cpanel for it.
    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    Yes, you are. All OS's handle loading differently. An experience I
    read about indicated that it works fine with the BSD family of OS's
    but not with (at least) Linux.
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    That was nice :)
    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...
    Ermm... I think there would be no point providing an environment that
    accommodated both versions, if both versions didn't exist. Sort of moot,
    isn't it?
    I did, I think it should generate an error message,
    E_RECOVERABLE_ERROR maybe? And then the default PHP version should
    just give the code a try, just like it does when it is installed on a
    host that has the wrong PHP version installed.
    I don't think an error makes any difference. If both versions aren't available,
    an environment that accommodated both would not/should not even be a
    consideration. Right?
    Regards,

    Tijnema

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    /////////////////////////////////////////////////////
    Service provided by hitOmeter.NET internet messaging!
    .
  • Tijnema at Jul 12, 2007 at 11:41 am

    On 7/12/07, chris# wrote:

    On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema wrote:
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    This is no more unusual that adding/eliminating directory access.
    Which is pretty common stuff for users on a hosting companies box.
    Extremely simple too. The hosting outfit will /surely/ indicate
    any changes they need to make to provide them with the /added/
    functionality. Maybe even add an applet in the Cpanel for it.
    My host hasn't a single .htaccess file ;)
    (Using DirectAdmin..)
    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    Yes, you are. All OS's handle loading differently. An experience I
    read about indicated that it works fine with the BSD family of OS's
    but not with (at least) Linux.
    of course they do, I was only thinking about linux.
    I always thought that it was possible in Linux too, as the dlopen
    function is available, and should work like that.
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    That was nice :)
    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...
    Ermm... I think there would be no point providing an environment that
    accommodated both versions, if both versions didn't exist. Sort of moot,
    isn't it?
    I did, I think it should generate an error message,
    E_RECOVERABLE_ERROR maybe? And then the default PHP version should
    just give the code a try, just like it does when it is installed on a
    host that has the wrong PHP version installed.
    I don't think an error makes any difference. If both versions aren't available,
    an environment that accommodated both would not/should not even be a
    consideration. Right?
    Well, If some script was written for PHP4, but abandoned, and people
    start using it on a host that has PHP5/6 installed, then it might run
    just fine on PHP5. It's worth trying I think.

    Regards,

    Tijnema
  • Chris# at Jul 12, 2007 at 12:10 pm

    On Thu, 12 Jul 2007 13:41:16 +0200, Tijnema wrote:
    On 7/12/07, chris# wrote:


    On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema wrote:
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    This is no more unusual that adding/eliminating directory access.
    Which is pretty common stuff for users on a hosting companies box.
    Extremely simple too. The hosting outfit will /surely/ indicate
    any changes they need to make to provide them with the /added/
    functionality. Maybe even add an applet in the Cpanel for it.
    My host hasn't a single .htaccess file ;)
    (Using DirectAdmin..)
    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    Yes, you are. All OS's handle loading differently. An experience I
    read about indicated that it works fine with the BSD family of OS's
    but not with (at least) Linux.
    of course they do, I was only thinking about linux.
    I always thought that it was possible in Linux too, as the dlopen
    function is available, and should work like that.
    Indeed. As memory serves, they both use dlopen(). But seems *BSD(i) is
    different than Linux, in that it's possible to load say; libphp4.so
    for processing the files with a .php extension. While /also/ loading
    libphp5.so for processing .php5 files. Apparently on Linux (and probably
    most other OS's - save OSX) you'll end up with symbol collisions. Which,
    of course result in the web server (or PHP) complaining that it couldn't
    find blah,blah. Or expected blah, blah, but got blah,blg. I'll be
    refreshing my memory on the way *BSD handles this real soon. As I'll be
    building a server in an attempt to discover the best process for
    accommodating multiple versions simultaneously. I'll be better prepared
    for giving a more detailed difference then. :)
    It was possible to have PHP3 and PHP4 both as modules, I think, but
    that was an anomoly?
    That was nice :)
    You also would have to re-think what happens when a version is
    requested that isn't installed at all...

    You currently have it just run in the default version, I think, but
    is
    that really useful? If the code really NEEDS PHP 5, and the server
    doesn't have 5, only 4, running the code that needs 5 is probably not
    the right action...
    Ermm... I think there would be no point providing an environment that
    accommodated both versions, if both versions didn't exist. Sort of moot,
    isn't it?
    I did, I think it should generate an error message,
    E_RECOVERABLE_ERROR maybe? And then the default PHP version should
    just give the code a try, just like it does when it is installed on a
    host that has the wrong PHP version installed.
    I don't think an error makes any difference. If both versions aren't available,
    an environment that accommodated both would not/should not even be a
    consideration. Right?
    Well, If some script was written for PHP4, but abandoned, and people
    start using it on a host that has PHP5/6 installed, then it might run
    just fine on PHP5. It's worth trying I think.

    Regards,

    Tijnema
    /////////////////////////////////////////////////////
    Service provided by hitOmeter.NET internet messaging!
    .
  • Tijnema at Jul 12, 2007 at 12:24 pm

    On 7/12/07, Tijnema wrote:
    On 7/12/07, chris# wrote:


    On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema wrote:
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    This is no more unusual that adding/eliminating directory access.
    Which is pretty common stuff for users on a hosting companies box.
    Extremely simple too. The hosting outfit will /surely/ indicate
    any changes they need to make to provide them with the /added/
    functionality. Maybe even add an applet in the Cpanel for it.
    My host hasn't a single .htaccess file ;)
    (Using DirectAdmin..)
    Other problems:

    Getting 2 PHP modules to co-exist without tromping on each others'
    symbols is, I think, the show-stopper...
    Both modules are different files, and only one will be dynamically
    loaded by dlopen(), that works fine right? or do I forget something?
    Yes, you are. All OS's handle loading differently. An experience I
    read about indicated that it works fine with the BSD family of OS's
    but not with (at least) Linux.
    of course they do, I was only thinking about linux.
    I always thought that it was possible in Linux too, as the dlopen
    function is available, and should work like that.
    I just wrote a very simple test script, that does, I think, what it
    should do, it loads one of the different php libraries.
    --------------------php4.c--------------------
    int parse_php_code(char *file)
    {
    return 4;
    }
    --------------------/php4.c--------------------

    --------------------php5.c--------------------
    int parse_php_code(char *file)
    {
    return 5;
    }
    --------------------/php5.c--------------------

    --------------------php6.c--------------------
    int parse_php_code(char *file)
    {
    return 6;
    }
    --------------------/php6.c--------------------

    --------------------loader.c--------------------
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char *argv[])
    {
    void *handle;
    char *error;
    int (*parse_code)(char *);

    if(argc != 2) {
    fprintf(stderr, "Syntax: %s <php module>\n", argv[0]);
    exit(1);
    }

    handle = dlopen(argv[1], RTLD_LAZY);
    if(!handle) {
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
    }

    parse_code = dlsym(handle, "parse_php_code");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "%s\n", error);
    exit(1);
    }


    printf("%d\n",(*parse_code)("abc.php"));
    dlclose(handle);
    return 0;
    }
    --------------------/loader.c--------------------

    I've compiled it like this:
    gcc -shared -fPIC php4.c -o libphp4.so
    gcc -shared -fPIC php5.c -o libphp5.so
    gcc -shared -fPIC php6.c -o libphp6.so
    gcc -rdynamic -o loader loader.c -ldl

    Now, I use the test program loader to load one of above compiled libraries:
    ./loader ./libphp4.so (Outputs 4)
    ./loader ./libphp5.so (Outputs 5)
    ./loader ./libphp6.so (Outputs 6)

    Now, to get back to the real world, libphp4.so, libphp5.so, and
    libphp6.so are the libraries compiled from PHP source, and the code of
    the loader would need to be integrated in the Apache2handler SAPI.

    So, I think this simple test shows that it is possible on Linux
    (atleast on my linux-2.6.17.11, Glibc-2.3.6, gcc-4.2.0), or did I
    forgot something else?

    Regards,

    Tijnema
  • Chris# at Jul 12, 2007 at 1:53 am

    On Thu, 12 Jul 2007 01:13:33 +0200, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    Another option is to also assign the PHP version on a directory/folder
    basis. That is to say; as an option to compliment, or as addition to using
    the extension option (.php5).
    Regards,

    Tijnema
    Tijnema kirjoitti:
    Hello developers,

    The thread about dropping support for PHP4 gave me a new idea, having
    multiple PHP versions to be loaded by the Apache2handler SAPI.

    The idea:
    I was thinking about something like the shebang(#!) line used in
    bash/perl/python and even PHP scripts. But this time not for the
    program to be executed, but for which PHP version to load. This could
    be used like this:
    <?php // PHP4 ?>
    for PHP4, and so it could be
    <?php // PHP5 ?> or <?php // PHP6 ?>
    for resp. PHP5 or PHP6.
    This way can scripts define which PHP version they require, as it is a
    normal comment line, other PHP version can simply ignore the line.

    The implementation:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.

    What needs to change:
    Currently, PHP is one big module for Apache, which will load a full
    PHP version at once. For this, we require a very small handler, that
    will use dlopen() to load the appropriate version and continue with
    the execution of the PHP script.
    Some kind of mini parser is also required to read the very first line
    of a PHP script, because that needs to be done before any PHP version
    is loaded. And maybe also a parser for the php.ini file, as php.ini
    needs an extra option for the default PHP version to be loaded, and
    one or more settings for configuring the different PHP versions and
    their path to the library.

    Some extra ideas, not sure if they need to be implemented:
    * Support for sub versions of PHP, like this:
    <?php // PHP4.3 ?>
    <?php // PHP5.2.1 ?>
    * Support for multiple possible PHP versions, like this:
    <?php // PHP4 || PHP5 ?>
    Where the first one is the preferred one, which can also be combined
    with the first one of course, like this:
    <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
    * Support for <, > and && signs in the version, like this:
    <?php // PHP > 5.2 && PHP < 5.3 ?>
    So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
    preferred one, if 5.3 should be the preferred one, it should be
    written like this:
    <?php // PHP < 5.3 && PHP > 5.2 ?>
    * Support for this in other handlers, like FastCGI, ISAPI, etc.


    It seems to be the perfect solution for shared hosting providers to
    me, as it will allow the user to select which PHP version he wants to
    use, and shared hosts can just install all three versions of PHP and
    use the one they need for their admin panels etc. (One of the reasons
    against upgrading to PHP5), and users can use another version.
    I don't know too much about PHP core, and nearly nothing about the
    apache2handler, so if it's not possible, please excuse me for wasting
    your time.
    But, if it is possible, I will definitely go deeper inside the core
    and SAPI code to get it working.

    Now, the reason I'm sending this to the list is that I need to know if
    *) it is possible?
    *) it is not yet done
    *) it is wanted
    *) it will have any negative effect on something?

    I'd like to hear all your comments and objections on this, and of
    course, if you have any question, feel free to ask.

    Regards,

    Tijnema

    --
    Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    /////////////////////////////////////////////////////
    Service provided by hitOmeter.NET internet messaging!
    .
  • Gaetano Giunta at Jul 13, 2007 at 9:51 am

    On 7/12/07, chris# wrote:

    On Thu, 12 Jul 2007 11:38:44 +0200, Tijnema wrote:
    Hello Richard,
    On 7/12/07, Richard Lynch wrote:
    On Wed, July 11, 2007 6:13 pm, Tijnema wrote:
    On 7/12/07, Jani Taskinen wrote:
    A lot easier (and works already) is to install PHP as CGI/FastCGI
    (one version or all of them, one can be module of course) and define
    the
    required PHP version by the file suffix..

    --Jani
    Hello Jani:

    I know this is possible, and I believe it is possible in Apache too
    with some kind of hack?
    But this still doesn't solve a lot of problems, but will generate a
    lot more with portable code. Take a bulletin board for example, there
    are a lot of files inside a board, and when you want to install that
    on your host that has PHP5 for files with .php5, you need to rename a
    hell lot of files to .php5, AND change code inside the .php5 files to
    point to the renamed files.
    No, you add a <Directory> config in httpd.conf or add to .htaccess a
    line like
    <Files ~.php>
    ForceType whatever/gets/you/to/php-5
    </Files>
    1) Did you ever see a shared host that has multiple versions
    configured like this?
    2) This will end up to be confusing for the end user, as they will
    need to create the .htaccess file (as most users don't have write
    rights for httpd.conf)
    This is no more unusual that adding/eliminating directory access.
    Which is pretty common stuff for users on a hosting companies box.
    Extremely simple too. The hosting outfit will /surely/ indicate
    any changes they need to make to provide them with the /added/
    functionality. Maybe even add an applet in the Cpanel for it.
    My host hasn't a single .htaccess file ;)
    (Using DirectAdmin..)
    Not really an excellent option for web hosters, but the easiest way I
    set up "alot" of php versions on my dev box (1 as apache module, all
    the rest cgi, of course) is using virtual hosts:
    every virtual host listens to either a different port or a different
    server name, eg: php4server.my.domain, and binds .php and .inc files
    to a different cgi app/php version.
    This way there is no need to rename files or keep multiple copies
    around, and it is pretty useful eg. for heavy unit testing: if the
    code does not work in a particular php version, add some hackish ifdef
    equivalent and you're done.

    Bye
    Gaetano
  • Stanislav Malyshev at Jul 14, 2007 at 7:14 am

    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.
    This means the engines would have to init/shutdown on each request,
    which makes it as bad as CGI. Why not just go FastCGI? You can use
    extensions like .php4 and .php5.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Tijnema at Jul 14, 2007 at 3:13 pm

    On 7/14/07, Stanislav Malyshev wrote:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.
    This means the engines would have to init/shutdown on each request,
    which makes it as bad as CGI.
    Is that really a big problem?
    And isn't that what Apache currently does?
    As I said before, I don't know a lot about PHP core/ Apache2handler
    SAPI, But I expected Apache to load PHP on each request.
    And what if I just load and init all PHP versions at once with
    different handles? (See example code at the bottom of this message)
    Why not just go FastCGI? You can use
    extensions like .php4 and .php5.
    --
    Stanislav Malyshev, Zend Software Architect
    It's not just for my personal server, I just load different PHP
    versions by updating a symlink (libphp.so -->libphp4.so, libphp5.so or
    libphp5-2-1.so), and restarting Apache.
    I talked to my webmaster of my Shared host, and he said:
    "I don't see a reason to use FastCGI with different extensions, this
    will probably lead to problems with unexperienced users on this
    server. If your idea shows no security issues, performance issues or
    difficult configuration settings, we will use it to support more
    versions of PHP."

    So, that confirms what I was thinking, but other webmasters might
    think different about it.

    Tijnema

    The code for loading and starting up different PHP versions at once:
    --------------------php4.c--------------------
    int *parse_php_code(char *file)
    {
    return 4;
    }

    int php_startup()
    {
    return 1;
    }
    --------------------/php4.c--------------------
    --------------------php5.c--------------------
    int *parse_php_code(char *file)
    {
    return 5;
    }

    int php_startup()
    {
    return 1;
    }
    --------------------/php5.c--------------------
    --------------------php6.c--------------------
    int *parse_php_code(char *file)
    {
    return 6;
    }

    int php_startup()
    {
    return 1;
    }
    --------------------/php6.c--------------------
    --------------------loader.c--------------------
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char *argv[])
    {
    void *handle4, *handle5, *handle6;
    char *error;

    int *(*parse_code4)(char *);
    int *(*startup4);

    int *(*parse_code5)(char *);
    int *(*startup5);

    int *(*parse_code6)(char *);
    int *(*startup6);

    FILE * fp;
    char *ver;
    char *buffer;

    if(argc != 2) {
    fprintf(stderr, "Syntax: %s <php file>\n", argv[0]);
    exit(1);
    }

    handle4 = dlopen("./libphp4.so", RTLD_LAZY);
    handle5 = dlopen("./libphp5.so", RTLD_LAZY);
    handle6 = dlopen("./libphp6.so", RTLD_LAZY);

    if(!handle4) {
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
    }
    if(!handle5) {
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
    }
    if(!handle6) {
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
    }

    startup4 = dlsym(handle4, "php_startup");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 4, error);
    exit(1);
    }

    startup5 = dlsym(handle5, "php_startup");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 5, error);
    exit(1);
    }

    startup6 = dlsym(handle6, "php_startup");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 6, error);
    exit(1);
    }

    if(!(*startup4)) {
    fprintf(stderr, "Failed to startup PHP %d\n", 4);
    exit(1);
    }

    if(!(*startup5)) {
    fprintf(stderr, "Failed to startup PHP %d\n", 5);
    exit(1);
    }

    if(!(*startup6)) {
    fprintf(stderr, "Failed to startup PHP %d\n", 6);
    exit(1);
    }

    parse_code4 = dlsym(handle4, "parse_php_code");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 4, error);
    exit(1);
    }

    parse_code5 = dlsym(handle5, "parse_php_code");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 5, error);
    exit(1);
    }

    parse_code6 = dlsym(handle6, "parse_php_code");
    if((error = dlerror()) != NULL) {
    fprintf (stderr, "PHP%d: %s\n", 6, error);
    exit(1);
    }

    fp = fopen(argv[1], "r");
    if(fp == NULL) {
    fprintf (stderr, "Error opening php file %s\n", argv[1]);
    exit(1);
    }
    buffer = (char *) malloc(13);
    ver = (char *) malloc(2);
    fread(buffer,1,12,fp);
    if(strcmp(buffer,"<?php //PHP ") == 0) {
    fread(ver,1,1,fp);
    } else {
    ver = "6";
    }

    if(strcmp(ver,"4") == 0) {
    printf("%d\n",(*parse_code4)(argv[0]));
    } else if(strcmp(ver,"5") == 0) {
    printf("%d\n",(*parse_code5)(argv[0]));
    } else if(strcmp(ver,"6") == 0) {
    printf("%d\n",(*parse_code6)(argv[0]));
    } else {
    printf("%d\n",(*parse_code5)(argv[0]));
    }

    dlclose(handle4);
    dlclose(handle5);
    dlclose(handle6);
    return 0;
    }
    --------------------/loader.c--------------------

    Test files used:
    --------------------test4.php--------------------
    <?php //PHP 4 ?>
    --------------------/test4.php--------------------
    --------------------test5.php--------------------
    <?php //PHP 5 ?>
    --------------------/test5.php--------------------
    --------------------test6.php--------------------
    <?php //PHP 6 ?>
    --------------------/test6.php--------------------

    Compiled with:
    gcc -shared -fPIC php4.c -o libphp4.so
    gcc -shared -fPIC php5.c -o libphp5.so
    gcc -shared -fPIC php6.c -o libphp6.so
    gcc -rdynamic -o loader loader.c -ldl

    Test results:
    ./loader ./test4.php (Outputs 4)
    ./loader ./test5.php (Outputs 5)
    ./loader ./test6.php (Outputs 6)
  • Rasmus Lerdorf at Jul 14, 2007 at 4:10 pm

    Tijnema wrote:
    On 7/14/07, Stanislav Malyshev wrote:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.
    This means the engines would have to init/shutdown on each request,
    which makes it as bad as CGI.
    Is that really a big problem?
    If you care at all about performance, yes.
    And isn't that what Apache currently does?
    No, of course not. The whole point of the Apache module version of PHP
    is to keep PHP in memory across requests and only call the MINIT and
    MSHUTDOWN hooks on server startup and shutdown.

    Not to sound too elitist here, and this is directed just at you
    personally, but if you are going to post to the internals list, you
    should have some notion of how PHP works internally. We don't mind
    people who don't work on the code posting here occasionally, but please
    keep in mind that it is our primary means of communicating amongst the
    people working on the code and lately it has gotten a bit hard to pick
    out the useful stuff from the chatter.

    -Rasmus
  • Rasmus Lerdorf at Jul 14, 2007 at 4:12 pm

    Rasmus Lerdorf wrote:
    Not to sound too elitist here, and this is directed just at you
    Argh! That should of course have been, "this isn't directed just at you..."

    -Rasmus
  • Tijnema at Jul 15, 2007 at 1:01 am

    On 7/14/07, Rasmus Lerdorf wrote:
    Tijnema wrote:
    On 7/14/07, Stanislav Malyshev wrote:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default version
    and issue a warning.
    This means the engines would have to init/shutdown on each request,
    which makes it as bad as CGI.
    Is that really a big problem?
    If you care at all about performance, yes.
    Well, I do, because if I don't, it won't be accepted anywhere.
    And isn't that what Apache currently does?
    No, of course not. The whole point of the Apache module version of PHP
    is to keep PHP in memory across requests and only call the MINIT and
    MSHUTDOWN hooks on server startup and shutdown.
    Thank you for your very short manual on Apache Module. So, the only
    way I can implement this (without the performance hit), is by loading
    all PHP version at once at startup of apache, which will increase
    startup time, but that shouldn't be a problem. A more worrysome thing
    is the memory usage, I don't think that in the code is described how
    much memory it takes to load and startup PHP, can you give an
    estimate?
    Not to sound too elitist here, and this is directed just at you
    personally, but if you are going to post to the internals list, you
    should have some notion of how PHP works internally. We don't mind
    people who don't work on the code posting here occasionally, but please
    keep in mind that it is our primary means of communicating amongst the
    people working on the code and lately it has gotten a bit hard to pick
    out the useful stuff from the chatter.

    -Rasmus
    Thank you for clarifying the intention of this list, as I had another
    intention of it. So, I'll start studying (docs of) the code soon. I
    think it would be the best to actually work with the core too, so I
    think I'll just start to implement this idea while learning how
    everything works.

    Tijnema
  • Arnold Daniels at Jul 17, 2007 at 8:09 pm
    Hi,

    Sorry for this late reaction, but I was away for a few days.

    We (as ISP) have solved this by running multiple instanced of
    Apache. This way you can switch the IP in DNS to switch between PHP
    versions. You only need 1 install of Apache and do not need to copy/move
    any files while switching. As hosting company you can't really ask your
    clients to change their scripts anyway. This way they can simply choose
    the PHP version in the control panel.

    I have written a short howto about this a while ago:
    http://blog.adaniels.nl/?p=13, (showing how well my blog is read). I
    have fine-tuned the method since than, this was more a test setup, so if
    you want to know more, please let me know.

    Best regards,
    Arnold

    Tijnema wrote:
    On 7/14/07, Rasmus Lerdorf wrote:
    Tijnema wrote:
    On 7/14/07, Stanislav Malyshev wrote:
    The Apache2handler SAPI should be loaded first, and read the very
    first line of the PHP script to determine if a version is specified
    there. If not, the handler needs to load its default PHP
    version. If
    it is specified, it should try to load that version, and if it
    couldn't find or load that version, fall back to the default
    version
    and issue a warning.
    This means the engines would have to init/shutdown on each request,
    which makes it as bad as CGI.
    Is that really a big problem?
    If you care at all about performance, yes.
    Well, I do, because if I don't, it won't be accepted anywhere.
    And isn't that what Apache currently does?
    No, of course not. The whole point of the Apache module version of PHP
    is to keep PHP in memory across requests and only call the MINIT and
    MSHUTDOWN hooks on server startup and shutdown.
    Thank you for your very short manual on Apache Module. So, the only
    way I can implement this (without the performance hit), is by loading
    all PHP version at once at startup of apache, which will increase
    startup time, but that shouldn't be a problem. A more worrysome thing
    is the memory usage, I don't think that in the code is described how
    much memory it takes to load and startup PHP, can you give an
    estimate?
    Not to sound too elitist here, and this is directed just at you
    personally, but if you are going to post to the internals list, you
    should have some notion of how PHP works internally. We don't mind
    people who don't work on the code posting here occasionally, but please
    keep in mind that it is our primary means of communicating amongst the
    people working on the code and lately it has gotten a bit hard to pick
    out the useful stuff from the chatter.

    -Rasmus
    Thank you for clarifying the intention of this list, as I had another
    intention of it. So, I'll start studying (docs of) the code soon. I
    think it would be the best to actually work with the core too, so I
    think I'll just start to implement this idea while learning how
    everything works.

    Tijnema

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 11, '07 at 10:44p
activeJul 17, '07 at 8:09p
posts28
users12
websitephp.net

People

Translate

site design / logo © 2022 Grokbase