[RFC] Rewrite in PHP (v2.0)

[philsturgeon]

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

Field	Type	Description
id	autoint
name	string	Things like Ubuntu 27.04 (Farty Ferrit)
url	string

distributions_events

Field	Type	Description
default_php_version	string
date	datetime
is_confirmed	bool	This will be set to true by the moderator, otherwise its just considered lies from a stranger.

hosts

Field	Type	Description
id	autoint
name	string
url	string

hosts_events

Field	Type	Description
is_shared_host	bool	Heroku would be false. 1&1 would be true.
latest_patch_versions	hstore (php52=5.2.1, etc)
default_php_version	string	Which PHP version will be there by default.
patch_policy	enum[them,you]	Who is in charge of updating patch versions of PHP? These could be a bug fix and you might be on holiday, so them is good.
manual_update_major_minor	bool	Can you easily switch your website to a different major or minor version.
date	datetime	When was this suggested
is_confirmed	bool	This will be set to true by the moderator, otherwise its just considered lies from a stranger.

versions

Field	Type	Description
version	string
eol_at	datetime	When does this thing EOL roughly/exactly?
has_vulnerabilities	bool	the cron job should flip this to false if it finds vulns on the API.
checked_at	datetime

vulnerabilities

Field	Type	Description
cve_id	string
risk	numeric
summary	text
fix_base_versions	array	Each minor branch will have a patch you should update to to fix this. Conflicted a bit because it'll recommend 4.0.0 users update to 4.0.1 which has its own issues. but hey, whatever for now.

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().

[bryannielsen]

Do you have any interest in showing versions for all the host's different packages (shared, vps, etc...) or just a general overview? Not sure if it's worth trying to support something like that, i.e. hostgator.

I'm happy to start jumping into some of the dev work if you'd like, the quickest route for me would be Laravel/Lumen if you're okay with that direction.

[philsturgeon]

Lumen would be fine. I was going to go with Slim myself but either one.

I've been trying to avoid VPS, as that has a lot of extra control. If you can install whatever you want then it probably doesn't matter, but I haven't used a VPS in forever.

[bryannielsen]

Ah that's a great point about VPS.

This seems like a good plan to start from. How would you like to organize this, I can get going on a fork or if you want it as a branch on this repo that works too. I'm not sure what the best way to get a few people on this would be. You in @jackmcdade ?

[philsturgeon]

Make a master branch and start it in there. I think dingo/api works with Lumen so that might be a good way to go.

If @jackmcdade is in that'll be lovely. I warn you though, the plan for this is to eventually shove in affiliate links and make a bit of money, and @drsii wanted to do the same, so we might have some things to work out later.

I don't care about the money too much, but Dan might, and setting up 5 way splits might get complicated. If y'all want to just make it and worry about that crap later it's fine with me.

[bryannielsen]

Okay that sounds good to me, I've used dingo with L4 and it looks like they've got some alpha support for Lumen so we can head that route. I'll plan to jump in shortly, never thought about the money. I guess all I'd ask is if it becomes a large revenue stream then it would be split in some way proportional to contribution (but weighted to founders). Obviously that's extremely hazy and I'm not overly concerned with it, just leave it at good faith for now.

[philsturgeon]

That’s how we worked things at PyroCMS and it worked out well enough for years. Worry about getting the work done before you worry about how to spend the millions. :)

[bryannielsen]

Haha perfect, though I've already planned for the millions...

[philsturgeon]

https://www.youtube.com/watch?v=aqqfGXrX__8

[GaryJones]

Can I suggest some Datatables output for the front-end? Would allow the content to be re-ordered by default PHP version, patch version for a particular major version etc.

[philsturgeon]

Want the moon on the stick as well?! 

But yeah ok thats a great idea.

[GaryJones]

Want the moon on the stick as well?!

Only if I could sort it along with other planatery bodies.

[bryannielsen]

Hey @philsturgeon sorry for the huge delay, I finally got to making some progress on this over the weekend and I don't think it should be too much longer before the api is ready to critique.
Full disclosure I haven't really had "free time" in the past 18 months so I haven't read your book yet and you might want to choke me... it's on my list for sure, maybe over Christmas :-)

Anyhow just wanted to give you an update and let you know I hadn't forgotten about this.

[philsturgeon]

Hey I'm not gonna complain. Taking what you've done as a base might be good. We could even pair up and do it on livestream.tv for giggles and I can enforce some "Wont Hate" on it.

[bryannielsen]

Yea that would be awesome, I'll ping you when I'm a good bit further and maybe we can setup a time to pair through some pieces.

[KorvinSzanto]

Where is this effort located? I'm interested in helping out.

[GaryJones]

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

Please don't just rely on colour - the colour-blind folks will apprecate patterned (coloured) backgrounds.

Also, each version that is vulnerable should have non-visible screen reader text (clip approach with CSS, not display: none;), for those using screen readers. i.e.

<td class="vulnerable">5.2.4 <span class="screen-reader-text">vulnerable</span></td>

[philsturgeon]

Great point Gary. 

There will be tooltips and links for “More info” absolutely, and we can make sure those are screen-readable.

-- 
Phil Sturgeon

I talk about turtles, bikes and code over here philsturgeon.uk

From: Gary Jones notifications@github.com
Reply: philsturgeon/phpversions.info reply@reply.github.com
Date: November 2, 2015 at 5:14:32 AM
To: philsturgeon/phpversions.info phpversions.info@noreply.github.com
CC: Phil Sturgeon me@philsturgeon.uk
Subject:  Re: [phpversions.info] [RFC] Rewrite in PHP (v2.0) (#82)

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

Please don't just rely on colour - the colour-blind folks will apprecate patterned (coloured) backgrounds.

Also, each version that is vulnerable should have non-visible screen reader text (clip approach with CSS, not display: none;), for those using screen readers. i.e.

5.2.4 vulnerable — Reply to this email directly or view it on GitHub.

[shrink]

Jekyll is not good for anything that isn't a blog, it's one of the worst static site platform choices for a site that requires more than just x listing on one page, so discounting a static site on the basis that the current site is far-from-great might be a mistake, as there are far superior static site solutions out there.

Having the data in the GitHub repository and using pull requests to manage the data provides lots of advantages for open source projects like this, where distributing information is the purpose, for example you don't have to build out moderation tools, you don't have to mediate requests, the project can effectively run itself (aside from accepting pull requests, but that's one click, and you can assign collaborators).

I'd suggest sticking with a static site, but using a different static site solution, something like Metalsmith (not php, node, very good!). Metalsmith is perfect for handling projects that are more complex than a blog, and it's straight forward to learn and use. I have been using it for my project httpstatuses.com (citricsquid/httpstatuses on GitHub -- see build.js for the brains). You could conceivably build a replacement using Metalsmith very quickly, and you could deploy to GitHub pages if you like.

I'll volunteer to rebuild the current site with Metalsmith as a starting point for future improvements if you're willing to reconsider the static site approach, although design isn't my strong suit so limited improvements in that area, but I can deliver a Metalsmith driven phpversions.info this weekend if you give the go ahead (looks like the PHP version has stalled?).

(Since CircleCI is free for open source projects, for the building we can use CircleCI and GitHub pages for hosting, nothing would change there.) Nevermind, you're already using circle.

[philsturgeon]

Thanks for offering but that won't achieve any of our goals.

Jekyll was fine as a choice because it was temporary, and I always knew that we'd need to change to use a database and get this thing automated. If you switch to another static site generator it won't help us achieve any of our goals and is kinda wasting time.

Thanks for your feedback! It's nice that people are interested in this project now PHP 7 is out :)

Phil Sturgeon
Sent from my iPhone and there's probably typos because I'm probably at the pub.

On Dec 4, 2015, at 7:25 PM, Samuel Ryan notifications@github.com wrote:

Jekyll is not good for anything that isn't a blog, it's one of the worst static site platform choices for a site that requires more than just x listing on one page, so discounting a static site on the basis that the current site is far-from-great might be a mistake, as there are far superior static site solutions out there.

Having the data in the GitHub repository and using pull requests to manage the data provides lots of advantages for open source projects like this, where distributing information is the purpose, for example you don't have to build out moderation tools, you don't have to mediate requests, the project can effectively run itself (aside from accepting pull requests, but that's one click, and you can assign collaborators).

I'd suggest sticking with a static site, but using a different static site solution, something like Metalsmith (not php, node, very good!). Metalsmith is perfect for handling projects that are more complex than a blog, and it's straight forward to learn and use. I have been using it for my project httpstatuses.com (citricsquid/httpstatuses on GitHub -- see build.js for the brains). You could conceivably build a replacement using Metalsmith very quickly, and you could deploy to GitHub pages if you like.

I'll volunteer to rebuild the current site with Metalsmith as a starting point for future improvements if you're willing to reconsider the static site approach, although design isn't my strong suit so limited improvements in that area, but I can deliver a Metalsmith driven phpversions.info this weekend if you give the go ahead (looks like the PHP version has stalled?).

—
Reply to this email directly or view it on GitHub.

[shrink]

Thanks for the prompt reply! As I see it all the goals outlined are achievable with a static site but completely understand if that isn't your vision for the project. Has there been any progress on the PHP v2.0, anywhere we can jump in to help or does someone need to kickstart the effort?

[bryannielsen]

I started things off but have been swamped with life. I'll push my fork this weekend in case somebody else can help push it along.

[bryannielsen]

Here's the work I've done so far - https://github.com/bryannielsen/phpversions.info/tree/dynamic I can probably get another push in this coming weekend and get things a bit further. @philsturgeon I did end up getting a copy of your book through my employer and it has been super helpful for one of our projects. If I can find another evening for this I can get it in a better spot.

[matthewtrask]

Im closing this for now. Ive started down a path and am not far from being done based on the issue here. Will open a checklist issue this week.