Forum Replies Created
-
AuthorPosts
-
Arno
ParticipantI asked FacetWP as well but they don't know. Do I need to format the received value somehow before I can use it in a view?
ParticipantHi Long,
Ok, that's likely the problem then. I assumed this would work out of the box, because FacetWP is a supported plugin. What do I need to do exactly? I'm not a developer so I need a bit more guidance.
FacetWP needs to be pointed to a field that holds he correct coordinates. So I guess your first method won't work because that's an example of how to get the lat/long values from code.
The second method might be ok. If I understand correctly, I can have code in functions.php that saves the field map value to an extra field, where it only stores lat/long without the zoom? How do I do that?
Thanks!
ParticipantHi Long,
Your findings made me do a different test. I forgot the quotes around the variable in the view, but that does not make a difference. I now have this in the FacetWP listing, but it does not work:
[mbv name="display-related-things" vw_posttype="{{post:type}}"]Passing the hardcoded value does work:
[mbv name="display-related-things" vw_posttype="activity"]Somehow the value passed by FacetWP does contain the string "activity", but it fails to match in the if-statement. The hardcoded string works fine. Really weird.
ParticipantHi Long,
I guess that works, but somehow the value is not what I expect. Here's an example:
{% set listing_current_post_type = vw_posttype %} Type is {{listing_current_post_type}} {% if (listing_current_post_type == 'activity') %} Match {% else %} Nomatch {% endif %}The output of the view is:
Type is activity Nomatch
I'd expect a match.
I have a similar issue with the post ID (integer) I want to use. Somehow it's not recognized as an integer.
ParticipantHi,
I got some feedback from Kadence: "It's intentional that we show custom fields; removing the field in Meta Box doesn't remove the data from your posts, and since you can use many things other than Meta Box (like your own custom code) to create custom fields, we intentionally show all the fields that WordPress shows when we do a query, not just the fields that you've created with Meta Box. This means that if you make a field and add content, then that data is registered with WordPress, and you would need to remove it there (not just the plugin) for it to not show in our options."
I did remove most, if not all, field data from the posts before removing the fields themselves. WordPress is not very good in cleaning things up I guess, and after a while it's inevitable to delete old stuff from the database using plugins like you suggested.
ParticipantHi Long,
Thanks, that helped me out. Here's what I ended up with to make it compare on time too:
meta_query: [{ key: 'promotion_start_date', value: 'now'|date("Y-m-d H:i"), compare: '<=', }, { key: 'promotion_end_date', value: 'now'|date("Y-m-d H:i"), compare: '>=', }],ParticipantAnd it seems to only become a problem once the taxonomy is associated with the post type.
ParticipantI found the issue. The taxonomy had the same slug as a custom post type. I did not realize that when creating it, and there's no error or warning for mistakes like this.
ParticipantThank you Long.
ParticipantThank you, that works great!
ParticipantHi Long,
Sorry, I am not exactly sure what I need to do. Go to the post in edit mode and save again? I did, but that didn't help. Or do I need to change the permalink? The problem is not restricted to one post.
How do I get the code that creates the post type? I used MB Custom Post Types & Custom Taxonomies to create it.
ParticipantThank you, I understand.
ParticipantHi Long,
I'm using Gutenberg. I must admit that I don't understand what this option is doing exactly. Is it only for the editor behavior and has nothing to do with how the field is saved to the database?
So, in my case I should disable this for all fields?
ParticipantO yes, I see that now. Even a new post will have at least one group of fields, even if nothing was filled out yet. So, if processing a group, we should always check for a group of fields without a value, or with a default value.
I'm not sure if this makes sense. For example: the post is a Product, and the cloneable group is possible Discounts. Then there's always at least one discount, with empty fields, even if the Product is not discounted.
It's unexpected, but good to know it works this way 🙂
ParticipantThanks, I got it working now.
Perhaps for a feature version of Views it would be a good idea to also add some help for working with taxonomies that are related to the post. That's pretty common. Almost all my custom post types have custom fields as well as custom taxonomies.
-
AuthorPosts