On Tue, Jul 9, 2024, at 19:15, Larry Garfield wrote:
> On Sat, Jul 6, 2024, at 1:12 AM, Mike Schinkel wrote:
>
> > <epiphany>
> >
> > Reading this however caused me to ponder things certain people has said
> > recently — and many people have said for years on this list — and I
> > think I am recognizing something that I have always known 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 reasonably justified
> > in their belief WordPress' coding standards are not the standards that
> > PHP developer who want to do professional level software engineering
> > should aspire.
> >
> > And since many (most?)* *PHP Internals members generally do not
> > experience the issues that WordPress developers have they do not
> > recognize that they are issues; IOW, *"out of sight, out of mind." *
> >
> > I also think some list members tend to dismiss WordPress developers
> > pains as unimportant and/or think that addressing those pains have will
> > harm* *PHP.
> >
> > (BTW, I recently had a dialog off-list with someone who wrote in an
> > email that *"Wordpress is an exception, but nobody these days treats
> > WordPress as a valid example to do anything. It is an ancient piece of
> > legacy code that has no bearing on modern situation and it's their
> > 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* WordPress
> > 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:
> >
> > WordPress = *User-managed app*
> > Most = *Developer-managed apps*
> >
> > In a* Developer-Managed app* developers choose which 3rd party
> > functionality will be incorporated into their sites whereas with a
> > *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 list who
> > dismiss the needs of WordPress developer BECAUSE it is WordPress to
> > recognize that User-Managed apps ARE a class of PHP applications have
> > needs that **deserve** to be addressed?
> > *
> > *
> > Two (2)* unmet needs of User-Managed apps *that *"standard" *PHP
> > 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 Drupal)
> > *that have conflicting dependencies, and
> >
> > 2. *Add-on directory structures *that do not follow a PSR-4 directory
> > hierarchy.
> >
> > As for #2, even if those apps could rearchitect their existing
> > directory structure they cannot realistically be expected to do with
> > because of the huge BC issues their users would experience.
> >
> > And newly created User-managed apps may still find that a PSR-4
> > directory structure is not in the best interest of their project or
> > their users. To elaborate, PSR-4 generally assumes that ALL code goes
> > into ONE hierarchy and that any and all code that will be autoload gets
> > placed in that hierarchy.
> >
> > But with add-ons it makes a lot more sense to have the entire add-on
> > contained in its own add-on directory. This is exactly where PSR-4
> > breaks down with respect to User-managed apps.
> >
> > Sure, you can have multiple PSR-4 autoloader root directories, but that
> > does not scale well to websites with a large number of add-ons as many
> > WordPress sites I worked on used. Some had over 100 plugins. With a
> > hierarchy of autoloader maps that Michael Morris is proposing WordPress
> > could collect 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 genuinely insightful observation (though not unique) and uninformed
> FUD.
>
> Some context: I haven't seriously used Wordpress in, ever. However, I was a
> Drupal lead developer for many years, and wrote, among other things, Drupal's
> DBAL, Drupal's first autoloader, Drupal's PSR-3 implementation, was involved
> in Drupal's file organization 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 between
> "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 former.
>
> However, I don't think it's fair to say that's why Internals folks "dismiss"
> Wordpress generally. We dismiss Wordpress generally because
>
> 1. WP actively harms the PHP community by encouraging the use of ancient PHP
> versions with known security issues.
> 2. WP'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 collaborate
> 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/client-side JS is
> where their focus is. The only WP-affiliated person I can even think of that
> has been a semi-regular Internals contributor is Juliette (whose
> participation I very much welcome).
>
> That said, it was recently pointed out to me that Automattic is the top
> contributor to the PHP Foundation (https://opencollective.com/phpfoundation),
> 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)reasonably
possible because I wanted to see WordPress Core (the free version) modernized.
That being said, I don't speak for any of them; these are just my personal
observations.
1. Much of the constraints there actually comes from [cheap] hosting. If 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 patches
applied. There's literally an entire industry keeping old php versions running;
so that argument isn't really valid. And yes, this was also one of my original
arguments...
3. The WordPress codebase seems to have 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_filters/do_action), you'd be dumb not 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 just don't
declare they have anything to do with Automattic or WordPress. Why would they?
— Rob
