php.net website

7 years ago by Mathias Grimm — view source

unread

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

7 years ago by mtkocak@gmail.com — view source

unread

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

7 years ago by Sara Golemon — view source

unread

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

7 years ago by Niklas Keller — view source

unread

On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm mathiasgrimm@gmail.com
wrote:

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

We should really change that and fully move to HTTPS.

Regards, Niklas

7 years ago by Sara Golemon — view source

unread

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

7 years ago by Rasmus Lerdorf — view source

unread

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

7 years ago by Rasmus Lerdorf — view source

unread

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

7 years ago by Stephen Reay — view source

unread

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

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

7 years ago by Rasmus Lerdorf — view source

unread

On Wed, Jul 19, 2017 at 11:59 PM, Stephen Reay php-lists@koalephant.com
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

7 years ago by Niklas Keller — view source

unread

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

7 years ago by Rasmus Lerdorf — view source

unread

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

7 years ago by Larry Garfield — view source

unread

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

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

7 years ago by Rasmus Lerdorf — view source

unread

On Thu, Jul 20, 2017 at 3:25 PM, Larry Garfield larry@garfieldtech.com
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

7 years ago by Mathias Grimm — view source

unread

If php is mainly static it could be almost fully cached in a CDN.
For the downloads I don't think the latency would be a problem but that can
also be in the CDN
If php owned two servers in US and two in Europe and possibly 2 in Asia we
would be goon in terms of latency for the search IMO.

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

7 years ago by Tony Marston — view source

unread

"Niklas Keller" wrote in message
news:CANUQDCjB9UY8jTmmp43bQAW_9xJnoMbREN1zOQh1LubTfO4C-w@mail.gmail.com...

On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm mathiasgrimm@gmail.com
wrote:

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

We should really change that and fully move to HTTPS.

Regards, Niklas

Why on earth should you need to use HTTPS for a website that does not deal
with personal information? Nothing on that website can possibly be classed
as "sensitive" so what would be the point?

--
Tony Marston

7 years ago by Andrey Andreev — view source

unread

Hi,

Why on earth should you need to use HTTPS for a website that does not deal
with personal information? Nothing on that website can possibly be classed
as "sensitive" so what would be the point?

Because HTTPS isn't just about encrypting secret data. Ensuring data
integrity, authenticity is just as important.

Cheers,
Andrey.

7 years ago by lists@rhsoft.net — view source

unread

Am 21.07.2017 um 10:47 schrieb Tony Marston:

We should really change that and fully move to HTTPS.

Regards, Niklas

Why on earth should you need to use HTTPS for a website that does not
deal with personal information? Nothing on that website can possibly be
classed as "sensitive" so what would be the point?

because in a few months major browsers start with warnings if a
unencrypted page contains any form not just logins? guess hwat happens
by the search field on the right top corner?

because HTTPS is also about data integrity?

because currently when you click on the download link and have not
explicitly called https://secure.php.net/ you land on unencrypted
download-pages?

because the whole web goes straight to HTTPS?

7 years ago by Lester Caine — view source

unread

Why on earth should you need to use HTTPS for a website that does not
deal with personal information? Nothing on that website can possibly be
classed as "sensitive" so what would be the point?

That applies to many of the websites I support yet the likes of Google
and Bing now 'downrate' sites that don't have https and browsers
complain about 'insecure' sites. Add the problems created when you add a
private https area to a 'public' domain name and things get even
messier. That some people even here insist that HTTP should be killed
off seems not to have been thought through at all?

On the website front, the problem I see is that while the MANUAL is a
static site, adding things like the wiki, bug system, pecl/pear
management, and other dynamic areas and allowing a decent CLEAN cross
content search is what I see as being needed. Add managed translations
then while a single static english copy of the main stuff is easy to
distribute, and dynamic set of content WOULD be easier going forward.
Except there would never be any agreement on how THAT would be managed
and on which database engine :(

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

7 years ago by Niklas Keller — view source

unread

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

7 years ago by lists@rhsoft.net — view source

unread

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

7 years ago by Kalle Sommer Nielsen — view source

unread

Hi Mathias

2017-07-19 19:07 GMT+02:00 Mathias Grimm mathiasgrimm@gmail.com:

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.

A side note to all of this, I would personally like to see if parts of
php.net redone, that we can integrate windows.php.net back into the
main website, I was never a big fan of the separation of the two. The
binaries are hosted by Microsoft if I remember correctly and has its
own mirroring system, we could still keep this by just pointing the
downloads to the relevant links to windows.php.net mirroring, as I can
easily agree with the size amount that the Windows binaries do contain
with all these flavors we produce nowadays.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Mathias Grimm — view source

unread

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.

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 :)

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.

Do you have more details on that? Is the build process in another repo?

Regards, Niklas

7 years ago by Mathias Grimm — view source

unread

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)

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

7 years ago by Andreas Heigl — view source

unread

Am 19.07.2017 um 19:12 schrieb Mathias Grimm mathiasgrimm@gmail.com:

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

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

7 years ago by Mathias Grimm — view source

unread

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 mathiasgrimm@gmail.com:

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

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

7 years ago by Andreas Heigl — view source

unread

Am 19.07.2017 um 20:34 schrieb Mathias Grimm mathiasgrimm@gmail.com:

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.

Am 19.07.2017 um 19:12 schrieb Mathias Grimm mathiasgrimm@gmail.com:

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

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

7 years ago by Sara Golemon — view source

unread

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.
coughglobalscough.

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

7 years ago by Mathias Grimm — view source

unread

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

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.
coughglobalscough.

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

7 years ago by Niklas Keller — view source

unread

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.
coughglobalscough.

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

7 years ago by Levi Morrison — view source

unread

As someone who has made a decent number of changes to the website I think
our future direction should focus on these points:

Ease of setup and deployment
Fewer moving parts (related to above)
Move to modern HTML, JavaScript and CSS practices (perhaps completely
disallowing inline CSS and JavaScript with CSP)
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.

7 years ago by johannes@schlueters.de — view source

unread

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

php.net website

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL