test url = default value?

The purpose of the “Test URL” is two-fold:

1. To test the regular expression provided when saving a VirtualPost providing “instant” feedback.
2. As more “visual editors” are supported, a default (or Test URL) is needed to populate the template page, otherwise shortcodes would have nothing to process or return.

Regarding your specific example, I believe you want two VirtualPost configurations. One for the “index” or “archive” page (/folder/subfolder/) and one for the item or “post” page (/folder/subfolder/something/).

Airpress VirtualPosts aren’t intended to be able to serve both the “archive” and the “post” pages with a single configuration as the URL pattern is different.

So your first VirtualPost config should be:
Pattern: ^folder/subfolder/?$
filterByFormula: NOT({Name}=BLANK())
… the filterByFormula in this case needs to return ALL the records you’re looking to list in your index/archive page

And your second VirtualPost config should be
Pattern: ^folder/subfolder/([^/]+)/?$
filterByFormula: {some field}=”$1″

I’m curious, with your specific example (a single VirtualPost config of ^folder/subfolder/(.*)/?), what did you expect to see (or want to see) when you visited /folder/subfolder/ ?

Ack there is a bug somewhere! I just got different results when I’m NOT logged into WordPress admin vs when I am… I will track it down and get back to you!

Ok, I got to the bottom of it and there is no bug.

If you’re logged into WordPress admin, you’re able to load the “Map to this page” and Airpress will use the “Test URL” to populate it. This is with the intention of testing and using (Cornerstone for now) visual page builders that need a “Test URL” in order to populate data while building.

If you’re not logged into WordPress admin, you’ll get a 404 when you attempt to directly access the Virtual Post “Map to this page” URL.

So my advice is to name all your “Map to this page” templates with a prefix of “TEMPLATE” so that the page slug is “template-something” and you’ll understand that you’re not supposed to access it directly.

If you have a use case for why you would like to directly access the template page (“Map to this page”), let me know—I’d love to hear it!

If you’re logged into WordPress admin, you’re able to load the “Map to this page” and Airpress will use the “Test URL” to populate it. … If you’re not logged into WordPress admin, you’ll get a 404 when you attempt to directly access the Virtual Post “Map to this page” URL.

Ah — makes sense!

I’m curious, with your specific example (a single VirtualPost config of ^folder/subfolder/(.*)/?), what did you expect to see (or want to see) when you visited /folder/subfolder/ ?

I expected a 404 or ‘no data returned’ page, as this is an erroneous entry. I don’t anticipate users of the final app to enter the URL manually — but if they did, I didn’t want a default value to be populated unexpectedly. (Actually, in this case it probably wouldn’t matter, as the returned page simply displays a list of records; I was more concerned about similar behavior on pages that might feed an edit or delete function.)

The application in question is a costume wardrobe database I’ve been fiddling with in part as a field test of AirTable and similar SAS offerings (exec summary: Airtable wins, hands-down) and in part to help in liquidating assets of a failed business venture that ended up in my lap. The index (archive?) Virtual Posts map to such things as ‘/wardrobe/genre/1940s’ or ‘/wardrobe/item/jacket’. Individual records will be accessed through RECORD_ID or a slug field, either as ‘/wardrobe/[key]’ or ‘/wardrobe/[item]/[key]’; I’ve not yet decided if there’s any value or detriment that would result from using the latter construction.

I think I may have made things more confusing by changing permalink formatting in midstream; that in combination with the “jes’ grew” nature of this development resulted in the template page permalink being the same as the Virtual Post match pattern sans $1. Accordingly,

nam[ing] all your “Map to this page” templates with a prefix of “TEMPLATE” so that the page slug is “template-something”

and changing the permalink to match took care of my concern, even if I mistakenly enter the truncated Virtual post URL while logged into WordPress.

Thanks for tracking this down so quickly and clearly!

Perfect. Thanks for the useful feedback!