Easy-digital-downloads: Bump the PHP minimum to 5.3

[DrewAPicture]

I think it's safe to assume that to truly bump the minimum to PHP 5.3 in 3.0, we'll likely need to handle it similarly to how we've done in AffiliateWP: keeping the main plugin file 5.2 compatible, throwing up an admin notice, and killing further execution, then do any 5.3+ stuff in other files.

[afragen]

Clearly this provides the opportunity to create an autoloader and namespacing. I’d love to help with a PR but I have a couple of questions.

• What do you see as the primary namespace? EDD or Easy_Digital_Downloads
• Should file restructuring and renaming be considered to more easily conform to PSR-4? This could mean renaming files from includes/class-edd-customer-query.php containing class EDD_Customer_Query to src/EDD/Customer_Query.php containing namespace EDD and class Customer_Query.

Really I’m looking for some guidelines for helping with an autoloader and file/directory restructuring to help, but these are decisions that @pippinsplugins et al would need to make.

[DrewAPicture]

We're talking about selectively autoloading some things, but not the whole codebase. The top-level namespace I've been using so far in the reports API reboot for the 3.0 sprint is EDD

[sunnyratilal]

Just to add to that: we've also decided against renaming/restructuring due to backwards compatibility purposes.

[pippinsplugins]

Renaming / re-structuring will have to happen slowly so as to prevent problems for existing integrations. We can, however, begin to introduce namespaces for all new code.

I would like the primary namespace to be EDD.

[afragen]

Well I was looking for direction and got it in spades. Thanks everyone.

[JeroenSormani]

I'd even suggest bumping it to a higher version (5.5+), 5.4 adds Traits which can be insanely powerful.

Caldera Forms is also pushing their PHP version more aggressively: https://calderaforms.com/2018/03/php-version-announcement/

Would be good to push it with EDD 3.0, but before then show a notice (so as soon as possible) show a notice to those who are running lower versions to inform them (without inline-dismissal, see what Yoast did)

[cklosowski]

@JeroenSormani At this time our active user base reporting PHP versions is too high for 5.3 for us to cut support for it. We closely monitor this number and when we hit a number we're comfortable removing support for, we can start that process.

[JeroenSormani]

Are those numbers about PHP versions for up-to-date installs? Active installs often are also outdated, e.g. someone running WP 3.7 and EDD 2.1 with PHP 5.3 shouldn't be really taken into consideration, IMO 😇

Starting with adding a notice for users to urge them to upgrade for the (m)any reasons would be a good start to start affecting the PHP version numbers. This is one of the things I hate WP isn't doing in Core, raising awareness is important. Would be neat to start showing notices for any EOL PHP version would have my blessing 🙌

[JJJ]

Going to make a WIP PR branch, and get to work. I'll largely be following the approach documented by @markjaquith here.

I _am_ anticipating needing to incorporate EDD-specific modifications to Mark's plan, to work around add-on gotchas - specifically, avoiding fatal errors from add-ons if/when EDD functions do not exist. (It's entirely possible we will end up including every "safe" file regardless of PHP version, rather than just shutting everything down, but I'd like to work towards that rather than assume it.)

[JJJ]

This is merged, so let's close it.

More discussion is happening on #6533, so let's continue that there.