#299 Article cover

Merged
elegaanz merged 8 commits from article-cover into master 2 years ago
elegaanz commented 2 years ago (Migrated from github.com)

Screenshots:

On the article page

On the home page

Fixes #236

Screenshots: ![On the article page](https://social.wxcafe.net/system/media_attachments/files/001/270/277/original/2cd574456e31d710.png?1540982197) ![On the home page](https://social.wxcafe.net/system/media_attachments/files/001/270/278/original/adaec1bcbc0ff751.png?1540982220) Fixes #236
elegaanz commented 2 years ago (Migrated from github.com)
Owner

I’m not 100% satisfied with the cover selector (a <select> field listing your media) but if we want to have a JavaScript-free implementation and to avoid duplicating the media upload form, I don’t see any better solution. 🤷‍♀️

I'm not 100% satisfied with the cover selector (a `<select>` field listing your media) but if we want to have a JavaScript-free implementation and to avoid duplicating the media upload form, I don't see any better solution. :woman_shrugging:
trinity-1686a reviewed 2 years ago
trinity-1686a left a comment

I’m getting an error when accessing the page to create a new post, however only when I have at least one media uploaded with that account, and there is no issue with /~/<blog>/<slug>/edit

GET /~/Yoloswagg/new/ text/html:
    => Matched: GET /~/<blog>/new (new)
    => Error: Error rendering Tera template 'posts/new'.
    => Error: Failed to render 'posts/new'
    => Error: Variable `form.cover` not found in context while rendering 'posts/new'
    => Error: Template 'posts/new' failed to render.
    => Outcome: Failure
    => Warning: Responding with 500 Internal Server Error catcher.
    => Response succeeded.

About the cover selector, to be frank I don’t really like how medias works currently, it feels strange to go to /medias/ to change your avatar. It feels strange too to upload medias on a page different than the one where you write your posts (which will hopefully be better when we start working on a rich text editor), and choosing from a <select> what media will be the cover feels the same, maybe even worth for peoples having a lot of uploaded medias as the time goes. It can stay like that for the moment, but we will need to address this in the future.
Also make me through of one thing : while it’s using a <select>, you should filter to only show images, not audio content for example (actually the same goes for peoples avatar, currently they can be an audio file)

@@ -633,0 +633,4 @@

#, fuzzy
msgid "Illustration"
msgstr "Administration"
trinity-1686a commented 2 years ago

wow fuzzy translation is so wrong

wow fuzzy translation is so wrong
elegaanz commented 2 years ago (Migrated from github.com)
Owner

Yes, I agree the way media are currently working is not ideal. I think we can change it once will we will switch to a new editor, by adding the possibility to upload an avatar directly from the profile edition page, and to add any other media directly from the editor.

Yes, I agree the way media are currently working is not ideal. I think we can change it once will we will switch to a new editor, by adding the possibility to upload an avatar directly from the profile edition page, and to add any other media directly from the editor.
trinity-1686a commented 2 years ago
Owner

Anyway changing how we handle medias is neither the goal nor in the scope of this pr, so even if it’s less than ideal, it shouldn’t affect how we merge this pr (and actually making sure people are not using a song as a picture is not that important as in the end how they select those will be totally changed latter on)

Anyway changing how we handle medias is neither the goal nor in the scope of this pr, so even if it's less than ideal, it shouldn't affect how we merge this pr (and actually making sure people are not using a song as a picture is not that important as in the end how they select those will be totally changed latter on)
trinity-1686a reviewed 2 years ago
trinity-1686a commented 2 years ago

This is the exact line that is failing. I think you can’t compare form.cover because form is null when creating a new article. if not form.cover (2 lines above) is legal as it verify the existence of the field, and its “nullness”, but a compare only make sense if the field exist, it being null or not

This is the exact line that is failing. I think you can't compare `form.cover` because `form` is `null` when creating a new article. `if not form.cover` (2 lines above) is legal as it verify the existence of the field, and its "nullness", but a compare only make sense if the field exist, it being null or not
trinity-1686a reviewed 2 years ago
trinity-1686a commented 2 years ago

Those 3 println! were for debug only I guess, so they should be removed

Those 3 `println!` were for debug only I guess, so they should be removed
elegaanz (Migrated from github.com) reviewed 2 years ago
Plume_migration_agent commented 2 years ago

Oops, you’re right. 😬

Oops, you're right. :grimacing:
trinity-1686a approved these changes 2 years ago

Reviewers

trinity-1686a approved these changes 2 years ago
The pull request has been merged as 25b7399e7f.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.