Support for Cloudflare's v4 API will be required after November 2016

Patch to Support for Cloudflare's v4 API

@maindeepak - it looks like you generated your patch one folder too high. Generate it from right inside the cfpurge module folder, so your git diffs look like:
diff --git a/cfpurge.inc b/cfpurge.inc
instead of
diff --git a/cfpurge/cfpurge.inc b/cfpurge/cfpurge.inc

Thank you @cwells. I have updated the patch.

@maindeepak - I think this patch may also be failing to apply because of the file encoding. It looks like it is UTF-16LE. I'm not able to open this file in my NetBeans in this encoding. I can however open in Sublime. You may want to try with us-ascii as the encoding.

Was this patch generated from a diff of 7.x-1.2 or from 7.x-1.x-dev? I think the testbot is applying against the tip of the development branch, but I see you updated the issue version to 1.2.

@cwells - Must be against dev. I was able to apply against dev, with hunk fail of the .inc file on stable.

Current patch generated from a diff of 7.x-1.x-dev. I have tested against 7.x-1.x-dev and look good.

Hope this time testbot will pass it.

This seems to me to be an error with the testbot.

It seems like it's trying to apply a patch to run-tests, which won't apply. Might have to kick testbot tomorrow or later after a new patch is made for it, and it is updated.

https://www.drupal.org/files/issues/2551981-21-add-directory-option-to-r...

17:09:02 Saving to: '/var/www/html/2551981-21-add-directory-option-to-run-tests.patch'
17:09:02 
17:09:02 
 0% [                                       ] 0           --.-K/s              
100%[======================================>] 3,112       --.-K/s   in 0s      
17:09:02 
17:09:02 2016-08-17 17:09:02 (84.6 MB/s) - '/var/www/html/2551981-21-add-directory-option-to-run-tests.patch' saved [3112/3112]
17:09:02 
17:09:02 HTTP/1.1 200 OK
17:09:02 Content-Type: application/vnd.docker.raw-stream
17:09:02 
17:09:02 
17:09:02 cd /var/www/html && git apply ./2551981-21-add-directory-option-to-run-tests.patch || true
17:09:02 Command created as exec id 61e60f46
17:09:03 error: patch failed: scripts/run-tests.sh:142
17:09:03 error: scripts/run-tests.sh: patch does not apply

#2733509-14: Support for Cloudflare's v4 API will be required after November 2016 does not look good.

It looks like every call to cfpurge_serial_request and cfpurge_parallel_request is purging everything. See https://api.cloudflare.com/#zone-purge-all-files

I also noticed cfpurge_serial_request is still looping over $urls. So if there are 10 urls, 10 curl requests are made that purge everything, not just what's in $urls.

Some other things that seem wrong:

- Why call get_zone_identifier() every single time? The zone id will not change. cfpurge_zone_identifier is never actually set.
- This new API seems to make cfpurge_parallel_request useless. All of the URLs you want to purge can be sent in a single curl request.

Attached is a new patch that: only runs one curl command, does not purge everything, and sets a purge URL. There are some extra watchdog logs too.

Seems to be failing for no good reason, similar to the patch in #14. Is it because there are no tests included with this module?

It's also worth noting that the v1 API does not work for members of multi-user organizations within CloudFlare. The v4 API is needed for multi-user orgs.

I have a very strange issue with the module while doing some tests, I just wonder if you experienced similar.
When I purge a specific URL via command line with curl, based on the CF docs for v4, all works fine.

However when I purge with the module, although the header of the object turns from HIT to MISS, but it also stays on MISS for a long period of time (like an hour)

While via the command line, I have one MISS and after it directly get's back to HIT as expected.

@gaborpeter - I assume you mean with the patched version using #20?

I am currently using this in production, and I'll let you know if anything goes wonky, but I looked over the code and it's great and simple. I appreciate the additional logging. Though this solution "overfixes" the issue, I believe this should go in as-is and for any nit-picks we can open additional issues, as the November deadline is looming...

So, RTBC.

I'm also using this patch successfully in production.

Would be good to see this committed !

Committed. Thanks everyone!