Can't Commit on plugin repository – E165001

Generally opening a forum post for issues in the repo makes it harder for the right people to get to you.

The email address is plugins AT www.remarpro.com ??

In this case, the issue is your code is bad.

svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
PHP Fatal error: Can’t use function return value in write context in – on line 30

That literally means you have an error in subscribe-to-comments-reloaded/trunk/options/panel4.php on line 30 or so (line numbers can be weird).

And you already know the answer:

Pre-commit hooks are custom scripts installed by the server admin to prevent commits that break whatever rules/standards they have in place. Your commit looks like it’s being blocked because you’re trying to commit a file that matches some sort of pattern that the hook is blocking.

There’s no single answer to this question, since a default subversion server has no pre-commit hooks. You need to talk to the server admin about this.

Without looking at the code, no one can help you figure out what’s wrong but, in short, something in your code is wrong.

If you need more help, you can email us at plugins AT www.remarpro.com but, when you do, please attach your code as a zip and we may be able to spot what’s wrong.

It looks like the problem is that empty() only supports variables as of PHP 5.5:

Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.

https://php.net/manual/en/function.empty.php

So this part of options/panel4.php on line 30 is throwing the error:

empty( trim( $_POST['options']['notification_content'] ) )

Note that the pre-commit hook currently performs a PHP 5.4 syntax check. So yes, a 5.5 only structure will throw an error and fail. Fix the code to not have that problem.

Also note that the error message that the script gives you does indeed have the correct line number. If it says that your code has an error, then the code has an error. It is not mistaken, because it is using the PHP interpreter itself to find this error. It is not a server problem, and it will not be “fixed” on our end. You must correct your code.

Thank you Mika for your answer,

Yes the issue is because on my PHP version sending a string to the empty() functions instead of a variable is correc, I have PHP version 5.6

https://php.net/manual/en/function.empty.php

Also note that the error message that the script gives you does indeed have the correct line number.

You are correct and also the line is the same, I am updating the code and will confirm when is done.

Guys,

Thank you for the support I finally commit the changes.

Issue solve after fixing the PHP code.

I find it disheartening that plugins are forced to validate against PHP 5.4 in order to be committed to the repository. This prevents us from utilizing other open source libraries/frameworks that are taking advantage of a modern version of PHP. It should be up to the plugin developer to choose the minimum version of PHP required. Is there no way to specify the version of the PHP Linter to use when committing to the repo?

+1 for jamiechong’s comment. The version the plugin supports could be checked on installation to prevent breakage.

Not only would it be advantageous to allow plugin authors to select their own minimum supported PHP version, but this would also provide subtle momentum to nudge web hosts into upgrading their servers to support a half-way modern version, as more and more of the best and newest plugins start to require a higher minimum version.

That would still allow WP to support the earlier versions in terms of the core platform, yet allow the plugin authors to drive the momentum to upgrade – which is surely what we all want in the end. It benefits nobody that so many persist in running old versions of PHP on their servers, but there is little impetus for the average WP admin to upgrade if all the plugins in the WP directory are restricted to older versions.

Owing to its strong “market share”, WordPress is in a strong position to play a significant role in generating upgrade momentum in general; if website owners start bothering their hosting companies with calls to offer higher PHP versions and/or selecting their host based on version support because they want the ‘latest plugins’, then that’s all to the good, whilst those who’re happy with what they’ve got would still be at liberty to go merrily on with running WordPress on 5.4 whilst it remains supported by core.