Support » Plugin: Pods - Custom Content Types and Fields » Pods update from version 2.7.20.1 (june 4) to 2.7.21 (june, 30) broke my website

  • Resolved ahartoog

    (@ahartoog)


    L.S.
    I run a website for a choir, that has a Pods-based database of songs, performances and their video-registrations.
    With the Pods-framework I built a system that can display the database-information as:(1) a list of songs, together with information when and where the were performed, with a link to the video-registration, and (2) a list of public performances and/or video-registrations, together with a list of songs that where then performed.

    Now, to my consternation, after upgrading the Pods-plugin from version 2.7.20.1 (june 4) to 2.7.21 (june, 30), these functions (1) and (2) have stoppped working:
    In (1), the list of songs is shown correctly, but the list of performances per song shows all performences, also the ones that do not include that particular song.
    In (2), the list of performances is shown correctly, but the list of songs per performance is empty (as if no songs were sung).

    I am now searching for the cause of this mishap. It is certain that it relates to the Pod version update, because when I roll back to the previous version everything works fine again.
    The application I built with Pods relies heavily on nested Pod statements (Pods shortcodes used in Pods-templates), and often the WHERE-clause is used as follows: WHERE=”song_DateTime='{@performance_DateTime}'” and the other way around: WHERE=”performance_DateTime='{@song_DateTime}'”.

    Looking at the changelog of version 2.7.21 update, I noticed two lines under “Bug fixes”, that may be related to my misfortune:
    * Fixed: Nested relationship fields should render as array of objects in REST. #5745 (@lkraav)
    * Fixed: DateTime field: Allow input values compatible with the display format. #5687 (@JoryHogeveen)

    I am not a programmer, and I don’t know what this means, but the words “nested relationship” and “DateTime field” caught my attention. Mayby my use of nesting is incorrect, but the most suspicious to me is the DateTime field, since the malfunction directly relates to this WHERE-clause, where judging from the result (1) WHERE=”song_DateTime='{@performance_DateTime}'” seems to be always TRUE (and renders all performances), and (2) WHERE=”performance_DateTime='{@song_DateTime}'” seems to be always FALSE (and renders not a single song).

    I am really stuck here. Not sure how to progress.
    It would help a lot to have more insight in the nature of this Pods-update, but as I said, I am not a programmer.
    I hope that there is someone out there to give me some hints how I could solve this problem.
    Of course I can provide more detailed information on this problem, and I would be happy to share all the shortcodes and templates I coded, but it is unclear to me what specific information would be needed.
    Please, maybe the Pods-update people can point me in the right direction….

    Alfred Hartoog

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    Sounds like there’s something there, you’re right.

    Quick question, why are there WHERE clauses based on exact date/time?

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    Are you registered on our Slack extended support chat yet? https://support.pods.io/chat/

    We use that some times when helping people debug specific issues that are time-sensitive (pun not intended). I’m on there today if you have time to jump into it. Once you join just DM me there, @sc0ttkclark is my username.

    ahartoog

    (@ahartoog)

    My! You are extremely quick.
    The reason for the WHERE-clauses is because a DateTime-field is used as a unique identifier for a certain performance.

    ahartoog

    (@ahartoog)

    I joined Slack support chat now

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    After discussing this with you briefly, we found a solution / workaround for you.

    Since you’re using the magic tags in the DB context, you’ll want the date to be returned as the MySQL format which can be done by adding this function:

    function my_custom_override_return_raw_value( $value ) {
        return $value;
    }

    For or your shortcodes, you can modify the magic tags you use like this: {@field_name,my_custom_override_return_raw_value} just update “field_name” to use the field you want to check the raw non-display value for.

    ahartoog

    (@ahartoog)

    Problem solved.
    Thank you so much for your excellent support!

    regards,
    Alfred

Viewing 6 replies - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.