I am receiving the following error when using paginate with Eloquent:
Argument 2 passed to Illuminate\Pagination\Factory::__construct() must be an instance of Illuminate\View\Factory, instance of Illuminate\View\Environment given, called in C:\****\vendor\laravel\framework\src\Illuminate\Pagination\PaginationServiceProvider.php on line 23 and defined
For testing purposes, this is all I have in the method of my controller:
return User::paginate(15);
I'm aware about the upgrade procedure from the docs, but I don't have any of the references mentioned there.
Update:
In my specific case there was a package in the workbench which was requiring Illuminate 4.1 components, I changed to 4.2 in composer.json, removed the vendor dir and composer.lock file, did a composer install, and the error is gone.
These operations were all done within the package folder.
Posted as a comment, but it was the right answer:
Is there any chance you are only requiring some of the Laravel components, and not the entire Laravel framework? If you are only working with some then things like this can get out of whack, especially if not all of your components are updated to 4.2.
I encountered the same issue as you when I updated from 4.1 to 4.2, which in my case I did a composer update on my development environment before pushing and did a pull from my staging. Now the pagination issue doesn't exist in my development but in my staging, so I figured it might be the issue with git pull missed some files, or cache in the views. So I did remove the entire project and do a clean clone from the repository, that seems to fix the problem.
So not fully sure on how you update, but you might want to check that your updated files has been fully applied.
I also ran into this same problem when upgrading from 4.1 to 4.2, but my fix was different to Phil Sturgeon's.
I simply had to remove the bootstrap/compiled.php file located in the root of the Laravel project.
Related
The Laravel Sanctum documentation states that to add Sanctum to existing Laravel project one has to:
Require Laravel Sanctum composer require laravel/sanctum
Publish Sanctum's resources to app dir php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"
I'm getting Unable to locate publishable resources. when running (2)
I already tried php artisan clear-compiled and composer dumpautoload in that order
I checked that vendor/laravel/sanctum/src/SanctumServiceProvider.php exists and the boot() method does publishes Sanctum's config and migration
I also checked that SanctumServiceProvider is discovered by autoload by making sure that the source path is listed in autoload_classmap.php
Again, this was an attempt to add Sanctum to an existing Laravel project
Did I miss something?
My setup:
Laravel 8.37
PHP 7.3.9
Composer 2.0.12
I have managed to solve my problem.
Short answer:
After composer require laravel/sanctum do this:
Backup or rename cache/services.php
Remove cache/services.php
Run php artisan. Seems that running artisan in any way will regenerate cache/services.php
After that, continue with the official documentation (publish, migrate, and so on)
Longer explaination
Not entirely sure what is going on. But apparently all discovered service provider is cached in cache/services.php.
I don't know how it's being generated and how service providers get discovered. Googling doesn't yield me any documentation regarding that file (official or otherwise).
I figured I if I add Sanctum's SP to config/app.php (i.e. the documented way of adding service provider) it will get discovered and cached. Apparently that wasn't the case. Removing and regenrating cache/services.php is the only way I found working. After the file was regenerated, Sanctum's SP is listed.
One thing I observe was that this only happens on an existing project (existing as in already being worked on, packages added, config changes and so on). Doesn't happen if I add Sanctum to a fresh project.
I followed instructions from an answer of a similar topic(https://stackoverflow.com/a/17531897/4388482). Well, my app is getting deployed on Heroku but it doesn't work good. I'm getting the following warning
Your project only contains an 'index.php', no 'composer.json'.
Using 'index.php' to declare app type as PHP is deprecated and may lead to unexpected behavior.
Do I need to install something maybe?
UPDATE
Project structure was initially this:
I did the following:
Installed PHP 5 and composer.
I renamed package.json to composer.json and removed package-lock.json.
Typed "composer update" command. I got "nothing to install or update" message.
Added vendor to gitignore. Pushed changes to heroku.
I got the following warnings
Your 'composer.lock' is out of date!
Composer vendor dir found in project!
The complaint that Heroku has is regarding this folder.
For the record, the contents of this folder presently are:
bootstrap
fontawesome-free
jquery-easing
jquery
What has happened here is that someone has committed dependencies to your version control, which is not good practice. It will work as is, but it is not very easy to do upgrades, especially since you cannot easily see what versions you currently do have.
There are three ways to go about this.
Decide if these are PHP dependencies, by searching Packagist. There is a Composer dependency for Bootstrap, but you would need to see if the version you are using is available (or whether you can upgrade to one that is available).
Decide if these are JavaScript dependencies, by searching NPM. I wonder if it is worth examining the contents of your package.json in case these are already covered. For what it is worth, I would generally consider these candidates for JavaScript libraries rather than PHP, but do what works for you.
Choose to leave these dependencies committed in the existing vendor folder. It will work, but it is not ideal for the reasons already stated.
In the last two cases, you could probably get away with a composer.json file thus, which you should commit to the repo:
{
"require": {
}
}
You could try a composer install after this, to see if it will generate a .lock file on an empty dependency list. If this does generate, then you should commit this also.
I have to update CakePHP from current, outdated version (2.7.7) to latest on 2 branch, because of PHP7 support.
While I've done numerous framework upgrades before, I found book.cakephp.org a more than a cryptic about key things which I ask here:
can it be done by replacing directoris
which directories are intended to be replaced (never edit dirs, like system in Codeigniter)
which directories are partially replaced if any
is there SQL commands that should be run?
is there other commands that should be run?
Any clue is appreciated, but 2 and 3 are of most value I guess. Thanks in advance.
Depending on how you've installed CakePHP, you either use composer to update the CakePHP core dependency:
$ composer update
or require a specific constraint/version if your current constraint doesn't allow upgrading:
$ composer require cakephp/cakephp:^2.10.3
If you're not using composer (I'd suggest to switch to using it), then you download the latest release package manually, and completely replace the /lib/Cake directory. With respect to the core, the upgrade is then complete.
Then read the migration guides to figure the possible changes that you have to apply to your application code or database schemas, and also compare the "application template" changes (/app/) to your local application and apply changes in case necessary. After this, run your test suite to ensure that everything works as expected.
With that being said, the upgrade from 2.7 to the latest 2.10 should be pretty easy, as it is said to be fully API compatible.
I recommend you to use composer to manage your framework and extensions.
With composer installed, it would be much easier to update. If you decide to use composer, let me know if you need any more help by installation, setup or update.
I don't know if this is a Symfony issue or a FOSUserBundle issue so I'll report here and hope get some help. I have two development instances:
CentOS 6.5, PHP 5.5.16, MySQL 5.5.37
CentOS 7, PHP 5.6.0, MariaDB 5.5.37
I tried the same project in both instances and by same project I mean the same: copied without any vendor and in both instances run "composer update" at first. After composer updates the vendor I tried to access admin area, which is handled by, FOSUserBundle and surprise in the first instance it works without any problem but in the second one it does not work and I get this error:
Error! Warning: Erroneous data format for unserializing
'Tanane\UserBundle\Entity\User' in
/var/www/html/tanane/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php
line 872
Can any give me some advice around this? Is a Symfony bug or a FOSUserBundle bug? Or it's other thing and I don't see it?
Yes, this is a known problem, though it's not in FOSUserBundle. This problem is caused by Doctrine 2, the deserialization is broken there on creating a ClassMetadataInfo.
However, fixing this problem involves introducing some incompatibilities in Doctrine's architecture, so this won't be fixed until Doctrine 2.5 release at least.
Currently, the options are to switch back to PHP 5.5 or less or use a master version of Doctrine (the pull request fixing this does not seem to be tagged yet)
See this Doctrine Jira ticket for more info.
When executing
php artisan workbench user/asset
additional dependency(module) placed to
workbench/user/asset/vendor/illuminate/support.
Then framework autoload this module(illuminate/support) from workbench/user/asset/vendor/*, but i think it must load it from /vendor/laravel/framework/src/Illuminate/
So we have confusion here - some classes are loaded from framework(vendor/laravel/*) and some classes are loaded from workbench/[vendor]/[module]. Is that supposed to work that way? Or is it a bug?
Yes and No.
During development of your package it will work that way, because the whole structure is inside /workbench. It also helps you working in different versions of packages, develop using Laravel 4.1 while your app is still on 4.0.
After you finish working on your package, it's better to create a real Composer package. You can create a private one and then, yeah, once you install it via Composer it will be placed in /vendor.