- This topic has 12 replies, 5 voices, and was last updated 8 years, 4 months ago by
.
-
Posts
-
-
Since beta 5 when I edit an existing add_more group of fields (containing two text fields), the UI is messed up, I get add_more containers within add_more containers.. the depth of this recursion is equal to the number of add_more blocks.
This can be reproduced with the piklist demos, in “Address (Grouped/Add-more)” if you enter two addresses then click save. When the page gets reloaded you’ll see what I mean.This doesn’t seem to happen when the add_more block contains only a single field.
This was working fine with beta 4, looks like a regression.
-
-
Problem looks related to change in parts/fields/group.php line 24 done for beta5:
empty() has been replaced by isset()using !isset() instead leads to similar results to empty(), group fields are not intertwined but still there is a problem with labels it seems.
once again, problem can easily be reproduced in piklist demos: Groups> add two grouped addresses and save.
-
-
-
-
Add-Mores are even better in Beta 6.
You can download it from Trunk at WordPress.org > -
This problem is indeed fixed in beta6.
I can see there are big changes in the format of those add_more metas: the array is inverted. When it was once an array of lines, it is now an array of columns (first key being the name of the field, second being the line).
Am I correct?That will change several parts of my code, which is understable because there’s a beta label after those 0.8 releases but it would be great to see a little note about these kinds of changes, especially data format, in a release note.
This is just a gentle advice, that doesn’t take anything away from the hard work you put in releases in general. Cheers guys. -
@chrisben– You’re absolutely correct. Changes as big as this should have noted in the announcement, and will be handled better in the future.
Let us know what you think about the new array structure. We think it works much, much better.
-
I think it will be easier for you guys whenever there’s a change in the fields of an add_more: it’s only a matter of changing 1 key in the array (instead of changing x keys). It should also incidentally use less space in the database because field names are only used once (the rest is made of index keys).
For me, I think it’s a little less easy to work with.
I use add_more fields to store lists of objects that have a given set of attributes. So it’s more intuitive to be able to pull a list of items, and inside each item a set of key/values.But it doesn’t bother me that much as I just needed to implement a short function to rotate the array from/to the metas, so it hasn’t had such a big impact on the rest of my code.
Perhaps you guys could offer such wrapper code to get/set the metas of add_more fields with that older behaviour.
-
@chrisben-
Good points, if you only knew how many conversations we have had on this subject 😉 We want this to be insanely flexible but just as easy as well. That being said can you post some code examples of what you like and don’t like so we can wrap our heads around the issue? We would like to make sure that if there are even more ways to improve this that we do just that before we launch the production version.
Thanks,
Kevin
-
Perhaps you could add something like:
piklist('get_post_custom', $post_id, array( 'add_more_array_type' => 'by_lines' ) );The third parameter being a set of options for this function (or could be merged with second parameter into a single array).
This would return the rotated array for add_more fields in case of ‘by_lines’ or the new behaviour with ‘by_field’ value (default).
That would make it easier to retrieve the values of those add_more fields.Another method needed would be a helper to save back those meta data. The purpose here is to hide completely the actual data format from the user, so that you could in the future change it if you need without breaking existing codes.
Perhaps a mirror to ‘get_post_custom’: ‘set_post_custom’ with similar parameters plus the array of fields/values to store (the new option “add_more_array_type” to tell the method how the input array is formed).That would make things extra easy to pull all meta data, modify one value in a field by changing the returned array and then store everything back.
Perhaps also one might need more granularity to load/save only one field at a time (wrapper around get_post_meta).
What do you reckon?
-
Just a heads up, this example in the docs no longer works.
<?php $orders = get_post_meta($post->ID, 'order_add_more', false); echo '<ul>'; foreach ($orders as $order): echo '<li>' . $order['item'] . ', ' . $order['qty'] . ', ' . $order['due']</li>'; endforeach; echo '</ul>'; ?>I instead had to use this.
<?php $quotes = get_post_meta($post->ID, 'location-testimonial', false); ?> <?php $qcount = count($quotes[0]['quote']); ?> <?php $i=0; while($i < $qcount) { ?> <div class="quote"> <blockquote> <p><?php echo $quotes[0]['quote'][$i]; ?></p> <small><?php echo $quotes[0]['source'][$i]; ?></small> </blockquote> </div> <?php $i++; } ?>Seems a bit more code than it should be, no? Is there a better way to get these values?
Thanks!
-
- You must be logged in to reply to this topic.