-
-
Notifications
You must be signed in to change notification settings - Fork 141
[RFC] Rewrite in PHP (v2.0) #82
Comments
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. |
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. |
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 ? |
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. |
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. |
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. :)
|
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. |
Want the moon on the stick as well?! But yeah ok thats a great idea. |
Only if I could sort it along with other planatery bodies. |
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. Anyhow just wanted to give you an update and let you know I hadn't forgotten about this. |
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. |
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. |
Where is this effort located? I'm interested in helping out. |
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 ( <td class="vulnerable">5.2.4 <span class="screen-reader-text">vulnerable</span></td> |
Great point Gary. There will be tooltips and links for “More info” absolutely, and we can make sure those are screen-readable. -- I talk about turtles, bikes and code over here philsturgeon.uk From: Gary Jones notifications@github.com 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. |
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?).
|
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
|
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? |
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.
|
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. |
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. |
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
Ubuntu 27.04 (Farty Ferrit)
distributions_events
hosts
hosts_events
them
is good.versions
false
if it finds vulns on the API.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.
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 toNOW()
.The text was updated successfully, but these errors were encountered: