Feature: Query Loop Block Support #98
Conversation
# Conflicts: # includes/Plugin.php
…-support # Conflicts: # includes/Plugin.php
s3rgiosan
changed the base branch from
feature/data-api-backbone
to
feature/classic-editor-support
# Conflicts: # includes/UI/BlockEditor.php
|
I've created a |
|
@rickalee @fabiankaegy bumping this for your review |
# Conflicts: # includes/UI/MetaBox.php
s3rgiosan
changed the title
|
Note that we'll also need a button to clear search query parameters: either just this integration's parameters, or all query parameters currently in use. |
…-support # Conflicts: # includes/API/V2/Post/Field/Relationships.php # package-lock.json # package.json
@benlk Clearing all query parameters is tricky. The Query block’s core filters don’t offer direct integration, and plugins like Advanced Query Loop can extend or alter them. That makes it hard to identify which filters are active or what the default state should be. I’ve switched from PanelBody to ToolPanel in the UI, which makes it easier to reset custom parameters tied to this integration. 
|
fabiankaegy
left a comment
fabiankaegy
left a comment
There was a problem hiding this comment.
This is working very well! I added a few minor comments that should all be easy to address :)
| {hasRelationships && ( | ||
| <SelectControl | ||
| options={relationshipsOptions} | ||
| value={relationshipKey} | ||
| label={relationshipsControlLabel} | ||
| onChange={onRelationshipChange} | ||
| help={relationshipsControlHelp} | ||
| __nextHasNoMarginBottom | ||
| /> | ||
| )} |
There was a problem hiding this comment.
We should only show this select control if there is more than one relationship available. I got it in an example where it only had one option
| label={relationshipsControlLabel} | ||
| onChange={onRelationshipChange} | ||
| help={relationshipsControlHelp} | ||
| __nextHasNoMarginBottom |
There was a problem hiding this comment.
| __nextHasNoMarginBottom | |
| __nextHasNoMarginBottom | |
| __next40pxDefaultSize |
If we need this control we should make sure it has the new default size to make it look better :)
| <ToolsPanelItem | ||
| hasValue={() => !!sourcePost} | ||
| label={__('Source post', 'tenup-content-connect')} | ||
| onDeselect={() => setAttributes({ sourcePost: undefined })} | ||
| isShownByDefault | ||
| > | ||
| <BaseControl help={sourcePostControlHelp}> | ||
| <ContentPicker | ||
| onPickChange={onSourcePostChange} | ||
| mode="post" | ||
| content={sourcePost} | ||
| contentTypes={postTypesSlugs} | ||
| maxContentItems={1} | ||
| singlePickedLabel={__('Selected post:', 'tenup-content-connect')} | ||
| /> | ||
| </BaseControl> | ||
| </ToolsPanelItem> |
There was a problem hiding this comment.
The way this currently works is odd. By default it already has the current post selected. I am not sure if this is how it should be 🤔
I think instead of that we should hide the ContentPicker entirely behind the ToolsPanel dropdown and just not have any value selected.
That way users that want to select a different post to relate to (which should be a very niche feature) can still do it but it isn't there front and center.
| * External dependencies | ||
| */ | ||
| import { v4 as uuidv4 } from 'uuid'; | ||
| import { registerBlockExtension, ContentPicker } from '@10up/block-components'; |
There was a problem hiding this comment.
If we update to version 1.21.1 of the block components we can use the new code split import syntax for these also:
| import { registerBlockExtension, ContentPicker } from '@10up/block-components'; | |
| import { ContentPicker } from '@10up/block-components/components/content-picker'; | |
| import { registerBlockExtension } from '@10up/block-components/api/register-block-extension'; |
which will result in a smaller bundle size :)
| "archive": "composer archive --file=$npm_package_name --format=zip" | ||
| }, | ||
| "dependencies": { | ||
| "@10up/block-components": "^1.20.1", |
There was a problem hiding this comment.
Lets update this again to the latest version :)
|
|
||
| // Clear dirty entities after successful save | ||
| dispatch(STORE_NAME).clearDirtyEntities(); | ||
| (dispatch(STORE_NAME) as any).clearDirtyEntities(); |
There was a problem hiding this comment.
Instead of typing it here as any we should use the actual store reference here instead of just the string of the name. this will ensure the types come across properly
| import React from 'react'; | ||
| import { useSelect } from '@wordpress/data'; | ||
| import { store as editorStore } from '@wordpress/editor'; | ||
| import { PluginDocumentSettingPanel } from '@wordpress/edit-post'; |
There was a problem hiding this comment.
Nice! We should always use the version from @wordpress/editor
|
@s3rgiosan back to you after some code review feedback |
4 participants
Warning
This PR is based on #97
Description of the Change
This PR introduces Content Connect relationship support for the Query Loop block, allowing posts to be filtered based on relationships.
Closes #83
How to test the Change
Changelog Entry
Credits
Props @s3rgiosan
Checklist: