Last articles

I've read recently about making SDCs dependent on Drupal Canvas because of needing to reference Canvas in the definition of your prop, so the right media widget is used inside Canvas:

image:
  $ref: json-schema-definitions://canvas.module/image
  type: object
  title: Image
  description: >
    Image of the singer
  examples:
    - src: 'micro.webp'
      alt: 'Nice picture of the singer'
      width: 200
      height: 300

That was the case during the alphas. But was fixed long ago, even before the 1.0.0 release. See canvas#3515074.

image:
  type: object
  title: Image
  required: [src]
  properties:
    src:
      type: string
      format: uri-reference
      contentMediaType: "image/*"
      x-allowed-schemes: [http, https]   # this is image-uri, itself a nested $ref
    alt:    { type: string }
    width:  { type: integer }
    height: { type: integer }
  description: >
    Image of the singer
  examples:
    - src: 'micro.webp'
      alt: 'Nice picture of the singer'
      width: 200
      height: 300

That's more verbose, but would make your SDC Canvas-independent and re-usable, and it's 100% equivalent. 

If we missed updating some docs, please create an issue on the Canvas issue queue.

Drupal has been working to add a JSON data type since 2023, but that has not landed yet. Drupal Canvas jumps ahead of that in its inputs for a component tree item with

'inputs' => [
  'description' => 'The input for this component instance in the component tree.',
  'type' => 'json',
  'pgsql_type' => 'jsonb',
  'mysql_type' => 'json',
  'sqlite_type' => 'json',
  'not null' => FALSE,
],

Recently some of our tests started failing for MySQL and Postgres on CI, but passed in SQLite and MariaDB, which is what most of us use locally. 

The problem was that the sorting of the keys of that field was not deterministic, and we used assertSame in our tests to see if operations added/removed the inputs as expected when components evolved. 

How does that translate to different engines?

For MySQL, there's a native data type. Quoting their docs:

To make lookups more efficient, MySQL also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.

For PostgreSQL, the engine offers two different data types: json and jsonb, with the second being the option we (and core) opted for because of its efficiency. But that's key, as the docs explain:

In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys.

That's exactly what our problem was.

For MariaDB, the JSON type is just an alias. See their docs:

JSON is an alias for LONGTEXT COLLATE utf8mb4_bin introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL:2016 standard, and MariaDB's benchmarks indicate that performance is at least equivalent.

And the last one, SQLite, has support for a jsonb format since 3.45, but the work in progress for introducing this in Core uses json, which, like MariaDB, is ordinary text and sorting of the keys is respected.

How did we fix this?

The actual sorting of the inputs in the database is, as of today, irrelevant to us. So we ended up with:

• Our own assertSameInputs, which sorts the keys before comparison. assertEqualsCanonicalizing is not an option, as that sorts by value.
• Our own PHPStan rule, which is not 100% accurate but detects most usages of assertSame with these inputs, and suggests using assertSameInputs instead. 

Translating Drupal Canvas

This is just one of the many show-stoppers that we faced while working on the much-anticipated symmetric translation support for Drupal Canvas. If you want to test this experimental feature, check the release notes in Canvas 1.7.0, but please only on test sites for now!

Last April I started blogging about my quarterly contributions as a way to look back and see what I've been working on, even if I've been tracking for 6 quarters already.

On Drupal.org, last quarter I had credits at 1376. Now it's 1495. So 119 new credits, which is above 1.3 credits/day. Just by numbers, this is the biggest quarter since I have been tracking it.

Breaking those down, all of them have been on my 4 focus projects:

Canvas: 247 (+104)
Core: 162 (+12)
CMS*: 44 (+2)
Dashboard: 62 (+1)

Of course the majority of them concentrate in Drupal Canvas. Thanks Acquia for sponsoring lots of my open-source work.

This doesn't measure at all complexity, but I feel like these on Canvas have been more complex on average: bugs and features are definitely harder to implement. I guess I ate the AI Red Pill 🤷🏽. But it's not just 2x quantity-wise than previous quarter, it has a bigger impact quality-wise. 

And these numbers don't track the work on security fixes and/or releases which I've been doing for Canvas. 

I'd highlight that, outside of Drupal, I also got my first contributions to jsonrainbow/json-schema, the PHP library that Drupal core and Canvas use for JSON Schema validation. 

Happy coding! 🎉