Invalid schema usage after revert of field localisation

[flaming-codes]

Bug Report

When creating an entity with localization: true, then changing the schema to localization: false, the stored entity becomes unusable. The locales are still stored and viewing/editing the entity becomes impossible, as now the value is a set of keys, which React can't render as children.

Expected Behavior

The default locale field value is picked for the new schema. Entities stay usable after disabling localisation for fields of saved entries.

Current Behavior

Entities become unusable after

• storing field value in multiple locales
• disabling localisation for the field
• starting the CMS again and viewing the entity

Possible Solution

Default locale value gets picked in restoration process.

Steps to Reproduce

I created a repo for quick testing. All instructions are included the in the README.md.

https://github.com/flaming-codes/payload-cms-localization-collection-issue

Detailed Description

Description	Image
	valid after initial save in multiple locales
	invalid, locales still present after entity is not localised anymore

[flaming-codes]

A naive thought after going through the Payload codebase for some minutes: Maybe this statement lacks the context to determine that only the default locale should be selected

• if multiple locales are used and
• if no localisation is used now

[jmikrut]

Hey @flaming-codes — thanks for the issue. This is actually probably something that should be taken care of with a migration script, which can be written and run specific to your database. I don't think that Payload should maintain any functionality to be able to determine if a field's data was once localized, but is now not, because that would add some pretty abstract and hard-to-follow logic. And it would be unprecedented.

An extreme analog of this would be to say something like - if I have a text field, but I change it to an array field, Payload should know that I changed the field and should try to safely adapt the data. I think this is where a migration script would be better served, personally.

Here is an example for how to do a migration script:

const payload = require('payload');

require('dotenv').config();

const { PAYLOAD_SECRET_KEY, MONGO_URL } = process.env;

payload.init({
  secret: PAYLOAD_SECRET_KEY,
  mongoURL: MONGO_URL,
  local: true,
});

const migrateStatus = async () => {
  const args = process.argv.slice(2); // nodejs command line args are an array that begin at the third item
  const [
    collectionSlug,
  ] = args || [];

  const docs = await payload.find({
    collection: collectionSlug,
    depth: 0,
    limit: 700,
  });

  await Promise.all(docs.docs.map(async (doc) => {
    try {
      await payload.update({
        collection: collectionSlug,
        id: doc.id,
        data: {
          ...doc,
          _status: doc.status || 'draft',
        },
      })

      console.log(`Success! Doc with slug: '${doc.slug}' in collection: '${collectionSlug}' successfully migrated its '${doc.status}' status.`);
    } catch (err) {
      console.error(`Failed. Doc with slug: '${doc.slug}' in '${collectionSlug}' failed to migrate its '${doc.status}' status.`);
      console.error(err);
    }
  }));

  console.log('Complete');
  process.exit(0);
};

migrateStatus();

In the above script, we are migrating old (pre-Drafts) collections from relying on a custom doc.status field to the new and internally supported doc._status field which works with Versions and Drafts. But the principle is the same. Find existing docs, update each one to the new data shape. This can be done with Payload operations and can also be done straight with Mongoose raw documents by accessing the internal Mongoose models via payload.collections[collectionSlug].Model.

What do you think? I'm going to convert this to a discussion for now, but I'd like to keep this conversation going!

[flaming-codes]

Hi @jmikrut, thanks for the quick and detailed answer, very much appreciated!

I think I agree with your point: the CMS should handle tasks related to a CMS. Migrating a DB after such table-breaking changes isn't one of them.

I was using other (commercial) CMS solutions in the past, where the issue raised by me wouldn't happen, e.g. Craft CMS. Those solutions are basically bulletproof in almost any way. They also include such migrations themselves. I think that's the reason why I considered it a bug in the first place.

---

I noticed that there aren't any guides on 'migration' on the Payload CMS site, so I would suggest to think about creating a separate section about this topic. Eventually this is a common issue for most devs working with any CMS and therefore also Payload, I assume.

Maybe such a section about migrations could also include a link to some common examples (e.g. migrating this very change) in either a different repo or directory in the main repo.

---

Finally, I would like to express my thanks for your truly great work with Payload, which already starts incredibly strong for a 1.0 release! I feel very confident in working with it at this point, and your community efforts (e.g. your great answers) make me feel confident in investing my time in Payload!

Cheers, Tom