php -v

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Baki Goxhaj
Perhaps to close this off for now all I have to say is this:

WordPress won't become that App platform that you can build anything on
which Matt presented as the future of WP in WPSF unless the system makes
use of the new goodness of PHP.

What would be the best route? I don't know. Does WP have to raise the bar?
Yes!

Kindly,

Baki Goxhaj
about.me/banago


On Fri, Nov 8, 2013 at 5:44 PM, Otto <[hidden email]> wrote:

> On Fri, Nov 8, 2013 at 10:36 AM, Eric Mann <[hidden email]> wrote:
>
> > > FWIW, I did a random sampling of some 3.7.1 API requests, and that too
> > showed
> > > about 50% of users on 5.2.17
> >
> > Would be nice if we could update the stats page to make this kind of
> > information publicly available. Would help us (developers) better target
> > our code and would go miles in helping to tone down the attitude of this
> > kind of conversation in the future.
>
>
> I'm not getting involved in this conversation, other than to say this. ;)
>
> The data used for the graphs on the stats page are built daily, using a
> random(ish) sampling of the API requests from the previous day.
>
> What you see on that page is current and up-to-date. It's not counting
> every install in the world, or months-old installs, or inactive installs
> that nobody is visiting. It's built from just the API requests from the day
> before.
>
> -Otto
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Eric Mann
In reply to this post by Otto-19
>
> What you see on that page is current and up-to-date. It's not counting every
> install in the world, or months-old installs, or inactive installs that
> nobody is visiting. It's built from just the API requests from the day
> before.


Yes, and this is good to know. But when many of us are saying "old
installs" we're referring to the 94.5% of WordPress installs that are less
than the current version.  3.7.1 is out, and the 3.7.X branch only makes up
~5.5% of the version chart.  How many of *those* installations are on older
versions of PHP.

According to those stats, more than a quarter of "active" sites are still
running WordPress 3.0 ... not being able to see juxtapose PHP versions and
WordPress versions makes it nearly impossible for anyone to create any sort
of conclusion based on this stats page, yet it's cited in every single "we
won't raise the minimum version" debate.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Ian Dunn
In reply to this post by Eric Mann
On 11/8/13 8:36 AM, Eric Mann wrote:
> My hesitation here is the same as Helen
> pointed out earlier - most end users have no idea what PHP is, how it
> works, what version they're running, or how to upgrade.  By hiding new
> features behind a versioned wall, we're introducing a world where WordPress
> is advertised to have X feature, but when Jimmy Blogger clicks the
> auto-install button on his hosting dashboard, X feature is nowhere to be
> found.  He'll blame WordPress, not his host, for the discrepancy.

What if instead of hiding the feature, we replaced it with a short
explanation? So, if they have 5.3+ then the screen for Feature X works
like normal, but if they don't then the screen will still appear in
menus, etc, but when the user visits the page they'll see a paragraph
saying something like, "Your server is running a very old version of
PHP, and it is not capable of supporting Feature X. Please contact your
hosting company or administrator and ask them to upgrade your site to
the latest version of PHP."

That way the user would know that the feature exists, and that their
hosting company is to blame for why it doesn't work, and that the action
they need to take is to contact the host.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Andrew Nacin-2
In reply to this post by Baki Goxhaj
On Fri, Nov 8, 2013 at 11:53 AM, Baki Goxhaj <[hidden email]> wrote:

> WordPress won't become that App platform that you can build anything on
> which Matt presented as the future of WP in WPSF unless the system makes
> use of the new goodness of PHP.


Yeah, no. Nothing is preventing *you* from using newer features you enjoy.
But WordPress core will continue with its minimum requirements for some
time. As John Blackbourn summarized, there are some niceties in PHP 5.3,
5.4, and 5.5, but nothing in them provide a benefit that would outweigh
literally abandoning a half (or more) of our userbase on old software,
unable to ever update WordPress again. (FWIW, since I saw this question was
asked: I don't think it's just a few hosting companies keeping most of our
userbase on 5.2.17. Bluehost, which is huge, recently pushed their servers
from 5.2 to 5.4, and the needle barely moved.)

 * short array syntax, ?:, <?=, function array dereferencing, empty()
supporting arbitrary expressions, etc. are syntactical sugar — they're
nice, but not something to abandon our users for
  * generators, traits, and late static bindings are cool, but their use
cases are fairly limited, you can architect things differently to work
around the lack of them, and they're not something to abandon our users for
 * closures are also cool, but they can largely be replaced by functions
and methods, and they also don't have much of a role in our hooks system
(as a closure attached to a hook can't easily be removed later)
 * namespaces aren't backwards compatible so we won't be able to leverage
them much anyway
 * it's about time PHP 5.5 added finally to try/catch, but we don't
currently use exceptions in WordPress
 * we already use spl_object_hash() when it is available (and it basically
always is, SPL is nearly never disabled)
 * we *could* do SPL autoloading for 5.3+ (and manual includes for 5.2) but
I've tried it and didn't see a performance benefit (happy to be proven
wrong)
 * we already have a solid password hashing mechanism, and we'd likely just
adopt/wrap the 5.5 one at a later point

Would it be "cooler" if we could use 5.3, 5.4, and 5.5 features/syntax/etc?
Absolutely. But 5.2 isn't what PHP 4 was. It's actually pretty decent and
does the job we've asked of it. I think we've been doing this all wrong.
Pushing 5.3+ for the purposes of developer happiness isn't going to get us
anywhere. We had some PHP 5.2-only features (for example, timezone support
and oEmbed XML handling) back when our minimum requirement was PHP 4, but
as Ryan McCue pointed out, I've yet to actually see something of
consequence for which we'd need PHP 5.3+.

If it's not developer happiness, then what is it? I'd argue performance,
stability, and security. We've been leaning on hosting companies and will
continue to do so because it's going to be better for them for these
reasons. Unfortunately, a lot of other software (not named WordPress) break
terribly on 5.3 or 5.4, so the hosts are in a tough spot, as they don't
want to break sites. The rise of WordPress-specific hosts — and
WordPress-specific hosting plans within larger hosting companies — actually
improves the chances that hosting companies will move faster, because
WordPress works on all modern versions of PHP without much issue.

Nacin
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Andrew Nacin-2
In reply to this post by Ian Dunn
On Fri, Nov 8, 2013 at 12:35 PM, Ian Dunn <[hidden email]> wrote:

> On 11/8/13 8:36 AM, Eric Mann wrote:
>
>> My hesitation here is the same as Helen
>> pointed out earlier - most end users have no idea what PHP is, how it
>> works, what version they're running, or how to upgrade.  By hiding new
>> features behind a versioned wall, we're introducing a world where
>> WordPress
>> is advertised to have X feature, but when Jimmy Blogger clicks the
>> auto-install button on his hosting dashboard, X feature is nowhere to be
>> found.  He'll blame WordPress, not his host, for the discrepancy.
>>
>
> What if instead of hiding the feature, we replaced it with a short
> explanation? So, if they have 5.3+ then the screen for Feature X works like
> normal, but if they don't then the screen will still appear in menus, etc,
> but when the user visits the page they'll see a paragraph saying something
> like, "Your server is running a very old version of PHP, and it is not
> capable of supporting Feature X. Please contact your hosting company or
> administrator and ask them to upgrade your site to the latest version of
> PHP."
>

First: as summarized in my previous post to this thread, I've yet to be
shown anything we'd want to build in 5.3+ only that we couldn't also easily
build for 5.2.

Second: Many of our users have extremely limited knowledge of their setup.
That includes not knowing what PHP is, or not realizing there is a
difference between their domain and their hosting, or not even remembering
who their host is, or being the "administrator" but having no clue about
any of this, including who to contact. It is not fair to them to present
them with a frustrating and highly technical problem and then ask them to
pass the buck to who-knows-who. We owe it to 20 percent of the Internet to
suck it up and absorb our technical debt so users don't have to. Passing on
technical problems to users is the antithesis of what we believe.

Third: But whether they do or not, we do not screw with our users like
this. WordPress is not a protest piece.

Further reading:
 * http://wordpress.org/about/philosophy/
 * http://ma.tt/2007/07/on-php/
 * http://nacin.com/2010/09/29/on-php-redux/

Nacin
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Nicholas Ciske-2
In reply to this post by Andrew Nacin-2
Case in point -- "developer happiness" is a slippery slope:
http://alexrayu.com/blog/drupal-forked-my-take-it


_________________________
Nick Ciske
http://thoughtrefinery.com/
@nciske

On Nov 8, 2013, at 11:43 AM, Andrew Nacin wrote:

> If it's not developer happiness, then what is it? I'd argue performance,
> stability, and security.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Gabriel Acosta
I would love to be part of a Wordpress fully MVC OOP fork (working over a
well stablished framework being a plus), count me in! I'm a professional
developer and I can't stand the current methodology to work with it, I'm
sorry, your ways may be more than valid but are certainly not in harmony to
what is being taught as "Modern Practices", let me repeat myself THERE
MIGHT NOT BE ANYTHING WRONG with your ways, but they're just not the ways
of must modern software projects.

To sum it up, I agree that you might not gain from a performance stand
point, but certainly you're not winning new developers either by staying as
is.


On Fri, Nov 8, 2013 at 10:56 AM, Nicholas Ciske <[hidden email]>wrote:

> Case in point -- "developer happiness" is a slippery slope:
> http://alexrayu.com/blog/drupal-forked-my-take-it
>
>
> _________________________
> Nick Ciske
> http://thoughtrefinery.com/
> @nciske
>
> On Nov 8, 2013, at 11:43 AM, Andrew Nacin wrote:
>
> > If it's not developer happiness, then what is it? I'd argue performance,
> > stability, and security.
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Thomas Scholz-4
In reply to this post by Andrew Nacin-2
Andrew Nacin,

> Yeah, no. Nothing is preventing *you* from using newer features you  
> enjoy.

That's not quite true. :)

Basic example: some API providers (Dropbox, Amazon and so on) offer PHP  
classes to access their APIs. Very comfortable, because as a plugin  
developer, you don't have to reinvent the wheel, and these tools are  
usually better tested than a single developer could do. But if they  
require at least PHP 5.3, you cannot use them.
The same applies to almost all existing frameworks and libraries: we  
cannot use that code, because so many users are still on 5.2, and we don't  
want to lose those.

This is not primarily about changes or new features in WP core. But by  
raising the requirements, WP would offer a better environment for plugin  
(and theme) authors. I think the overall code quality would be improved if  
we had not to reinvent everything we need.

This process should not be scary or annoying for the users. Of course. A  
short, nicely written hint would be a good start. Something like: Hey,  
your site would be faster and more secure after an PHP upgrade! _How can I  
do that?_ (helpful link)

Would that hurt anyone? I don't think so.

Thomas
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Bryan Petty
On Fri, Nov 8, 2013 at 1:04 PM, Thomas Scholz <[hidden email]> wrote:
> Basic example: some API providers (Dropbox, Amazon and so on) offer PHP
> classes to access their APIs. Very comfortable, because as a plugin
> developer, you don't have to reinvent the wheel, and these tools are usually
> better tested than a single developer could do. But if they require at least
> PHP 5.3, you cannot use them.
> The same applies to almost all existing frameworks and libraries: we cannot
> use that code, because so many users are still on 5.2, and we don't want to
> lose those.

None of that has anything to do with WordPress still supporting 5.2.
He was right, that doesn't mean you can't require 5.3+ in your plugins
that require those 5.3+ libraries, several plugins on WordPress.org
do.

Regards,
Bryan Petty
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Andrew Nacin-2
In reply to this post by Thomas Scholz-4
On Fri, Nov 8, 2013 at 3:04 PM, Thomas Scholz <[hidden email]> wrote:

> But by raising the requirements, WP would offer a better environment for
> plugin (and theme) authors.
>

If by better environment you mean vastly smaller user base. Feel free to
use that PHP 5.3 library, just make sure your plugin doesn't crash a 5.2
site and instead presents "a short, nicely written hint", as you suggest.
You're more than welcome to do that. WordPress will not.

Nacin
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Andrew Nacin-2
In reply to this post by Gabriel Acosta
On Fri, Nov 8, 2013 at 2:17 PM, Gabriel Acosta <[hidden email]>wrote:

> To sum it up, I agree that you might not gain from a performance stand
> point, but certainly you're not winning new developers either by staying as
> is.


No one is suggesting we're staying as-is. Rather, we've been evolving
fairly rapidly across the board. The argument is simply that PHP 5.2 isn't
slowing is down, and that dropping support for it won't provide any
benefit. PHP 5.2 is plenty modern for what we're aiming to do.

We added WP_Theme in 3.4 and WP_Post in 3.5. Both were used to rewrite
older code, improve performance and caching, and fix some long-standing
bugs. WP_Comment is probably next, along with WP_Term. But beyond cleanup,
they're setting the stage for us to move on exciting new things. For
example, they'll probably be decorated with methods for CRUD and other
operations. There's now a whole roadmap that outlines how we plan to remake
terms (adding meta) and possibly add post relationships — which wouldn't be
possible without these kinds of major changes:
http://make.wordpress.org/core/2013/07/28/potential-roadmap-for-taxonomy-meta-and-post-relationships/.
Here's a flash talk I gave in August that touches on how we evolve forward
without breaking sites — which includes PHP version and OOP (or whatever)
just the same: http://vip.wordpress.com/2013/09/27/nacin-wordpress-evolves/.

All I've mentioned here is bringing a little OOP to our objects. This is
just the tip of the iceberg.

Nacin
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: php -v

Ryan McCue-3
In reply to this post by Eric Mann
Eric Mann wrote:
> This. I really like this idea. Would be fairly easy to expose a
> PHP_BLEEDING or similar constant in core and use that as a switch to turn
> on/off enhanced (new) features. My hesitation here is the same as Helen
> pointed out earlier - most end users have no idea what PHP is, how it
> works, what version they're running, or how to upgrade.  By hiding new
> features behind a versioned wall, we're introducing a world where WordPress
> is advertised to have X feature, but when Jimmy Blogger clicks the
> auto-install button on his hosting dashboard, X feature is nowhere to be
> found.  He'll blame WordPress, not his host, for the discrepancy.

To be clear, I was thinking more of behind-the-scenes developer-focused
features. Making use of performance enhancements where possible (ala
spl_object_hash()) and the like that still have a fallback, even if that
fallback isn't that great. Maybe even advanced APIs, but that's sort of
on the edge.

Introducing user-focused features that don't work with all WP installs
would be an incredibly bad idea.

--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
12