Add integration for Sophi Overrides API about sophi-for-wordpress HOT 7 CLOSED

Noting that if the intended integration here is for folks using the Site Automation block, then updating that to something like the Curated Content block that's like the core nested list block where each post shown in the updated Sophi block would have individual block controls that could show an "override" icon that flows into the add/remove/replace/ban workflow and eventual Sophi Override API request.

from sophi-for-wordpress.

An additional, potential integration point that was discussed was a generic WP Admin page for Sophi Overrides that would allow editors to submit their add/remove/replace/ban requests (admitting this is likely the least optimal integration as it'll almost certainly be outside the normal editorial workflows for Sophi customers).

from sophi-for-wordpress.

As discussed today, we'll look to have the initial integration be code-only and exposing the Overrides integration via a hook(s) for existing Sophi customers to individually customize their Overrides integration via the Sophi plugin hook(s) available.

from sophi-for-wordpress.

Inner Blocks Approach

Currently, the Site Automation block is built as one custom block that uses ServerSideRendering in order to generate the Page List. This should get replaced with a controlled InnerBlocks approach.

The current Site Automation block should get refactored to render an InnerBlocks area. This InnerBlocks area should only allow the newly created sophi/page-list-item to be used in the InnerBlocks area. This can be done via the allowedBlocks property. The InnerBlocks should also be locked so that editors cannot manually reorder the page list item blocks. We can however use the core mechanism to add & remove the block in order to build in the add & remove API integration. For that, we need to use the data API in the parent block to subscribe to changes in the child block list. Every time the child blocks change we can determine what changed and then dispatch the correct action to the API.

import { store as blockEditorStore } from '@wordpress/block-editor';
import { useSelect } from '@wordpress/data';

export function SophiBlockEdit(props) {
	const { clientId } = props;

	const innerBlocks = useSelect(
		(select) => select(blockEditorStore).getBlock(clientId).innerBlocks,
	);

	// add the logic to handle updates in the child block list here
	
	return (...);

}

Warning
We will need to find a mechanism to differentiate between updates in the inner blocks that come from updates the user made and updates that happened because we refetched the data from the server and replaced the inner blocks manually.

Also in the parent block, we can create a timer to re-fetch the actual page list from the API on a regular basis. Every time we do that we can replace the list of inner blocks with the actual correct page list as it comes from the API. An example of how to do this can be found in the Core Columns block here: https://github.com/WordPress/gutenberg/blob/76672117848cd18d6d0ceb41d85bedc03f123e12/packages/block-library/src/columns/edit.js#L153-L224

import { store as blockEditorStore } from '@wordpress/block-editor';
import { dispatch } from '@wordpress/data';
import { useEffect } from '@wordpress/element';

export function SophiBlockEdit(props) {
	const { clientId } = props;
	const { replaceInnerBlocks } = dispatch( blockEditorStore );

	useEffect( () => {
		// set a timer to re fetch the pages from the API every X minutes

		// create the newInnerBlocks based on the API response

		replaceInnerBlocks( clientId, newInnerBlocks );
	}, [] )

	return (...);
}

Styling

In order to change how each of the list items should get displayed, there are a few different settings. These settings should exist as attributes on the Parent block. Using the context API in the block editor we can then inform the child blocks which settings are currently set and therefore how they should render their appearance. Ad @jeffpaul had mentioned an example of this can be seen in the Curated Content Block.

Let me know if you have any questions about this approach :)

from sophi-for-wordpress.

After discussing with Sophi and existing clients, it seems like the best initial approach will be building the block editor experience and ensuring hook(s) are included to allow custom Sophi integrations to have a similar Override capability via the plugin. The following are rough wireframes to consider in our technical analysis on approach: Sophi Overrides.pdf

In more detail, going screen-by-screen from the PDF document above, that starts with updating the existing Sophi Site Automation Block to be a nested block as @fabiankaegy notes in #328 (comment) wherein the blocks nested within the Sophi parent/container block adds an Override gear icon:

Clicking the Override gear icon in a nested block exposes the Override modal that defaults to ADD but the initial dropdown can be changed to select the REPLACE, REMOVE, and BAN options as well. From there, depending on the option selected additional fields are shown. Add and Replace should include a basic WP post search to allow an editor to search for and select a single post to be sent in the Add or Replace command. The expiration field should default to 2 for all request types (for now, until we get better defaults). The Page name (for all types) and Widget name (for all types except Ban) should be set from the parent/container block settings. The Position should be set by the position of the nested block amongst other nested blocks within the parent/container block (in the example here we clicked on the post sample 1 block which correlates to position 1).

Example order of modal fields for ADD and REPLACE requests including the sample copy for the dropdown field:

Example order of modal fields for REMOVE and BAN requests including the sample copy for the dropdown field:

from sophi-for-wordpress.

@fabiankaegy thanks for the details on innerBlocks approach.

We will need to find a mechanism to differentiate between updates in the inner blocks that come from updates the user made and updates that happened because we refetched the data from the server and replaced the inner blocks manually.

Why do we need to do so? I mean we will call the override API and update the change made by the user to the Sophi server, so it will be synced already and we will get the same (updated by user) data from the server on the next page load. In this case, we don't have to worry to save what is being changed by the user as we will fetch the latest data from the API and render it in the block on every page load. Please let me know if this is not the case. But if this is correct, then we don't need to create nested blocks! We can still use the ServerSideRender in the current (Site Automation) block and just show a gear icon in front of individual list items after it gets rendered (because we might not have control inside the ServerSideRender so we have to wait until it finishes rendering and then append the gear icon). Please share your thoughts on this. (cc @jeffpaul)

Also in the parent block, we can create a timer to re-fetch the actual page list from the API on a regular basis. Every time we do that we can replace the list of inner blocks with the actual correct page list as it comes from the API.

Why do we need a timer to re-fetch the page list every time? Isn't it enough to fetch the data on page loads?

Using the context API in the block editor we can then inform the child blocks which settings are currently set and therefore how they should render their appearance.

What will be those new styling settings?

@jeffpaul I have checked the documents and tried to understand how the Automation Block works. I have a few questions:

1. To follow the the Override API Docs, we need {{apiGateway}} and {{accessTokenWithOverrideReadScope}} and {{accessTokenWithOverrideCreateScope}} values. Do we have these values?
2. I have checked the https://sophi.10uplabs.dev/ and observed the Site automation block, I‘ve noticed that the posts are coming from the site itself! I thought the posts are being displayed from the Sophi server but it seems like only IDs (from the current site) are being saved at the Sophi server. Do Sophi only store the post IDs and nothing else?
3. Did we create a page and widget? (i.e. test_name: test_widget_2)
4. Can we make the Sophi Automation block work local? I see only the hosts of the 10uplabs and VIP sites are configured. I have configured the 10uplabs setting configuration locally and used the Automation Block, it auto-selected the latest 5 posts and rendered. So just wanted to understand how it selects the posts.
5. Does the Sophi server keep changing the posts list of the widget according to the posts' performance and user interactions?
6. What are the expiration dates? does the specific post is deleted at the Sophi server after expiry?

from sophi-for-wordpress.

1. Those 3 values will need to be added to the settings page, likely in a new "Overrides" section.
2. Sophi only sends the Post IDs via the Automation API. The site keeps all post content in sync with post publish/update actions to the Sophi server, but when WP requests a site automation request from Sophi we only receive the Post IDs in return and then render whatever info we need based on block settings.
3. You can see that sample in the Pages table list view in the 10uplabs test site.
4. You would have to fake your domain and make your settings also act as though you're the 10uplabs site (but then that might pollute the Sophi dataset by injecting invalid Post IDs that would then get recommended on actual requests from the 10uplabs test site). That's not a major issue, but also why we tend to test on the 10uplabs/VIP sites.
5. More or less, yes. It "learns" about those performances via the frontend JS/AMP tracking data.
6. The expiration timeframe is how long that override is forced on Sophi. After the timeframe expires Sophi goes back to its "normal" content curation/recommendations.

from sophi-for-wordpress.