Tagged: 

This topic contains 12 replies, has 2 voices, and was last updated by  Jason 4 years, 8 months ago.

  • Author
    Posts
  • #2925

    Jason
    Keymaster

    Here’s an interesting one:

    piklist('field', array(
      'type'    => 'group',
      'field'   => 'test-group',
      'label'   => 'Test Group',
      'fields'  => array(
        array(
          'type'    => 'editor',
          'field'   => 'test',
          'label'   => 'Test Editor',
          'options' => array(
            'media_buttons' => false
          )
        )
      )
    ));

    Pull the editor out of the group and it works just fine. But in there if you click the anchor button on some text, enter the url, and click “Add Link”, it takes you back to the editor but the anchor isn’t actually added. I also noticed the switching between Visual and Text causes issues. It seems like a javascript issue.

    In case it’s important, I’m using this field on a settings page.

  • #2929

    Steve
    Keymaster

    @jason– Try upgrading to v0.9.4.21. I think that fixes the issue.

  • #2930

    Jason
    Keymaster

    It did! Perfect!

  • #2933

    Jason
    Keymaster

    Greetings!

    I found that if ‘quicktags’ => false then the anchor button stops working again. If true, then no problem. The strong and other buttons continue working fine in either case.

  • #2934

    Steve
    Keymaster

    @jason– Could you test with the wp_editor function directly? Would like to know if this is a WordPress or Piklist bug.

  • #2935

    Jason
    Keymaster

    So here’s what I did:

    wp_editor('', 'test_editor', array(
      'media_buttons' => false,
      'teeny'         => true,
      'wpautop'       => false,
      'quicktags'     => false
    ));
    
    piklist('field', array(
      'type'    => 'editor',
      'field'   => 'test_field',
      'label'   => 'Test Editor',
      'options' => array(
        'media_buttons' => false,
        'teeny'         => true,
        'wpautop'       => false,
        'quicktags'     => false
      )
    ));

    I also tested using an underscore instead of hyphen in the field name, as I assumed you’re getting the editor id from the field and I read that hyphens can cause problems (which I usually use in field names).

    On a side note, I can’t get ‘textarea_rows’ to work with Piklist, either, but it works just fine with the native function.

    The conclusion, though, is that there’s an issue with Piklist. I had no anchor issues with the native wp_editor function.

  • #2938

    Jason
    Keymaster

    As far as the ‘textarea_rows’ issue goes, I was looking at the editor.php code and realized you’re using ‘editor_height’. I’m not exactly sure why. If I use that in the field properties instead of textarea_rows, then I’m able to adjust the height properly. I tried omitting ‘editor_height’ from the default options and using ‘textarea_rows’ instead, but for some reason that didn’t work.

  • #2939

    Jason
    Keymaster

    I believe I figured out the issue, and it’s the default ‘textarea_name’ that Piklist derives from the $name and $_attributes variables. I believe it’s an illegal characters issue, as the name would then include hyphens, spaces, and equal signs.

    If I include a ‘textarea_name’ in the field options, it fixes the issue.

  • #2940

    Jason
    Keymaster

    Ok.. so I’ve found that Piklist uses the textarea_name in order to know where to save the field. I’ll let you guys take it from here since I’m not sure how you’re using the textarea_name to save properly.

  • #2942

    Steve
    Keymaster

    @jason– Appreciate you investigating the issue. It’s a bit tough to follow in your posts. Can you specify what the issue is and how to resolve?

    • #2943

      Jason
      Keymaster

      Hi Steve,

      Sorry for the mixture of notes. 🙂

      After some research, I realized that the wp_editor function relies on the ‘textarea_name’ to save to the settings. So while setting it to something simple fixes the editor issue, it breaks the editor actually saving to the database (a rather bittersweet victory).

      I believe the final issue is that I’ve made a habit of using hyphens in database names. Normally this isn’t an issue, but I believe that wp_editor is attempting to build javascript variables based on the id and textarea_name, which is why hyphens cause issues.

      As for a fix? I believe that’s really a wp_editor bug, so I’d just put a note in the docs to avoid using hyphens when dealing with the editor field.

  • #2961

    Steve
    Keymaster

    @jason– What am I looking for to duplicate the issue? I add hyphens in the field name… now, what should happen… or not happen?

    • #2963

      Jason
      Keymaster
      This reply has been marked as private.

You must be logged in to reply to this topic.