Justify curl (and other) exceptions when submit plugin

[123milliseconds]

Trasferred from ​#WP49341.

When I submitted a plugin the WordPress QA team suggested I raise a ticket - this is that ticket.

If you mean the curl, curl is acceptable BUT you have to document your code as to why. We also ask you make a ticket so WordPress corrects this.

I got impression after 2 tries to get plugin approved the QA auto scan source code and auto replies to me with list of problems.

I could not get anyone to look at code since I had code issues ... with curl.

Could we have some tag in source code where developers list reasons they use a 'forbidden' function ... like curl.

This tag needs to be in source code. Then QA team can see the problem case INSIDE the context of the source code.

Example:

justify ## Using CURL Instead of HTTP API

justify This plugin needs the curl total-time response from CURL
justify This curl time measure is the reason the plugin exists.
justify I cannot use the wp http api - it has no total-time.

[SergeyBiryukov]

Hi there, welcome to WordPress Meta Trac! Thanks for the ticket.

For some context, as noted in ​#WP49341, getting the total_time from cURL via WordPress HTTP API is possible using the requests-curl.after_request action hook, see the comments on ​#WP47659 for an example.

[Otto42]

Generally speaking, we want you to have a conversation with the plugins team for such cases, because we're not aware of any cases where direct use of curl is needed, since the http API can be used for everything we know of. If you find something new, then we want to know about it.

All emails from the plugins team come from people. You can reply to them. Talk to us, so that we can talk about it and understand the issues.

[dd32]

Documenting in the code why you're not doing something the standard WordPress way, and instead using an alternate or more lower "raw" method would also fulfil the purpose here and would make it obvious to the non-plugins-team members who look at the source code as to why you're doing something different.

If I saw a plugin using curl directly, with no comments as to why in the code, I'm going to assume that they just didn't know about WP_HTTP and need reminding/teaching/etc.

That being said, if you're just after the total-time from cURL, then you're probably better off using timer_start() and timer_end() around the WP_HTTP call.. at least that way your code will work on servers without cURL (more than you may think).

Given the significant number of different things that the plugins team reviews and rejects, I don't think listing every single possible thing for justification is going to be viable. If it's justifiable, it should be obvious from the code, like using a X.509 certificate in the request or something.

If/when there's automated scanning on submission, maybe that's where it could be added.. But even then, to bypass the the rejection I have a feeling we'd require an email to the plugins team first..

I'm closing this as wontfix for now, but with the intention that it can be re-opened later if needed by the plugins team. Discussion can continue while the ticket is closed.