trouble reproducing Virtual Post example

Chester –

I ran into trouble trying to create a nested loop in a base with the following definitions. (Don’t get too hung up on the mechanics of the loop or [especially] the field designations, which aren’t to be taken literally, as my question doesn’t actually involve this base.)

(Item table) table defined in Virtual Post
(Item|Container) many-to-many link to (Container table)
(Item|Container|Item) many-to-many link to (Item table)
Base contains 4 Items and 1 Container, with 2 Items linked to the Container.

--------------------------------------------

[populate Container relatedTo Container]

[loop Container]
   {{Container|Name}}
   [loop1 Container|Image]
       {{Container|Image}}
   [/loop1]
   [populate Container|Item relatedTo Item]
   [loop2 Container|Item]
       {{Container|Item|Name}}
       [loop3 Container|Item|Image]
          {{Container|Item|Image}}
       [/loop3]
   [/loop2]
[/loop]

I tried to define this a number of ways, but could never get it to work correctly: Either the second loop matched no ‘Item’ records, resulting in no data returned following the last {{Container|Image}}, or I encountered a fatal PHP error when attempting to access any {{Container|Item|(variable)}}.

I remembered this as being similar to your VP example using the Restaurants base, with the exception of the placement of the second [populate] function. Using that as a model, I moved the second [populate] function to immediately after the first, but with no success.

Even though my understanding is Airtable treats a one-to-one or many-to-one linked field the same as a one-to-many or many-to-many, I thought perhaps the difference was the Restaurants base used x-to-one links; when I checked, though, I discovered the [Restaurants]>–<[Districts] links were many-to-many, as well. Accordingly, I decided to try to duplicate your example VP and page definition — and found that it, too, fails under some conditions:

• If the specified restaurant is in a district by itself, the page displays correctly.
• If the restaurant is in a district containing more than one restaurant, the page display aborts with a fatal PHP error: "AH01071: Got error 'PHP message: PHP Catchable fatal error: Object of class AirpressRecord could not be converted to string in /[...]/wp-content/plugins/airpress/lib/chetmac/AirpressCollection.php on line 231.'"

I’ve triple-checked the code for the restaurant-template page, and it appears to be correct.

Frankly, I stumbled into the “1 entry good, >1 entry bad” delineation only accidentally — if I hadn’t first grabbed the record_id of a restaurant with no others in its district, I would have thought all attempts failed. As a double check, I returned to my original base and deleted the second [Item]>–<[Container] link. Now, the page correctly displayed both the {{Container}} info as well as data from {{Container|Item}}.[1] When I returned the second [populate] function to its original place inside the main loop, as shown above, it continued to work. Furthermore, when I added [loop3] defined above, it correctly looped through display of {{Container|Item|images}} as well.[2]

However… when I looked over the template code one last time, I noticed I had failed to close the main [apr_loop], the one that loops through the connected [Containers]. When I added the closing shortcode immediately following the [/apr_loop2] shortcode, the page now hangs with the following error: "AH01071: Got error 'PHP message: PHP Fatal error: Call to a member function getFieldValues() on null in /[...]/wp-content/plugins/airpress/lib/chetmac/Airpress.php on line 76.'"

So, to recap:

1. Using your Restaurants base Virtual Post example, the page fails for Restaurants in Districts containing more than one Restaurant.
2. A similar failure occurs in my development base when the secondary linked field links to more than a single target.
3. In my development base, if the secondary linked field links to a single target, the nested loops function as intended — but only if the outer loop remains unclosed.
4. Also see issues discussed in footnote 2, below.

Once again, not tested in a clean install.

I realize this isn’t described as cleanly as it could have been, so if I can clarify anything or provide code (as opposed to pseudo-code) examples, please ask.

Thanks!
Maz
__________
1. I did find a couple of peculiarities in loop processing, though. First, within the main loop as defined above, when I attempted to reference {{Container|Name}} by placing it within double curly brackets, Airpress did not parse it as a variable reference, displaying the literal string ‘{{Name}}’ instead. Using the embedded shortcode ‘[apr field=”Name”]’ does work. However, the variable must be referenced explicitly as ‘[apr field=”Container|Name”]’; using ‘Name’ alone within the shortcode causes the Name of the parent Item to be displayed, instead.

2. Admittedly, it’s difficult to be certain the innermost loops are functioning correctly when testing is limited to one-to-one links: Since {{Container|Item}} points to the same Item record as the parent Item itself, how can one tell if a loop through {{image}} is displaying {{parent item|image}} or {{Container|Item|image}}?

As a test, rather than follow the reciprocal {{Item|Container|Item}} link, I defined a second [Container]>–<[Item] linked field named ‘Item2’ and changed the second [propagate] function to [apr_propagate field=”Container|Item2″ relatedTo=”Item”] and [loop2] to [apr_loop2 field=”Container|Item2″]. With those modifications, references to {{Name}} and {{images}} caused the variables associated with the [Item] record referenced by {{Container|Item2}} to be displayed. While not absolutely definitive, this at least suggests the innermost loops are correctly referencing the secondary linked Item rather than the parent Item.

• This topic was modified 9 years ago by mazoola. Reason: formatting changed for readibility
• This topic was modified 9 years ago by mazoola. Reason: formatting changed for readibility
• This topic was modified 9 years ago by mazoola. Reason: formatting changed for readibility