Closed (outdated)
Project:
CAPTCHA
Version:
6.x-2.x-dev
Component:
Image Captcha (image_captcha)
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
10 Mar 2010 at 03:50 UTC
Updated:
27 Sep 2019 at 20:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
soxofaan commentedThe Image CAPTCHA admin page scans for available fonts in various places:
Maybe you have a huge "files" directory and it's the scanning of that directory that takes all the time?
Can you try disabling the scanning of the files directory and check if that fixes your problem:
Comment #2
eldrupal commentedRight on @soxofaan. Yes, the files dir is linked to an image dump containing thousands of files! Disabling the scanning code solved the problem. Thank you for providing rapid support and thank you for creating this wonderful spam-killing module :-)
I would like to suggest that you consider i) making the search optional with a check box; and 2) permit the admin to specify the directory targeted for search. That would be awesome!
Cheers,
~DrupalFan
Comment #3
soxofaan commentedI'm even tempted to just drop the scanning of the files directory.
In #496204: Configurable font storage location (eg. /usr/share/fonts), we added scanning in folders
sites/all/libraries/fontsandsites/example.com/libraries/fonts. This is much better than the files directory, which was the only option originally.But maybe it's best to make it optional for the Drupal 6 version
and drop it for the Drupal 7 version
Comment #4
eldrupal commentedSounds good and it is in very good hands. I am closing this issue since you have already address it. I look forward to future releases of a module that make it possible to run interactive websites (and without relying on external services).
Cheers,
~DruaplFan
Comment #5
soxofaan commentedPlease leave it active, because It's not fixed yet :)
Comment #6
soxofaan commentedcommit http://drupal.org/cvs?commit=453490 from #670810: Port to Drupal 7 removed support for the files directory, so this issue is fixed for the Drupal7 version.
Comment #7
japerryThis issue is not fixed for 6.x version. And causing issues. The default array for scanning has the correct paths entered, but the admin page that calls the function passes in the files directory, negating the default paths.
Attached is a patch to remove that call and use the defaults only.
Comment #9
abautu commentedI have this issue too. Our files directory is on a SAN with 20GB+ and 200K+ files. Scanning all them by default would take ages. I created a patch that allows users to set extra folders to scan (one or more local dirs and/or the drupal files (sub)folders). By default it turns off files scanning thus breaking compatibility with current code (intentionally). It's patched against 6.0-2.5.
Cheers,
Andrei
Comment #10
soxofaan commentedI'm not sure if this is worth all the hassle of making it optional (note that explode(":", ..) of an empty string does not return an empty array).
Why not just drop support for the files directory in D6 completely?
There are security and performance reasons to do so.
Comment #11
abautu commentedI personally don't use the files feature, but I didn't want to just take it away since D6 version has it already. Maybe others rely on it.
I also wanted to make it customizable in case other want to use some different folders.
Related to explode and empty string, there is a
if ($extra_paths). I think that's ok, right?Comment #12
wundo commentedComment #13
wundo commented