So I just took over a laravel 5.2 based project with some dependency hell.
The backend is build on a smarch/watchtower package which has been abandoned and laravel 5.3 is the highest version it supports.
tsawler/laravel-filemanager is one more abandoned package.
Now I would like to update the whole project to the latest version of laravel to enjoy the new features, bug fixes and security patches and add the possibility to use other packages.
What are the best practices in such a situation?
Should I go with hijacking the abandoned packages one at a time and update them,
find similar packages with strong community support and replace the abandoned ones,
build the whole project from the start on a fresh copy of laravel 6
or accept the truth and continue on the old version?
any other suggestions?
Links to abandoned packages:
smarch/watchtower
tsawler/laravel-filemanager
Typically, I use packages from vendors that I know will be kept updated (such as Spatie packages). In place of Watchtower, you could use [laravel-permission] https://github.com/spatie/laravel-permission. However, tsawler/laravel-filemanager did install on Laravel v6.x. Though it says use https://github.com/UniSharp/laravel-filemanager so I'd install that instead.
From there you can upgrade from 5.2 to 6.x yourself or have a service like Laravel Shift do it for you. I create a new laravel instance and diff the directories to see what files changed. Also, make sure you read the upgrade guide: https://laravel.com/docs/6.x/upgrade. This might help as well: https://laracasts.com/discuss/channels/laravel/laravel-52-to-6?page=1
Related
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.
Does composer provide a way to update the package a project was created with? i.e., if I create a new laravel project with the following
composer create-project --prefer-dist laravel/laravel blog
Composer will grab the latest version of the laravel/laravel package, unarchive it into the blog folder, and then run composer install from the blog folder.
What I want/need to know is, does composer provide a way for me to update the laravel/laravel package that was downloaded to the blog folder? I know I could run composer update inside the blog folder myself, but this will only update things listed in the compser.json's require property — it will not update the unarchived laravel/laravel in blog (or will it?)
As far as I know it's not really possible.
Imagine that you create a new as example Laravel project.
The composer create-project creates the skeleton with all initial routes in your configuration etc.
From the very very first moment you are starting to change the default routes, removing the default controllers and changing the default views, your project would be out of sync. because meanwhile laravel changes the skeleton to newer versions with some new default routes etc or event changes directory structure.
It would be really hard to merge those changes over your existing application.
A better solution would be to follow the "Upgrade guides" (laravel: https://laravel.com/docs/5.4/upgrade) and then just commit those changes to your own project.
If you want to upgrade to a new laravel version, you can always follow the upgrade guide for your specific version:
Laravel 5.8 to 6.0
Laravel 5.7 to 5.8
Laravel 5.6 to 5.7
Laravel 5.5 to 5.6
If you are more than one version behind, you need to apply the previous upgrade guide. So if you are on 5.6 and want to upgrade to 5.8, you need to follow the guide for 5.6 to 5.7 and then from 5.7 to 5.8.
The guides are pretty helpful: they tell you which package must be updated to what version and inform you about deprecated methods which will be removed in the upcoming versions.
Another method which you can use to upgrade to new minor versions is to just look at the differences from one laravel release to the next. That way, you can see what exactly has changed and which files are new (configuration files for example which you can copy and paste into your project as the default composer create-project command would do).
As for the current version, you can see the commits since last release here: v5.8.30 to 5.8
Directly under the headline for a release, there is a small link labelled "36 commits to 5.8 since this release" which will take you to the link above, just for the latest version.
That's not the goal of composer, that just manage your packages.
You should see composer create-project just as a shortcut of git clone + composer install. If you need to deploy your application you've multiple options, from a simple git pull, to more advanced deployment tools like Capistrano. But composer isn't one of these tools.
I just needed to do this, and I couldn't find anything simpler than a git clone and a git pull (as #Federkun). Maybe an alternative would be to publish a phar file for the project and download that?
I can see db-ping does this. It's based on joomla/using phar. Here is the main file for building, inspired from joomla's file.
I'm building an SDK for developers to use to build modules for ecommerce platforms that will consume our API for a new startup.
Obviously it would be ideal to use composer, which I am doing right now. But as I examine most of the ecommerce platforms out there right now, or at least the most popular ones, they don't use composer.
So I'm wondering what's the best way to get all the dependencies all my current packages need and build them into a freestanding SDK.
This way I can have a version that will work for both composer and non-composer enabled platforms.
Is there a standardized way to do this in terms of a design pattern? How would I lay out all the dependency packages in any organized way?
Because those e-commerce platforms don't use composer, that doesn't force you to exclude composer from equation. You can't distribute your package as a plugin/module/whatever for that particular e-commerce platform, but you can still use composer's autoloader in production.
You could prepare the package for deployment on your machine or on a build server, archive the result and distribute the archive.
For the sake of simplicity, my example will assume that you will prepare your package on your local machine:
Create a temporary working directory:
$ mkdir -p ~/.tmp && cd ~/.tmp
Clone your package:
$ git clone <package>
Install dependencies1
$ cd ~/.tmp/<package> && composer.phar install --no-dev --optimize-autoloader
or if you do this from an automated tool:
$ cd ~/.tmp/<package> && composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader
Remove .git directory.
Create the zip/tar archive from ~/.tmp/<package>
Distribute the archive.
Assuming that your package is already a plugin/module for that e-commerce platform, it can be installed as usual from that zip/tar archive.
1) Regarding --optimize-autoloader, please read this answer from Sven, which explains why in some cases doesn't help your application to become faster.
Don't have dependencies!
Yes, seriously. If you'd develop an API client that would use Guzzle as the HTTP client, you'd have to make a choice: Use Guzzle version 3, 4, 5 or 6?
Guzzle 3 is out of maintenance and abandoned. You wouldn't want to use it.
Guzzle 4 is also considered end-of-life, because version 5 came very fast. Nobody really use this version.
This boils down to using either version 5 or 6. But Guzzle is using the same namespace and likely the same class names in both versions, but is incompatible to each other. No matter which version you choose: Your customer will have made the opposite choice - and now you have a codebase where two versions of Guzzle are running at the same time - this will not work.
If you don't have dependencies, but deliver everything within your own codebase, you have all of your code under your control, and are reducing the need to use Composer as a tool to easily install all your dependencies. Your package will have everything already included, it's unlikely that there will be any namespace conflicts.
You'd be able to offer a ZIP file for download. And if you additionally offer a composer.json to allow developers to include your package that way, everyone will be happy.
Update
Now after finding out that everyone thinks I am crazy proposing not to use stuff invented elsewhere, I challenge you to think about the situation once again: You find that you have to produce code that will likely be included in a codebase that is NOT managed with Composer. That means you have no idea what kind of software is put together there.
It may simply be so that you have a version of Guzzle in the existing codebase - undetectable, because there is no composer.json. Now you provide your own package with a bundled Guzzle version (whatever way made it appear there). This will likely crash the entire software at some point because of conflicts, because the autoloading will of course be merged at some point, and then some part of the code will request some Guzzle class to be loaded, which is included twice from two different versions of Guzzle.
WHAT SHOULD HAPPEN IN THIS CASE? THINGS WILL CRASH!
And it is unavoidable that this will happen. Even in the lucky case of being able to use Composer, it will conflict - the software won't crash, but the entire package won't be installed. The good thing is: You will notice this immediately.
If the primary goal is to deliver an API client anyone can use in every situation, without using a dependency manager: Don't have dependencies!
Alternatively, be completely sure that you know which software is already being used, and create a package that will not conflict in any case. However, this is still an effort, because there might be other addons also being installed, which might include conflicting software.
My central point is: If you don't have a dependency manager like Composer being able to manage the dependencies, you are better off NOT to have dependencies in your own code to make it super easy to include your own code in someone else code base.
And the question above clearly states that Composer is not an option in the general case.
Now there is one light at the end of the tunnel: When it comes to general tasks, the PHP-FIG has started to standardize interfaces that should leverage interoperability. For HTTP, the standard is PSR-7.
You COULD provide an API SDK that depends (and brings with it) the PSR-7 interface and requires the user of the SDK to provide a HTTP client that implements this interface.
The problem with this approach I see is that you will still run into trouble if you try to use for example Guzzle for the same reason: The only valid choice now is to use Guzzle 6 for the SDK - what if Guzzle 5 was already used elsewhere? Conflict! The good thing is: You can avoid using Guzzle 6 if you are already using Guzzle 5 by using any other PSR-7 capable HTTP client.
I'm writing an app using Laravel 4.2. This time, I needed some extra functionality and I decided to create a package. I used the workbench functionality as described in Laravel's docs.
Currently (and locally), the package is very small but it suits my app very well. I don't think this should be published to the community because it is still very green. I'll put a few hours into it when I finish with my app but I can't right now.
Now, I know the workbench/ directory is not to be pushed to production. Then, how do I use my package on production?
So far, I heard I have to push the package to GitHub (which I already did), and then publish it on Packagist. But I feel that publishing the script as is won't be helpful to others and might as well harm those in search of this functionality (like me a few days ago) on this so under developed package.
Is there a way to add my package to my app's composer.json and have it installed without publishing it to the community while it's under development?
What you are looking for is "private repository". Inside your composer.json file you can define an object repositories where you can define other locations to search for this repository
Detailed explanation can be found on Autoload bitbucket repository. The same principal is true for github.
I am trying to update my project written in Symfony 2.0 into Symfony 2.2.
Moving source codes into 2.2 project ended with config.yml and security.yml incompatibiliy.
Is there way how to properly migrate Symfony 2.0 project into Symfony 2.2?
It better to wait until Symfony 2.3 before migrating. It will be released somewhere in May. It's the first LTS (Long Time Support) release, meaning that it's maintained for three years. So: You don't have to worry about BC breaks for 3 years!
For the migrating of Symfony 2.0 to 2.3: There is nothing you can do. Read the UPGRADE-*.md files (which are stored in the root of the symfony/symfony package) and fix anything that is in their in your code. Every BC break that's important for normal users will be put in those UPGRADE files.
If you can't solve it after the fixing everything in the UPGRADE files, you should take a look at the CHANGELOG.md files in the root of the package (e.g. the symfony/security package). Try to find something that is changed and cause your code to break.
Finally, if you don't get your script working, there are a lot of active Symfony2 users who are waiting to help you. Take a look at the community page and find your place to ask questions.