December 3, 2014 at 11:56 am #2925
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 ) ) ) ));
In case it’s important, I’m using this field on a settings page.
December 3, 2014 at 12:09 pm #2929
@jason– Try upgrading to v0.9.4.21. I think that fixes the issue.
December 3, 2014 at 12:29 pm #2930
It did! Perfect!
December 3, 2014 at 12:58 pm #2933
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.
December 3, 2014 at 1:01 pm #2934
@jason– Could you test with the wp_editor function directly? Would like to know if this is a WordPress or Piklist bug.
December 3, 2014 at 2:05 pm #2935
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.
December 3, 2014 at 2:46 pm #2938
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.
December 3, 2014 at 3:06 pm #2939
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.
December 3, 2014 at 3:32 pm #2940
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.
December 3, 2014 at 3:53 pm #2942
@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?
December 3, 2014 at 4:45 pm #2943
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).
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.
December 4, 2014 at 5:50 pm #2961
@jason– What am I looking for to duplicate the issue? I add hyphens in the field name… now, what should happen… or not happen?
December 4, 2014 at 8:44 pm #2963This reply has been marked as private.
You must be logged in to reply to this topic.