Removing the PHP 5.4 plugin directory linting The…

Removing the PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. 5.4 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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:

  1. Upgrade the PHP linting to PHP-latest-stable (7.0)
  2. 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
  3. Switch PHP linting to being a warning instead of a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.
  4. 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.

#plugins-svn, #svn

@nbachiyski asked to add a pre commit hook…

@nbachiyski asked to add a pre-commit hook to plugins.svn to check for php syntax. I have enabled it. Please let us know if anything gets broken 🙂

#plugins-svn

Do you think we could get OpenGrok working…

Do you think we could get OpenGrok working reliably for plugins.svn.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/?

#opengrok, #plugins-svn

Daniel Convissor is having trouble reaching plugins svn…

Daniel Convissor is having trouble reaching plugins.svn.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, here’s a traceroute:

http://paste2.org/p/2075823

Is this a broader issue?

Will give his email to @barry on Skype if any more info is needed.

#network, #plugins-svn