# php.net website - Thread: https://externals.io/message/99937 - Original archive: https://news-web.php.net/php.internals/99937 - Started by Mathias Grimm on 2017-07-19T17:07:14+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/99937.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #99937 — Mathias Grimm — 2017-07-19T17:07:14+00:00 URL: https://externals.io/message/99937#99937 Hi, I would like to know who is/are "in charge" of the website ( https://github.com/php/web-php). I think I would like to help improving it a bit. I can possibly understand the reasons why it is still like it is, code wise, but I think there is a lot of room from improvement. Also, from the reference point of view, I don't think it's a good example/image for the php community. I would like to understand also a little bit about how it is hosted/deployed/build etc. I was briefly asking Sara about it and as she pointed out it is likely a big project but I think we can do something about it. Cheers, Mathias Grimm --- ## #99938 — mtkocak@gmail.com — 2017-07-19T17:08:50+00:00 URL: https://externals.io/message/99937#99938 · In reply to: #99937 I can help. > > > Hi, > > I would like to know who is/are "in charge" of the website ( > https://github.com/php/web-php). > I think I would like to help improving it a bit. > > I can possibly understand the reasons why it is still like it is, code > wise, but I think there is a lot of room from improvement. Also, from the > reference point of view, I don't think it's a good example/image for the > php community. > > I would like to understand also a little bit about how it is > hosted/deployed/build etc. > > I was briefly asking Sara about it and as she pointed out it is likely a > big project but I think we can do something about it. > > Cheers, > Mathias Grimm --- ## #99939 — Sara Golemon — 2017-07-19T17:31:48+00:00 URL: https://externals.io/message/99937#99939 · In reply to: #99937 > I was briefly asking Sara about it and as she pointed out it is likely a > big project but I think we can do something about it. > One thing I should have mentioned on twitter was: https://wiki.php.net/web/mirror That'll get you a locally running web-php instance though it's not ideal for iterative development against the git repo without some massaging. As to the actual hosts: There are (I believe) two hosts actually administered by @php.net folk: us1.php.net and us2.php.net, others (AIUI) are run by third parties and not under our control. The PHP version on these hosts is, comically, not the lastest-and-greatest. I'm fairly confident it's not even consistently 7.0+ so whatever you write needs to take that into account (particularly given the status of third-party mirrors). -Sara --- ## #99940 — Niklas Keller — 2017-07-19T17:41:35+00:00 URL: https://externals.io/message/99937#99940 · In reply to: #99937 Hey, > I would like to know who is/are "in charge" of the website ( > https://github.com/php/web-php). > I think I would like to help improving it a bit. > > I can possibly understand the reasons why it is still like it is, code > wise, but I think there is a lot of room from improvement. Also, from the > reference point of view, I don't think it's a good example/image for the > php community. > Could you name a few points that need improvements? I'd really say that PHP.net a really good reference compared to other projects. > I would like to understand also a little bit about how it is > hosted/deployed/build etc. > It's built on one server and then rsynced to other servers IIRC. Regards, Niklas --- ## #99941 — Niklas Keller — 2017-07-19T17:42:53+00:00 URL: https://externals.io/message/99937#99941 · In reply to: #99939 > > On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm > wrote: > > […] > One thing I should have mentioned on twitter was: > https://wiki.php.net/web/mirror > > That'll get you a locally running web-php instance though it's not > ideal for iterative development against the git repo without some > massaging. > > As to the actual hosts: There are (I believe) two hosts actually > administered by @php.net folk: us1.php.net and us2.php.net, others > (AIUI) are run by third parties and not under our control. The PHP > version on these hosts is, comically, not the lastest-and-greatest. > I'm fairly confident it's not even consistently 7.0+ so whatever you > write needs to take that into account (particularly given the status > of third-party mirrors). > We should really change that and fully move to HTTPS. Regards, Niklas --- ## #99942 — Sara Golemon — 2017-07-19T17:50:57+00:00 URL: https://externals.io/message/99937#99942 · In reply to: #99941 > We should really change that and fully move to HTTPS. > I was actually just thinking how lovely it would be to re-architect the mirroring process to use docker images. Benefits: * Usual consistent/predictable deployment arguments... * Full control of the webserver and PHP version (and extensions) used on mirrors. * Use docker hub as the distribution channel. (https out of the box) * Extra level of isolation for site hosts (web-php isn't alone on its hosts AIUI) * Apparently we could even add container image signing. That's sort of an orthogonal project to rewriting the site code, but it's arguably a simpler task to undertake. -Sara --- ## #99943 — Mathias Grimm — 2017-07-19T18:11:58+00:00 URL: https://externals.io/message/99937#99943 > > > > > > […] > > Just one example: https://github.com/php/web-php/blob/master/releases/ > index.php > I haven't checked every file but in general I would be pretty sad if I had > to work on a code like that. > Good thing is that I am willing to work on in now :) > > > > […] > > ​Do you have more details on that? Is the build process in another repo?​ > > > […] --- ## #99944 — Mathias Grimm — 2017-07-19T18:12:22+00:00 URL: https://externals.io/message/99937#99944 I think it's a great idea about docker, although a separated project. The wiki says minimum php is 5.3 but that page is from 2013 and would be really great to not depend on the mirrors php version, although we can write beautiful php even in php 4 (never did prior to 4) > > > […] > I was actually just thinking how lovely it would be to re-architect > the mirroring process to use docker images. > > Benefits: > * Usual consistent/predictable deployment arguments... > * Full control of the webserver and PHP version (and extensions) used > on mirrors. > * Use docker hub as the distribution channel. (https out of the box) > * Extra level of isolation for site hosts (web-php isn't alone on its > hosts AIUI) > * Apparently we could even add container image signing. > > That's sort of an orthogonal project to rewriting the site code, but > it's arguably a simpler task to undertake. > > -Sara --- ## #99945 — Andreas Heigl — 2017-07-19T19:12:26+00:00 URL: https://externals.io/message/99937#99945 · In reply to: #99944 Am 19.07.2017 um 19:12 schrieb Mathias Grimm : > > I think it's a great idea about docker, although a separated project. > > The wiki says minimum php is 5.3 but that page is from 2013 and would be > really great to not depend on the mirrors php version, although we can > write beautiful php even in php 4 (never did prior to 4) I think the most important thing is that the PHP-website keeps a VanillaPHP-approach. Every library or framework used for a rewrite of the PHP-website will be looked upon with different eyes and will therefore seem to be "PHP-approved" to people not that deep into the website (so about 99% of PHP-developers). So the PHP-website would - even though that might not be intended - recommend frameworks or libraries over others. And we would not want that! Just my 0.02 € Cheers Andreas > > > > […] --- ## #99946 — Mathias Grimm — 2017-07-19T19:34:43+00:00 URL: https://externals.io/message/99937#99946 · In reply to: #99945 Thats a valid point but that can be addressed in some nice ways. The documentation can mention it somehow and that doesn't mean somebody else should use that framework/lib for every project/case. That would be similar to saying that we prefer Linux over Windows, just because we use Linux hosting and better would be to instead build our own operating system, just so that people don't get inclined to one side or another A bit of a stretch of an analogy but more or less the same idea. The fact that we use some well known framework/package would reduce the barrier to get more people involved in the project, now and for the future. Not using them is going back to 2005 when everybody had their own framework. I am not suggesting any framework in specific but think there as some good options out there. We would be quit well served with a micro-framework as we basically need just some kind http stack + routing, but that is deep down the execution plan discussion. > Am 19.07.2017 um 19:12 schrieb Mathias Grimm : > > […] > > I think the most important thing is that the PHP-website keeps a > VanillaPHP-approach. Every library or framework used for a rewrite of the > PHP-website will be looked upon with different eyes and will therefore seem > to be "PHP-approved" to people not that deep into the website (so about 99% > of PHP-developers). So the PHP-website would - even though that might not > be intended - recommend frameworks or libraries over others. And we would > not want that! > > Just my 0.02 € > > Cheers > > Andreas > > > > […] --- ## #99947 — Andreas Heigl — 2017-07-19T20:02:07+00:00 URL: https://externals.io/message/99937#99947 · In reply to: #99946 > Am 19.07.2017 um 20:34 schrieb Mathias Grimm : > > Thats a valid point but that can be addressed in some nice ways. > > The documentation can mention it somehow and that doesn't mean somebody else should use that framework/lib for every project/case. > That would be similar to saying that we prefer Linux over Windows, just because we use Linux hosting and better would be to instead build our own operating system, just so that people don't get inclined to one side or another > A bit of a stretch of an analogy but more or less the same idea. > > The fact that we use some well known framework/package would reduce the barrier to get more people involved in the project, now and for the future. > Not using them is going back to 2005 when everybody had their own framework. > > I am not suggesting any framework in specific but think there as some good options out there. > We would be quit well served with a micro-framework as we basically need just some kind http stack + routing, but that is deep down the execution plan discussion. I personally strongly disagree with that approach. Most of the pages on php.net are static pages. And those few that aren't can be well addressed with their own script and within that vanillaPHP-script the task can be solved. IMO there is no need for routing or an HTTP-Stack. And it shows that we - even in 2017 still know how to build a basic PHP-site. The entry barrier is absolutely low as no framework/library knowledge is necessary and the scripts can be easily analysed from start to end. As there are - due to the mirrored setup - no DB-queries or sessions or any other more complex stuff going on we should keep it simple and stupid. But thats - as I said - just my 0.02€ Cheers Andreas PS: As it's a pretty massive change to the infrastructure I'd personally think there should be an RFC about that. > > > > > > > […] --- ## #99950 — johannes@schlueters.de — 2017-07-19T20:16:48+00:00 URL: https://externals.io/message/99937#99950 · In reply to: #99946 > Thats a valid point but that can be addressed in some nice ways. > > The documentation can mention it somehow and that doesn't mean > somebody else should use that framework/lib for every project/case. > That would be similar to saying that we prefer Linux over Windows, > just because we use Linux hosting and better would be to instead > build our own operating system, just so that people don't get > inclined to one side or another > A bit of a stretch of an analogy but more or less the same idea. > > The fact that we use some well known framework/package would reduce > the barrier to get more people involved in the project, now and for > the future. Not using them is going back to 2005 when everybody had > their own framework. > > I am not suggesting any framework in specific but think there as some > good options out there. We would be quit well served with a micro- > framework as we basically need just some kind http stack + routing, > but that is deep down the execution plan discussion. Mind that the php.net site except for the doc search actually is a static web page we could also generate completely as static HTML. This is not a complex system where any "business logic" does complex stuff, thus a framework doesn't help much, while bringing complexity. johannes --- ## #99951 — Sara Golemon — 2017-07-19T20:21:41+00:00 URL: https://externals.io/message/99937#99951 · In reply to: #99947 > I personally strongly disagree with that approach. Most of the pages on > php.net are static pages. And those few that aren't can be well addressed > with their own script and within that vanillaPHP-script the task can be > solved. IMO there is no need for routing or an HTTP-Stack. And it shows that > we - even in 2017 still know how to build a basic PHP-site. The entry > barrier is absolutely low as no framework/library knowledge is necessary and > the scripts can be easily analysed from start to end. As there are - due to > the mirrored setup - no DB-queries or sessions or any other more complex > stuff going on we should keep it simple and stupid. > > But thats - as I said - just my 0.02€ > And for my $0.02, I agree with Andreas. Caesar's wife must be beyond reproach, and quite frankly there is plenty that can be done to beautify/update the web-php codebase that doesn't involve frameworks. *cough*globals*cough*. In fact, if you want to start with a more constrained problem space, web-bugs has fewer variables and build steps and is in greater need of updates (the main site having been revamped much more recently). -Sara --- ## #99952 — Mathias Grimm — 2017-07-19T20:47:25+00:00 URL: https://externals.io/message/99937#99952 · In reply to: #99951 Bugs could be good thing as well. What the case with the bugs? For the php.net I think it could actually be worthy generating html. But as I said, the idea is to make the code readable again, be it with a framework or not. Having all that html mixed with php + globals is really bad. Even if we wanted to get a designer to help on the website it would be really hard. It can be a very static php and still be more organised. A basic MVC doesn't hurt > > > […] > addressed > > […] > that > > […] > and > > […] > to > > […] > And for my $0.02, I agree with Andreas. Caesar's wife must be beyond > reproach, and quite frankly there is plenty that can be done to > beautify/update the web-php codebase that doesn't involve frameworks. > *cough*globals*cough*. > > In fact, if you want to start with a more constrained problem space, > web-bugs has fewer variables and build steps and is in greater need of > updates (the main site having been revamped much more recently). > > -Sara --- ## #99953 — Niklas Keller — 2017-07-19T20:54:32+00:00 URL: https://externals.io/message/99937#99953 · In reply to: #99951 > > And for my $0.02, I agree with Andreas. Caesar's wife must be beyond > reproach, and quite frankly there is plenty that can be done to > beautify/update the web-php codebase that doesn't involve frameworks. > *cough*globals*cough*. > > In fact, if you want to start with a more constrained problem space, > web-bugs has fewer variables and build steps and is in greater need of > updates (the main site having been revamped much more recently). While I can understand the argument, I don't agree with it. It's fine for the main website which is indeed mostly static and could be an actual static website, but I think web-bugs could really benefit from some libraries being used. There's no need for a framework, but libraries are really helpful. And I understand people might say "php.net uses that", but honestly, does anybody use Dokuwiki because we use that for wiki.php.net? We should use whatever works. Quite a lot of libraries / components are well-tested and maintained, I don't see why we should roll our own if we need such functionality. Regards, Niklas --- ## #99954 — Levi Morrison — 2017-07-19T21:51:15+00:00 URL: https://externals.io/message/99937#99954 · In reply to: #99953 As someone who has made a decent number of changes to the website I think our future direction should focus on these points: 1. Ease of setup and deployment 2. Fewer moving parts (related to above) 3. Move to modern HTML, JavaScript and CSS practices (perhaps completely disallowing inline CSS and JavaScript with CSP) 4. Generate a nearly static site including comments. I can try to explain some of these at a later time but hopefully those who have worked with the site can understand why I'd want to go this way. I have ordered them roughly in my personal order of importance. To be frank for any major changes to succeed we need ordered and scheduled cooperation. These cannot be done by ad-hoc volunteering for a few hours per month. They will need a focused and scheduled approach to succeed because there are some challenging aspects: - Changing setup or deployment will affect every box in production. - We render much of the manual using PHD which is then rsync'd and thus if you are changing HTML/CSS that is related to changes in PHD you have to coordinate the releases and need to potentially support both versions simultaneously. - As with many large websites our site has more odds and ends needs that are not immediately apparent. - Much of the code is old and not well understood and there are basically no tests for it. I am happy for new people to contribute and will do the best I can to help but honestly we're in need of serious commitments if we want serious change. Otherwise we'll keep moving along as we are. --- ## #99957 — Rasmus Lerdorf — 2017-07-20T00:40:49+00:00 URL: https://externals.io/message/99937#99957 · In reply to: #99941 > > We should really change that and fully move to HTTPS. > I have looked at various ways of doing this, but it isn't trivial and it has absolutely nothing to do with the actual html and slapping in some https links instead of http. The problem here is that we have external volunteers running all our mirrors and we do geo-dns for www.php.net to your geographically close mirror site. Putting the private key for www.php.net on dozens of servers around the world we don't control is a non-starter. One way that I played with was to use letsencrypt and have each mirror request an ssl cert for their local mirror, ca1.php.net, for example, and include a CN alias for www.php.net in that request. Then we would run domain a validation gateway/proxy on www.php.net which would validate these requests on behalf of the mirrors. But there are some security issues with this approach that I haven't quite thought through. I would love to hear suggestions for perhaps a simpler solution to this problem that doesn't require pasting our private key all over the internet. -Rasmus --- ## #99958 — Rasmus Lerdorf — 2017-07-20T00:43:10+00:00 URL: https://externals.io/message/99937#99958 · In reply to: #99942 > > * Use docker hub as the distribution channel. (https out of the box) > Getting https support in the web server is not what prevents us from getting https for www.php.net. It is key management across our geodns www.php.net that is the limiting factor here. A Docker image doesn't do anything to help with that. -Rasmus --- ## #99959 — Stephen Reay — 2017-07-20T03:59:49+00:00 URL: https://externals.io/message/99937#99959 · In reply to: #99957 > > > > […] > > I have looked at various ways of doing this, but it isn't trivial and it > has absolutely nothing to do with the actual html and slapping in some > https links instead of http. The problem here is that we have external > volunteers running all our mirrors and we do geo-dns for www.php.net to > your geographically close mirror site. Putting the private key for > www.php.net on dozens of servers around the world we don't control is a > non-starter. > > One way that I played with was to use letsencrypt and have each mirror > request an ssl cert for their local mirror, ca1.php.net, for example, and > include a CN alias for www.php.net in that request. Then we would run > domain a validation gateway/proxy on www.php.net which would validate these > requests on behalf of the mirrors. But there are some security issues with > this approach that I haven't quite thought through. I would love to hear > suggestions for perhaps a simpler solution to this problem that doesn't > require pasting our private key all over the internet. > > -Rasmus Hey Rasmus, Does it need to be geo-dns, or could it instead be "geo-http" - a small number of servers responding to (www.)?php.net, which then respond with http redirects based on client ip. This is similar to how Debians "new" mirror service works for apt repos. I know it would be very nice to have the URLs stay as php.net (no CCn. Prefix) but anything else simple is going to involve tls certs for the base domain on servers the project doesn't control. The only other option I can see, would be to use "keyless" tls. It's described pretty well by CF here: https://www.cloudflare.com/ssl/keyless-ssl/ Unfortunately I don't know that cf have open sourced their nginx&openssl patches to make them talk to a remote key server. Happy to discuss this further if I can help. Cheers Stephen --- ## #99960 — Niklas Keller — 2017-07-20T05:42:04+00:00 URL: https://externals.io/message/99937#99960 · In reply to: #99957 > > I have looked at various ways of doing this, but it isn't trivial and it > has absolutely nothing to do with the actual html and slapping in some > https links instead of http. The problem here is that we have external > volunteers running all our mirrors and we do geo-dns for www.php.net to > your geographically close mirror site. Putting the private key for > www.php.net on dozens of servers around the world we don't control is a > non-starter. > I expected something like that. How does it work then that https://www.php.net and https://php.net can redirect to https://secure.php.net? I must be reaching a server with a valid certificate, otherwise that wouldn't work. If putting a private key for php.net doesn't work, then we should get rid of these mirrors ASAP IMO. > One way that I played with was to use letsencrypt and have each mirror > request an ssl cert for their local mirror, ca1.php.net, for example, and > include a CN alias for www.php.net in that request. Then we would run > domain a validation gateway/proxy on www.php.net which would validate > these > requests on behalf of the mirrors. But there are some security issues with > this approach that I haven't quite thought through. I would love to hear > suggestions for perhaps a simpler solution to this problem that doesn't > require pasting our private key all over the internet. > They can also just request them themselves, but only for their mirror domain. If you allow them to issue for www.php.net, you can as well just put the current private key there. Regards, Niklas --- ## #99964 — lists@rhsoft.net — 2017-07-20T08:27:37+00:00 URL: https://externals.io/message/99937#99964 · In reply to: #99937 Am 19.07.2017 um 19:07 schrieb Mathias Grimm: > I would like to know who is/are "in charge" of the website ( > https://github.com/php/web-php). > I think I would like to help improving it a bit a good start would be http://www.php.net/ also support https:// instead one needs to know that https://secure.php.net/ exists and supports encryption or at least point the downloads-menu to the encrypted page --- ## #99977 — Rasmus Lerdorf — 2017-07-20T17:34:09+00:00 URL: https://externals.io/message/99937#99977 · In reply to: #99959 On Wed, Jul 19, 2017 at 11:59 PM, Stephen Reay wrote: > > Does it need to be geo-dns, or could it instead be "geo-http" - a small > number of servers responding to (www.)?php.net, which then respond with > http redirects based on client ip. This is similar to how Debians "new" > mirror service works for apt repos. > > > I know it would be very nice to have the URLs stay as php.net (no CCn. > Prefix) but anything else simple is going to involve tls certs for the base > domain on servers the project doesn't control. > > The only other option I can see, would be to use "keyless" tls. It's > described pretty well by CF here: https://www.cloudflare. > com/ssl/keyless-ssl/ > > Unfortunately I don't know that cf have open sourced their nginx&openssl > patches to make them talk to a remote key server. > I did look at the stuff from Cloudflare last year, but at the time they hadn't opened enough of it to implement. And it is really nice to have www.php.net be fast and low-latency from all over the world. Even the initial request. We are quite spoiled in Europe and North America with our fast peering. But in many other parts of the world, even if the local connection is fast, getting to a server in N.America is quite slow. but yes, eventually we may have to give up on geo-dns if we can't find a decent way to layer https on top of it. -Rasmus --- ## #99978 — Rasmus Lerdorf — 2017-07-20T17:38:26+00:00 URL: https://externals.io/message/99937#99978 · In reply to: #99960 > > They can also just request them themselves, but only for their mirror > domain. If you allow them to issue for www.php.net, you can as well just > put the current private key there. > I think there is a big difference between putting the private key there and proxying validation for just a www.php.net CN alias. We already have a list of known mirrors, so we would make sure to only validate www.php.net for those. By validating www.php.net we allow any mirror to pretend they are www.php.net and no other *.php.net domain, which is exactly what we want. -Rasmus --- ## #99979 — Larry Garfield — 2017-07-20T19:25:08+00:00 URL: https://externals.io/message/99937#99979 · In reply to: #99978 > > > […] > I think there is a big difference between putting the private key there and > proxying validation for just a www.php.net CN alias. We already have a list > of known mirrors, so we would make sure to only validate www.php.net for > those. By validating www.php.net we allow any mirror to pretend they are > www.php.net and no other *.php.net domain, which is exactly what we want. > > -Rasmus I figure this is a long-shot, but Platform.sh hosts a number of community sites for free. (We recently became the home of https://externals.io/, for example.) We have multiple data centers and SSL-all-the-things using Lets Encrypt. We'd be happy to help on the hosting side of the equation for any *.php.net sites if there's interest, either full or partial. We also offer PHP 7.1 and will have the just-released 7.2 beta up shortly. :-) (We have no opinion on the code side; we're just happy to help on the infrastructure side.) --Larry Garfield --- ## #99980 — Rasmus Lerdorf — 2017-07-20T19:39:42+00:00 URL: https://externals.io/message/99937#99980 · In reply to: #99979 On Thu, Jul 20, 2017 at 3:25 PM, Larry Garfield wrote: > > I figure this is a long-shot, but Platform.sh hosts a number of > community sites for free. (We recently became the home of > https://externals.io/, for example.) We have multiple data centers and > SSL-all-the-things using Lets Encrypt. We'd be happy to help on the > hosting side of the equation for any *.php.net sites if there's > interest, either full or partial. We also offer PHP 7.1 and will have > the just-released 7.2 beta up shortly. :-) > I like the current mirror system which spreads out the duties to many different providers in more (around 60) countries than even someone as big as AWS can have data centers in. It is just the geodns part on www.php.net that makes https tricky. Nothing else about the current mirror system prevents https. -Rasmus --- Next page: https://externals.io/message/99937.md?page=2