Forum Replies Created
-
Posts
-
Thanks! Glad to help!
So.. it turns out that the wp-plugins/anything on github is just a mirror of the plugins available from WP. Making a pull-request there does absolutely nothing. 🙂
Is the only way to contribute to Piklist through svn, currently?
You’re actually accomplishing exactly in the reply box (what I’m typing in now) what I’m going for. If I set tinymce => false it removes everything and makes it a glorified textarea. I’d still like the HTML buttons to be there.
The add_filter method has the same result.
Thanks!
Hi Steve!
Unfortunately that doesn’t work.. at least not well. The class, in that form, is applied to the textarea. I can apply a width to the textarea, but that means its not inheriting its width from the chain of parent divs; consequently if the browser is resized the textarea pushes into the sidebar area. So in order for this workaround to work, I’d need the class to apply to the parent.
I could use the jQuery parent selector, but, honestly, that’s starting to become more and more work and overhead just to get a proper width. Hope this bug is able to get fixed soon!
That works. It does scrunch the textarea, but at least the user can manually resize for now. Looking forward to the fix!
Thank you!
If found this bit in class-piklist-form.php on line 1156:
if (is_numeric(self::$field_rendering['columns']) && self::$field_rendering['child_field']) { self::$field_rendering['attributes']['data-piklist-field-columns'] = self::$field_rendering['columns']; }The latter part of the if statement was commented out. Uncommenting it (like I did above) fixed the problem. It did, however, break the column sizing for the textareas, but I’d rather have it work functionally.
I figured out the bug, but I’m not sure where to fix it.
First, make a post (or something) that has an add_more with multiple pre-existing items (i.e. pulled from db). Then add some new lines and inspect the elements. You’ll notice that each pre-existing line is wrapped in its own div.piklist-field-column. The new lines, however, are all children of a single div.piklist-field-column.
I suspect, therefore, add_more is designed not to allow the div.piklist-field-column to have less than one child. So it ignores the remove button.
This also causes a bug where the fields can’t change order since they’re not siblings.
If you can’t roll out a new version with this fix, please let me know whereabouts I can fix this and I’ll try to do it.
Thanks!
Hi!
Was anything every figured out with this? I eventually changed it to a text area, but I’m still having the issue. Here’s the code for it:
piklist('field', array( 'type' => 'textarea', 'field' => 'includes', 'label' => 'Includes', 'rows' => 2, 'columns' => 10, 'add_more' => true ));Am I doing something wrong here?
Woo! I was hoping to see this end up on github. My only hesitation to contribute by this point is that the roadmap doesn’t seem to be documented anywhere, and it sounds like you guys have a lot of ideas.
I don’t know if this is causing the issue, but I’m confused by you’re both adding support for and removing the meta box for author and revisions.
I found it works when I bring it out of the attributes array. So apparently this needs to be corrected in the docs.
Works great! Thanks, Steve!
That will definitely be very cool when they’re loaded on the fly in the future, but this is still great.
That is awesome. Thanks, Steve!
Seeing as the page isn’t “defined” like a post type, how would I remove the default editor in order to design a proper workflow?
As I figured you’d made, I found get_term_meta in class-piklist-taxonomy.php. Please add this to the term metabox page. Helps to know how to retrieve what you’re storing. 🙂
