Nothing yet I donāt believe
Most likely not and I donāt believe we plan to add it (at least not in the short to medium term future) just as we donāt plan to add manually ordering collection for entries.
These things are not what you would see in a headless CMS, and itās not really how APIs typically function.
These things are not what you would see in a headless CMS, and itās not really how APIs typically function.
Iām not trying to be overly critical and Iām happy v4 is coming along, butā¦ are you telling me the ātypicalā way to implement user-defined sorting would be to add an extra layer of UI, DB, API proxy etc. between the Frontend and the CMS, just to store and edit order-ids? Please also refer to Ordering Content Type entries in the List view (preferably using drag and drop) Ā· Issue #3946 Ā· strapi/strapi Ā· GitHub
2 Likes
I do agreeā¦ I talked a lot with the strapi team, even with Pierre, and they all told me the goal was to become a CMS more than an API. And this is absolutely mandatory for a CMS. There has been numerous votes for this (both relationships and list view).
For now, the only solution is a repeatable component which holds the relationship. We already refactored a bunch of entities this way to be ready for V4, and this is, no surprise, way worse in terms of performanceā¦ 
We need to get a look on the new plugin API though, because maybe this is something that will be enabled by a plugin, in which case this is totally fine to ditch it from strapiās scope, but we don need a solution for drag and drop, manual ordering 
4 Likes
That could be an interesting idea
@DMehaffy Will there be any migration guides for v3 ā v4?
I have had some alterations to users-permissions plugin.
Also added some changes to the strapi/core to allow adding new models for plugins via extensions, which is living on my fork at the moment.
Eventually yes but we are taking it slowly to start with as there is a lot of breaking changes and we want to have as simple a migration process as possible which means a lot of testing and validation on our side. Goal for a full migration guide is end of Q4 (though ideally sooner)
@dennishh i feel your pain. We ended up using a custom middleware to filter out private data. probably a better approach would have been to āfreezeā the graphl queries so that no additional fields could be added. We were unable to access the request.body for graphql requests though: which is not surprising if you look at the related middleware
initialize() {
strapi.app.use(async (ctx, next) => {
// disable for graphql
// TODO: find a better way later
if (ctx.url === '/graphql') {
return next();
}
how did you solve it? itās kind of a hard problem since everything is bypassed for relational data, if you look here [graphql] controller bypassed when querying nested relations Ā· Issue #8735 Ā· strapi/strapi Ā· GitHub
Hey there. Has anyone managed to connect the v4 beta to a Postgres database yet? The standard config I used in previous versions is not working.
Thank you! Turns out I was using āusernameā instead of āuserā.
The GraphQL plugin is built on top of Nexus which allows for a lot of customizability. For example, this code snippet shows how to add a field level permission to the default email attribute on the UsersPermissionsUser.
Here is the Strapi docs referenceāalthough I ran this code inside the src/index.js file as it didnāt work within the config/functions/register.js file.
Oh, I hadnāt realized that, thanks for pointing that out. Iāve been working with Nexus a bit recently and certainly agree that there is lots of flexibility there (including perhaps with the Field Authorize plugin).
there is a problem from previous versions, you cannot organize the records with a drop and drag that allows you to view the records in frontend according to the order
Yes, I remember that. When I had to organize everything manually
Hi, thanks for the release. I just installed a v4 instance and I can see the plugins section in admin panel is still under construction.
How do I install and enable e.g. the graphql plugin?
And also I can see that the latest version of strapi-plugin-graphql is still 3.6.8, this one is supposed to work with strapi v4 for now?
OK let me answer myself, maybe someone will find this useful when experimenting with the new features.
Graphql plugin can be installed via CLI using this command:
npm run strapi install graphql
Anyway this takes me to another question: when I query a collection via graphql, I can now get the total count of records in the ResponseCollectionMeta field. Cool, thanks for that!
But - when there is a relation type field, it returns different type (RelationResponseCollection), which doesnāt have any kind of meta datatype, thus itās impossible to get the related records count OOTB.
Is there a plan to implement this in v4?
I donāt know if this is a bug or intended as a āfeatureā in Strapi v4, but the REST API doesnāt seem to include the relations and components used in a collection when it is returned. The attributes returned by default only include the direct fields, but if I add ā?populate=*ā to the path the relations are added. However, components are not populated with their data, instead it only responds with the id used in the mapping table for the associated component, not any actual data. Finally, there is no indication in the default response that the collection contains relations, e.g., the āAuthorā field pointing to users is not even included in the response so there is no way to tell what relations you may want to populate unless you first populate all relations to figure out whatās in the model.
Let me know if this is a bug that I should raise as an issue on GitHub instead and Iāll do that.
1 Like
Donāt have anything useful to share but I am experiencing the exact same thing. Dynamic zone doesnāt show in API response but adding that query string shows the base structure of the dynamic zone without further components.
Hello,
Can anyone help customizing MiddleWare in V4.x? Basically trying to get raw / unparsed body in custom endpoint.
Any hint would be helpful.
Thanks.