Allow to change the URLs to use for importing useragent information

+1 - works for me, but would let more reviews before RTBC

It looks like the Full browscap.ini file might be overkill for most projects and could cause performance problems until #484346: Improve performance of useragent lookup is fixed.

I think the best way forward would be to provide an administration interface which gives site administrators the ability to select which Browscap database is used for useragent detection information.

Hi,

a patch for this. It implements:

1. two defines for the default URLs to version and data;
2. two Drupal variables to store the URLs as changed in configuration;
3. changes to the admin form to edit the URLs;
4. one additional button in the admin form to 'force' the reload of the Browscap data, bypassing version checking. This is useful if admins want to change the .ini database e.g. from basic to full within the same version.

#3 works good for me.

Title change to make this issue more clear.

Redacted.

Works brilliantly,

Note the domain change of browscap project (see: http://tempdownloads.browserscap.com/moved.php?BrowsCapINI), the URL's now should read:
http://browscap.org/version-number
http://browscap.org/stream?q=Lite_PHP_BrowsCapINI
(I'm using the lite version but you can alter this url for other versions, see: http://browscap.org/)

Thanks!

URLs out of date

This change would let a user with the administer browscap permission cause the site to request an arbitrary URL, which is dangerous. As such, 'restrict access' => TRUE should be added to browscap_permission().

Patch in #3 looks mostly good, but seems confusing in two regards:
1. The distinction between "refresh Browscap data" and "force reload" seems like it could be unclear to an administrator.
2. Changing URLs could cause a situation where it is unknown from which URL the data was downloaded. For instance, I download ...PHP_BrowsCapINI version 1234 and switch the data URL to ...Full_PHP_BrowsCapINI. The version still says 1234, but for which URL is that?

Here is an updated patch which I think is simpler. When a URL is changed it just deletes the existing Browscap data and resets the version to 0 (i.e., "Never fetched"). This removes the need for a new button, and prevents any confusion over which URL the downloaded data comes from.

Other changes in this patch:
1. Update default URLs.
2. Rename variables from browscap_current_version_url and browscap_current_data_url to browscap_version_url and browscap_data_url. I think the word "current" is unneeded here, and the URLs also do not have to point to current Browscap data anyway.
3. Incorporate suggested change from #9.
4. Remove "from main repository" from URL field descriptions. These URLs do not necessarily have to point to the main http://browscap.org repository.

Patch no longer applies.

I have Browscap-7.x-2.2 and adaptivetheme-7.x-3.2 installed on my project. All was working fine until now. Since the last automatic update by drupal cron of Browscap useragent information to the last version (5037), the module cannot not detect Mobile browsers. On mobiles, I get the same blocks as the desktops.
Deinstall and reinstall Browscap to dowwload a clean data don't solve this issue. An alternative for me can be to download another version of Browscap data using the administration interface of Browscap, but it seems like #10 and #12 cannot be applied on the current 7.x-2.x-dev version of Browscap using patch command. I hope it is the good thread for these two issues.

[I]t seems like #10 and #12 cannot be applied on the current 7.x-2.x-dev version of Browscap using patch command.

This updated patch should apply.

Browscap 6.x has an old URL that's not working. It should probably be updated to a URL at browscap.org .

HongPong, you are right but that is a different issue, #2171549: Can't dowload last Browscap.ini RC from http://browscap.org/. It is already fixed in 6.x-2.x-dev. A new 6.x-2.x release is needed. I created an issue for this: #2423209: Make AohRveTPV the maintainer for 6.x branch (so he can make new releases, change status, etc.).

This issue is to add the ability for administrators to configure download URLs themselves.

The patch in #14 no longer works with the most recent version of 7.x-2.x-dev. A new version is attached for review.