`userpageId` field on users (instead of content.contentType="userpage")

randomouscrap98 / contentapi

A generic content system to make some kinda standard websites

GNU General Public License v3.0

9 stars 2 forks source link

`userpageId` field on users (instead of content.contentType="userpage") #130

Closed 12Me21 closed 2 years ago

12Me21 commented 2 years ago

Currently, a user's userpage is their (first?) page with contentType="userpage", I think it might be easier to have a userpageId field on users instead

Advantages:

userpages become a builtin feature of the api (rather than a hack)
frontends can use api/Request/about to generate the form for editing user info, so adding new fields shouldn't be an issue (vs content types, which aren't really standardized)
easier to request a user's userpage (id in @user.userpageId vs contentType = @userpage AND createUserId in @user(I think))
prevents users from having multiple user pages
userpages can have other contentTypes now (maybe this is a bad thing?)

Disadvantages:

harder to filter userpages when searching
creating your userpage involves creating a page /and/ editing your user data
existing userpages won't be linked to users anymore

randomouscrap98 commented 2 years ago

Oh thank you for thinking about disadvantages, I hadn't thought about those

randomouscrap98 commented 2 years ago

So I'm putting oldsbs on this because it will impact how oldsbs operates, whatever decision we make.

As for the disadvantages:

Filtering userpages when searching, yes this is a big problem. I think this is honestly a bigger problem than the one we're trying to solve, which is finding user pages.
Creating the userpage does indeed require both, at least the first time. Subsequent updates generally won't though
I can run database updates (migrations) to relink all the existing userpages based on our current logic.

I'm starting to wonder if the disadvantages are worth it. What's the problem with user pages as they are now... just that deciding which one to use isn't trivial? I still think the query is easier than all the problems that arise, what do you think? The query still amounts to just one request, something like "type is userpage, create user is userid, sort by id desc limit 1 (to give latest)"

randomouscrap98 commented 2 years ago

I think we have decided to go with a different solution: create an internal_type for userpages and migrate all (or most) of the userpages to that. This way, they are natively supported by the api, and still easily removable from the resultsets. Also, macros can be created to standardize how a userpage is retrieved.