You don't need a license code AT ALL, if you're just installing Backpack on localhost. Just go ahead and install Backpack, you'll have zero limitations until you go to production.
Yes, you do need a license code. But not a separate license code. If you've already purchased a license code, you should use the same code for both your staging and production instances - even if the domains are different.
If you're interested in a license code to test your project online, before you purchase a Backpack license - take note that we don't do that. We do not issue licenses for testing an already built app on a staging domain. If you've reached a point where you put your project on a staging server, that should mean Backpack has already helped you or your company save dozens or hundreds of hours of work - so that qualifies as commercial use. We recommend you purchase a license code - you can use the same license code on both your staging and production domain.
An alternative to be able to test a project online, without paying anything, would be to put your project online and bear the annoying notification bubbles. If you don't mind the notification bubbles, you can get a general idea of what's working and what's not. It's not ideal, but it's free.
No, you do not. But there's a huge catch.
Because Backpack requires a license code to work in production, all users of your open-source project will require a Backpack license code for their apps to work in production. So yes, your project will be open-source, but developers will need to pay for a Backpack license if their project is commercial, or apply for a free non-commercial license on our website. This makes it a bit inconvenient to use Backpack for open-source work, we know that.
To rephrase and clarify - you don't need a license code to develop an open-source project that uses Backpack. But your users will. And no, if you purchase a Backpack license, your open-source users are not covered by your license, only you are. Even if you do have a Backpack license code, that is for you alone, and you should never ever make that code public, or share it with anybody outside your company.
We plan to address this inconvenience in Backpack v5, by having a "Backpack Lite" package under MIT License, with limited features. Then you could easily build things on top of that, instead of the main Backpack package. But until then, I'm afraid the problem remains - and the only solution is to clearly state in your README file that your package is open-source, but one of your dependencies requires payment for commercial use. Feel free to email [email protected] with details about your project, for more information.
There are two places where you can put your Backpack license code:
config/backpack/base.php, at the bottom, you'll find
'license_code' => env('BACKPACK_LICENSE', false)- you can replace
falsewith your license code (wrapped by single quotes)
Option (A) is the recommended one, because there's no point in saving the license code within the code base (in git), and exposing it to whoever has access to the source code. The Backpack license code is only needed in production, so the best way is to add an environment variable there, in on your production server.
First of all, run
composer update on your project. That will pull in the latest supported version of all your Backpack packages.
Then you should re-publish the JS and CSS assets. There are two ways to do that:
php artisan vendor:publish --provider="Backpack\CRUD\BackpackServiceProvider" --tag=public --force. Please note this will overwrite anything that's already there. This B solution has a downside: unused files are not removed. A few files Backpack no longer uses will still be in your public/packages folder, even though they're no longer used.
(B) If you have NOT touched you
public/packages folder, or placed anything custom inside it:
php artisan vendor:publish --provider="Backpack\CRUD\BackpackServiceProvider" --tag=public
php artisan backpack:filemanager:install
You can remove Backpack from your project pretty easily, if you decide to stop using it. You just have to do the opposite of the installation process:
# delete the files Backpack has placed inside your application rm -rf app/Http/Middleware/CheckIfAdmin.php rm -rf config/backpack rm -rf config/gravatar.php rm -rf public/packages rm -rf resources/views/errors rm -rf resources/views/vendor/backpack rm -rf routes/backpack # delete any CrudControllers you've created, so MAYBE: rm -rf app/Http/Controllers/Admin # delete any Requests you've created for your CrudControllers. # MAKE SURE YOU DON'T NEED ANYTHING IN THIS DIRECTORY ANYMORE. # You might have OTHER requests that are not Backpack-related. rm -rf app/Http/Requests # (maybe) remove other Backpack dev tools you've used composer remove --dev laracasts/generators # remove Backpack from your composer.json requirements composer remove --dev backpack/generators composer remove backpack/crud
That's it! If you've decided NOT to use Backpack, we'd be super-grateful if you could send us an email telling us WHY you didn't like Backpack, or it didn't fit your project. It might help us take Backpack in a different direction, one where you might want to use it. Thank you 🙏
Then you'll love our premium add-ons - productivity tools and tons of new features.