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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I help with regards to Polylang's integration with Gutenberg and the REST API? #15

Open
danielbachhuber opened this Issue Oct 3, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@danielbachhuber
Copy link

danielbachhuber commented Oct 3, 2018

馃憢 What questions do you have remaining that need extensibility support from Gutenberg and the REST API? Happy to help track down answers as I can.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Oct 4, 2018

Hi Daniel,

I am also writing on behalf of @manooweb.

Thank you very much for your interest and proposal.

Here are the features broken when we activate Gutenberg together with the current stable version of Polylang:

  • When you create a new translation, Polylang imports the content, post metas and taxonomies from the source post.

  • When you change the language in the metabox, Polylang refreshes:
    鈰 The page parent dropdown in the page attributes metabox (as pages are filtered by language)
    鈰 The taxonomies metaboxes (as terms are filtered by language)
    鈰 The permalink (to change the part varying with the language)

We have decided to rewrite the metabox to handle most of the compatibility with Gutenberg in React. However, here are the issues that we have identified for which we would need help:

Blocking:

  • Importing the content (+ taxonomies and post metas) from a source post to a new translation is one of the most important features used by our users. It's currently broken by the change in order of the actions add_meta_boxes and admin_enqueue_scripts. We have described this issue in WordPress/gutenberg#7000 and WordPress/gutenberg#4929 is kept open to track the issue. We saw that it has been recently added to WP 5.0 milestone.

  • However even when the problem above will be solved, we would still have a blocking issue to import the title due to the way the title of a new post is handled by Gutenberg. We explained it in WordPress/gutenberg#7421. We looked into alternative solutions with existing WordPress filters but they are not honored by Gutenberg. See WordPress/gutenberg#8757.

  • The two problems above have been solved and it's now possible to import the content (+ taxonomies and post metas) from a source post to a new translation in WP 4.9.8 + Gutenberg. But the merge of Gutenberg in WP 5.0 has re-introduced the issue as scripts are loaded before the action add_meta_boxes is fired. See: https://core.trac.wordpress.org/ticket/45250

  • We haven't identified a way to fire a refresh of the page attributes panel to refresh the list of parent pages when changing the language. See WordPress/gutenberg#7565
    The workaround for the taxonomies panel described below doesn't work with the page attributes panel.

Annoying:

  • We haven't identified a way to fire a refresh of taxonomies panels when changing the language. See WordPress/gutenberg#7549.
    Having the Languages panel in a plugin sidebar works around this as the re-render of the document sidebar re-renders the taxonomies panels.

  • We haven't identified a way to add the Languages panel to the document sidebar. That's also why we created a plugin sidebar. But it doesn't make much sense to have a sidebar for only one panel. What if many plugins do the same? And our users won't understand why the legacy metabox is in the document sidebar and not the new panel that we specifically designed for Gutenberg.

Nice to fix:

  • We haven't identified a way to fire a refresh of the complete permalink.
    We work around this by saving the post, but this doesn't look good as long term solution.

  • We haven't identified a way to activate the Publish/Update button.
    @youknowriad proposed us a hack (modifying the title with the same value) to work around this. But this doesn't look good as long term solution.

So far, we have not identified any issue with the REST API. We could add our own routes or fields when needed. And Gutenberg allows us to filter its REST API calls when we need, for example to filter the content per language.

@danielbachhuber

This comment has been minimized.

Copy link

danielbachhuber commented Oct 4, 2018

Thanks @Chouby. Could you add me as a contributor to this repo so I can assign this issue to myself as a way of keeping tabs on it?

To start replying to your points:

It's currently broken by the change in order of the actions add_meta_boxes and admin_enqueue_scripts

I'd like to be able to revert this change. However, in order to do so, we'd need to confirm the original reason for making change has been resolved. I believe it was ACF but we'd need to do a dive through the history to verify.

We looked into alternative solutions with existing WordPress filters but they are not honored by Gutenberg.

Supporting those existing filters seems feasible to me if you'd like to submit a pull request for it.

We haven't identified a way to fire a refresh of the page attributes panel to refresh the list of parent pages when changing the language.

I've replied directly on that issue. We can continue the conversation there.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Oct 12, 2018

@danielbachhuber

This comment has been minimized.

Copy link

danielbachhuber commented Oct 12, 2018

* Importing the content (+ taxonomies and post metas) from a source post to a new translation is one of the most important features used by our users. It's currently broken by the change in order of the actions `add_meta_boxes` and `admin_enqueue_scripts`

We discussed this some today in Slack and are open to reversing the order. Would you be willing to research, open a pull request, and test against a few plugins?

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Oct 16, 2018

I just submitted WordPress/gutenberg#10660 after I tested it with a few plugins. My test with ACF is not relevant as it looks like ACF was broken somewhere between Gutenberg 3.9 and 4.0.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Nov 1, 2018

Well in fact, our post pre-filling issue that was solved by WordPress/gutenberg#10660 and WordPress/gutenberg#10362 is now back in WordPress 5.0. I also noticed that these 2 pull requests did not completely fix our issue as some fields such as 'menu_order' or 'comment_status' are not read by the editor.

I opened a ticket in core trac: https://core.trac.wordpress.org/ticket/45250

@danielbachhuber

This comment has been minimized.

Copy link

danielbachhuber commented Nov 9, 2018

* The workaround for the taxonomies panel described below doesn't work with the page attributes panel.

Which is this workaround? I've created WordPress/gutenberg#11700 to offer an API for refreshing the data.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Nov 12, 2018

Thanks for th ticket.

Currently we are obliged to put the languages panel in a plugin sidebar. So when we select a new language, the document sidebar is hidden. When we come back to the document sidebar, the taxonomies panels are refreshed and correctly filtered by the new language.

Our main concern is that this doesn't work for the page attributes panel. It looks like, unlike the taxonomies panels, the page attributes panel doesn't fire a new REST request when the document sidebar is refreshed. See WordPress/gutenberg#7565.

For us, this is a workaround, because the user workflow is worse with a languages panel in separate plugin sidebar compared to the current situation where the legacy metabox is in the document sidebar.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Nov 12, 2018

As a side note, I have added a new blocking point in the list. Although the cause is different, the consequence for us is the same as the 2 points which are already solved. We are unable to prefill a new post due to the different behavior between WP 4.9.8 + Gutenberg and WP 5.0. We have already discussed that in https://core.trac.wordpress.org/ticket/45250

@danielbachhuber

This comment has been minimized.

Copy link

danielbachhuber commented Nov 23, 2018

@Chouby Could you unassign me from this issue, please? Thanks

@manooweb manooweb assigned manooweb and unassigned danielbachhuber Nov 23, 2018

@manooweb

This comment has been minimized.

Copy link
Collaborator

manooweb commented Nov 23, 2018

@danielbachhuber done :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment