Removing the PHP 5.4 plugin directory linting
The plugin directory has linting against PHP 5.4 for quite some time now. It used to be a feature to prevent accidental bad commits, but today it’s now regarded by many as a bug.
We need to do one or more of the following:
- Upgrade the PHP linting to PHP-latest-stable (7.0)
- Upgrade the PHP linting to PHP 5.6 with a plan to move to PHP 7.0 (latest stable) and keep up with future releases
- Switch PHP linting to being a warning instead of a block
- Remove the linting all together
Simply upgrading the linting to PHP 5.6 only kicks the can down the road, and still blocks people from using PHP 7 syntaxes in plugins (which is totally okay, if the plugin specifies that as a requirement).
Removing the linting seems like a bad idea, as I believe authors should still be notified they’re committing code that may not be compatible (Unfortunately we currently don’t do php fatal error prevention checks on plugin upgrades, so I’d like to retain it to prevent an unexpected WSOD).
So, I personally feel we should leave the linting at PHP 5.4 (which is what the majority of WordPress sites run today) and make it a warning, not a block.
In order to warn instead of outright blocking, the linting needs to be moved from the
pre-commit hook to the
post-commit hook and the script exiting with a error-level code, STDERR will then be sent to the client after the commit is made.
Hi, could I have commit access to https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub for #475-meta?
Could I please have commit access to https://meta.svn.wordpress.org/sites/trunk/wordpress.org/public_html/style in order to fix #555-meta?
Can we turn off gitolite on svn1? Trying to clone anything on *.git.wordpress.org over the HTTP protocol (instead of the git protocol) ends up checking out the dead/never used WordPress for Android gitolite project.
I don’t see anything listening on *.git.wordpress.org, just android.git.wordpress.org, so I’m not sure what’s going on and it’s why I’m not doing it myself.
Could I please get commit access to https://meta.svn.wordpress.org/sites/trunk/profiles.wordpress.org/public_html/wp-content/ in order to fix #485-meta?
Can I please get me commit access to https://meta.svn.wordpress.org/sites/trunk/global.wordpress.org/public_html/wp-content/ (for #471-meta and #472-meta)?
Can I please have commit access granted to bbpress.svn.wordpress.org for the username ‘netweb’?
We’ve had the Uncle Ben talk, and @matt‘s looped in and given his nod of approval.
The SVN server appears to run PHP 5.4 now. For most repositories (notably core), we strongly benefit from pre-commit syntax checking to be PHP 5.2.
I think we need to install PHP 5.2 (old, I know) on this server. Then, a pre-commit hook can use
php52 -l as needed.
There are a select few files (in our unit tests) that use 5.3 syntax, but I can patch around that in core’s pre-commit hook.
There are other options for verifying that files can be parsed (like a continuous integration procedure), but nothing beats an immediate commit rejection.
Please give DrewAPicture rw for develop.svn.
Could I please have write access to https://meta.svn.wordpress.org/sites/trunk/wordcamp.org/public_html/wp-content/plugins/wc-post-types ?
I need to commit some changes to the [schedule] shortcode for WCSF. They’d like it to go live today if possible.
ian@macenzie wc-post-types: svn ci
Authentication realm: Use your WordPress.org login
Password for 'iandunn':
svn: Commit failed (details follow):
svn: access to '[redacted]' forbidden
svn: Your commit message was left in a temporary file: