Mastoapi login and config fixes #2102

Closed
hj wants to merge 0 commits from gitlab-mr-iid-833 into develop
Member
  • Remove formattingOptionsEnabled because it doesn't stop one from using formatting options, what stops is list of available post content types, added display of post content type as a label if there's only one available.
  • Removed background-image hack, added support for MastoAPI background image and chat token fetching, moved background image setting to MastoAPI.
* Remove `formattingOptionsEnabled` because it doesn't stop one from using formatting options, what stops is list of available post content types, added display of post content type as a label if there's only one available. * Removed background-image hack, added support for MastoAPI background image and chat token fetching, moved background image setting to MastoAPI.

what's the relation between backgroundpreview and background here, why could all this be removed?

what's the relation between backgroundpreview and background here, why could all this be removed?
Author
Member

The whole thing should be refactored IMO, but the thing is that there's uploadFile() which sets {slot} and {slot}Preview, i.e. for background it would be background and backgroundPreview, the preview is used to display it in the UI as a preview and it's a data: URI, the just background is file itself, just raw data IIRC.

If I understand correctly the old code and QvitterAPI was expecting the data: uri with some crop options which weren't implemented and instead image's own dimensions were determined client-side and passed as parameters, probably GNU/Social or original Qvitter actually did some cropping? idk. Meanwhile MastoAPI doesn't support anything and expects raw data for image data.

All that I can say is that it worked for me this way and not the other way.

The whole thing should be refactored IMO, but the thing is that there's uploadFile() which sets `{slot}` and `{slot}Preview`, i.e. for background it would be `background` and `backgroundPreview`, the preview is used to display it in the UI as a preview and it's a `data:` URI, the just `background` is file itself, just raw data IIRC. If I understand correctly the old code and QvitterAPI was expecting the `data:` uri with some crop options which weren't implemented and instead image's own dimensions were determined client-side and passed as parameters, probably GNU/Social or original Qvitter actually did some cropping? idk. Meanwhile MastoAPI doesn't support anything and expects raw data for image data. All that I can say is that it worked for me this way and not the other way.
Author
Member
  form.append('pleroma_background_image', background)
```suggestion:+1 form.append('pleroma_background_image', background) ```

ah right, qvitter did this weird cropping.

ah right, qvitter did this weird cropping.
Member

would keep the object notation spaced out as eslint demands, already spaced out the rest in polls MR so there might be a conflict regarding this file where it will be changed to fit the rest most likely

would keep the object notation spaced out as eslint demands, already spaced out the rest in polls MR so there might be a conflict regarding this file where it will be changed to fit the rest most likely
Member

LGTM

LGTM
Member

Yes, qvitter was pain in this regard, I'm happy if it works this way.

Yes, qvitter was pain in this regard, I'm happy if it works this way.
Author
Member
  const updateBg = ({ background }) => apiService.updateBg({ credentials, background })
```suggestion const updateBg = ({ background }) => apiService.updateBg({ credentials, background }) ```

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
pleroma/pleroma-fe!2102
No description provided.