Where I’m coming from

With Airtable’s previous API one was able to import table records into PHP with a simple

$json = file_get_contents('https://api.airtable.com/v0/{YOUR_BASE_ID}/{YOUR_TABLE_ID_OR_TABLE_NAME}?api_key={YOUR_API_KEY}');

Convert that to an array with $array = json_decode($json, true);—boom. Done.

As for the cURL approach…
There is not that much helpful documentation available, that is actually digestable by a newbie to the matter. Most articles seem to explain using cURL in the command line, too.

Fishing in the mud

So, I started searching around the interwebs and stitching together what I could find.

This is, what a very basic version of a cURL call in PHP looks like:

$url = "https://someapi.com/…";
$ch = curl_init();  
curl_setopt($ch, CURLOPT_URL, $url);  
$result = curl_exec($ch);  
curl_close($ch); 

Make that an Airtable API call:

$base_id = '{YOUR_BASE_ID}';
$table_id = '{YOUR_TABLE_ID_OR_TABLE_NAME}';
$token = '{YOUR_BEARER_TOKEN}';
$url = "https://api.airtable.com/v0/" . $base_id . "/" . $table_id;
$headers = [
    'Content-Type: application/json',
    'Authorization: Bearer ' . $token
]; 
$ch = curl_init();  
curl_setopt($ch, CURLOPT_URL, $url); 
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);   
$result = curl_exec($ch);  
curl_close($ch); 

Be aware, that you do need to generate the bearer token in your Airtable account. When logged in, go to airtable.com/create/tokens and hit “Create new token”. Name your new token, give it an appropriate scope—data.records:read will do in our case—and select the base you want to access with it.

The above code does return something—a JSON object to be exact. But that something gets echoed in the browser. Not all that helpful. But it’s a start.

The full code example

Digging around some more, I figured, curlsetopt($ch, CURLOPTRETURNTRANSFER,1); must be, what’s missing. And it was.

This is, what the full example from API call to array looks like:

$base_id = '{YOUR_BASE_ID}';
$table_id = '{YOUR_TABLE_ID_OR_TABLE_NAME}';
$token = '{YOUR_BEARER_TOKEN}';
$url = "https://api.airtable.com/v0/" . $base_id . "/" . $table_id;  
$headers = [
    'Content-Type: application/json',
    'Authorization: Bearer ' . $token
];
$ch = curl_init();  
curl_setopt($ch, CURLOPT_URL, $url);  
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);  
$result = curl_exec($ch);
curl_close($ch); 
$array = json_decode($result, true);

Much more complicated than file_get_contents, but (supposedly) much more secure, too.

BTW, props to Airtable for announcing their switch to the new API a whole year up front. 🙏
And congratulation to cURL to its 25^th anniversary, which is—wait for it—today. 🎉

Runway has been around for quite some time and was sort of the bigger sibling of standard Perch—some called the latter “Perch proper“.
After the CMS changing owners in early 2021, the standard version has been retired.

There is a helpful guide in the docs for migrating. That article lacks some minor details, though, that I’ll jot down here for future reference.

MySQL errors

Many times, when migrating, I got a massive list of Syntax error or access violations after replacing the core folder and reloading the admin panel in the browser.

As per this old forum post, these can be ignored.
At the bottom of the page displaying the errors you can “accept these errors and continue.” I haven’t had any issues following that so far.

.htaccess

Although it being mentioned in the migration guide, the URL to an explanation of the rewrite rules required for Runway is broken. Here’s the correct document: docs.grabaperch.com/runway/getting-started/installing/rewrites
Basically, replace whatever rewrites you had in your .htaccess so far with this:

# Perch Runway
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/perch
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* /perch/core/runway/start.php [L]    

Include the runtime conditionally and relative to the site root

In the beginning of my migration journey I often came across errors notifying me, that I included the runtime.php more than once. When removing it from the page template affected, I would end up it being missing entirely in certain constellations. To avoid that, include the runtime like this:

if (!defined('PERCH_RUNWAY')) include($_SERVER['DOCUMENT_ROOT'] . '/perch/runtime.php');

Missing “error master pages”

If it is not there already, copy the directory /perch/templates/pages/errors/ from the 4.x folder you downloaded from the Perch website into the corresponding folder of your installation.
Coming from standard Perch, you likely rolled your own 404 page and redirected to that in your .htaccess.
In Runway you simply use the page template given in the errors folder. Rewriting is handled automatically. Alter the template to your liking, of course.

Amend page templates to account for missing physical files

If you decide to make “your Perch site more Runway-like”, remember to also update the page option to the perch_content_custom calls in your PHP templates. Given, you are retrieving content from another page than the one using the template, that is.
Instead of

perch_content_custom('Content', [
    'page' => '/news.php'
]);

set the option to:

perch_content_custom('Content', [
    'page' => '/news'
]);

Otherwise you will get “Template not found” notices instead of the content you were looking for.

Issues with localized dates

Most websites I do are in German. Thus, the localization of dates is unavoidable in some instances, i.e. if we want to display a month’s name, rather than its one- or two-digit representation.
After upgrading to Perch Runway 4.x, all the sites trying that showed broken dates—e.g. “%041 %2023” instead of “März 2023”.
I suspected this being related to the deprecation of strftime in PHP 8.1 (and it well might be), but the problem persisted after reverting to PHP 7.4. The Perch support team wasn’t able to help me with this and they were not able to reproduce the issue. So I wrote a template filter, that replaces the standard English-based names for weekdays and months with their German counterparts.
This is cumbersome, somewhat hacky, and the translations live inside the filter for now. Also it is not suited for multi-lingual setups. But it reinstated the correct format of the dates.
Here’s the filter:

class PerchTemplateFilter_localdatestrings extends PerchTemplateFilter 
{
    public function filterAfterProcessing($value, $valueIsMarkup = false)
    {   
        $strings = [
            'January'   => 'Januar',
            'February'  => 'Februar',
            'March'     => 'März',
            'April'     => 'April',
            'May'       => 'Mai',
            'June'      => 'Juni',
            'July'      => 'Juli',
            'August'    => 'August',
            'September' => 'September',
            'October'   => 'Oktober',
            'November'  => 'November',
            'December'  => 'Dezember',
            'Monday'  => 'Montag',
            'Tuesday'  => 'Dienstag',
            'Wednesday'  => 'Mittwoch',
            'Thursday'  => 'Donnerstag',
            'Friday'  => 'Freitag',
            'Satday'  => 'Samstag',
            'Sunday'  => 'Sonntag',
            'Mon'  => 'Mo',
            'Tue'  => 'Di',
            'Wed'  => 'Mi',
            'Thu'  => 'Do',
            'Fri'  => 'Fr',
            'Sat'  => 'Sa',
            'Sun'  => 'So',
        ];
        return $strings[$value];
    }
}
PerchSystem::register_template_filter('localdatestrings', 'PerchTemplateFilter_localdatestrings');

After incorporating that into your filters setup, use it like this in your Perch template:

<perch:content id="date" type="date" format="F" filter="localdatestrings"> <perch:content id="date" type="date" format="Y">

The filter could be enhanced to do more complex convertions. But it serves its purpose for now.
Feel free to grab it and alter it to your requirements.

Sitemap

Don’t forget to redo your sitemap, too. It should no longer be a PHP file sitting in your folder structure, but a virtual page, just like all the other ones. Treat its template like those of the remaining pages, add the route sitemap.xml in the page’s details and you’re good to go.

Anything else? Anyone?

Have you found a missing piece you’d like to see added here?
Send me an email or hit me up on Mastodon!

Shorter if statements

For me, it all started when I realize, that this block of code

<?php
if(condition) {
  echo ’some text’;
} else {
  echo ’some other text’;
}
?>

can be turned into this:

<?php
echo (condition) ? ’some text’ : ’some other text’;
?>

Neat, ey?
Likewise this can be used to define variables.

This syntax has its limits, of course. You wouldn’t want to write more complex statements like that. It is more of a one-liner thing.

(Am I boring you with my unspectacular findings already? Well,…if you’ve come this far, you might as well keep at it. 😉)

The <?= short tag

Only a few weeks ago I came across this little gem in the Kirby CMS docs:

<?= ’some text’ ?>

The <?= is a shorthand for “echo this piece of PHP”.
Brilliant.

Bringing together, what belongs together

Taking the last code block a step further, you might end up with this:

<?= (condition) ? ’some text’ : ’some other text’ ?>

So cool!
This is particular handy, if you want to echo some small piece of conditional content inline in your HTML. E.g. when prefilling a form.

Once you get the hang of it, your code will even be much more readable.

Hope, you share my enthusiasm. 😊

I bet, there is tons more.
Send me your favorite minimal PHP snippet on Mastodon!

The problem

When it came to introduce a strong CSP to a client’s web presence, I hit a wall, trying to load the Fathom script.js. The obvious solution was to add the custom domain used to circumvent add blockers (there’s nothing fishy about that, seriously—more info on the use of custom domains in Fathom’s documentation) as a resource to the script-src directive, of course.
Browsers kept throwing a 403 Forbidden Error for the above-mentioned request at me, all the same.
Disabling the CSP reinstated the analytics functionality, so the problem was obviously with it.

Searching up and down the interwebs, I didn’t get any wiser.
I tried introducing a nonce to the script-src directive. No luck.
Asking for help on Twitter and reaching out to Paul and Jack of Fathom via email didn’t give me any pointers. Although Paul replied in a very timely fashion—as usual. The problem was on my end, not their’s, after all.

The epiphany

When trying to explain what I was experiencing, to post that to StackOverflow in search for help, it hit me. I revisited the CSP, turning off one directive after another. I had done that before, but obviously had missed something.
Commenting out the “Referrer-Policy” solved the issue.
That Fathom cannot do its work, if they don’t know which website was calling the script, is a no-brainer. Why the server returns a 403—rather than just failing to do its thing—is beyond me, though.

Completing the CSP

But now I was left without a “Referrer-Policy”—in the CSP, that is. Luckily we had opted for rel="noreferrer" attributes on the anchor tags of external links before, so there was a policy in place. It wasn’t obvious to the CSP, though.
To mitigate for that, I added an empty directive to the policy—like so Header always set Referrer-Policy ""—, thus telling it, that there is an alternative approach in effect.

Lessons learned (again)

• Do not hesitate to formulate your problem—in written form or in a discussion. That might trigger you thinking about it differently.
• Always try testing by exclusion. Multiple times, if need be.