pods-framework / pods

The Pods Framework is a Content Development Framework for WordPress - It lets you create and extend content types that can be used for any project. Add fields of various types we've built in, or add your own with custom inputs, you have total control.
https://pods.io/
GNU General Public License v2.0
1.06k stars 264 forks source link

Pods Item List block; unfinished SQL statements (still typing) crashes block, no immediate fix. #7207

Closed oldrup closed 8 months ago

oldrup commented 8 months ago

Description

I'm transitioning from Pods shortcodes to the Gutenberg blocks, enjoying how I can actually see the content within the editor.

However, the rendered block in the editor “crashes” when the parameters for the block aren't completely valid. That is a problem, as the block editor attempts to render the Pods block output while still typing the parameters.

Screenshot 1 - the Pods Item List returns some items, fine.

image

Screenshot 2 - after starting to type t.post_title ASC in the Order By

image

I think that affects all the SQL parameters but I specifically experienced it on the limit, where and order by.

The only resort is to exit the editor and cancel saving.

Is that something you can reproduce?

Version

3.0.7

Testing Instructions

No response

Screenshots / Screencast

No response

Possible Workaround

Can be worked around by coping and pasting in a finished where or order by clause from another text editor.

Site Health Information

No response

Pods Package

No response

oldrup commented 8 months ago

One way to mitigate the issue, is to create a pattern of a working Pods block. Then you can insert the pattern, and editing say, short strings in the where clause can be done faster than the editor refreshes.

image

sc0ttkclark commented 8 months ago

Good point here, we'll add a better try/catch for the SQL error and avoid this problem.

sc0ttkclark commented 8 months ago

Fixed via https://github.com/pods-framework/pods/commit/9aba67bad2c9218fd2e1fdce5a508b8d95a8d54e

sc0ttkclark commented 8 months ago

I wasn't able to get the error to happen itself, but the code I added will catch any other remaining errors that might be happening.

I've made additional adjustments and the errors appear much better now too:

When not using WP_DEBUG:

Screenshot 2023-10-20 at 11 49 23 AM

When using WP_DEBUG:

Screenshot 2023-10-20 at 11 51 12 AM