Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: distribute media items by themselves #775

Open
dkoo opened this issue Jul 1, 2021 · 3 comments
Open

Feature request: distribute media items by themselves #775

dkoo opened this issue Jul 1, 2021 · 3 comments
Labels
help wanted type:enhancement New feature or request.
Milestone

Comments

@dkoo
Copy link

dkoo commented Jul 1, 2021

Is your enhancement related to a problem? Please describe.

Currently, media attachments are only distributed when they're attached to another post type that's being pushed or pulled. They can't be pushed or pulled by themselves.

Describe the solution you'd like

Ideally, we should be able to push and pull media items like any other post types, either by pushing from the media item's edit page, or by pulling from the "Pull Content" screen. Distributed media items should download the image to the destination site and pull in any caption/credit content and metadata associated with the source item. Distributed media items that remain linked to the source item should sync changes from the source like other post types.

Even better, it would be great to have a bulk push action available in the Media Library screen, where you can select multiple attachments using the existing "Bulk select" feature and push them all to the same site(s).

Currently, it's possible to show the Distributor "push" menu item on media item edit pages by filtering both distributable_post_types (to add attachment) and dt_distributable_post_statuses (to add inherit), but attempting to push this way results in an error response:

{"success":true,"data":{"results":{"internal":[],"external":{"3426":{"date":"July 1, 2021 10:37 pm","status":"fail","errors":["Could not determine remote post id."]}}}}}

Designs

At minimum, no new UI would be required. For the "bulk push" feature, new UI would be required in the Media Library screen when more than one item is selected.

Describe alternatives you've considered

I thought about the idea of creating a private "exporter" page and adding media items I want to push to the page content, then adding private to the allowed statuses via the dt_distributable_post_statuses filter, then turning on the "Process the featured image and any attached images" option in plugin settings.

However, when pushing the private post, the post gets pushed to remote site, but the media items in the post's content don't get pushed as I would expect based on the plugin setting.

Additional context

Being able to distribute media items by themselves would allow Distributor to be used as a sort of basic DAM alternative, where the main site can distribute images along with caption/credit data to other sites and automatically sync any changes to the remote sites.

@dkoo dkoo added the type:enhancement New feature or request. label Jul 1, 2021
@jeffpaul jeffpaul added this to the 1.7.0 milestone Jul 2, 2021
@dkotter
Copy link
Collaborator

dkotter commented Jul 2, 2021

@dkoo Thanks for the request and all the helpful context.

I played around with this myself today to see if existing hooks could get us close to where we would need to be. The short answer is probably but the longer answer follows.

As you mention, we explicitly remove attachment from our list of supported post types. This can be added back by using the distributable_post_types filter.

We also only support items that have a post status of publish out of the box. This can be changed (to add inherit) using the dt_distributable_post_statuses filter.

This does give us the normal Push UI on attachments (when going to the attachment edit screen). For an internal connection, you are able to successfully push the attachment post type but the actual attachment media is not sent along. For external connections, you end up with the error you mention and nothing is pushed.

To fix the issue for an internal connection, you would need to hook into dt_push_post and manually send across the actual media item.

For an external connection, this is where it gets trickier. We distribute content to external connections via the proper post type REST API endpoint which in this case is the media endpoint. This endpoint expects you to send across a file object in order to create a media item. This would almost certainly require hooking into dt_push_post_args and dt_auth_format_post_args in order to add the proper data to the request.

All that said, here's a few different approaches we could take:

  • This could be a feature we build straight into Distributor
  • This could be a feature that utilizes the hooks mentioned above and is built out as a stand-alone "enhancement" extension
  • This could be a feature that utilizes the hooks mentioned above and individual users could build this functionality out as they need it
  • For either of those last two, there are probably other things we could do in Distributor itself to make this work easier, whether that's additional hooks or changing the structure of the code

I really like the idea of getting to the point where Distributor would work for a use-case as described but kind of a toss up in my mind on whether this is worth building as a feature straight into Distributor itself or if it should be maintained as a separate extension.

@jeffpaul
Copy link
Member

jeffpaul commented Jul 8, 2021

Related to #771.

@coenve
Copy link

coenve commented Feb 7, 2022

If you are changing the way media is handled by Distributor. You should also take into account #765, by making sure media is not duplicated anymore.

@jeffpaul jeffpaul modified the milestones: 1.7.0, 2.1.0 Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted type:enhancement New feature or request.
Projects
Status: Backlog
Development

No branches or pull requests

5 participants