[6.x] Prototype of an asset reference viewer#13832
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| if ($matches[3] === $this->assetPath) { | ||
| $this->found = true; | ||
| } | ||
| } |
There was a problem hiding this comment.
Only first statamic URL checked in string fields
Medium Severity
The findStatamicUrlsInStringValue method uses preg_match which only finds the first statamic URL in a string field. If a Bard or Markdown field contains multiple asset references and the target asset isn't in the first URL, the reference will be missed. The existing AssetReferenceUpdater::updateStatamicUrlsInStringValue correctly uses preg_replace_callback to process all matches, but this new finder only checks the first one.
| $entries = $entries->slice(($page - 1) * $perPage, $perPage)->values(); | ||
|
|
||
| // Use the first entry's blueprint for processing, but we'll use simple columns | ||
| $blueprint = $entries->first()->blueprint(); |
There was a problem hiding this comment.
Null pointer error on out-of-bounds pagination page
Medium Severity
When a pagination page beyond the available results is requested, $entries->slice() returns an empty collection. The subsequent call to $entries->first()->blueprint() then attempts to call blueprint() on null, causing a fatal error. The emptiness check on line 184 only validates the original unsliced collection, not the paginated result.
|
This looks awesome Jack, and thanks for considering the idea. If that real estate feels too tight, a Stack could be useful too as then it could be triggered from the Asset browser for an individual “…” for an asset. Like the Revisions panel approach. |
|
I loooove this feature. However I wonder if it might be structured a bit differently. Instead of finding everything, what if we kept track of where everything was used (like in https://github.com/thoughtco/statamic-cache-tracker). That way the CP side is extremely performant (imagine some sites that have 20k+ entries etc) and we can use that for other bits of components too, like entries. We could even use a local sqlite db to store all of this, which would make the look ups wicked fast. The stache watcher would do this work locally to keep things up to date and of course the save listeners/etc used on the CP side. Only brainstorming here, this caught my interest. |
This is ideal, but would require some rearchitecture. I think the idea of this PR is to get something, even if it's not performant.
I think this is a good idea. It probably takes some overhead to find references, especially when there's a lot of content. Showing it in a stack means you could trigger it when you open the stack. As opposed to doing all the work whenever the asset editor is opened. Or maybe not a stack - could even be a popover. But I think making it happen on click might be a better idea. |
Yup, I get it, was only doing some thinking while it was top of mind. |
It does this now actually. You click a button and then it fetches. |
|
Well then.
|
4 participants
It's just a Cursor prototype of the feature, nothing production-ready. But useful to chat about if this is the direction we'd like to go with this feature.
From statamic/ideas#1412
Note
Cursor Bugbot is generating a summary for commit f0f314b. Configure here.