Do you mean $start_date_time and $end_date_time instead of 2x $start_date_time ?
If so, the first example seems to be ok.
If start_date_time = 2017-08-18 00:00:00
and $end_date_time = 2017-08-18 11:59:59
then it shouldn’t get a result because 2017-08-18 20:00:00 is bigger than both dates instead of bigger than one and smaller than one.
The second example also seems to be ok.
If start_date_time = 2017-08-01 00:00:00
and $end_date_time = 2017-08-31 11:59:59
then 2017-08-18 20:00:00 is bigger than start_date_time and smaller than $end_date_time so it would show.
I don’t see anything wrong with this right now. This would give the result as expected (or i’m missing what the issue is…).
This is my take on the solution. Not saying it is the best, but I think what you want can be achieved with it. You could look into render_field (create_field in the non-pro version). You can add html to any field there.
You could create a form there with 3 buttons, which each have their own function and send a mail with wp_mail and hook it in the field you want it to show. Shouldn’t be too hard…
Maybe real simply thought, but why not store the data in post_meta in an array ? Then it can hold several evaluations. It doesn’t have to be a single value.
I understand, that’s why I quoted ‘right way’. Because if prefer to do it as Eliot had in mind when he wrote the template for extensions but I don’t mind using it this way. I’m already happy it works 🙂
It just has me wondering why it doesn’t work, with the ‘default’ update value function.
If you’re interested, you can testdrive the plugin (it’s on Github)… Always appreciate any input from other devs on it…
I will open a new ticket… I wanted to already before I found this one 🙂
I think I have fixed it with a workaround by using save_post and storing the value through update_post_meta.
I had to make an exception so this doesn’t run when v5 is active (because it works there already), so when the v4 fields are loaded I store an option value which is checked in the save_post. If it’s v4 the function runs, otherwise not.
While it does appear to be working now as I want it, I’d still like to have it working the ‘right way’. Maybe @hube2 has some insight ?
I dug around a bit. I learned that get_field_objects( get_the_ID() )
returns as false. Which tells me the fields don’t seem to be ‘connected’ to this post.
I started with a vanilla install again to test what happens without my plugin. Then the save function works as expected. So I concluded the flaw lies in my plugin. This code comes from the template provided by ACF, so I would think/expect it would work with that.
I checked through my file and I can’t see anything (yet) that would ‘stop’ values from being saved or the field from being ‘disconnected’. If I look in my database I can also see the stored Field group rule which is connected to posts, so that looks ok.
The normal save_post action works but I would still need get_field_objects to get the correct field key for it, to save it properly.
But then I probably run into the issue that the fields might not be loaded properly since the field is not recognised.
If I add a normal text field to the same group, its value does get stored….
So I just need to ‘connect’ this field to a post, then it should work I think.
I am building an extension for ACF so I can’t ditch ACF 🙂
I tried different priorities for acf/save_post but it just won’t reach the function. I put var_dumps and dies in there but it just won’t reach it.
I also tried several priorities already; 1, 10, 20, 100. Nothing would hook.
I hadn’t thought about WP’s save_post. That might be an option for me as well.
@hube2 since you recommended looking at the logs, I did, but nothing shows up there.
I have run into the same issue that values are not saved when using the Free version.
Using the Pro version (on the same installation, which is a vanilla WP install with twentyseventeen) does work.
I have used this template to create my plugin.
Everything works as expected with the Pro version but I can’t seem to hook into the acf/save_post action nor store/see any post data (with the free version active).
I tried to hook it from functions.php as well as from my custom plugin.
It seems update_value in this file is not reached.
@thelonedeveloper did you ever find a fix ?
@gilzow doesn’t the filter work for you ?
Sorry my misunderstanding… I’m using the filter, so I’m not bothered (anymore).
5.6.1 didn’t fix this.
Was hoping that someone has some insight perhaps ?
I think you can do this with acf/save_post.
Get the values from that repeater field.
Check if a page exists by title.
If it doesn’t exist, create a new post.
Please mark it as resolved.
Thanks !!
If you achieved it already, why repost it ?
Would it be an idea to create a repeater for each post (to select), with 1 Post selector and 1 empty text field.
Upon save you hook into acf/save and write a simple function which fills the empty field with the necessary shortcode.
Hey @westjef, thanks for the reply, sorry it took a bit, but I don’t think our ‘situations’ are similar.
My base language is English, not Dutch. All values/entries/choices/options are in English.
I don’t want the user to have to translate anything. There should be one post only for all languages and the label is the thing that needs to be translated (imo).
They enter the profile in the way the form is presented to them, which is in English right now.
I think there are 2 steps:
1) translating the output so visitors can use a different language to view
2) translating the input so users can use a different language
But for both the values need to be the same imo.
you’re welcome, glad I could help.
$stored_type should return an array or WP_Error, see this link.
$posted_type should return the value which was selected in the form.
With this value you create an a term object/array, see here.
Now you should have 2 values to compare.
I think you should look into defining $_POST[‘acf’] differently.
AFAIK (but I can be wrong), the fields are only defined by key and not by name.
So I would change
$_POST['acf']['field_picktype']
to
$_POST['acf']['field_key']
like I did in my example.
If you don’t know how to find them go to Custom Fields > Field Groups > Your group > Screen options > Check Field keys.
Does anyone have any insight/intel reg. this ? I’m stumped….
I can’t get it to work 🙁
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.