Enable Mastodon Apps: support profile editing, blog user #788
Conversation
|
I'm not sure if it's a good idea to store the information directly in the |
Can you explain more? I don't follow. I've used Models to coordinate CRUD layers before, but always open to learning a better way of doing things! |
|
I am sorry, my brain is still a but fuzzy! It is not about the CRUD idea, it is about directly saving the data to the DB. Normally Maybe we should use this feature to refactor the code a bit and to consistently use attributes and maybe have a |
mattwiebe
force-pushed
the
add/enable-mastodon-apps-profile-editing
branch
from
fcd97be
to
29db809
Compare
|
@mattwiebe There is no way you can login as the blog author (yet), or do you have found a way? The other thing: Some of the informations seem to be generic and not related to ActivityPub, so why not move them to Enable-Mastodon-Apps instead? Like |
mattwiebe
force-pushed
the
add/enable-mastodon-apps-profile-editing
branch
from
bbe2a01
to
a33cbd2
Compare
Yup there is! See above, only when only the Blog User is active.
Those easily could, and should be supported in EMA itself, but it doesn't yet have a concept of header or avatar. The latter is still managed in Core through Gravatar, and there is only the (deprecated in Block Themes) header_image for the whole site. So perhaps EMA supports name and description, but we do avatar, header, and soon, extra fields |
includes/model/class-blog.php
Outdated
| public function save( $key, $value ) { | ||
| switch ( $key ) { | ||
| case 'name': | ||
| return \update_option( 'blogname', $value ); |
There was a problem hiding this comment.
That seems a bit dangerous, you might not realize that you're changing the whole blog name. Should this just be an override?
There was a problem hiding this comment.
It's tricky. Once we introduce an override, now you have to go into wp-admin to also change the blogname, if that's what you want to do, and/or being able to delete the override, falling back to the blogname, which you can now only edit in wp-admin. If you want a consistent name, you have to go to wp-admin. I'm thinking more of somebody who never wants to go there at all.
I'm erring on the side of consistency, not on the side of safety. And if somebody doesn't like the change they made, they can go back and change it again, without having to go to wp-admin.
At least that's the kind of thinking I was doing when I made it behave this way
includes/model/class-blog.php
Outdated
| case 'name': | ||
| return \update_option( 'blogname', $value ); | ||
| case 'summary': | ||
| return \update_option( 'blogdescription', $value ); |
There was a problem hiding this comment.
Same as above, maybe rather with an override?
includes/model/class-user.php
Outdated
| * - header: The User-Header-Image. | ||
| * @return bool True if the attribute was updated, false otherwise. | ||
| */ | ||
| public function save( $key, $value ) { |
There was a problem hiding this comment.
I would rename that, so that we will be able to have a generic save in the future, that saves all attributes to the DB.
There was a problem hiding this comment.
maybe something like save_attribute or so?!?
There was a problem hiding this comment.
Happy to have dedicated functions. I went in an update_key direction with it.
There was a problem hiding this comment.
Sorry for maybe not being precise enough: My proposal was to simply not use the generic save function, but something different instead. I am fine with having one function with key => value params, but I am also fine with dedicated functions :)
Only Extra Fields remains of that. We could probably just ship Extra Fields in a subsequent PR, but otherwise I'll wrap this up early next week. |
|
Extra Fields support went quicker than expected! We will require akirk/enable-mastodon-apps#167 to test. I will come back and try to form some testing instructions later. |
| return '<!-- wp:paragraph --><p>' . $content . '</p><!-- /wp:paragraph -->'; | ||
| } | ||
|
|
||
| public static function set_extra_fields_from_mastodon_api( $user_id, $fields ) { |
There was a problem hiding this comment.
I think we should have all "enable mastodon apps" functions in the integration file and not mix them up with the "core" files!?!
There was a problem hiding this comment.
Yup sounds good to me
mattwiebe
changed the title
api/v1/accounts/update_credentials route
includes/class-admin.php
Outdated
| <?php | ||
| esc_html_e( 'These are extra fields that are used for your ActivityPub profile. You can use your homepage, social profiles, pronouns, age, anything you want.', 'activitypub' ); | ||
| echo '<br />'; | ||
| esc_html_e( 'Note that Mastodon clients will only show four fields.', 'activitypub' ); |
There was a problem hiding this comment.
That is not completely correct! You can only add 4 extra fields through the Mastodon frontend, but it displays way more than these 4 when a different platform supports/provides it.
See my blog as example:
There was a problem hiding this comment.
Nice find, I foolishly believed something I read in an API doc rather than testing things :D
mattwiebe
force-pushed
the
add/enable-mastodon-apps-profile-editing
branch
from
b7269ec
to
d022392
Compare
Below is a screen recording of me using this PR to drive a Mastodon app, providing full profile editing support through 3rd party apps. (still requires akirk/enable-mastodon-apps#167 to work for Extra Fields)
Screen.Recording.2024-09-16.at.15.34.46.mov
Proposed changes:
Other information:
Testing instructions: