-1

this is very weird. I've successfully created an index on my local server and it showed up in Algolia dashbord.

However, when I ran php artisan scout:import 'App\MyModel' on my staging server I get:

Imported [App\MyModel] models up to ID: 22
All [App\MyModel] records have been imported.

but the index doesn't show up in Algolia dashboard.

I've compared my .env files and these fields are the same on both of my apps:

SCOUT_DRIVER=algolia
SCOUT_PREFIX=staging_ //this one is "development_" on my local server 
ALGOLIA_APP_ID=aaaaa
ALGOLIA_MONITORING_KEY=bbbbb
ALGOLIA_SEARCH=ccccc
ALGOLIA_SECRET=ddddd

my config/scout.php

'driver' => env('SCOUT_DRIVER', 'algolia'),
'prefix' => env('SCOUT_PREFIX', ''),
'queue' => true,
'algolia' => [
    'id' => env('ALGOLIA_APP_ID', ''),
    'secret' => env('ALGOLIA_SECRET', ''),
],

and here is my config/algolia.php

'default' => 'main',
'connections' => [

    'main' => [
        'id' => env('ALGOLIA_APP_ID'),
        'key' => env('ALGOLIA_SECRET'),
    ],
    'alternative' => [
        'id' => 'your-application-id',
        'key' => 'your-api-key',
    ],

],

Any help is appreciated. Thanks!

UPDATE

It seems that index file my_models.index in the storage folder gets updated when I run php artisan scout:import 'App\MyModel'

I believe this is a leftover from using TNTSearch before Algolia but I can't figure out why is my app using TNTSearch and not Algolia one on my staging server.

I concluded this because when I run php artisan scout:import 'App\MyModel' this index file gets updated on my staging server but not on my local machine.

UPDATE #2

ssh into server, inside of php artisan tinker I get algolia if I run env('SCOUT_DRIVER') or config('scout.driver').

UPDATE #3

Tried the php artisan config:clear and cache:clear but I still get new my_model.index file after I run the scout:import on my model. Even after I've deleted all mention of TNT from .env, composer.json and AppServiceProvider.php.

deceze
  • 510,633
  • 85
  • 743
  • 889
dbr
  • 1,037
  • 14
  • 34
  • OK, this is a bit of an awkward situation, but probably the best course of action: we don't want "[solved]" in the question, there is an answer, and the problem is hence not really reproducible, but this whole thing may still help somebody in the future… I've undeleted your "answer" so you can accept it, rolled back your question edit and closed it too. You can now accept your answer to put this to rest. – deceze Jan 25 '17 at 15:58
  • I know this sounds like a silly mistake but I think that something went wrong (probably a feature, not a bug thing) with caching on my server. I don't think this should be deleted. I lost a day trying to figure it out and only restarted the server out of despair. This is not Windows XP and restarting a server after installing a new PHP library shouldn't be (and isn't) something you're expected to do. Right thing to do would be to find out why this happened but sadly I don't have the time nor the expertise to do it. – dbr Jan 25 '17 at 16:10
  • Well, if you can ever expand this answer to something more in-depth, I'd agree that it's a worthwhile problem with a solution. As such… "restarting it" should be one of the default troubleshooting steps methinks. Anyway, this question won't be deleted, it'll just stay closed until further notice. – deceze Jan 25 '17 at 16:13
  • Hm, ok I wont be lazy and will sent the email to Laravel and DigitalOcean. Hope something comes up from it. – dbr Jan 25 '17 at 16:18

1 Answers1

2

Restarting the server fixed it!

dbr
  • 1,037
  • 14
  • 34