Forum Replies Created
-
AuthorPosts
-
chrisbenMemberPerhaps 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?
chrisbenMemberI 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.
chrisbenMemberThis 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.
chrisbenMemberProblem 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.
chrisbenMemberAny news about this bug?
chrisbenMemberGuys, this is it! — at least for the issue I reported here, I haven’t tried the main widget one —
Thanks for your work!
chrisbenMemberAnybody else can reproduce the js issue with the “add new Piklist Demo” > “set Featured Image(s)” button (“Cannot read property ‘id’ of undefined”) in beta 4 ?
chrisbenMemberTried with both FF and Chrome, nuked their cache and the extension in my wordpress shows version number “0.8.0b4”, I can still reproduce issue with Piklist Demos.
chrisbenMemberMy issue, even with latest beta 4, is with custom image upload on a custom post type edit : I get javascript errors preventing me from uploading the image (clicking on the button does nothing).
To reproduce: piklist demos, try to set a feature image on “add new piklist demo”.The fix you suggested here (wp_enqueue_media) fixes that issue, though only when editing an existing CPT, not when creating a new post.
Sorry I got confused between the two issues here, but they seem somehow linked (same javascript errors related to media stuff).
chrisbenMemberThanks for this fix atomworks, though it only seem to work when editing an existing post: there’s still a javascript issue preventing us from uploading an image when editing a new post.
chrisbenMemberNot sure the code will helps as it’s more of a feature request than a bug report.
Here it is nonetheless:
myplugin.php:
$post_types['my_model'] = array(
'labels' => piklist('post_type_labels', 'Models'),
'public' => true,
'supports' => array('title', 'revisions'),
'rewrite' => array( 'slug' => 'my-model' ),
'capability_type' => 'post',
);
parts/meta-boxes/product.php:
/*
Title: Product Reference
Description:
Post Type: my_product
*/
piklist('field', array(
'type' => 'post-relate',
'scope' => 'my_model',
'label' => 'Model',
'description' => 'Model associated to this product',
'position' => 'wrap'));
From that basis I’d like to define the relationship between a Product and its Model via a selectbox instead of the current checkbox UI. The reasons are detailed in the first post.
chrisbenMemberActually the file in the above link is the same as in beta 3, Steve I think you’ve forgotten to commit to trunk.
chrisbenMembersorry to say that, but the javascript issue is still not completely fixed with beta 3, even with the updated piklist.js.
Edit a custom Piklist Post in Chrome and you’ll see 2 js errors:
1. “Cannot read property ‘id’ of undefined ” in what looks like jquery UI initialisation
2. “Object [object Object] has no method ‘pointer'” in post.php :
$(‘.misc-pub-section.num-revisions’).pointer( options ).pointer(‘open’);I did reload the page completely to avoid a possible cache problem, and just commenting out line 114 of class-piklist-admin.php removes the error.
chrisbenMemberI don’t think it’s exactly the same issue, but using piklist 0.8 beta2 and wordpress 3.6 custom user fields do not appear (only workflow tab appears in the picklist_demos), even for users other than the current user.
chrisbenMemberI see.. I had removed the ‘draft’ status from my CP and left only one status, so that one was actually Draft.
I have just discovered this caveat in the documentation:Due to the nature of WordPress, your first post status has to remain “draft“. You can change the label so it displays “New“, or “Howdy“, but the key will have to remain draft (will explain more later in the tutorial)
I got it to work now!! Thanks for that.
Another question: how do I show the relationship in the list of items? I have tried
'show_admin_column' => true
but it doesn’t add a relationship column.
-
AuthorPosts