Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124324 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 2A72C1A00B7 for ; Tue, 9 Jul 2024 22:37:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720564733; bh=3CDQG/xqYJ40nVC9+ia3TFHl441B1ygd2IPwlKDgOpw=; h=In-Reply-To:References:Date:From:To:Subject:From; b=Gb0+Yr5zmTYSfYCJM4LczZU+9KGdbuei/YgD+Q9sjOeDUD8Cr0el/d2iQDpdnlWl1 FGijS0Gc0GKdaKrysJlizMQ+OINHX6bPptne3krRKXQ/BHTZefyc5RLLwdWrgmvQai ywjS4afqK5WBWB6E7UrR352gNnpgm2J9hO6SVrdM/F+cbOVVLNcclktU2HUVTkW0Y1 WTpR5Zd5sO2CMDlCRe0L5vDZhKeFfNmlTCBKrWy18kdagyBT8w/hj3KrzoLlDCA3jJ JNc6L0URaxC8DtBUo/sK+/AuirvtuoXskego4ojkyVrTDYdwwU2LykbOct36i4f8SB qv+MWcgyb5pNQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EB29E18006F for ; Tue, 9 Jul 2024 22:38:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh2-smtp.messagingengine.com (fhigh2-smtp.messagingengine.com [103.168.172.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 9 Jul 2024 22:38:51 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 5A1131140495 for ; Tue, 9 Jul 2024 18:37:25 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Tue, 09 Jul 2024 18:37:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1720564645; x=1720651045; bh=bkuJpwvNLh w9KOHHYqTX+gcJqIAoY9wl/oZnY8fjQKc=; b=uXbnieap7kddi8AA7g57duGYov CB5ewxoRoF0SJfkWPAybYvcaQ5LU+2EBJBj/+B5gQGZ/MVaHHK1aAe9hLkSNWlsS 2ZqKidpzUK3X3puXvEQ0JbsJT6bFHGzVP1mVgY7/XlW4tKiVH1faThYUoI/owBjN ypSzg3YRai5JIB7HhbnCYqfzdMUF7z3WMk5WC+8FZosnSrefcWHbuLb0ZkZTCK7g vZBjbQQVcxb+uZdy1wimbOrY/TwH203eRHMyvddVEQnKPs3IjA5/fgbLem46VIg/ yxpEXTzFxZ0HX0LKoNxljxiFqAGwYoUbz/CIHAEzu4ycU1Q8TBoLvncEvS4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1720564645; x=1720651045; bh=bkuJpwvNLhw9KOHHYqTX+gcJqIAo Y9wl/oZnY8fjQKc=; b=rxiKbYbkicf07FJ8/i3QGm9QsIVAepte4cJKG13vcR4f KG3SKuZDs9fyFB0YK3QA6ronJZ+iTzLvxQ1juAuzzoyAM1AGmadn1hyU7crt7MBJ EnMiwnpG4Ku3KrDUP7KVMDeG6UG+q7WbW1hGobO9dLBnxnir7kYlRFxt96jzc5G5 arrEQHd4xiYYbkx0xfDpvgvAEhyHKOzkpfexcxxlCOVimWgkA+pEDwlMMLhc46Od FAqbU4oV565Zi/GosLVZPHd7PjKIcttD70+YY3rsdbw6XqjSJXyEO00lyFChenwO JbcrjByOe8KL6w7e7l8z8KS5XW6QpuqOiWv2dcxLCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfedtgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhl vggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeeutefhtdduveefjefhveegffetje elieehiedvleeileeuvdeuudegudefffefteenucffohhmrghinhepohhpvghntgholhhl vggtthhivhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvsh X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18AD515A0092; Tue, 9 Jul 2024 18:37:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <6dbc2231-a5af-489b-ac04-c317a5539a67@app.fastmail.com> In-Reply-To: <7b40e925-d642-4cf4-83f8-f903a9964362@app.fastmail.com> References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net> <0E11F373-99DC-496E-9BBC-2F8688B9F66A@newclarity.net> <4F720A7A-B7DD-4B31-B0C9-6907419B53A5@newclarity.net> <7b40e925-d642-4cf4-83f8-f903a9964362@app.fastmail.com> Date: Wed, 10 Jul 2024 00:36:57 +0200 To: internals@lists.php.net Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) Content-Type: multipart/alternative; boundary=100b323202d845749077a0e613d3bee9 From: rob@bottled.codes ("Rob Landers") --100b323202d845749077a0e613d3bee9 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2024, at 19:15, Larry Garfield wrote: > On Sat, Jul 6, 2024, at 1:12 AM, Mike Schinkel wrote: >=20 > > > > > > Reading this however caused me to ponder things certain people has s= aid=20 > > recently =E2=80=94 and many people have said for years on this list = =E2=80=94 and I=20 > > think I am recognizing something that I have always known but never = put=20 > > the pieces together before. > > > > Many (most?) people on PHP Internals view WordPress coding standards= as=20 > > bad and some even view addressing WordPress developers needs as bad = for=20 > > PHP. And in general I concur that those people are reasonably justif= ied=20 > > in their belief WordPress' coding standards are not the standards th= at=20 > > PHP developer who want to do professional level software engineering=20 > > should aspire.=20 > > > > And since many (most?)* *PHP Internals members generally do not=20 > > experience the issues that WordPress developers have they do not=20 > > recognize that they are issues; IOW, *"out of sight, out of mind." * > > > > I also think some list members tend to dismiss WordPress developers=20 > > pains as unimportant and/or think that addressing those pains have w= ill=20 > > harm* *PHP.=20 > > > > (BTW, I recently had a dialog off-list with someone who wrote in an=20 > > email that *"Wordpress is an exception, but nobody these days treats=20 > > WordPress as a valid example to do anything. It is an ancient piece = of=20 > > legacy code that has no bearing on modern situation and it's their=20 > > problem to deal with." *So I am not just erecting a straw man here.) > > > > But I think what most may not consciously recognize is that* WordPre= ss=20 > > is a different type of web app* than an app build using Symfony or=20 > > Laravel and deployed by its developers, or by some other professiona= l=20 > > developer.=20 > > > > WordPress differs from the apps many *(most?)* developers on PHP=20 > > Internals work with in the following way: > > > > WordPress =3D *User-managed app* > > Most =3D *Developer-managed apps* > > > > In a* Developer-Managed app* developers choose which 3rd party=20 > > functionality will be incorporated into their sites whereas with a=20 > > *User-managed app* users choose which 3rd party functionality will b= e=20 > > incorporated into their site. And that is the KEY difference.=20 > > > > So I am wondering if we can get people on this PHP Internals list wh= o=20 > > dismiss the needs of WordPress developer BECAUSE it is WordPress to=20 > > recognize that User-Managed apps ARE a class of PHP applications hav= e=20 > > needs that **deserve** to be addressed? =20 > > * > > * > > Two (2)* unmet needs of User-Managed apps *that *"standard" *PHP=20 > > currently does not address come to mind: > > > > User-managed apps needs to be able to handle both: > > * > > * > > 1. *User-added add-ons* *("plugins" in WordPress, "modules" in Drupa= l)=20 > > *that have conflicting dependencies, and > > > > 2. *Add-on directory structures *that do not follow a PSR-4 director= y hierarchy. > > > > As for #2, even if those apps could rearchitect their existing=20 > > directory structure they cannot realistically be expected to do with=20 > > because of the huge BC issues their users would experience.=20 > > > > And newly created User-managed apps may still find that a PSR-4=20 > > directory structure is not in the best interest of their project or=20 > > their users. To elaborate, PSR-4 generally assumes that ALL code goe= s=20 > > into ONE hierarchy and that any and all code that will be autoload g= ets=20 > > placed in that hierarchy. > > > > But with add-ons it makes a lot more sense to have the entire add-on=20 > > contained in its own add-on directory. This is exactly where PSR-4=20 > > breaks down with respect to User-managed apps. > > > > Sure, you can have multiple PSR-4 autoloader root directories, but t= hat=20 > > does not scale well to websites with a large number of add-ons as ma= ny=20 > > WordPress sites I worked on used. Some had over 100 plugins. With a=20 > > hierarchy of autoloader maps that Michael Morris is proposing WordPr= ess=20 > > could collect up all the maps and create one map every time a plugin= is=20 > > added, updated or deleted. > > > > >=20 > I am going to jump in here on this point specifically, because it seem= s to be a mix of genuinely insightful observation (though not unique) an= d uninformed FUD. >=20 > Some context: I haven't seriously used Wordpress in, ever. However, I= was a Drupal lead developer for many years, and wrote, among other thin= gs, Drupal's DBAL, Drupal's first autoloader, Drupal's PSR-3 implementat= ion, was involved in Drupal's file organization guidelines for Drupal 8+= (when Drupal adopted a PSR-0/4 autoloader), and led the Drupal 8 "Moder= nize all the things" effort. So I do have some non-trivial experience i= n this area. >=20 > First, you're correct that there is an architectural difference betwee= n "projects that assume the owner has CLI access" and those that do not.= You are also correct that most of the Internals crowd comes from the f= ormer. =20 >=20 > However, I don't think it's fair to say that's why Internals folks "di= smiss" Wordpress generally. We dismiss Wordpress generally because >=20 > 1. WP actively harms the PHP community by encouraging the use of ancie= nt PHP versions with known security issues. > 2. WP's code base actively avoids using what have been considered know= n best-practices (in either type of application) for 15 years. > 3. WP's core team actively avoids being involved in Internals to colla= borate on how to make the language better for them. In fact, they've ma= de it very clear that PHP is a legacy implementation detail and Node/cli= ent-side JS is where their focus is. The only WP-affiliated person I ca= n even think of that has been a semi-regular Internals contributor is Ju= liette (whose participation I very much welcome). >=20 > That said, it was recently pointed out to me that Automattic is the to= p contributor to the PHP Foundation (https://opencollective.com/phpfound= ation), which is very much appreciated and nothing to sneeze at. I have some insight on this, but also, there are people here who are ex-= coworkers from Automattic. I haven't worked there for a couple years now= , but I did get involved in these discussions ... as much as (un)reasona= bly possible because I wanted to see WordPress Core (the free version) m= odernized. That being said, I don't speak for any of them; these are jus= t my personal observations. 1. Much of the constraints there actually comes from [cheap] hosting. I= f they make it harder to upgrade ... people just won't upgrade. Getting = people to upgrade is already challenging enough. Though, there was a lot= of work fixing that problem when I left. 2. You can purchase backported PHP versions with all the security patch= es applied. There's literally an entire industry keeping old php version= s running; so that argument isn't really valid. And yes, this was also o= ne of my original arguments... 3. The WordPress codebase seems to have taken a different branch throug= h history. But I wouldn't say that they avoid best-practices. Are there = a lot of plugin developers that do? Yes. Yes they do. But if you have a = lightweight strategy-pattern (apply_filters/do_action), you'd be dumb no= t use it. WordPress does use it, and they use it quite well to do a lot = of things you don't really see in other CMS's/codebases because strategy= -patterns are usually quite expensive. 4. And finally, I *do *see colleagues on here giving feedback, they jus= t don't declare they have anything to do with Automattic or WordPress. W= hy would they? =E2=80=94 Rob --100b323202d845749077a0e613d3bee9 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, = 2024, at 19:15, Larry Garfield wrote:
On Sat, Jul 6, 2024, at 1:12 AM, Mike Schinke= l wrote:

> <epiphany>
>
> Reading this however caused me to ponder thing= s certain people has said 
> recently =E2=80=94 an= d many people have said for years on this list =E2=80=94 and I 
=
> think I am recognizing something that I have always know= n but never put 
> the pieces together before.
=
>
> Many (most?) people on PHP Internals = view WordPress coding standards as 
> bad and some= even view addressing WordPress developers needs as bad for 
> PHP. And in general I concur that those people are reasonab= ly justified 
> in their belief WordPress' coding = standards are not the standards that 
> PHP develo= per who want to do professional level software engineering 
> should aspire. 
>
> A= nd since many (most?)* *PHP Internals members generally do not 
=
> experience the issues that WordPress developers have the= y do not 
> recognize that they are issues; IOW, *= "out of sight, out of mind." *
>
> I a= lso think some list members tend to dismiss WordPress developers 
> pains as unimportant and/or think that addressing thos= e pains have will 
> harm* *PHP. 
>
> (BTW, I recently had a dialog off-list with s= omeone who wrote in an 
> email that *"Wordpress i= s an exception, but nobody these days treats 
> Wo= rdPress as a valid example to do anything. It is an ancient piece of&nbs= p;
> legacy code that has no bearing on modern situatio= n and it's their 
> problem to deal with." *So I a= m not just erecting a straw man here.)
>
= > But I think what most may not consciously recognize is that* WordPr= ess 
> is a different type of web app* than an app= build using Symfony or 
> Laravel and deployed by= its developers, or by some other professional 
> = developer. 
>
> WordPress differs= from the apps many *(most?)* developers on PHP 
>= Internals work with in the following way:
>
<= div>> WordPress =3D *User-managed app*
> Most =3D *D= eveloper-managed apps*
>
> In a* Devel= oper-Managed app* developers choose which 3rd party 
= > functionality will be incorporated into their sites whereas with a&= nbsp;
> *User-managed app* users choose which 3rd party= functionality will be 
> incorporated into their = site. And that is the KEY difference. 
>
=
> So I am wondering if we can get people on this PHP Internals l= ist who 
> dismiss the needs of WordPress develope= r BECAUSE it is WordPress to 
> recognize that Use= r-Managed apps ARE a class of PHP applications have 
= > needs that **deserve** to be addressed?  
&= gt; *
> *
> Two (2)* unmet needs of Us= er-Managed apps *that *"standard" *PHP 
> currentl= y does not address come to mind:
>
> U= ser-managed apps needs to be able to handle both:
> *
> *
> 1. *User-added add-ons* *("plugin= s" in WordPress, "modules" in Drupal) 
> *that hav= e conflicting dependencies, and
>
> 2.= *Add-on directory structures *that do not follow a PSR-4 directory hier= archy.
>
> As for #2, even if those ap= ps could rearchitect their existing 
> directory s= tructure they cannot realistically be expected to do with 
> because of the huge BC issues their users would experience.&n= bsp;
>
> And newly created User-manage= d apps may still find that a PSR-4 
> directory st= ructure is not in the best interest of their project or 
<= div>> their users. To elaborate, PSR-4 generally assumes that ALL cod= e goes 
> into ONE hierarchy and that any and all = code that will be autoload gets 
> placed in that = hierarchy.
>
> But with add-ons it mak= es a lot more sense to have the entire add-on 
> c= ontained in its own add-on directory. This is exactly where PSR-4 <= br>
> breaks down with respect to User-managed apps.
>
> Sure, you can have multiple PSR-4 autolo= ader root directories, but that 
> does not scale = well to websites with a large number of add-ons as many 
<= div>> WordPress sites I worked on used. Some had over 100 plugins.&nb= sp; With a 
> hierarchy of autoloader maps that Mi= chael Morris is proposing WordPress 
> could colle= ct up all the maps and create one map every time a plugin is 
> added, updated or deleted.
>
> </epiphany>

I am going to jump= in here on this point specifically, because it seems to be a mix of gen= uinely insightful observation (though not unique) and uninformed FUD.

Some context: I haven't seriously used Wordpr= ess in, ever.  However, I was a Drupal lead developer for many year= s, and wrote, among other things, Drupal's DBAL, Drupal's first autoload= er, Drupal's PSR-3 implementation, was involved in Drupal's file organiz= ation guidelines for Drupal 8+ (when Drupal adopted a PSR-0/4 autoloader= ), and led the Drupal 8 "Modernize all the things" effort.  So I do= have some non-trivial experience in this area.

=
First, you're correct that there is an architectural difference bet= ween "projects that assume the owner has CLI access" and those that do n= ot.  You are also correct that most of the Internals crowd comes fr= om the former.  

However, I don't= think it's fair to say that's why Internals folks "dismiss" Wordpress g= enerally.  We dismiss Wordpress generally because
1. WP actively harms the PHP community by encouraging the us= e of ancient PHP versions with known security issues.
2. W= P's code base actively avoids using what have been considered known best= -practices (in either type of application) for 15 years.
3= . WP's core team actively avoids being involved in Internals to collabor= ate on how to make the language better for them.  In fact, they've = made it very clear that PHP is a legacy implementation detail and Node/c= lient-side JS is where their focus is.  The only WP-affiliated pers= on I can even think of that has been a semi-regular Internals contributo= r is Juliette (whose participation I very much welcome).
<= br>
That said, it was recently pointed out to me that Automatt= ic is the top contributor to the PHP Foundation (https://opencollective.com/phpfoundation), which is very much appreciated and nothing to sneeze at.
<= /blockquote>

I have some insight on this, but also, t= here are people here who are ex-coworkers from Automattic. I haven't wor= ked there for a couple years now, but I did get involved in these discus= sions ... as much as (un)reasonably possible because I wanted to see Wor= dPress Core (the free version) modernized. That being said, I don't spea= k for any of them; these are just my personal observations.

  1. Much of the constraints there actually comes from [c= heap] hosting. If they make it harder to upgrade ... people just won't u= pgrade. Getting people to upgrade is already challenging enough. Though,= there was a lot of work fixing that problem when I left.
  2. Yo= u can purchase backported PHP versions with all the security patches app= lied. There's literally an entire industry keeping old php versions runn= ing; so that argument isn't really valid. And yes, this was also one of = my original arguments...
  3. The WordPress codebase seems to hav= e taken a different branch through history. But I wouldn't say that they= avoid best-practices. Are there a lot of plugin developers that do? Yes= . Yes they do. But if you have a lightweight strategy-pattern (apply_fil= ters/do_action), you'd be dumb not use it. WordPress does use it, and th= ey use it quite well to do a lot of things you don't really see in other= CMS's/codebases because strategy-patterns are usually quite expensive.<= br>
  4. And finally, I do see colleagues on here gi= ving feedback, they just don't declare they have anything to do with Aut= omattic or WordPress. Why would they?

=E2=80=94 Rob
--100b323202d845749077a0e613d3bee9--