cms
cms copied to clipboard
Multisite: manual entry creation messes up stache
Bug Description
I am creating entries via an artisan console command using the entry facade. It's for a scheduled task that pulls posts from an external source periodically.
Entry::make()
->collection('posts')
->locale('ie')
->published(true)
->slug(uniqid())
->data([
'title' => $item->title,
'posted_at' => $item->date->format('Y-m-d H:i')
])
->set('updated_by', User::all()->first()->id())
->set('updated_at', now()->timestamp)
->save();
It works fine and entries are created for the 'ie' locale. The problem is that every time view the dashboard, or each time I re-run the command I get these errors:
Error 1: (occurs on second call of my function)
Error
Call to a member function sites() on null
at xxx\vendor\statamic\cms\src\Stache\Stores\CollectionEntriesStore.php:39
35▕ }
36▕
37▕ if (Site::hasMultiple()) {
38▕ [$site, $relative] = explode('/', $relative, 2);
➜ 39▕ if (! $this->collection()->sites()->contains($site)) {
40▕ return false;
41▕ }
42▕ }
43▕
1 xxx\vendor\statamic\cms\src\Stache\Stores\CollectionEntriesStore.php:39
Statamic\Stache\Stores\CollectionEntriesStore::collection()
2 [internal]:0
Statamic\Stache\Stores\CollectionEntriesStore::getItemFilter(Object(Symfony\Component\Finder\SplFileInfo))
Error 2: (occurs on third call of my function - I can't get past this error without wiping the entire cache)
Call to a member function hasStructure() on null
at xxx\vendor\statamic\cms\src\Stache\Stores\CollectionEntriesStore.php:133
129▕ }
130▕
131▕ protected function removeEntryFromStructure($collection, $id)
132▕ {
➜ 133▕ if (! $collection->hasStructure()) {
134▕ return;
135▕ }
136▕
137▕ $collection->structure()->trees()->each(function ($tree) use ($id) {
1 xxx\vendor\statamic\cms\src\Stache\Stores\CollectionEntriesStore.php:128
Statamic\Stache\Stores\CollectionEntriesStore::removeEntryFromStructure("6ad7bafc-7a4c-44a6-81d2-8d5a0ea708bd")
2 xxx\vendor\statamic\cms\src\Stache\Stores\Store.php:220
Statamic\Stache\Stores\CollectionEntriesStore::handleDeletedItem("xxx/content/collections/posts/ie/2606639329436392456.md", "6ad7bafc-7a4c-44a6-81d2-8d5a0ea708bd")
Temporary Solution
It seems I've run into a similar before: https://github.com/statamic/cms/issues/3175
php artisan cache:clear
fixes the problem locally and for some reason the problem hasn't presented on a staging domain.
Is this something to do with running my artisan command outside of the vagrant box I wonder...
Yes, it seems doing a vagrant ssh
before running my command fixes it. Now why is that?? Is cached data being incorrectly created when running directly from my Operating System - Possible Windows filesystem conflict??
Other Clues
- Refreshing the stache at the end of my artisan command fixes things sometimes but it also breaks things occasionally. These errors are produced by various uses of stache::refresh(), warm() and clear()
- call to member function dated() on null popup - when viewing any of my other collections in the control panel
- Running stache::refresh() a second time fixes the above, but occasionally breaks my collection trees. My home page gets unset, and that's a totally separate collection.
- storage\framework/cache/data/stache/items/collection-trees/home/): failed to open stream: No such file or directory
- Refreshing the site's and control panel's pages over and over sometimes fixes things up, but not always.
- It seems to be less of a problem on a staging server but not sure why. I've cleared my local vagrant box's caches multiple times but that didn't solve it. Maybe there's some other corrupted local files.
- In the above code I sometimes get an error: Cannot call member function first() on null - for this line of code
User::all()->first()->id()
- Suggesting that I don't have any users, but this only happens one in every ten calls. - I'm getting stache merge conflicts on deploy, mainly in the storage/framework/cache/data/stache/ folder
Environment
Statamic version: 3.1.29 PHP version: 7.4 Install method (choose one): Existing Laravel app OS: Windows 10
Is that collection set to "allow" that locale?
It is indeed. I have also tried allowing all sites on the collection and generating localizations using the Entry->makeLocalisation()
function, but I end up with similar errors.
Think I've stumbled onto the root of the problem. If I vagrant ssh to my homestead box first (Windows) before running my artisan command, then the error does not occur. I've updated the issue with a temporary solution above.
I haven't used Homestead in a few years but I do remember having issues w/ Laravel here and there when running commands outside of the box vs inside with SSH. Although, can't remember any specifics.
Since this issue is quite old now, hasn't had any recent activity and we haven't heard from others running into the same issue, I'm going to close this issue.
If you're still running into this issue with Homestead, let us know and we can look at re-opening.