[6.x] Prototype of an asset reference viewer

[jackmcdade]

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.}

[cursor]

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.}

[cursor]

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.

 

[cursor]

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.

 

[martyf]

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.

[edalzell]

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.

[jasonvarga]

Instead of finding everything, what if we kept track of where everything was used

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.

a Stack could be useful

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.

[edalzell]

Instead of finding everything, what if we kept track of where everything was used

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.

Yup, I get it, was only doing some thinking while it was top of mind.

[jackmcdade]

But I think making it happen on click might be a better idea.

It does this now actually. You click a button and then it fetches.

[jasonvarga]

Well then.

[ryanmitchell]

+1 for some sort of lookup/relationship table, you know its time to do it @jasonvarga 🤣

@jackmcdade UI looks hot, we currently prevent deleting assets on some projects to avoid references being left orphaned so this will be so useful!