static-fe overhaul #236
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#236
Loading…
Reference in a new issue
No description provided.
Delete branch ":pretty-staticfe"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
makes static-fe look more like pleroma-fe, with the stylesheets matching pleroma-dark and pleroma-light based on
prefers-color-scheme
.also i forgot
how it looks + sneak peek at statuses:
WIP: Add navbar, sidebar and background to static-feto WIP: static-fe overhaulprofile view:
"show newer" button seems to not work at all even in original static-fe.
nsfw attachments:
need help: separating the timelines into posts, with replies, media, and followers/following
i just don't know elixir or the codebase enough to know which functions to call
abb6f00cdd
tod5c0aac3b8
it'S DONE
WIP: static-fe overhaulto static-fe overhaul091baf5d47
toe5ebb2ab20
e5ebb2ab20
to4cc35924ea
i Think (tm) this works but my machine for some reason doesn't wanna do tests correctly 🥴
static-fe overhaulto WIP: static-fe overhaul3e75178b61
tod494addf54
011eb5bcaa
to2178c96ff6
WIP: static-fe overhaulto static-fe overhaulok Now it should be done but for real actually tm
working demo at snowdin.town
@ -26,0 +26,4 @@
defp no_static?(conn) do
conn.query_params
|> Map.has_key?("no_static")
we shouldn't allow people to change routing with query parameters
okay so this was like a last minute update because people complained about how they can't move to the primary frontend from the backend, and pleroma-fe lies about your url, so there's no other way to figure out whether static-fe Should be loaded except for like. a cookie maybe?
i'm fine with removing this commit for the time being but it's a feature that should be added sometime
@ -726,1 +726,4 @@
scope "/", Pleroma.Web do
# Note: html format is supported only if static FE is enabled
pipe_through([:accepts_html_xml, :static_fe])
we're not posting, this scope doesn't need to take any
Accept
headers - you can remove the accepts@ -760,2 +769,3 @@
scope "/", Pleroma.Web.ActivityPub do
pipe_through([:activitypub_client])
# Note: html format is supported only if static FE is enabled
pipe_through([:activitypub_client, :accepts_html_xml_json, :static_fe])
why was this changed?
fetching
/users/:nickname/followers
orfollowing
withAccept: application/activity+json
should return the AP data, but with HTML it needs to return the static-fe list of follow(er)s. i could take those two specifically though instead of the whole bunch
@ -56,10 +57,31 @@ defmodule Pleroma.Web.StaticFE.StaticFEController do
|> Map.take(@page_keys)
|> Map.new(fn {k, v} -> {String.to_existing_atom(k), v} end)
params =
you should probably have a hard
limit
on your params, else you can manually specify?limit
in your URL and make it apply@ -63,0 +77,4 @@
|> Enum.map(&represent/1)
"following" ->
User.get_friends(user)
you should honour
user.hide_followers
anduser.hide_follows
here@ -153,0 +175,4 @@
reply_to_user =
if data["inReplyTo"] do
data["inReplyTo"]
|> Activity.get_create_by_object_ap_id()
this should never pull in data
use https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/activity.ex#L291
@ -153,0 +177,4 @@
data["inReplyTo"]
|> Activity.get_create_by_object_ap_id()
|> Map.get(:actor)
|> CommonAPI.get_user()
why are you using commonAPI here?
@ -22,17 +21,44 @@ defmodule Pleroma.Web.StaticFE.StaticFEView do
Utils.fetch_media_type(@media_types, mediaType)
end
def time_ago(date) do
replace with https://hexdocs.pm/timex/Timex.html#from_now/1 instead of reinventing the wheel
it looks nice, but parts of this will be very difficult to maintain
mostly looking at SVG literals - these should absolutely be replaced
if you can manage that i'll take another look
@ -17,0 +14,4 @@
</a>
<div class="user-summary">
<div class="top-line">
<span class="username">
formatting is all over the place in this file
yeah there's a lot of shit in here because i was doing this blind and mostly looking at similar things 🥴
70fe8fb993
toecfda57461
ecfda57461
to12db8a40c5
two other things i have to add:
5bb95256ee
fucked with img classes, emoji are now not discernable from other images, and they're incorrectly sized12db8a40c5
toe4c9d57aa2
@ -102,2 +102,4 @@
"alt"
])
Meta.allow_tag_with_this_attribute_values(:img, "class", ["emoji"])
????????????????????????????????????????????????????????????????????????????????????????????????
...yes?
there is literally nothing differentiating an emoji from an inline image except for the emoji tag here
https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/emoji/formatter.ex#L32 adds the
emoji
tag to emoji, but the changes in5bb95256ee
effectively reverses that, making it impossible to size emoji correctly without ruining all other imageswe should not be allowing literally any server on the network to pass classes through to the frontend
including our own? as far as i can tell emoji assignment is done on our side even for remote, could be wrong though
in any case how would you render any emoji without knowing what's an emoji
"our own" is the whole reason that the leak happened in the first place
there is no distinction between "our" classes and what can be applied via image classes
no but what i mean is
maybe the classes could be scrubbed before our server adds emoji postprocessing
you can't inject classes in a
:shortname:
again, unless remote servers send their emoji already processed and not in shortcode, in which case "aaa" and "fuck"
remote servers are entirely allowed to send
<img>
tagsthis change would allow those to pass classes through the scrubbe
i guess a compromise would have to be.. non-emoji images given without width or height would by default be sized like emoji?
ok yes so
removing this commit and talking specifically about emoji
are they sent as
<img>
tags or as shortcodes? if the latter, you could first scrub the incoming post, then format it, thereby ending up with correctly classed emojiif not then that's a different problem but i feel like there's potentially a really easy solution to this
this is ugly and i don't like it but it works
e4c9d57aa2
toad76fcc673
422b2a9a12
toefa3f1b71b
much more readable
a few cache things
you may also want to add some attribution for fontawesome (just a txt file in the static fe view will do) - they don't require it but they prefer it
@ -724,6 +724,12 @@ defmodule Pleroma.Web.Router do
get("/users/:nickname/feed", Feed.UserController, :feed, as: :user_feed)
end
scope "/", Pleroma.Web do
this fragment can be refactored
which allows you to remove the prefix in the routes
@ -153,0 +185,4 @@
activity
|> Activity.get_in_reply_to_activity()
|> Map.get(:actor)
|> User.get_by_ap_id()
use
get_cached_by_ap_id
@ -24,1 +23,4 @@
def time_ago(date) do
{:ok, date, _} = DateTime.from_iso8601(date)
{:ok, now} = DateTime.now("Etc/UTC")
you can use DateTime.utc_now for this
i've also been trying to trim down the number of commits and make it more coherent what each commit does, but the css file doesn't wanna cooperate with all of the changes.
they seem to actually not mind at all actually
daf5fc7e78
to9ed1398651
9ed1398651
to7063631787
@floatingghost (this is ready to review i just cant seem to ask for review again)
this seems fine now!
thank you very much, this is... massive - finally a functional static-fe