Forum Replies Created
-
Posts
-
@sbruner I’ve just struck the same issue, it breaks term_meta database queries made by Restrict Content Pro, which occur pretty much on every page load.
Reading the source, I can’t determine what the filter does… can you shed some light, and what disabling it will disable, within Piklist?
in an init handler, I’m using
remove_filter('terms_clauses', array('piklist_taxonomy', 'terms_clauses'), 10);to unhook it.https://piklist.com/learn/section/widgets/ ?
Basically each widget can consist of either one or two files – if you do not define the form file, then the widget will have no options, it will just execute the single file you provide.
Please note that widgets currently break the Customizer in more recent versions of WordPress. @sbruner this seems to be one of the nastiest bugs in the current codebase. Given the way WP are pushing the customizer as a one-stop-shop for configuration, it is a deal-breaker for some, and makes me shy away from using widgets in production code.
@sbruner should I be flagging this as a GitHub issue? I don’t want to pollute the bug list there unnecessarily.
To be clear, I don’t have any Piklist-created metadata fields associated with the Events post type, but they don’t seem to play nice without the fix above in place.
OK I think I’ve tracked this down.
I’m using 1.1 beta2
in
Piklist_Revisionthere’s asave_posthook that appears to pull a raw value from the database, and then executes anadd_metadata()with the value that’s extracted.Disable the hook, Events save.
Enable the hook, I start seeing PHP Strings in the DB in place of Arrays and I get a 500 when saving Events.I added the following line @ line 56, before
add_metadata():$object->meta_value = maybe_unserialize($object->meta_value);Values end up in the database, clean, and Events are saving OK.
The only issue that I can see, at a database level, is that the metadata values are doubled up, but this may be a hangover from an original issue, where at some point duplicates were created and now values are being slavishly copied from one revision to another perpetuating the duplicates.
What is the
save_posthook trying to achieve? Transcription of piklist-specific values from one post revision to another?FWIW, I commented out the relevant lines in
wp_save_post_revision_post_meta_serialize()but the issue remains. There must be something else going on here.this is great news @sbruner, I hope the community can add some value.
I’d second @Stephens comment above.
Steveb, I can see you’re an active member of github (ie I can see your commits here: https://github.com/sbruner).
And Piklist has this, but it’s a non-event: https://github.com/piklist
A github repo, from which 3rd parties could fork, and then make pull requests to get small improvements and bug fixes added, would be a great start (yes it would attract issues as well, but I’d see that as secondary).
There is enthusiasm, and some skill here in the community that you can tap into. There is also a lot of buy-in for the framework from developers who are now starting to get nervous, as features break with WordPress core changes, with no ETA on fixes (shortcodes, I’m looking at you).
Other things like incompatibility with W3TC caching also come to mind; they have the net effect of sapping confidence.
You don’t have to do it all alone, and it feels in the last 6 months at least, that you’ve been struggling to do so. Let the community help!
This is a big step in the right direction @sbruner ! Helps a lot when trying to drill down to a particular feature.
This is what the output looks like in Chrome; you can see the first (of an infinite number) of footer scripts being output, and a repeated piklist editor div.
@steve did this make the 0.9.9.9 non-beta release? I can’t find anything on it in the docs (or even a scan of the codebase).
