Records suddenly unavailable to [pdb_list] become available if submitted again

  • I am writing a custom template to go with a [pdb_list] shortcode. The template writes out, as separate tables, all parenting program run face-to-face, and all parenting programs run online. I am using groups to discriminate between which fields are common to both types of parenting programs, and which are specific to only one type of program. One of the common fields is a hidden field called ‘program_type’. Here I store either the string ‘list-online-program’ or ‘list-face-to-face-program’ when a user first registers a parenting program online (there are two different signup forms, one for each type of program). I populate the hidden ‘program_type’ field by giving it a default value of post->post_name. The result is that the field is populated with the slug of the relevant sign up page.

    This morning, my list template, while still in development, was showing both program_type=’list-online-program’ and program_type=’list-face-to-face-program’ quite nicely when suddenly, seemingly out of the blue, all the program_type=’list-face-to-face-program’ programs became unavailable to the template. When I say ‘unavailable’, I mean no records for these programs were present in a dump of $this->records, while records for the program_type=’list-online-program’ programs were still available. I’ve found that if I use the Participants Database ‘List Participants’ page and simply Submit details of a face-to-face program (without changing these details in any way) then this record does become available to my template. Doing a WordPress cache ‘Purge all’ has no effect.

    I’m wondering if you have any explanation as to why I might be seeing this behaviour. Is it perhaps caused by some kind of WordPress or Participants Database (or even MySQL) caching behaviour? In a test setup it’s not a big deal to have to re-submit less than a hundred records, but I wouldn’t like to see such a sudden ‘disappearance’ of records on my list page to occur in a production environment.

Viewing 4 replies - 16 through 19 (of 19 total)
  • Plugin Author xnau webdesign

    (@xnau)

    Yes, you’re correct about the effect of importing records with blank or empty values, and this is something I have addressed in the upcoming release. It gives the user more flexibility in how to handle empty fields when importing records.

    As you your query, the query object is not set up to work with NULLS explicitly, but if you add a filter like this, you’ll get the test for a null value:

    $query->add_filter( 'record_is_for_testing_only', '=', '', 'OR' );

    Thread Starter peterdann

    (@peterdann)

    Thanks for the clarification re the NULL values in some field following CSV import. I was beginning to think I might have been imagining that. I’ll look forward to the next update for some new options in that area.

    In the meantime, thanks, too, for the suggestion as to how to code a NULL test via the query object. Unfortunately I’m still having trouble getting this to work. I wasn’t quite sure in which place to add your suggested add_filter statement, so I tried a few variations.

    Variation 1:

    $query->add_filter(‘record_is_for_testing_only’, ‘=’, ”, ‘OR’ );
    $query->add_filter(‘record_is_for_testing_only’, ‘!=’, ‘X’);

    Resulting WHERE clause: WHERE p.record_is_for_testing_only <> “X”

    Variation 2:

    $query->add_filter(‘record_is_for_testing_only’, ‘!=’, ‘X’);
    $query->add_filter(‘record_is_for_testing_only’, ‘=’, ”, ‘OR’ );

    Resulting WHERE clause: WHERE p.record_is_for_testing_only <> “X”

    Variation 3:

    $query->add_filter(‘record_is_for_testing_only’, ‘!=’, ‘X’, ‘OR’);
    $query->add_filter(‘record_is_for_testing_only’, ‘=’, ”, ‘OR’ );

    Resulting WHERE clause: WHERE (p.record_is_for_testing_only <> “X”)

    Variation 4:

    $query->add_filter(‘record_is_for_testing_only’, ‘!=’, ‘X’, ‘OR’);
    $query->add_filter(‘record_is_for_testing_only’, ‘=’, ”, ‘OR’);

    Resulting WHERE clause: WHERE (p.record_is_for_testing_only <> “X”)

    As you can see, I’ve not managed to get a NULL check with any of these. Have I misunderstood your guidance?

    Plugin Author xnau webdesign

    (@xnau)

    Ok, so I can’t test this the way you’re doing it, but I do know that this works when using the shortcode filter, for example:

    [pdb_list template=bootstrap-pcmga filter="record_is_for_testing_only!=X|record_is_for_testing_only="]

    Check the docs here for explanation of how those filters are built: List Shortcode Filters

    Thread Starter peterdann

    (@peterdann)

    Perfect! Gives me:
    `WHERE (p.record_is_for_testing_only <> “X” OR (p.record_is_for_testing_only IS NULL OR p.record_is_for_testing_only = “”))’
    Just what I need. Thank you so much.

Viewing 4 replies - 16 through 19 (of 19 total)
  • The topic ‘Records suddenly unavailable to [pdb_list] become available if submitted again’ is closed to new replies.

Tags