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

Distributing blocks with site-specific attributes doesn't work #430

Open
cmmarslender opened this issue Jul 17, 2019 · 4 comments · May be fixed by #432
Open

Distributing blocks with site-specific attributes doesn't work #430

cmmarslender opened this issue Jul 17, 2019 · 4 comments · May be fixed by #432
Labels
help wanted needs:discussion This requires discussion to determine next steps. type:enhancement New feature or request.
Milestone

Comments

@cmmarslender
Copy link
Contributor

Is your enhancement related to a problem? Please describe.
We have a handful of blocks that store data in the json inside the block comment. For example, we might have something like this in the json:

{"leadershipGroup":1320}

Where leadershipGroup is the id of a term, and we need to filter the block display on the frontend (this block is rendered in php) to only show items from this particular term.

Describe the solution you'd like
Would love to have a filter as blocks are syndicated that allows modification to the json for each block in the content.. In this example, we could update the term ID to reference the proper term on the site we are distributing to.

We run into similar issues with stored media IDs, or really anything that references data specific to the original site in the block data.

@cmmarslender cmmarslender added the type:enhancement New feature or request. label Jul 17, 2019
@jeffpaul jeffpaul added this to the 1.6.0 milestone Jul 17, 2019
@cmmarslender cmmarslender linked a pull request Jul 17, 2019 that will close this issue
8 tasks
@adamsilverstein
Copy link

Hi @cmmarslender, thanks for the feature request!

This may be possible with existing filters. I have a few questions about your use case:

  • Are you distributing to a site on the same WordPress network, or to an external site connection via the REST API?
  • Are you pulling or pushing the content (or both)?

In this example, we could update the term ID to reference the proper term on the site we are distributing to.

How would you know determine the correct term by its id? Are you sure the term already exists on the remote site or might you need to create it? You may need to distribute an object with the term name and slug.

We run into similar issues with stored media IDs, or really anything that references data specific to the original site in the block data.

Right! This is an issue with distributing any id referenced content. We currently handle some things automatically, it feels like supporting things like the core image block would be a logical next step (or at the very least documenting how to add support for them).

@adamsilverstein adamsilverstein self-assigned this Jul 22, 2019
@cmmarslender
Copy link
Contributor Author

Currently pushing and pulling within a multisite network, though ideally there could be some filters exposed for pushing/pulling in either context.

In a multisite network, we can compare term on source site and either fetch or create a new term on a destination site.. Would be a bit more challenging in a REST API scenario, but I think exposing the hooks and letting developers deal with implementation details would be amazing - not expecting distributor to do this automatically.

@adamsilverstein
Copy link

👍 Seeing the PR now, I missed that earlier. Nice work! I'll leave a comment there.

@jeffpaul
Copy link
Member

There's still a good amount we need to discuss on this and it relates to work we want to tackle in 2.1.0, so I'm going to move this to the 2.1.0 release in hopes someone's able to pick this up and own it during that release cycle.

@jeffpaul jeffpaul modified the milestones: 2.0.0, 2.1.0 Mar 26, 2020
@jeffpaul jeffpaul added help wanted needs:discussion This requires discussion to determine next steps. labels Mar 26, 2020
@jeffpaul jeffpaul linked a pull request Jan 16, 2023 that will close this issue
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted needs:discussion This requires discussion to determine next steps. type:enhancement New feature or request.
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants