Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When ACF "Date Picker" field is used inside a "Flexible content" field always return epoch time from WPGraphQL Query #212

Open
2 of 3 tasks
DenislavPopov opened this issue Jun 7, 2024 · 11 comments · May be fixed by #217
Assignees
Labels
needs: reproduction This issue needs to be reproduced independently status: actionable Ready for work to begin type: bug Issue that causes incorrect or unexpected behavior

Comments

@DenislavPopov
Copy link

Description

When ACF "Date Picker" field is used inside a "Flexible content" field, the returned value for this date field is always epoch time, disregarding the saved value. ( 1970-01-01T00:00:00+00:00 ).

Setup of the fields in ACF:
acf-setup

Saved settings on the page:
settings-on-the-page

GraphQL result:
graphql-result

Steps to reproduce

  1. Create ACF Field group and assign it to post type of Page
  2. Add "Flexible content" field and inside that field add "Date Picker" field, you can add additional fields just to check, that the data from this flexible field is returned.
  3. Query the fields added, and you'll notice the "Date Picker" field will always return epoch time.

Additional context

No response

WPGraphQL Version

1.27.0

WordPress Version

6.5.4

PHP Version

8.1.23

Additional environment details

WPGraphQL for ACF: version: 2.2.0

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have disabled ALL plugins except for WPGraphQL.

  • Yes
  • My issue is with compatibility with a specific WordPress plugin, and I have listed all my installed plugins (and version info) above.
@DenislavPopov DenislavPopov changed the title ACF "Date Picker" field is used inside a "Flexible content" field always return epoch time from WPGraphQL Query When ACF "Date Picker" field is used inside a "Flexible content" field always return epoch time from WPGraphQL Query Jun 7, 2024
@justlevine
Copy link

Hey @DenislavPopov

As you noted, this is an issue with WPGraphQL for ACF and however they're resolving their date field, so you should probably file an issue with them

(Marking as invalid? - not because we think you're not experiencing a real issue, but simply because there's no way to address a potential bug in code that exists outside of this repo).

@justlevine justlevine added type: bug Issue that causes incorrect or unexpected behavior close candidate Needs confirmation before closing labels Jun 7, 2024
@josephfusco josephfusco transferred this issue from wp-graphql/wp-graphql Jun 7, 2024
@josephfusco
Copy link
Member

Hey @DenislavPopov, I transferred this issue over to WPGraphQL for ACF.

@josephfusco josephfusco added needs: reproduction This issue needs to be reproduced independently and removed close candidate Needs confirmation before closing labels Jun 7, 2024
@DenislavPopov
Copy link
Author

Hey @DenislavPopov, I transferred this issue over to WPGraphQL for ACF.

Great, thanks! 🍻
I was just about to create new issue there and saw it's there already

@justlevine
Copy link

Hey @\DenislavPopov, I transferred this issue over to WPGraphQL for ACF.

Good to know we can do that for next time I send someone to do duplicate work 🤦

@jasonbahl
Copy link
Contributor

jasonbahl commented Jun 10, 2024

@DenislavPopov in my first attempt to reproduce, I was not able to. The date field nested within a flexible content layout is returning the date as expected:

CleanShot 2024-06-10 at 10 21 39@2x

CleanShot 2024-06-10 at 10 19 40@2x

I tried reproducing with the following:

  • ACF Field Group: acf-export-2024-06-10.json
  • WordPress: 6.5.4
  • PHP: 8.1.23
  • WPGraphQL v1.27.0
  • ACF Pro v6.3.1.2
  • WPGraphQL for ACF v2.3.0

@jasonbahl
Copy link
Contributor

I just tried with WPGraphQL for ACF v2.2.0 as well and same results. A date picker field within a flexible field layout is resolving as expected. Can you check to see that the values stored in the database are what you expect?

Also, can you share your ACF Field Group export to make sure I'm setting things up the same?

@jasonbahl
Copy link
Contributor

@jasonbahl
Copy link
Contributor

@DenislavPopov here's how the data is stored when I tested:

CleanShot 2024-06-10 at 10 36 01@2x

I'm curious if the data is saving differently for you?

@jasonbahl jasonbahl self-assigned this Jun 10, 2024
@jasonbahl jasonbahl added the close candidate Needs confirmation before closing label Jun 10, 2024
@DenislavPopov
Copy link
Author

Hi @jasonbahl

Sending the info.

The database entry looks saved in the same format and also when reloading the post page the field is correctly populated with the saved data:
database

The GraphQL result:
graphql

Export of the fields from my end:
acf-export-2024-06-10_Denis.json

@DenislavPopov
Copy link
Author

DenislavPopov commented Jun 10, 2024

Debugged the line pointed, and it looks like the format is correctly passed but the date received is not, hmm, will try to investigate further also.

debug

Addition1: I can see the $root contains correct data, but then somehow the function resolve_field returns the epoch time
debug2

Addition2: Compared the JSON exported files as with your import it works fine and narrowed it to the return format, which in my case is "return_format": "d/m/Y", while in your case is "return_format": "F j, Y",. So to narrow it down it looks it doesn't work only with the first return format:
not-working-format

@jasonbahl
Copy link
Contributor

@DenislavPopov I was able to reproduce when the return format is changed. Investigating this further.

@jasonbahl jasonbahl added status: actionable Ready for work to begin and removed close candidate Needs confirmation before closing labels Jun 17, 2024
@jasonbahl jasonbahl linked a pull request Jun 17, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs: reproduction This issue needs to be reproduced independently status: actionable Ready for work to begin type: bug Issue that causes incorrect or unexpected behavior
Projects
Status: 🆕 New
Development

Successfully merging a pull request may close this issue.

4 participants