New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Facilitate switching PHP versions between 5.2.4, 5.3.x, 5.4+ #98

Closed
westonruter opened this Issue Jul 16, 2013 · 13 comments

Comments

Projects
None yet
8 participants
@westonruter
Member

westonruter commented Jul 16, 2013

Since the minimum requirements for WordPress are 5.2.4, and since the vast majority of WordPress installs are still on PHP 5.2 followed by PHP 5.3, it is not very helpful that VVV comes with PHP 5.4.17RC1. In order to ensure broad compatibility in plugins and themes developed across the WordPress ecosystem, it's important that they be testable in the lowest version of PHP. It would be ideal if there could be some command to switch between PHP versions on the fly, or even better to assign different PHP versions to each site instance. I'm not sure what is feasible at the moment.

@simonwheatley

This comment has been minimized.

Show comment
Hide comment
@simonwheatley

simonwheatley Jul 16, 2013

Contributor

Installing a specific PHP version in the initial provisioning when running vagrant up would certainly be possible, the apt-get command is discussed here: http://askubuntu.com/a/116586

How this would work in the context of this vagrant, e.g. how you would trigger the provisioning of a PHP 5.3 machine rather than PHP 5.4, I'm unsure. Can you prompt the user during provisioning? One (possibly dubious) option might be to split into multiple machines: http://docs.vagrantup.com/v2/multi-machine/index.html You could then run vagrant up php53, though I think you'd end up firing up any and all machines on a simple vagrant up, which could be confusing.

(I've always been a little nervous of merrily upgrading and downgrading PHP on a "running" machine, but perhaps someone else has experimented with this.)

Contributor

simonwheatley commented Jul 16, 2013

Installing a specific PHP version in the initial provisioning when running vagrant up would certainly be possible, the apt-get command is discussed here: http://askubuntu.com/a/116586

How this would work in the context of this vagrant, e.g. how you would trigger the provisioning of a PHP 5.3 machine rather than PHP 5.4, I'm unsure. Can you prompt the user during provisioning? One (possibly dubious) option might be to split into multiple machines: http://docs.vagrantup.com/v2/multi-machine/index.html You could then run vagrant up php53, though I think you'd end up firing up any and all machines on a simple vagrant up, which could be confusing.

(I've always been a little nervous of merrily upgrading and downgrading PHP on a "running" machine, but perhaps someone else has experimented with this.)

@johnpbloch

This comment has been minimized.

Show comment
Hide comment
@johnpbloch

johnpbloch Jul 16, 2013

Contributor

My gut reaction is that there are much better tools out there for broad testing across versions of PHP than a Vagrant being used to facilitate rapid local development. For example, many plugins will run their unit tests on Travis using PHP 5.2, 5.3, 5.4, and 5.5, for the stable version of WP, the previous version, and trunk, all in both multisite and single site mode.

Contributor

johnpbloch commented Jul 16, 2013

My gut reaction is that there are much better tools out there for broad testing across versions of PHP than a Vagrant being used to facilitate rapid local development. For example, many plugins will run their unit tests on Travis using PHP 5.2, 5.3, 5.4, and 5.5, for the stable version of WP, the previous version, and trunk, all in both multisite and single site mode.

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Jul 16, 2013

Member

There is a place in the ecosystem for a Vagrant that does handle this type of switching for thorough testing of plugins and themes that are being developed for possible use in multiple environments. VVV is probably not that place, as it's default configuration is intended to match what 10up considers to be a common setup for high traffic WordPress sites.

PHP 5.4.17RC1 being installed rather than the latest stable (5.4.17) is another issue that should be sorted out.

Member

jeremyfelt commented Jul 16, 2013

There is a place in the ecosystem for a Vagrant that does handle this type of switching for thorough testing of plugins and themes that are being developed for possible use in multiple environments. VVV is probably not that place, as it's default configuration is intended to match what 10up considers to be a common setup for high traffic WordPress sites.

PHP 5.4.17RC1 being installed rather than the latest stable (5.4.17) is another issue that should be sorted out.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jul 16, 2013

Member

For example, many plugins will run their unit tests on Travis using PHP 5.2, 5.3, 5.4, and 5.5, for the stable version of WP, the previous version, and trunk, all in both multisite and single site mode.

Great point. Travis is a nice solution to test on other PHP versions, but it would be nice to not have to rely on this external service to do so.

There is a place in the ecosystem for a Vagrant that does handle this type of switching for thorough testing of plugins and themes that are being developed for possible use in multiple environments.

Where is this place?

Member

westonruter commented Jul 16, 2013

For example, many plugins will run their unit tests on Travis using PHP 5.2, 5.3, 5.4, and 5.5, for the stable version of WP, the previous version, and trunk, all in both multisite and single site mode.

Great point. Travis is a nice solution to test on other PHP versions, but it would be nice to not have to rely on this external service to do so.

There is a place in the ecosystem for a Vagrant that does handle this type of switching for thorough testing of plugins and themes that are being developed for possible use in multiple environments.

Where is this place?

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Jul 16, 2013

Member
Where is this place?

Nowhere. Somewhere. :)

@tollmanz and I had some talks about what it could look like. I have a name for it, but nothing else yet. Really, it's a space to be filled.

Member

jeremyfelt commented Jul 16, 2013

Where is this place?

Nowhere. Somewhere. :)

@tollmanz and I had some talks about what it could look like. I have a name for it, but nothing else yet. Really, it's a space to be filled.

@TheLastCicada

This comment has been minimized.

Show comment
Hide comment
@TheLastCicada

TheLastCicada Jul 16, 2013

Contributor

How about in @westonruter's github account once he figures out how to accomplish this :-)

Contributor

TheLastCicada commented Jul 16, 2013

How about in @westonruter's github account once he figures out how to accomplish this :-)

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Jul 19, 2013

Member

Closing this now, though continued discussion is always welcome.

Member

jeremyfelt commented Jul 19, 2013

Closing this now, though continued discussion is always welcome.

@jeremyfelt jeremyfelt closed this Jul 19, 2013

@nerrad

This comment has been minimized.

Show comment
Hide comment
@nerrad

nerrad Oct 28, 2013

I just did a fork that adds php5.3/apache as a box. I'm not a server guru so it's fairly hackish, however for those searching for something like this feel free to use (or contribute to). I suspect the majority of vvv users don't care about running a apache/5.3 box so not doing any pull requests for adding support but feel free to school me if you think I should :)

https://github.com/nerrad/varying-vagrant-vagrants-apache

nerrad commented Oct 28, 2013

I just did a fork that adds php5.3/apache as a box. I'm not a server guru so it's fairly hackish, however for those searching for something like this feel free to use (or contribute to). I suspect the majority of vvv users don't care about running a apache/5.3 box so not doing any pull requests for adding support but feel free to school me if you think I should :)

https://github.com/nerrad/varying-vagrant-vagrants-apache

@jb510

This comment has been minimized.

Show comment
Hide comment
@jb510

jb510 Mar 9, 2014

Contributor

This is an issue again with VVV 1.2 moving to 5.5. Well an issue for me at least ;)

Wondering if we could keep 5.3, 5.4 installed and then use a handler in htaccess or a php.ini in htdocs to trigger which version runs? (note: not really familiar with the intricacies of php-fpm so maybe that's impossible).

Contributor

jb510 commented Mar 9, 2014

This is an issue again with VVV 1.2 moving to 5.5. Well an issue for me at least ;)

Wondering if we could keep 5.3, 5.4 installed and then use a handler in htaccess or a php.ini in htdocs to trigger which version runs? (note: not really familiar with the intricacies of php-fpm so maybe that's impossible).

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Mar 9, 2014

Member

The immediate solution (beyond sticking with v1.1) is to change the custom apt source back to php55-oldstable. This may introduce other dependency issues, but will probably go relatively smooth.

It's tough, but I think good that we start moving up to PHP 5.5 sooner than later. I'm not sure how well we can get nginx/php-fpm floating around between versions, but that would definitely be a custom setup.

Member

jeremyfelt commented Mar 9, 2014

The immediate solution (beyond sticking with v1.1) is to change the custom apt source back to php55-oldstable. This may introduce other dependency issues, but will probably go relatively smooth.

It's tough, but I think good that we start moving up to PHP 5.5 sooner than later. I'm not sure how well we can get nginx/php-fpm floating around between versions, but that would definitely be a custom setup.

@getsource

This comment has been minimized.

Show comment
Hide comment
@getsource

getsource Mar 11, 2014

Now that VVV is more of a community project, rather than only a general 10up development tool, it'd be great for it to have either multiple boxes per PHP version, or to have a simple way to swap versions for unit/integration testing.

PHP 5.5 is not currently a common setup -- at least for now -- and making it easier to test multiple versions would be a welcome addition.

getsource commented Mar 11, 2014

Now that VVV is more of a community project, rather than only a general 10up development tool, it'd be great for it to have either multiple boxes per PHP version, or to have a simple way to swap versions for unit/integration testing.

PHP 5.5 is not currently a common setup -- at least for now -- and making it easier to test multiple versions would be a welcome addition.

@jb510

This comment has been minimized.

Show comment
Hide comment
@jb510

jb510 Mar 11, 2014

Contributor

Sorry - going a bit off topic on this closed thread, but...

While I find VVV is great tool for trunk, it is somewhat lacking otherwise for development of many sites at once. I've long wanted to run multiple machines (vagrant servers w/ different configs) sharing a single set of files. I could never get the symlinking working though. If I only needed a couple servers or one running at a time that'd be one thing, but I need a dozen or more. It's too cumbersome to up/down vagrant instance for each site when jumping between them and too heavy to keep a multiple VMs running simultaneously. Right now I run a single VVV managed box with about a dozen active sites inside it. This setup works well for me (aside from difficultly managing juggling apache/nginx php53/54/55)

However... worth noting.. I'm actually looking at moving to Docker / Boot2Docker with docker containers for each site (vagrant-less). Vagrant becomes unnecessary in that scenario because the DockerFile syntax is simple (similar to VagrantFile) for provisioning and the only Vbox one actually needs to manage is the single Boot2Docker box. I think I can even setup the singular shared set of files I've been dreaming of. I have just started playing with it though and haven't worked out file sharing and networking but it does looks promising (and full disclosure I am far far far from an expert at any of this server devops stuff so take anything I say with a pile of salt about the size of Everest).

Contributor

jb510 commented Mar 11, 2014

Sorry - going a bit off topic on this closed thread, but...

While I find VVV is great tool for trunk, it is somewhat lacking otherwise for development of many sites at once. I've long wanted to run multiple machines (vagrant servers w/ different configs) sharing a single set of files. I could never get the symlinking working though. If I only needed a couple servers or one running at a time that'd be one thing, but I need a dozen or more. It's too cumbersome to up/down vagrant instance for each site when jumping between them and too heavy to keep a multiple VMs running simultaneously. Right now I run a single VVV managed box with about a dozen active sites inside it. This setup works well for me (aside from difficultly managing juggling apache/nginx php53/54/55)

However... worth noting.. I'm actually looking at moving to Docker / Boot2Docker with docker containers for each site (vagrant-less). Vagrant becomes unnecessary in that scenario because the DockerFile syntax is simple (similar to VagrantFile) for provisioning and the only Vbox one actually needs to manage is the single Boot2Docker box. I think I can even setup the singular shared set of files I've been dreaming of. I have just started playing with it though and haven't worked out file sharing and networking but it does looks promising (and full disclosure I am far far far from an expert at any of this server devops stuff so take anything I say with a pile of salt about the size of Everest).

@jeremyfelt

This comment has been minimized.

Show comment
Hide comment
@jeremyfelt

jeremyfelt Mar 13, 2014

Member

I think all of the purposes fit here. One development environment that is a close match to a good production environment. A default server configuration that matches a setup common to high performance WP setups. Multiple WP configurations to aid in developing for WordPress in this environment.

If there are performance concerns with PHP 5.5 that don't make it ideal for a production environment, we should cover that separately and possibly roll back to 5.4. (See #197 for the conversation that brought in 5.5)

I'm planning on using it in production and made the shift from APC to Zend Opcache in the last few revs of PHP 5.4.x to check for surprises. Overall, I'm okay erring on the side of shifting the VVV configuration earlier than later to try and push for continued change.

It may be possible to use auto site setup scripts to install multiple versions of PHP on demand or to replace the version shipped with VVV. I can visualize it, but haven't actually tried it. If anything can be changed in the core provisioning to help that process, it would be great to get that in. I don't think we should provide that by default.

We do have a VVV-docker repository up after the great conversation in #258. I think it's possible that the ideas explored in that conversation could lead to a Docker/Vagrant setup that handles multiple PHP/MySQL/Nginx/Apache versions very well. If anybody is willing to start charging forward there and would like to do it as part of the VVV community, commit access will be granted liberally at the beginning. :)

Member

jeremyfelt commented Mar 13, 2014

I think all of the purposes fit here. One development environment that is a close match to a good production environment. A default server configuration that matches a setup common to high performance WP setups. Multiple WP configurations to aid in developing for WordPress in this environment.

If there are performance concerns with PHP 5.5 that don't make it ideal for a production environment, we should cover that separately and possibly roll back to 5.4. (See #197 for the conversation that brought in 5.5)

I'm planning on using it in production and made the shift from APC to Zend Opcache in the last few revs of PHP 5.4.x to check for surprises. Overall, I'm okay erring on the side of shifting the VVV configuration earlier than later to try and push for continued change.

It may be possible to use auto site setup scripts to install multiple versions of PHP on demand or to replace the version shipped with VVV. I can visualize it, but haven't actually tried it. If anything can be changed in the core provisioning to help that process, it would be great to get that in. I don't think we should provide that by default.

We do have a VVV-docker repository up after the great conversation in #258. I think it's possible that the ideas explored in that conversation could lead to a Docker/Vagrant setup that handles multiple PHP/MySQL/Nginx/Apache versions very well. If anybody is willing to start charging forward there and would like to do it as part of the VVV community, commit access will be granted liberally at the beginning. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment