为什么我看不到解码那一块的源码呢？

I agree that using an env variable would be more clean. In my case I was just adding the urlproperty (following the nginx guide), so something like this would be better:

module.exports = ({ env }) => ({
  ...
  url: env('STRAPI_PUBLIC_URL', '127.0.0.1')
});

Apart from this small issue I had no problems in installing and using strapi. Congratulations for this great project. I tried it 2 years ago, it's much more robust now.

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/heroku-memory-leak/1443/5

I’ve signed the CLA now. Med venlig hilsen Robin Louis van Komen … On 1 Dec 2020, 09.16 +0100, cyril lopez @.***>, wrote: @rlvk-vk can you make sure to accept our CLA so we can merge your PR? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks a lot!

It appears your PR contains some conflicts do you mind checking them?

I'm not quite sure where I can see these conflicts?

While I do agree we should adjust the loading. I don't entirely agree with the root cause (you shouldn't be editing the file in production, it's expected you are using source control)

Likewise we never recommend directly editing the file in production, you should be using environment variables and likewise the .env file to handle changes.

See the following documents as "workarounds" to the bug and how we intend things to be done in production.

https://strapi.io/documentation/v3.x/concepts/configurations.html#environment-variables https://strapi.io/documentation/v3.x/concepts/configurations.html#environments

Bug report

Describe the bug

When using emacs to edit config/server.js (which would be a natural choice in a production environment), a new file is created by emacs (a backup): config/server.js~ (note the tilde character at the end).

For some reason strapi will also read this backup file (I confirmed by adding a quick console.log in lib/core/app-configuration/config.loader.js).

The problem is that the contents in the actual configuration file (config/server.js) now seem to be ignored and strapi will use the default values instead (which are hardcoded in lib/core/app-configuration/index.js).

That is, even if both files are equal, and even if the port is set as 1338, strapi will use the default 1337 (but this problem is verified for any other property in the configuration).

Steps to reproduce the behavior

1. cp config/server.js config/server.js~
2. change any config property in config/server.js (example: port)
3. verify that the configuration in config/server.js is now completely ignored

Expected behavior

The config/server.js~ should not be read by the logic in lib/core/app-configuration/config.loader.js (only config/server.js should be read)

System

• Node.js version: 12
• Strapi version: 3.3.4
• Database: sqlite
• Operating system: linux

Thanks for your time!

why not do a simple require('strapi') ?

The re-register issue is gone, yes! So that's good. The only thing that is off right now is that when I add content locally - it isn't reflected in production. I assume content-types are defined outside the ./tmp/data.db, but the content itself is stored there?

I tried to solve this myself and point the development server at the postgre db by editing ./config/database.js to contain:

const parse = require('pg-connection-string').parse;
const config = parse(process.env.DATABASE_URL);

module.exports = ({ env }) => ({
  defaultConnection: 'default',
  connections: {
    default: {
      connector: 'bookshelf',
      settings: {
        client: 'postgres',
        host: config.host,
        port: config.port,
        database: config.database,
        username: config.user,
        password: config.password,
      },
      options: {
        ssl: false,
      },
    },
  },
});

However, when I do this I cant start the development server and get this error:

Error while running command develop: Could not load js config file /Users/nathanleroy/Documents/projects.nosync/nathanleroy-io-cms/config/database.js: Cannot read property 'charAt' of undefined

It's not a critical issue, but it would be nice to have both the development server and the production server reflect the content identically just like they do the content types.

I know this is now beyond the scope of this issue - so I can open another one if need be.

Ah that's fine, I don't mind if it's in the doc repo just wasn't sure if it would "stay" in the monorepo.

The script will not be in the main repo strapi/strapi because it has no sense for future users, but I'm not against putting it in another repo if there is a good one. For the moment it's where we thought it would be the best. Ping @alexandrebodin

Okay - I was writing out a long post about my process only to realize I made a dumb error and had my directory set up as: ./config/env/production/database.js/database.js instead of ./config/env/production/database.js...

I guess this is what I get for working straight out of the terminal and not in VSCode.

Hahahaha, it's all good, it happens to the best of us. I take it you got it all working?

Okay - I was writing out a long post about my process only to realize I made a dumb error and had my directory set up as: ./config/env/production/database.js/database.js instead of ./config/env/production/database.js...

I guess this is what I get for working straight out of the terminal and not in VSCode.

This pull request has been mentioned on Strapi Community. There might be relevant details there:

https://forum.strapi.io/t/global-authenticate-issue-facebook-google-local-provider-4998/1453/2

node-pngcrush does not support your node v10.19.0

Could add another step to delete the script (optional)

Would it be better to link to the GitHub script instead or do you think it's better to include this in the docs?

This issue has been mentioned on Strapi Community. There might be relevant details there:

https://forum.strapi.io/t/how-to-resolve-ui-issues-in-windows-and-linux/1451/1

<details> <summary><a href="https://linear.app/strapi/issue/ENG-127/create-a-migration-script-for-rf-to-activate-the-sort-on-relational">ENG-127 Create a migration script for RF to activate the sort on relational fields by default</a></summary> <p>

Long Title

As a Strapi user, I want to use a migration script to set sort options to true by default when upgrading to Strapi 3.4

Description

Pierre discovered that curently in Strapi the options to sort is set to falsefor all relational fields. It means that if you upgrade Strapi to the next version with RF, when adding a rf in a LV, you'll have to go into each rf's settings modal to set enable the sort.

It's a problem because:

• The default behavior on normal field is set to trueand we want to have the same behaviors to avoid confusion
• If you already have 100 CT in your project and add 1 rf in LV by CT you'll have to do it 100 times → annoying

Several options have been suggested by the team:

• Do a first release to set the behavior to truethen release RF
• Create script to share with the migration guide
• Create a hardcoded script that check that everytime
• Change the sort enablement in the Admin to make it less annoying
• Let the behavior as it is

We decided to go with the migration script

• The script will put the config at `true` for existing relations x-to-one

Related design

Up-to-date validated design from InVision

Management rules

Full list of management rules

• quantitative details
• access / permission restriction
• …

Documentation needs

• list of updates in Strapi documentation
• Need to Inform/involve the documentation team?

Acceptance tests

/ Given I am [starting point with link],

/ When I [action],

/ Then [expected result] </p> </details>

The script has to be tested on a generated strapi app (with branch feature/relational-fields).

However, if you want to test it on the getstarted app, you will need to change the following in the script:

-   const strapiIndexPath = path.resolve(projectPath, 'node_modules', 'strapi', 'lib', 'index.js');
+   const strapiIndexPath = path.resolve(projectPath, '..', '..', ''packages, 'strapi', 'lib', 'index.js');

It looks like you are using the old configuration system, can you check https://strapi.io/documentation/v3.x/deployment/heroku.html#_3-set-database-variables-automatically and https://strapi.io/documentation/v3.x/deployment/heroku.html#_4-create-your-heroku-database-config-file-for-production

DATABASE_HOST:     ******
DATABASE_NAME:    ******
DATABASE_PASSWORD: ******
DATABASE_PORT:     ******
DATABASE_URL:      ***********
DATABASE_USERNAME: *******
NODE_ENV:          production

No just remotely, excluding any private details can you give the output of heroku config (if you are using the Heroku CLI), just be sure to blur out any private information.

Give access in "Roles and permissions" to destroy uploads, then you can delete file by /upload/files/:id

I've got NODE_ENV set to production on Heroku... I shouldn't do this locally right?

Codecov Report

Merging #8789 (891529a) into feature/relational-fields (61c321f) will increase coverage by 21.82%. The diff coverage is 100.00%.

@@                      Coverage Diff                       @@
##           feature/relational-fields    #8789       +/-   ##
==============================================================
+ Coverage                      33.51%   55.34%   +21.82%     
==============================================================
  Files                           1231      129     -1102     
  Lines                          13850     4174     -9676     
  Branches                        1398      847      -551     
==============================================================
- Hits                            4642     2310     -2332     
+ Misses                          8298     1463     -6835     
+ Partials                         910      401      -509     

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 66dd23d...891529a. Read the comment docs.