phpversions / phpversions.info Goto Github PK

What are your thoughts on adding a section for managed hosting?

For example, my employer primarily does managed VPS hosting - we handle everything for clients who don't have the expertise or time to configure the OS, install packages, tweak performance, install security updates, upgrade their CMS/framework, etc. We support PHP 7.0.3 but don't fit under the umbrella of Shared Hosting or PaaS.

Would you be interested in adding a section for managed hosts or would you prefer sticking with "self-service" providers?

Because 1and1 for example gives you php4.4.9 or something around that when you connect via SSH.

It would be awesome to get PHP 7.3 section started... Thank you for all the good efforts from this site.

per wordcamp

The "default" version is showing under the header for 5.3:

Hello, I'm not sure if this site is still maintained but it might be good to add PHP 8.2... Thank you.

According to http://blog.ircmaxell.com/2014/12/php-install-statistics.html:

Debian 7 (Wheezy) 5.4.4
Debian 6 (Squeeze) 5.3.3
Ubuntu 14.10 (Utopic) 5.5.12
Ubuntu 14.04 (Trusty) 5.5.9
Ubuntu 12.04 (Precise) 5.3.10
Ubuntu 10.04 (Lucid) 5.3.2
CentOS 7.0 5.4.16
CentOS 6.6 5.3.3
CentOS 5.11 5.1.6

Looks like entries on the site are there multiple times. It looks like not only the last scan run is displayed but all scan runs. Is that necessary?

The new "Managed Hosts" link causes weird sizing when you shrink the screen width:

the domain has been up for a while, and now that it is there and not broken, we need to come up with a list of things to do in order to end the .info and move to the .org permanently.

• See about a 301 redirect on the .info repo to the .org project
• Put together last commands to make sure .org is fully automated
• Hook in Twitter API so we can help promote hosts as we merge in

What else am I missing? It's still early and I haven't had any coffee yet.

Ideally, we should probably note that 5.2 and 5.3 are EOL, 5.4 is security fixes only, 5.5 and 5.6 are currently supported.

Or just prominently link to http://php.net/eol.php and http://php.net/supported-versions.php

https://runcloud.io/

from wordcamp.

@outlandishjosh on twitter

1&1 say they offer PHP 7 beta (under "Tools"), providing very little in the way of specifics.

Should they be on the PHP 7 page? If so, as what?

There seems to be a bug in sturgeon/phparse: philsturgeon/phparse#1. As a result, this project is unable to update PHP 7.3 infos.

I've submitted a PR to that project. If for any reason it can't be (or isn't) merged, I'll instead use https://github.com/cweagans/composer-patches to patch the library locally.

at least up to 7.2

If we call whatever crap is up there now to be v1.0, then v2.0 should be the bigger, better and more badass version.

Right now it's a Jekyll based site with a YAML data store, which people have to send PRs too. That's obviously not ideal.

1. Database

I want to have a database powering this, with the following schema:

distributions

distributions_events

hosts

hosts_events

versions

vulnerabilities

The events stuff is all there so we can show a history, and not just "what it looks like right now." This will make for some interesting graphs one day, but mostly also a handy "history" page for v3.0.

2. Frontend

Exactly what it is now is fine for v2.0, but have red/yellow/green cell shading.

• red - has vulnerabilities
• yellow - EOL so upgrade dammit
• green - so far so good

In addition to this, we need two basic-ass forms

Report Distribution Versions

Dropdown of distributions, or a "Submit new Distribution" option. Then enter the bundled PHP version and you're done.

Report Host Versions

Dropdown of hosts, or a "Submit new Host" option.

Show input boxes for 5.2.[ ], 5.3.[ ], 5.4.[ ], 5.5.[ ], 5.6.[ ], 7.0.[ ]. Leave it empty if unknown or not supported.

Shove that all in an email to me, and I'll ssh into the production DB because yolo.

3. CRON

We should have a cron job running every few hours that looks up each version used by distros and hosts, and check to see if its secure by hitting http://phpsecinfo.com/version/5.6.5.

If it has vulnerabilities, save them in the vulnerabilities table and set has_vulnerabilities to true. Regardless, set checked_at date to NOW().

I like how the .info site displays the versions:

• All version numbers are shown. Currently, the .org site will hide 7.2 version numbers if the host supports 7.3. This means that anyone looking for 7.2 hosting won't see their full range of options.
• The order of hosts is determined by how up-to-date their versions are, not alphabetically. This gives hosts an incentive to keep their versions (and phpversions data) up-to-date so they rank higher in our display.

Thoughts on including these features in the new .org site?

Add a "Secure or not" indicator to PHP versions at the patch level, using output from this https://github.com/psecio/versionscan

For now just put a secure: true/false field in, but we could get really granular later and list actual issues. This would be great at reminding people not to use a certain host, or get people to ask them to update.

IMHO the goal of this site is two-fold:

1. Encourage web hosts to keep their versions of PHP up-to-date.
2. Connect web developers with web hosts who do that ^

To better achieve this goal, what if we change the default sort order to promote the hosts who keep up-to-date versions to the top? Basically sorting by PHP 7.3.x DESC then PHP 7.2.x DESC (as a tie-breaker) then PHP 7.1.x DESC (as a tie breaker) etc.

So the results would look less like this:

And more like this:

With lots of green versions up top! (Note that I'm only sorting by one column here, but you get the gist.)

Do you think this is a worthwhile idea?

The bin/update-versions script is unable to update PHP beta versions (and likely release candidate versions) due to the format of PHP beta release version numbers not being valid semantic versioning according to vendor/naneau/semver/src/Naneau/SemVer/Regex.php.

$ php7.0-sp bin/update-versions

...

Parsing ServerPilot PHP 71 from: http://php71.serverpilot-phpversions.info/
-- ERROR: Failed to parse ServerPilot

"7.1.0beta3" is not a valid SemVer

https://pantheon.io/features

Cheers! :)
=C=

The shared hosting page is currently sorting alphabetically and by case. This seems wrong since it is "brand" names that are being sorted. e.g. names.co.uk now appears at the end, rather than in the middle.

LiquidWeb's shared hosting information is missing 5.6.XX.
Additionally LiquidWeb is missing from the managed hosting page. There are offerings of both shared and dedicated hosting types.

I will include pull requests to update these missing or outdated details.

on 7.1.x per wordcamp.com conf

It appears some PHP versions are showing red, even with a publicly available phpinfo page to verify the version.

I think OVH allow the user to change the PHP version in use, see: https://www.ovh.ie/g1175.php-fpm-optimisation

On Linode, you control which operating system is installed. So, you have absolute control over which version of PHP is on there.

While not as relevant as Linux Distributions, I still find myself searching for that info occasionally.

I have access to a couple of different OS X versions. If there's interest, I can try to get some historical data.

http://en.wikipedia.org/wiki/Endurance_International_Group

7.1.2 is latest from godaddy host

Is this the expected behavior or should this show just 7.0.6 instead?

The old Travis CI build process doesn't seem to be working, so updates made to this repository are not getting reflected on the website.

https://www.siteground.com/dedicated-hosting.htm

Cheers! :)
=C=

Microsoft Azure Web App, the Linux variant, only supports the following: 7.4 and 8.0, with 7.4 support ending 2022 November 28. Microsoft Azure Web App, the Windows variant, will not support PHP 8.x.

I think the current graph is confusing , many shared hosts do not offer any versions or upgrades, rather they just have a default.

Maybe have 2 graphs:
One for shared hosts with only default
One for specialized hosts that allow version switching or upgrades (cloud/VPS/etc).

The real problem is shared hosting and the liability with upgrading a server that might have 5k websites on it.

• OVH http://fpm7.0-check.cluster015.ovh.net/phpinfo.php
• HostEurope http://php56.hosteurope-infos.de/phpinfo.php

Please add any more you know of in the comments and I'll get this into a Jekyll build step for now, then make something fancy for #82.

There are two branches. The default branch master, and the active branch gh-pages. I fixed the fatal errors on the master branch and it builds, but the active branch still isn't updating with the new information. This means the site http://phpversion.info/ isn't updating still. I see a pull on master branch titled "Manual update oops" from @philsturgeon on 2017-05-24, but that doesn't seem to have updated the files on the website either since they all show 2+ months since the last update and new hosts haven't been added. If there is anything I can do to help let me know. :)

Appears phpversions.info hasn't updated in a couple months, is this expected?

Took me and some other guys quite some time to figure out that the number [provided in a table cell for a specific PHP version (for e.g. 5.4)] actually is the patch level version. Would be nice to note that somewhere - preferably above the table.

For v2 (install/dev steps/etc)

PHP 7.4 is just around the corner. We'll want to update the table output and version sorting to take those versions into account.

Now that PHP 7.1 is out, the New and Shiny page wording needs updating.

I need the domain name, so I can spin up a server and move things around since I have started rewriting this application. Do you know who has it?

The data config file has versions stored as just the PATCH version (39 for 6.1.39). Only the default key is the full version string.

This makes the display of data confusing. Instead of showing full version strings you have tables of what looks like random numbers. Sometimes question marks. Sometimes RC version strings.

So the fix is to either have the config file use full version strings (easiest, sort might need fixing) or have a jekyll plugin to display the correct version string given the patch version (RC4 -> RC4, 13 -> 5.1.13, ?? -> unknown etc.)

Hey yall,

As this project gets bigger (met a ton of mainline hosts for Wordpress yesterday with tons of interest), I wanted to make a check list here of things we should do/will do to bump this:

a. off jekyll and into PHP
b. write a few things that will help us automate this easier.

So the list which will be updated as we go is as follows:

• Move to PHP 7.2 (Forge/DO)
• Build base platform on Laravel (I want to use it to build it, but not rely on Laravel)
• Keep the way we add information - data.yml file (parse it by PHP/Laravel)
• REST API for Twitter bot (I want to alert hosts their PHP is out of date, and automate it)
• instructions for hosts to help us automate it i.e. they expose /version or something, and it returns a JSON/YML/whatever response of the version. More reliable.

On CircleCI container istance, php ./bin/update-versions check for Debian 6 breaks, maybe due to LTS ended on 2016-02-29.

https://packages.debian.org/squeeze/php5 URL used in CI container returns an error, at least human recognizable.

wheezy and jessie URLs are returning useful response