[6.x] Support storing meta data as content

[godismyjudge95]

This PR has the potential to resolve a lot of issues people have with remote storage of assets.

Related issues:

• Lots of S3 files still breaks stuff #11949
• Unable to read file from location: asset meta on s3 #8641

There are also a lot of Discord discussions about S3 storage being slow. These almost all are resolved by moving the meta data to local storage through the eloquent driver.

The problem with both S3 and eloquent driver storage of meta data is that you lose one of the key features of Statamic - flat file git tracking. This means that if the focal point, custom fields, or other meta data is changed it is not tracked via git.

This PR provides the option to store the asset meta data as content - in the content directory and thus available to be tracked/synced by git.

--

I only provided two tests atm because I am not sure how deeply this needs to be tested as it just changes the paths where things are stored. Let me know if there are other points I need to test at and I will add them.

Also, I could foresee people requesting a command to migrate the asset meta from the standard storage mechanism and back.

Maybe in the future this feature gets turned on by default? 😄

[godismyjudge95]

I might need some help fixing these tests; they are working on my Windows machine. It might be a UNIX path issue?

[jasonvarga]

No problem, we'll handle them. 👍 Thanks for the PR

[ryanmitchell]

@godismyjudge95 its because line 326 (metaPath) has a ltrim() - it seems to be trying to make the path relative.

Updating the function to something like this seems to ensure the tests pass:

    public function metaPath()
    {
        if (config('statamic.assets.meta_as_content')) {
            return implode('/', [
                Stache::store('assets')->directory(),
                $this->container()->handle(),
                dirname($this->path()),
                $this->basename() . '.yaml',
            ]);
        }

        $path = implode('/', [
                dirname($this->path()),
                '.meta',
                $this->basename().'.yaml',
            ]);

        return Str::of($path)->replaceFirst('./', '')->ltrim('/')->value();
    }

[caseydwyer]

What are the chances that this PR finds its way into v6 alpha/beta? 👀

[edalzell]

Pushed a commit reverting the unrelated test array reformatting so the diff is just the feature.

One thing to consider: as written, existing sites get no speed or memory benefit from flipping meta_as_content on. Their .meta/ folders stay on the container disk, so the recursive listContents call (and the listing cache it feeds) still includes every meta file, and statamic:assets:meta:clean still only looks at metaFiles() on the disk. Reads of existing meta would also silently fall back to regenerating it since File::get() won't find anything under content/.

A statamic:assets:meta:migrate command (or similar) that copies .meta/*.yaml from the container disk into content/assets/<container>/ and deletes the originals would let people with large S3 containers actually realise the gain. Happy to help with it if you'd like.

[godismyjudge95]

A statamic:assets:meta:migrate command (or similar) that copies .meta/*.yaml from the container disk into content/assets/<container>/ and deletes the originals would let people with large S3 containers actually realise the gain. Happy to help with it if you'd like.

Yep definitely could see the usefulness for a migrate command - noted that in the description. I didn't originally include it as I was trying to keep this PR light.

I also think sometime in the future this option should be turned on by default and then that would necessitate a migrate option.