I installed honeypot with Drush and honeypot.css was created without Apache having the permission to write to it. When the dummy field name was changed in the admin UI the module wasn't able to update the css file leaving the field displayed.

CommentFileSizeAuthor
#6 honeypot-permissions_check-2839775-6.patch670 bytesponies
#2 honeypot-permissions_check-2839775.patch674 bytesponies
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ponies created an issue. See original summary.

ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented
Issue summary: View changes
FileSize
honeypot-permissions_check-2839775.patch674 bytes

This patch adds a check on file_unmanaged_save_data returning an error if Apache isn't able to update honeypot.css.

This does not revert the field name change. It just lets you know it's going to be broken when you submit it.

ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented
Issue summary: View changes
ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented
Status: Active » Needs review
geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented
Status: Needs review » Needs work

One quick nit—it looks like there are four spaces of indentation in the line inside the if statement.

ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented
FileSize
honeypot-permissions_check-2839775-6.patch670 bytes

Now with fewer spaces!

ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented
Status: Needs work » Needs review
joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented
Status: Needs review » Reviewed & tested by the community
geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented
Status: Reviewed & tested by the community » Needs review

@ponies / @joseph.olstad — do you know if this problem also affects D8? I'd rather not merge a patch into the D7 branch until I'm sure it's fixed in D8 as well.

ponies’s picture

ponies
Location Chico, CA
CreditAttribution: ponies commented

@geerlingguy I've got one D8 site in development. I'll try to test it today.

geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented

@ponies - Awesome, thanks!

geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented
Status: Needs review » Postponed (maintainer needs more info)

Updating the status to reflect what this is waiting on. If I get a chance, I'll try testing in D8 as well... just haven't found the time yet.

bwaindwain’s picture

bwaindwain CreditAttribution: bwaindwain as a volunteer commented

I'm experiencing this too. On drush install, honeypot works fine. The honeypot folder and css file are created on install, but they're owned by me so apache can't write to it. The config page shows error message "Unable to create Honeypot CSS directory, honeypot. Check the permissions on your files directory."

So, I can only use the default field name.

Other modules, like fontyourface, create their folder and css file on first usage, not install. They use an md5 hash. This seems like a better way which works in all situations by ensuring that the folder and files are created by apache. See discussion and commits at https://www.drupal.org/project/fontyourface/issues/1165658

TR’s picture

TR CreditAttribution: TR commented

Has anyone tried to see if this problem affects the D8/D9 version of Honeypot? That is where this issue stalled > 4 years ago.