Undefined array key 1 related to PageRoutesService

[raheelms]

i am getting this error when trying to clear config, route etc. i don't know how to solve it. Anyone got any ideas?

at vendor\z3d0x\filament-fabricator\src\Services\PageRoutesService.php:87
   83▕     public function removeUrlsOf(Page $page): void
   84▕     {
   85▕         // First remove the entries from the (ID -> URI) mapping
   86▕         $idToUrlsMapping = $this->getIdToUrisMapping();
➜  87▕         $urls = $idToUrlsMapping[$page->id];
   88▕         $idToUrlsMapping[$page->id] = null;
   89▕         unset($idToUrlsMapping[$page->id]);
   90▕         $this->replaceIdToUriMapping($idToUrlsMapping);
   91▕

1   vendor\z3d0x\filament-fabricator\src\Services\PageRoutesService.php:87
    Illuminate\Foundation\Bootstrap\HandleExceptions::Illuminate\Foundation\Bootstrap\{closure}("Undefined array key 1", "C:\xampp\htdocs\nextxlfabricator\vendor\z3d0x\filament-fabricator\src\Services\PageRoutesService.php")

2   vendor\z3d0x\filament-fabricator\src\Commands\ClearRoutesCacheCommand.php:47
    Z3d0X\FilamentFabricator\Services\PageRoutesService::removeUrlsOf(Object(Z3d0X\FilamentFabricator\Models\Page))```

I did composer update. After this I started getting this error after config:clear or route:clear. And the fabricator pages were giving a 404.

[Voltra]

Could you please provide the following details so I can debug this more easily without resorting to a hacky fix?

• The values in your project's config/filament-fabricator.php file
• The result of executing the following code via php artisan tinker in your project:

// Each ">" indicates a new line prompt
/*>*/ Cache::get('filament-fabricator::PageRoutesService::id-to-uri')
/*>*/ Page::pluck('id')->toArray()

[raheelms]

this is config/filament-fabricator.php

// config for Z3d0X/FilamentFabricator
return [
    'routing' => [
        'enabled' => true,
        'prefix' => null, //    /pages
    ],

    'layouts' => [
        'namespace' => 'App\\Filament\\Fabricator\\Layouts',
        'path' => app_path('Filament/Fabricator/Layouts'),
        'register' => [
            //
        ],
    ],

    'page-blocks' => [
        'namespace' => 'App\\Filament\\Fabricator\\PageBlocks',
        'path' => app_path('Filament/Fabricator/PageBlocks'),
        'register' => [
            //
        ],
    ],

    'middleware' => [
        \Illuminate\Cookie\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        // \Illuminate\Session\Middleware\AuthenticateSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \Illuminate\Foundation\Http\Middleware\VerifyCsrfToken::class,
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
    ],

    'page-model' => \Z3d0X\FilamentFabricator\Models\Page::class,

    'page-resource' => \Z3d0X\FilamentFabricator\Resources\PageResource::class,

    'enable-view-page' => false,

    /*
     * This is the name of the table that will be created by the migration and
     * used by the above page-model shipped with this package.
     */
    'table_name' => 'pages',
];

[raheelms]

Could you please provide the following details so I can debug this more easily without resorting to a hacky fix?

• The values in your project's config/filament-fabricator.php file
• The result of executing the following code via php artisan tinker in your project:

// Each ">" indicates a new line prompt
/*>*/ Cache::get('filament-fabricator::PageRoutesService::id-to-uri')
/*>*/ Page::pluck('id')->toArray()

Psy Shell v0.12.7 (PHP 8.2.12 — cli) by Justin Hileman
> Cache::get('filament-fabricator::PageRoutesService::id-to-uri')
= []

> Page::pluck('id')->toArray()
[!] Aliasing 'Page' to 'App\Livewire\Pages\Page' for this Tinker session.

   BadMethodCallException  Method App\Livewire\Pages\Page::pluck does not exist.

> Page::pluck('id')->toArray()

   BadMethodCallException  Method App\Livewire\Pages\Page::pluck does not exist.

>```

[raheelms]

u can send me a message

[Voltra]

My apologies, you might need to use the Fully Qualified Name of your Page model class instead of just Page (to disambiguate)

i.e.

\Z3d0X\FilamentFabricator\Models\Page::pluck('id')->toArray()

[raheelms]

> Cache::get('filament-fabricator::PageRoutesService::id-to-uri')
= [
    6 => [
      "/",
    ],
  ]

> \Z3d0X\FilamentFabricator\Models\Page::pluck('id')->toArray()
= [
    6,
  ]

>

before i deleted the table cache to solve the issue temporarily

[raheelms]

So what is the solution?

[Voltra]

That is very odd, according to the data you provided there's nothing that would cause a read for index 1 in $idToUrlsMapping.

By

before i deleted the table cache to solve the issue temporarily

Did you mean to say that you got that data before deleting the cache table, or that you deleted the cache table before getting that data?

[raheelms]

That is very odd, according to the data you provided there's nothing that would cause a read for index 1 in $idToUrlsMapping.

By

before i deleted the table cache to solve the issue temporarily

Did you mean to say that you got that data before deleting the cache table, or that you deleted the cache table before getting that data?

I deleted the data from the table and then did that query. So there is a problem.

[Voltra]

Undoubtedly. Given that the index comes from $page->id, unless you have a soft delete system (or something similar with a global scope) then there shouldn't be an access to the key 1 which doesn't exist.

Can you provide a minimal reproducible repo with the issue? Or even just a set of steps to get to trigger the issue. So far I haven't managed to manifest it in my experimenting.

[raheelms]

Undoubtedly. Given that the index comes from $page->id, unless you have a soft delete system (or something similar with a global scope) then there shouldn't be an access to the key 1 which doesn't exist.

Can you provide a minimal reproducible repo with the issue? Or even just a set of steps to get to trigger the issue. So far I haven't managed to manifest it in my experimenting.

I can add you to the repo. But I would need your email?

[Voltra]

If it's on github I'm pretty sure you can add by username. That being said, a repo that isn't minimal will always be tricky to find the actual underlying cause instead of a side effect of using another package in conjunction

[Voltra]

@rezadindar Do you have more info on the issue/repro?

[raheelms]

@rezadindar Do you have more info on the issue/repro?

Z3d0X\FilamentFabricator\PageBlocks\PageBlock::preloadRelatedData(): Argument #1 ($page) must be of type Z3d0X\FilamentFabricator\Models\Contracts\Page, null given, called in C:\xampp\htdocs\nextxlfabricator\storage\framework\views\7bc23af4b28fbaa47e8a0267dacb0daa.php on line 45

[raheelms]

[Voltra]

That shouldn't be possible unless page blocks are embedded elsewhere as they always have access to the page within the context of filament-fabricator.

[Voltra]

With the repository you've provided me, I ran some tests. Here is the protocol I followed.

1. Setup the repository
2. Install the packages
3. Remove the ./vendor/ directory and the composer.lock file
4. Pin the version of filament-fabricator to ~2.3.0 (which is the release right before the new routing system was merged)
5. Installed the packages
6. Create a few pages via php artisan tinker
7. Delete the very first page
8. Delete another random page (all that to simulate a pre-existing state for the database)
9. Install filament-fabricator at ^2.4.0 (to bring in the new routing system)
10. Run php artisan optimize
11. Run php artisan optimize:clear

Following this protocol I did not encounter the error. This is getting a bit confusing ^^

[Voltra]

I think I see what might be going on for your repository.

In your routes/web.php you have the following:

// Below is your own custom Page "wrapper" class
Route::get('/{page:slug}', Page::class)->name('page.show');

But in the config for filament-fabricator you still have it unprefixed:

return [
    'routing' => [
        'enabled' => true,
        'prefix' => null, // <--- Here
    ],
];

As such, there might be a conflict in which routing is used and you're likely to be bypassing the package's routing system.

[Voltra]

OK, so I seem to have found a way to reproduce it on a personal repo.

I have a theory and I'm looking into it. I'll keep you guys up to date!

[Voltra]

It seems that somewhere in php artisan optimize (not even php artisan optimize:clear) the cache gets corrupted somehow.

It's set to an empty array instead of being null. I've checked, it's not an issue from the getIdToUrisMapping method as the cache is already messed up there.

I'm going up the trail to find out what messes up the cache

[raheelms]

Let me know if you need any more information. Very weird what is happening.

[Voltra]

Found the bug! The fact that it was an array access should have been a clue, but the way it's triggered doesn't help in making it obvious. I've made the hotfix PR that will fix that issue!

[raheelms]

Found the bug! The fact that it was an array access should have been a clue, but the way it's triggered doesn't help in making it obvious. I've made the hotfix PR that will fix that issue!

How do I solve this? Or I have to wait for a package update?

[Voltra]

You just have to wait for the next release :p

[raheelms]

You just have to wait for the next release :p

When is the next release? But the problem lays whitin fabricator package?

[Voltra]

It should be soon enough, and yes

[raheelms]

I hope it gets released soon because I have to finish my project.

[Z3d0X]

Fix for this released in version v2.4.1

[raheelms]

i am getting this

Class "Z3d0X\FilamentFabricator\View\ResourceSchemaSlot" not found

and this error still is there after composer update

Z3d0X\FilamentFabricator\PageBlocks\PageBlock::preloadRelatedData(): Argument #1 ($page) must be of type Z3d0X\FilamentFabricator\Models\Contracts\Page, null given, called in C:\xampp\htdocs\nextxlfabricator\storage\framework\views\7bc23af4b28fbaa47e8a0267dacb0daa.php on line 45

[Voltra]

@raheelms

For ResourceSchemaSlot, #206 has been merged

Your issue with preloadRelatedData is unrelated to this issue, and I suspect the problem comes from the usage as that method is used in a context where the view is @aware of the page being rendered. There's also the fact that I use that "hook" on my personal project and it works just fine.