Tagged: 

Viewing 9 reply threads
  • Author
    Posts
    • February 17, 2014 at 12:45 pm #1415
      Jason
      Keymaster

      I’m using 0.9.3

      I have an add_more textfield, when I add a new line I’m able to immediately remove it. If, however, I publish the post (or go to edit it), I’m not able to remove the pre-existing lines. If, however, I add more, I’m able to remove those new ones.

      Is this a known issue?

    • February 18, 2014 at 12:14 am #1420
      Kevin
      Keymaster

      Not yet, but if you can post your version of WordPress and what OS/Browser you are using we will add it to our current test list.

      Thanks,

      Kevin

    • February 18, 2014 at 2:53 pm #1427
      Jason
      Keymaster

      I’m using WordPress 3.8.1 from Chrome 32.0.1700.107 on Ubuntu 12.04.

      Thanks, Kevin!

    • April 3, 2014 at 11:42 am #1640
      Jason
      Keymaster

      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?

    • April 3, 2014 at 12:08 pm #1641
      Jason
      Keymaster

      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!

    • April 3, 2014 at 12:50 pm #1642
      Jason
      Keymaster

      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.

    • April 7, 2014 at 4:23 pm #1644
      Steve
      Keymaster

      @jason–

      If you remove the “columns” attribute that will temporarily fix the issue.

    • April 8, 2014 at 10:47 am #1647
      Jason
      Keymaster

      That works. It does scrunch the textarea, but at least the user can manually resize for now. Looking forward to the fix!

      Thank you!

    • April 9, 2014 at 6:24 am #1648
      Steve
      Keymaster

      @jason– You can use CSS to size the box. You can even add your own css classes to the field:

      "attributes" => array(
  "class" => "my-class"
)
    • April 17, 2014 at 5:45 pm #1653
      Jason
      Keymaster

      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!

  • Author
    Posts
Viewing 9 reply threads
  • You must be logged in to reply to this topic.