Hide blank field when form displayed in modal

For some reason, CTools modals don't include the CSS that I inject into forms with Honeypot; I'm not sure why this happens (Honeypot simply uses the Drupal-standard way of attaching CSS to a form), and I can't find any issue in the CTools issue queue having to do with this.

I'm going to mark this as needs more info, as I don't use CTools modals that much, and I haven't encountered this problem; if someone could find out what, specifically, causes the CSS to not be attached to the modal properly, I'll try to fix it. (I'm guessing it's some sort of bug with CTools, but I may write around that if enough people encounter this problem).

It does look like #561858: [Tests added] Fix drupal_add_js() and drupal_add_css() to work for AJAX requests too by adding lazy-load to AJAX framework could fix it. Please let me know if this is fixed for you once 7.10 is released (should be this week, since it's the end of the month...).

John_B: Did this issue get fixed with latest Drupal?

Going to close this for now; if anyone can find anything that would help with this in the meantime, please re-open. Or, if this issue has fixed itself in the meanwhile, let us know!

This issue still exists (in D7 -- I haven't tested in D6). I have attached a screenshot. However, I have also informed one of the site maintainers that she can just add the {display: none !important;} to her CSS. So, you may not see the issue if you happen to visit that site.

Steps to reproduce.
1. Install modal_forms.
2. Navigate to admin/config/development/modal_forms and select Enable for register new account links.
3. Create a menu item to allow people to register for the site (path = user/register)
4. Install Honeypot.
5. Navigate to admin/config/content/honeypot and either select Protect all forms with honeypot or General Forms: User Registration form.
6. Log out of the site.
7. Click the link to register.

Okay, thanks for the detailed steps! I'll try to take a look at this soon.

Here's another screen shot that shows that your #attached CSS is not appearing.

There's also a screenshot to show what it looks like when navigating directly to user/register on the site and you can see that your #attached CSS is there.

We have a custom non-iframe modal implementation which loads a drupal path into itself via a jquery $.ajax call. The form in question is a custom form which calls honeypot_add_form_protection().

We can add our own css to hide the honeypot field in the code that sets up the modal on the parent page, but I am thinking that it would be nice if honeypot could break out the code that generates the css rule into a public function, so we could just call that and not have to worry about how the specifics of the selector or the hide rule.

Any update on this? have the same problem

Hi

This is a problem of core Ajax Framework, it didn't include CSS inline properties. Attached pathe solev this proble and replace inline css styles on file. Necessary actions:
1. Apply patch
2. Run update.php

Add line to the end of file.
Necessary actions:
1. Apply patch
2. Run update.php

Fix coding standart and one fatal error.

#15 works for me.

Finally had time to review this code, and it looks like a great solution to the problem, especially since it will still work perfectly with CSS aggregation and not cause any extra problems. A few nitpicks before I finally add the patch:

1. +++ b/honeypot.admin.inc
   @@ -173,8 +173,20 @@ function honeypot_admin_form_validate($form, &$form_state) {
   - * Clear the honeypot form cache on submit.
   

   Can you stick this as an inline comment above cache_clear_all, so the documentation isn't lost?

2. +++ b/honeypot.admin.inc
   @@ -173,8 +173,20 @@ function honeypot_admin_form_validate($form, &$form_state) {
   + * Submit admin form.
   

   Can you change this to "Honeypot admin form submit callback." instead?

3. +++ b/honeypot.admin.inc
   @@ -173,8 +173,20 @@ function honeypot_admin_form_validate($form, &$form_state) {
   +  // Create css style file for honeypot.
   +  $path = 'public://honeypot/css';
   +
   +  if (!file_prepare_directory($path, FILE_CREATE_DIRECTORY)) {
   +    drupal_set_message(t('Unable to create Honeypot css directory, %path. Check the permissions on your files directory.', array('%path' => file_uri_target($path))), 'error');
   +  }
   +  else {
   +    $filename = $path . '/honeypot.css';
   +    $data = '.' . $form_state['values']['honeypot_element_name'] . '-textfield { display: none !important; }';
   +    file_unmanaged_save_data($data, $filename, FILE_EXISTS_REPLACE);
   +  }
   

   I'd rather have this in a separate function (so it has a cleaner interface, and so it could potentially be called from other settings-related functions).

4. +++ b/honeypot.install
   @@ -129,3 +132,18 @@ function honeypot_update_7003() {
   + * Create  honeypot css file if it doesn't exist.
   

   Remove extra space before honeypot, and capitalize Honeypot/CSS.

5. +++ b/honeypot.install
   @@ -129,3 +132,18 @@ function honeypot_update_7003() {
   +    drupal_set_message(t('Unable to create Honeypot css directory, %path. Check the permissions on your files directory.', array('%path' => file_uri_target($path))), 'error');
   

   Same thing, please capitalize CSS (nitpicky, I know... ;).

6. +++ b/honeypot.module
   @@ -162,7 +162,8 @@ function honeypot_add_form_protection(&$form, &$form_state, $options = array())
   +          'type' => 'file',
   

   Is this line required? The docs are a little sparse on #attached, but I thought you just pass a path to a file, and Form API is happy. I could definitely be wrong, but just wondering :)

@Arlina thank you for testing patch and updating issue.

@geerlingguy thank you for review. I fixed all notes and here is patch.

Oops, wrong patch. Here is correct.

I think I can set this issue as RBTC, cause it was checked by geerlingguy previously.

Sorry I've taken so long to get around to this; I will try to commit it to dev branch within the next week or so.

I've committed the patch from #20 with a few minor changes (added a 'create css' call to hook_install, so the module would have a CSS file in place if the user doesn't go to the admin form and submit it, and changed a couple comment lines). Thanks so much for the help on this!

I'm going to leave this feature in the -dev branch for a little while, then tag a new version once I've confirmed it works on all the sites on which I use Honeypot (since it changes the way CSS is generated and applied, I want to make sure we're not missing any use case).

hmm, how is the css file loaded without adding it through drupal_add_css()?

nevermind - my oversight:

      '#attached' => array(
        'css' => array(
          'data' => variable_get('file_public_path', conf_path() . '/files') . '/honeypot/css/honeypot.css',
        ),
      ),