loop failure or operator error?

Airpress 1.1.35

Chester –

I’ve run into an issue with looping using the [apr_loop] shortcode. (I think I mentioned this in passing in an earlier post.) I’m not sure if it’s an Airpress problem or if I’m trying to push recursive references too far….

This is using the wardrobe Airtable base I mentioned earlier. Essentially, the base is centered around the ‘garment’ table, each record of which describes an individual item of clothing. In addition, one or more garments may be brought together as an ‘outfit’, stored in a separate table. A garment may be a component of multiple outfits. Garments and outfits both may have associated images.

I encountered this problem while working on the garment display page of my application, which is generated via a Virtual Post matching the garment table’s primary field (in this case, the garment’s name, slugged, concatenated with “-” and the garment record’s Auto Number).

As part of the template to which the VP maps is a section detailing each outfit of which that garment is a component. Contained within the outfit detail are the outfit images and a section on each garment within the outfit, including garment images. Accordingly, there are several [apr_loop]s in play.

garment
| |
| [apr_loop1] =-> image[0]...image[x]
|
[apr_loop2] =-> outfit[0]...outfit[x]
                 | |
                 | [apr_loop3] =-> image[0]...image[x]
                 | 
                 [apr_loop4] =-> garment[0]...garment[x]
                                  |
                                  [apr_loop5] =-> image[0]...image[x]

The problem occurs with [apr_loop2], above. Frankly, it took me a while to run into this, as in my initial implementation of the database, a garment is never a component of more than one outfit. In my original tests, everything worked fine, down through [apr_loop5]. When I added a second outfit to a garment as a test, though, rather than display information on each outfit, it apparently merged outfit information. (That is, for the outfit name, my app reported the names of all associated outfits, followed by a merged and deduped list of all garments making up those outfits.)

Further investigation revealed I was still running an unclosed [apr_loop2], as discussed in this earlier post. This seemingly causes no problems when the garment is a component of only a single outfit, but fails when a second outfit is added.

When I add an [/apr_loop] shortcode to the template in order to close the loop, the loop fails completely; in my httpd_error.log, I find this message:

“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.'”

In stepping through the code – and my apologies in advance, if I’ve bollixed up something here, but my php is beyond rusty – it appears the problem occurs as the app attempts to set up [apr_loop4]. Here’s a snippet of code from the template (prettified a bit and minus some unimportant ‘div’s):

[apr_populate field="outfit|garment" relatedTo="garment"]
[apr_loop4 field="outfit|garment"]
   <a href="/wardrobe/garment/{{slug}}">{{name}}</a>
   [apr_loop5 field="images"]
   <a href="{{url}}" class="et_pb_lightbox_image"><img src="{{thumbnails|small|url}}">
   </a>
[/apr_loop5]
[/apr_loop4]

As best I can tell (after seeding numerous airpress_debug() statements throughout the code), Airpress begins to process [apr_loop4] through ‘outfit|garment’ records. It branches correctly into nested loop processing at line 69. After the ArrayShift() in line 72, $field = ‘outfit’ and $keys = ‘Array[0] => garment’.

Failing line 76 reads:
$records_to_loop = $this->currentRecord[$field]->getFieldValues($keys);
Given the values for $field and $keys, this would suggest ‘$this->currentRecord’ should reference an AirpressRecord corresponding to an entry from the garment table. However, if I dump ‘$this->currentRecord’ immediately before the failure, it references an outfit entry. Since an outfit record contains no ‘outfit’ field, an attempt to reference ‘$this->currentRecord[‘outfit’]’ would return null — which [presumably] would cause the ‘Call to a member function […] on null’ fatal error. (After further digging, I have to wonder if the problem somehow involves an earlier invocation of that $this->currentRecord = $previousRecord swap in line 159 — but that’s as far as I’ve been able to take it.)

Now, I realize everything from “In stepping through the code” onward may be complete rubbish; as I’ve said, it’s been years since I’ve done any php hacking — and my involvement was minimal, even then. If that’s the case, feel free to ignore that portion, with prejudice. As regards the rest, if I’m pushing the shortcode through one too many levels of recursion, let me know, and I’ll try to find another way to handle it. (For my own purposes, simply asserting a garment may be a component of only one outfit would solve the problem; however, I’m interested in seeing if I can create a pure Airtable implementation that might serve as a lifestyle template for more generic use.)

Again, thanks for releasing such a full-featured and, as I am increasingly discovering, so elegantly coded a plugin, as well as for all your work to explain and support it!

Maz