Forum Replies Created
-
Posts
-
Manually setting
$_REQUEST[piklist::$prefix . 'post']['ID']before callingdo_shortcode()seems to be a perfectly workable (if slightly kludgey) solution.For anyone else who comes across this on Google, it’s actually very simple to do:
add_filter('piklist_part_data', function ($data, $folder) { $data['foo'] = 'Foo'; return $data; }, 10, 2);In this example, ‘Foo’ is the text you’ll include in comment blocks, like so:
/* Foo: Bar */While ‘foo’ will be the key in the part’s data array:
add_filter('piklist_part_process', function ($part, $folder) { if ($part['data']['foo'] == 'Bar') { // Do something... } }, 10, 2);If anyone else comes across this thread while looking for this information, the Piklist Documentation has since been updated with an overview of the
piklist_part_processhook:Also, I’m not sure if this is related or not, but I’ve noticed that adding and removing add more items sometimes causes the text in a middle item to seem to disappear. Upon selecting the text, it has apparently turned white.
Fair enough. I’m definitely looking forward to v1.0 – it’s natural for the API to be a bit of a moving target while it’s in beta, but it will be awesome to have an official stable release to work with, so I understand that being the priority. That said, this issue has probably been the one significant recurring pain point for me in working with Piklist, so I’m glad to hear your team will give it some thought when time allows.
Thanks Jason, that sounds like just what I need.
I look forward to the new documentation site. I hope it’ll be a Wiki – I understand the Piklist team may have limited time to write it, but with the assistance of the community, the documentation could easily be a lot more thorough. For example, since I’m going to have to dig through the code for
piklist_part_processanyway, I wouldn’t mind making some documentation notes while I’m at it, but the current docs site provides no way for me to do that.While I agree with the philosophy for most fields, I have to say I believe this is the wrong approach when it comes to add more fields. In every situation where I’ve ever wanted to use an add more field, I’ve needed to allow entry of 0 to infinity items. However, this functionality is currently impossible in Piklist; instead, we can only allow entry of 1 to infinity items. This results in ugly, awkward workarounds because posts that have no items associated with them in reality will always appear to have one item associated with them anyway. But some posts really do have one item associated with them. So when there’s one item associated with a post, we have to add in extra logic to double check whether it’s a real item or not. The fact that we have to check that means we’re getting bad data; and Piklist isn’t just allowing bad data to be entered, it’s forcing bad data to be entered.
In turn, this leads to further complications if the add more is a grouped field (which has usually been the case for my usage). Which fields are absolutely required for an item? You can’t actually make the fields required (since that will break data entry for posts with no items), so you have to expect bad data and then double-check that the required data is really there before displaying it. If any required fields are missing, you have to assume it’s bad data and ignore it. This forces you to effectively make fields secretly required, and when a user fails to fill out one field that was secretly required, they’re going to be mighty confused as to why the item they entered won’t show up on the front end.
Bottom line, add more fields are not like other fields, so forcing a blank entry to be saved when they’re empty causes a ton of problems while providing no real benefit. Add more fields need to support a truly empty, no-items-added state.
For anyone else experiencing this issue who comes across this thread, I was experiencing the same problem as the OP in WordPress 4.4 with Piklist 0.9.4.29. Upgrading to the Piklist 0.9.9.7 beta does seem to resolve the issue.
We did try flushing permalinks repeatedly to no avail. The only thing that seemed to work was swapping out the piklist filters for standard WordPress register_* functions. There may be some more complex interaction at play, but enabling/disabling other plugins didn’t make a difference. If I have some time later this week, I’ll see if I can put together some kind of minimum viable example.
