Upgrade from 1.2.1 > 1.2.5

[samcoppock]

I have tried upgrading from v 1.2.1 > 1.2.5

I have done it simply with composer update

and also done it by getting a copy of 1.2.5 and copying over all files which were changed between the versions ( since composer only updates vendor files ) and then running composer update

in both cases when i try and run artisan cache:clear or look at the website i get this

"Class "XXX\YYY\Classes\ServiceProvider" not found"

Where XXX is the author name we use and YYY is one of the plugin folders

I have tried composer dump-autoload

"XXX\YYY\Classes\ServiceProvider" is defined in config/app.php providers array

[LukeTowers]

@samcoppock why do you have the custom service provider defined in the config/app.php providers array? Can you share it here?

[samcoppock]

I dont know why it is defined in app.php - a different developer did it

it looks like this
( i have preserved case when using the XXX and YYY masks - remember XXX is out author name and YYY is one of our custom plugin names )

'providers' => array_merge(include(base_path('modules/system/providers.php')), [

    // 'Illuminate\Html\HtmlServiceProvider', // Example

    Xxx\Yyy\Classes\ServiceProvider::class,
    Barryvdh\Debugbar\ServiceProvider::class,
    'System\ServiceProvider',
    KitLoong\MigrationsGenerator\MigrationsGeneratorServiceProvider::class,
    MargaTampu\LaravelTeamsLogging\LoggerServiceProvider::class,
    Illuminate\Notifications\NotificationServiceProvider::class,
    NotificationChannels\MicrosoftTeams\MicrosoftTeamsServiceProvider::class,
    Maatwebsite\Excel\ExcelServiceProvider::class
]),

[LukeTowers]

None of those should be present, plugins should have been used to dynamically include them instead. For the last one, Winter.Excel can be used, for the debugbar Winter.DebugBar can be used.

For the other ones I would highly recommend moving them into their own plugins.

Why does your plugin even have a custom ServiceProvider? Plugin.php is already a ServiceProvider, there should be no reason to have a separate one.

The reason that your code is no longer working is because plugins are not added to the class autoloader until the call to loadPlugin() (https://github.com/wintercms/winter/blob/develop/modules/system/classes/PluginManager.php#L153), which means at the point in time that the providers are being loaded from app.php the class cannot be found.

The best way to solve this for you right now is to get rid of your service provider entirely and just move its contents into your Plugin.php, and the hackiest way to solve this is to add a require_once('plugins/Xxx/Yyy/Classes/ServiceProvider'); to the top of your app.php config file - but please do not do that.

[samcoppock]

Thanks for that

I dont know why all those dependancies were in app.php because a different developer put most of them there.
The project started out as a October version 1 with Laravel 6 so maybe that had something to do with it ( i believe there was no package auto discovery in Laravel 6 could that be the reason )

anyway there is a second problem.

I tried removing "Xxx\Yyy\Classes\ServiceProvider::class" from app.php ( only that one as its the only one that references one of our custom plugins ) and we got a new error

"Class XXX\YYY\Traits\SitemapEventListeners not found"

( Where XXX and YYY are out author name and custom plugin name respectively. )

the file that refers to is in the "plugins\xxx\yyy\Traits" directory
its file name is "SitemapEventListeners.php"
its namespace is "Xxx\Yyy\Traits"

The particular file is NOT referanced in app.php

Do you know of any framework based reason why this would be happening?

[LukeTowers]

Why is it saying "class not found" about a trait? Sounds like there's some coding errors in your project, if you'd like to schedule a call with me where I can help you go through the errors you're seeing and solve them; then just shoot me an email or a message on discord and we can get that done.