Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## Description Implements: #4770 This PR is a **proof of concept** of a legacy widget block. A block that allows existing WordPress widgets to be added as Gutenberg blocks. The design is similar to the one proposed by @melchoyce in #4770 (comment) (option 1). Although it seems option two was preferred, it would require to expose each widget as a block similar to what embeds do, and it would increase the technical complexity and make testing/debugging harder, so I preferred to use option 1 for now. I will gladly iterate on the UX after this proof of concept gets more stable. ## Some technical details The available widgets are preloaded to Gutenberg similar to what happens with page templates. ### REST-API user story I want to able to pass a widget identifier to an endpoint, pass the existing widget attributes and the changes the user is making if any, and receive from the rest API, the sanitized new widget attributes ready to save and an HTML form that allows the user to edit the widget in the new state. ### REST-API endpoint A very simple REST-API endpoint was implemented. The endpoint receives the previous instance of a widget (previous attributes) the changed instance of a widget (changed attributes if any) and returns the new instance of the widget and the HTML form that allows editing this widget. There are two ajax-admin endpoints save-widget and update-widget. It looks like each one has specificities that make using it here complex. The ajax admin code would probably require some changes to be used here. Our use case is straightforward from the backend perspective as the widget does not need to be saved anywhere, and the widget is not associated with any widget area. The most straightforward approach seemed to be using a very simple endpoint. If I missed something and adapting existing endpoints is simpler feel free to comment, and I will have a look. ### Block Architecture The edit component of the block handles the start placeholder that allows selecting a widget, and the tab mechanism that allows switching between edit and preview. The preview is done using the ServerSideRender component. The edit is done using two components: **WidgetEditHandler:** Is responsible for server communication using the endpoint we created, and for keeping the required local state for the edition. Renders an update button, when pressed we retrieve from the dom the changed fields (using a method provided by WidgetEditDomManager) issues a request to the server and updates the legacy widget instance attribute with the server answer. **WidgetEditDomManager:** Component responsible for rendering the starting dom for a widget. After the first render React never rerenders the component again, the content rendered by this component is then managed by the scripts the widgets may implement. When a new instance of the form HTML is received we manually update the dom changing .widget-content (like the customizer and the widget screen) do. This component provides a method that returns an object with the widget changed attributes. When this component is mounted it triggers a widget-added event when a new update happens and the dom is changed by the component widget-update jQuery event is triggered. On front end widget are rendered with a simple call to [the_widget](https://codex.wordpress.org/Function_Reference/the_widget). ## Screenshots <!-- if applicable --> ![jan-25-2019 19-37-44](https://user-images.githubusercontent.com/11271197/51768637-c3b5b100-20d8-11e9-941f-00adb4c7b0a1.gif) ![jan-25-2019 18-58-49](https://user-images.githubusercontent.com/11271197/51768645-cb755580-20d8-11e9-89e7-1aa9ba7256c3.gif) ## Known problems - The block is not aware of any change inside the widget until the update button is pressed. This replicates the save button on the widgets screen. But it is annoying if we change something on the widget and go to the widget preview right away our changes are not reflected in the preview. Having an explicit update, makes testing and debugging easier, we may than explore other approaches e.g.: also save when preview happens, save on blur events, etc. - The text widget that contains TinyMCE crashes and fails to init. It calls wp.editor.initialize to reference TinyMCE and on Gutenberg, wp.editor is our editor module. This problem may have happened with meta boxes if it was solved probably the same approach may be applied. - The widget design may be affected by CSS that exists in Gutenberg, so the design of the widgets does not look the same. Ideally, Gutenberg CSS would not affect the widgets but as they are on the same page that's not the case. - Some third-party widgets using don't initialize correctly. That happens because the dom of the editor is not equal to the dom of the customizer and/or the widget screen. Some JS widgets use click events on the widgets screen to initialize while on Gutenberg these events don't happen, some check if they are on the customizer page (body contains customizer classes) before handling widget-updated events. Normally adapting a widget that does not initialize correctly is a matter of changing a very simple condition on the plugin.
- Loading branch information