Single Type Pages Fail to Render

RWransky commented 2 years ago

Bug report

Required System information

Node.js version: 14.19.3
NPM version: 8.10.0
Strapi version: 4.2.0 (also happens in 4.1.11)
Database: Postgres via Amazon RDS
Operating system: Ubuntu 20.04

Package dependencies and plugins:

"dependencies": {
    "@babel/core": "^7.18.0",
    "@notum-cz/strapi-plugin-record-locking": "^0.2.4",
    "@strapi/admin": "^4.2.0",
    "@strapi/database": "^4.2.0",
    "@strapi/helper-plugin": "^4.2.0",
    "@strapi/plugin-content-manager": "^4.2.0",
    "@strapi/plugin-content-type-builder": "^4.2.0",
    "@strapi/plugin-documentation": "^4.2.0",
    "@strapi/plugin-email": "^4.2.0",
    "@strapi/plugin-graphql": "^4.2.0",
    "@strapi/plugin-i18n": "4.2.0",
    "@strapi/plugin-sentry": "^4.2.0",
    "@strapi/plugin-seo": "^1.7.3",
    "@strapi/plugin-upload": "^4.2.0",
    "@strapi/plugin-users-permissions": "^4.2.0",
    "@strapi/provider-upload-aws-s3": "^4.2.0",
    "@strapi/provider-upload-local": "^4.2.0",
    "@strapi/strapi": "4.2.0",
    "@strapi/utils": "^4.2.0",
    "css-loader": "^6.7.1",
    "knex": "^0.21.21",
    "objection": "^2.2.18",
    "pg": "8.7.1",
    "strapi-plugin-email-designer": "^2.1.1",
    "strapi-plugin-import-export-entries": "^1.4.1",
    "strapi-plugin-notes": "^1.0.1",
    "strapi-plugin-publisher": "^1.1.3",
    "strapi-plugin-react-editorjs": "^2.0.1",
    "strapi-provider-upload-aws-s3": "4.2.0",
    "style-loader": "^3.3.1",
    "webpack": "^5.72.1"
  },

Describe the bug

Single Types do not load in the admin panel Content Manager. I have tested this with and without internationalization, with and without React Dev Tools active on the site, and running the server in develop and production modes.

Steps to reproduce the behavior

Create a Single Type in the Content-Type Builder. Does not matter what fields are present even a simple short text box is fine.
Save and go to the Content Manager.
Click on the Single Type to make an entry.
Experience white screen of death and cry.

Expected behavior

The Single Type edit page should load and allow entries added.

Screenshots

This screenshot shows the exact error shown in Chrome Dev Tools

This screenshot shows the API requests for the single type comes back successful.

Here are the permissions set for Single Types in our server:

Additional context

Note that Strapi can successfully retrieve all relevant information via API requests to Single Types still. This appears to solely be a frontend bug.

The original bug came without updating Strapi and started happening after arranging the edit views for other content types (not Single Types though). Upgrading to Strapi v 4.2.0 nor returning to original v 4.1.11 resolved the issue.

Also, please be nice to me as this is my first time submitting a bug report to a big project. Thx! UwU

akuhar commented 2 years ago

Help us, Strapi! This one's been a real doozy to troubleshoot.

derrickmehaffy commented 2 years ago

Can you please try to reproduce this without the community plugins installed? I'm guessing the issue is actually coming from a community plugin because I cannot reproduce this.

hdeadman commented 2 years ago

We are seeing this error on an app that we are migrating from strapi 3 to strapi 4. Are any of our dependencies considered community plugins? We are also using postgresql.

    "@strapi/plugin-documentation": "4.1.12",
    "@strapi/plugin-graphql": "4.1.12",
    "@strapi/plugin-i18n": "4.1.12",
    "@strapi/plugin-users-permissions": "4.1.12",
    "@strapi/provider-email-nodemailer": "4.1.12",
    "@strapi/plugin-email": "4.1.12",
    "@strapi/strapi": "4.1.12",
    "better-sqlite3": "7.5.3",
    "npm-check-updates": "~13.0.3",
    "lodash": "4.17.21",
    "pg": "~8.7.3",
    "sqlite3": "5.0.8"
  },

RWransky commented 2 years ago

Removing the record locking plugin "@notum-cz/strapi-plugin-record-locking": "^0.2.4" resolves this issue. Will post this bug to their repo to hopefully be able to correct things.

hdeadman commented 2 years ago

@derrickmehaffy This error (or a similar error) was happening to us because the one locale we had ("en") wasn't marked as the default locale via a setting row in the core strapi settings table in the database. This was probably missing due to us having migrated the database from Strapi 3 to Strapi 4. Once we checked the box to mark the locale as default (which adds row to the settings table) the problem went away.

derrickmehaffy commented 2 years ago

@derrickmehaffy This error (or a similar error) was happening to us because the one locale we had ("en") wasn't marked as the default locale via a setting row in the core strapi settings table in the database. This was probably missing due to us having migrated the database from Strapi 3 to Strapi 4. Once we checked the box to mark the locale as default (which adds row to the settings table) the problem went away.

Interesting 🤔 did you use our database migration scripts?

RWransky commented 2 years ago

Ok so this makes a ton of sense because in messing around trying to debug on my end I had narrowed down one of the potential culprits to the internationalization locales. We never were on Strapi v3 so never bothered with migration scripts etc.

hdeadman commented 2 years ago

@derrickmehaffy This error (or a similar error) was happening to us because the one locale we had ("en") wasn't marked as the default locale via a setting row in the core strapi settings table in the database. This was probably missing due to us having migrated the database from Strapi 3 to Strapi 4. Once we checked the box to mark the locale as default (which adds row to the settings table) the problem went away.

Interesting 🤔 did you use our database migration scripts?

My co-worker is doing the migration but he is using the migration scripts in some form, albeit with some modifications. If the migration scripts are handling that default locale entry, maybe we aren't using the latest but I can check next week.

derrickmehaffy commented 2 years ago

@derrickmehaffy This error (or a similar error) was happening to us because the one locale we had ("en") wasn't marked as the default locale via a setting row in the core strapi settings table in the database. This was probably missing due to us having migrated the database from Strapi 3 to Strapi 4. Once we checked the box to mark the locale as default (which adds row to the settings table) the problem went away.

Interesting thinking did you use our database migration scripts?

My co-worker is doing the migration but he is using the migration scripts in some form, albeit with some modifications. If the migration scripts are handling that default locale entry, maybe we aren't using the latest but I can check next week.

Sounds good, glad you found the root cause. I'll add this to our list to check once we get into some really deep testing before making the scripts "stable"

santoswiller commented 1 year ago

Good morning, Someone can it find a solution to solve this problem of use strapi v4, i18n and import-export-entries?

strapi / strapi