Support for api/v1/accounts/update_credentials route
#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 |
| $icon_id = (int) $data['avatar']; | ||
| $attachment = \get_post( $icon_id ); | ||
| if ( $attachment && 'attachment' === $attachment->post_type ) { | ||
| l( 'set_icon' ); |
There was a problem hiding this comment.
this should cause errors outside of the wp.com context.
mattwiebe
force-pushed
the
add/enable-mastodon-apps-profile-editing
branch
from
fcd97be
to
29db809
Compare
| * | ||
| * @return int The user id | ||
| */ | ||
| public static function maybe_map_user_to_blog( $user_id ) { |
There was a problem hiding this comment.
It is! I use it inside a couple of our callbacks to change somebody's WP User ID to the Blog User ID only when the user type is disabled and the blog is enabled. In this way a user who is logged in is doing what the plugin supports: only the Blog User. It does not allow us to log in as the Blog User when both Blog and User types are enabled, but that seems to be a much smaller problem overall.
includes/model/class-user.php
Outdated
| * @param string $name The User-Name. | ||
| * @return bool True if the User-Name was updated, false otherwise. | ||
| */ | ||
| public function save_name( $name ) { |
There was a problem hiding this comment.
I would prefer to move the save functions to the EMA-API class instead then, because they are very specific and I do not know if we can re-use them in other parts of the code.
There was a problem hiding this comment.
For the User type I completely agree, as long as we and EMA are both using the same attributes
EDIT Although one problem there is how to store avatars and headers
|
@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 |
includes/model/class-user.php
Outdated
| $icon = wp_get_attachment_url( $maybe_id ); | ||
| } | ||
|
|
||
| $option_name = 'activitypub_user_icon_' . $this->_id; |
There was a problem hiding this comment.
For signatures we use $user->user_login instead, because the ID can change on migrations!?!
There was a problem hiding this comment.
That seems like a pretty good idea. For dotcom Simple -> Atomic migrations we do maintain the User ID although that may not always be the case when we do something like a WXR Import
There was a problem hiding this comment.
But we should be consistent! I am already having a hard time with this login key on the deletion feature. If we decide to use the id instead then I will migrate that stuff!
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 |
| 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
| 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?
Running this along with akirk/enable-mastodon-apps#157 ~= profile editing support via 3rd party Mastodon apps :D
Proposed changes:
Other information:
Testing instructions: