October: Move to Laravel 6

Created on 12 Jun 2019 · 117Comments · Source: octobercms/october

https://www.bountysource.com/issues/75392602-move-to-laravel-6

Laravel 6 has been released and is a LTS release (https://laravel.com/docs/6.x/releases#laravel-6). As such, October should look at moving from 5.5 to 6. This issue will contain discussions relevant to that change and related issues.

Upgrade Guides:

[x] 5.5 -> 5.6: https://laravel.com/docs/5.6/upgrade
[x] 5.6 -> 5.7: https://laravel.com/docs/5.7/upgrade
[x] 5.7 -> 5.8: https://laravel.com/docs/5.8/upgrade
[x] 5.8 -> 6.x: https://laravel.com/docs/6.x/upgrade

Related Issues: (so far)

[x] https://github.com/octobercms/october/issues/4182 (No longer necessary)
[x] https://github.com/owncloud/core/issues/13052 & https://www.happyassassin.net/2014/12/29/adventures-in-php-web-asset-minimization/ (Change from JSMin to JSqueeze) - (implemented in https://github.com/octobercms/october/pull/4893/commits/627c0aa6431ad67c6575851b85630856eb5448d8)
[x] #4797 will be moving to a fork of Assetic maintained by the core October CMS team, also will need to ensure that we use wikimedia's fork of LessPHP which will require PHP 7.2.9 (Fixed by https://github.com/octobercms/library/pull/443)
[x] https://github.com/rainlab/builder-plugin/issues/212#issuecomment-489566704 (Upgrade doctrine/dbal) (Fixed by https://github.com/octobercms/library/pull/443)
[x] https://github.com/octobercms/october/pull/4280 (Update autoloading) (Implemented in https://github.com/octobercms/october/commit/e099b7bdeea9f9619196cb288da9603aae016ea7)
[x] https://github.com/octobercms/october/pull/3051 (Laravel Dusk replacing Selenium) (Fixed by https://github.com/octobercms/october/pull/4919)
[x] https://github.com/octobercms/october/issues/3532 (Update PHPUnit) (Fixed by https://github.com/octobercms/library/pull/443)
[x] https://github.com/octobercms/october/issues/4649 (HasOneThrough relationship) (Implemented in https://github.com/octobercms/library/commit/90718d8c6def5c86fd9479e031f38fb8c5534d29, unit tests https://github.com/octobercms/october/commit/26944a5f68ae34723d9ecfdeac8be4bd799950d4)
[x] https://github.com/octobercms/october/issues/3893 (SameSite cookie not working) (Fixed by build 462)
[x] https://github.com/octobercms/october/issues/3227 (Bring October's Auth system more in line with Laravel's) (This will be investigated for inclusion at a later stage - at the moment, our authentication process is largely incompatible with Laravel's Auth system)
[x] https://github.com/octobercms/october/issues/4184 (Update Carbon to Carbon2)
[x] https://github.com/octobercms/library/commit/c8e2740d974a4409f9990d64f19ef493acf7c0e6 (Revisit cookie serialization and encryption serialization in general)
[x] https://github.com/octobercms/library/pull/443 (Unit testing upgrading) (Merged)
[x] L6 also includes a switch to the Ignition error page handler (https://github.com/facade/ignition), we should look into integrating that into October (We will not be including this in October at this stage.)
[ ] Support added back for serializable closures, also check if route caching works with closures (https://github.com/octobercms/docs/issues/425)
[x] Update marketplace's list of pre-installed composer dependencies: https://github.com/octobercms/october/issues/2831
[x] October's Translation service doesn't match Laravel's https://github.com/octobercms/october/issues/5092, fixed by https://github.com/octobercms/library/commit/b8e400b6a3a076a9a70dba42631bfe13bff30cd3

Breaking changes: (so far)

[x] storage/framework/cache/data directory needs to be added and !data/ added to the .gitignore file under storage/framework/cache (Fixed by https://github.com/octobercms/october/pull/4893/commits/25511bfd34e338bd95f2b4d1721d2ca50d8a551d)
Cms\Classes\CmsObjectCollection->where() method signature changed
[x] Require PHP 7.2 (Fixed by https://github.com/octobercms/library/pull/443)
[x] Require PHP Unit 8.0 (unit tests will need to have return type hints added) - also remove https://github.com/octobercms/october/commit/72f85ebc558a8e6fe514f6496f5393e535bac41b when updating (Fixed by https://github.com/octobercms/library/pull/443)
[x] Cache TTL has been changed from minutes to seconds when using integers, recommend using datetime objects instead
[x] ~~May need to swap https://github.com/meyfa/phpunit-assert-gd for https://github.com/lupka/phpunit-compare-images as assertGD doesn't support PHPUnit 7.0~~ (No longer required, phpunit-assert-gd supports PHPUnit 8 now) (Fixed by https://github.com/meyfa/phpunit-assert-gd/pull/2)
[x] setUp() and tearDown() methods in unit tests require adding : void as a return type hint to their definitions. (Fixed by https://github.com/octobercms/library/pull/443)
[x] If you're utilizing the core unit tests you will need to grab the latest copies of the base unit tests from octobercms/october on GitHub and drop them into your project
[x] Carbon will be updated from v1 to v2, see https://carbon.nesbot.com/docs/#api-carbon-2 (Still need to go through and upgrade in core)
[x] Sparkpost & Mandrill mail drivers removed from core Laravel, we should probably add them back to October (i.e. revert https://github.com/laravel/framework/commit/e2461f19c3b951f7cbb4b424601cad1f6553774a#diff-c1d5bf1c77457840314f00f3837a2b2a in octobercms/library) (Implemented in https://github.com/octobercms/library/commit/c8e34ea17579b5c8a7a4f9d9414d713425e6f30c)
[x] The Input facade has been removed as it was mostly a mirror of the Request facade, we need to add it back in (https://laravel.com/docs/6.x/upgrade#the-input-facade) (Fixed by https://github.com/octobercms/library/pull/443)
[x] The default redis client has changed from predis to phpredis. Configuration change may be required by users wishing to retain predis, or potentially we need to dynamically set the configuration for people (by adding a client config value defaulting to phpredis and doing Config::set() if the value isn't detected). See more here: https://laravel.com/docs/6.x/upgrade#redis-default-client (Fixed by https://github.com/octobercms/library/commit/4aeaf54d7e3d12a916a3e096cdbf730fe2aee992, https://github.com/octobercms/october/compare/0394494fbe43...a2966da395bb)
[x] Rackspace storage support was removed. Potentially needs to be re-added? (Re-added in https://github.com/octobercms/library/commit/3ee82fd1af518fac829d780fcedf2cbf723efff0)
[x] email validation rule changed internal behaviour to use a broken version of RFC validation instead of PHP's built in validation, need to change it back. See https://github.com/octobercms/october/issues/5070
[x] trans() and transChoice() methods have been removed from the Translation service, fixed by https://github.com/octobercms/library/commit/a364d6455698b4786efc6870cf097a8677b2dccc

Other tasks:

[x] Integrate old helpers (https://github.com/laravel/helpers/blob/master/src/helpers.php) into Rain library. (Implemented in https://github.com/octobercms/library/pull/456/commits/af29bbfc32230140d4deac1a76b5b81d38f401f1)
[x] Update the Unit Testing documentation in the docs repo and https://github.com/octobercms/october/tree/wip/laravel-6/tests#plugin-testing
[x] Confirm Selenium tests in tests/functional directory still work, update README if necessary. (Replaced with Dusk testing: https://github.com/octobercms/october/pull/4919)
[x] [Low priority] Add Selenium tests to GitHub Actions workflow.
[ ] Go through all of the documentation under octobercms/docs that originally mirrored the Laravel docs and update it to reflect the latest changes to the Laravel docs.
[x] [Update Validator to include latest rules.](https://github.com/octobercms/october/pull/4893#issuecomment-591152927) (fixed by https://github.com/octobercms/october/commit/9911c6b5817088a99ac65d9f2ac76346402e1d47)
[x] Update Laravel Tinker to 2.0 to improve compatibility of dependencies https://github.com/octobercms/library/commit/6fae9cd2baed001f9aa69415f2f130fc104eb573

Known issues:

[x] [Signed URLs do not seem to work.](https://github.com/octobercms/october/pull/4893#issuecomment-576755152) (fixed by https://github.com/octobercms/library/pull/456/commits/c258e666b9c66174e773a57317764209665f2703)
[x] php artisan cache:clear removes the required storage/framework/cache/data folder.

Completed Enhancement

Source

LukeTowers

👍59 ❤6 🚀3

Most helpful comment

To everyone interested, we've made a lot of progress and this is now ready for active testing. Please review https://github.com/octoberrain/meta/blob/master/l6-upgrade-notes.md for information on how you can test the changes in your own projects and any changes that may be required in your code bases.

LukeTowers on 27 Jan 2020

🎉17 ❤3

All 117 comments

Will you be moving to the Laravel 5.7 email verification system?

danharrin on 12 Jun 2019

@DanHarrin what's that?

LukeTowers on 12 Jun 2019

@LukeTowers https://laravel.com/docs/master/verification, built-in email verification into the Laravel auth system

danharrin on 12 Jun 2019

@DanHarrin Probably not? October still isn't using Laravel's auth system so that sounds like a headache to implement.

LukeTowers on 12 Jun 2019

Another related issue:
https://github.com/rainlab/builder-plugin/issues/212#issuecomment-489566704 (Laravel 5.9 should include a compatible version of doctrine/dbal)

bennothommo on 12 Jun 2019

Just to note too, Laravel 5.9 is going to actually require at least PHP 7.2, according to their composer.json.

bennothommo on 12 Jun 2019

Finally time to implement strict types! And in all the DocBlocks too.

adrenth on 12 Jun 2019

Hope this gets merged too :D https://github.com/octobercms/october/pull/4280

Samuell1 on 12 Jun 2019

Is it possible to turn October CMS into an "ever-green" and just have rolling updates that follow Laravel, so let's say we are on stable 5.8 laravel, then October is on 5.7 laravel etc. When 5.9 laravel comes out we are on 5.8 etc. that way October just's updates all the time and is one version down so they can sort out the bug fixes in the meantime.

There's really big LTS release gaps.

See here timeline: https://laravel-news.com/laravel-release-process

Seems like every 2-3 years. In that time so much happens. 5.5 jump to 5.9

I remember 3 years ago we had a vote to update to LTS 5.5 can't we just have another vote to get rolling updates. Every release offers many valuable things! I remember Laravel 5.7: New Pagination Link Customizations and getting excited about that feature and then disappointed I couldn't use them in October.

ghost on 12 Jun 2019

👎4 👍3

Also maybe updating to Laravel 5.9 will fix this issue as well: https://github.com/octobercms/october/issues/3893

ghost on 12 Jun 2019

@ayumihamsaki no, not unless someone is willing to pay for that work to be done. Just to give you some background on how we feel about Laravel's breaking changes in every release, we've toyed around with the idea of moving completely away from Laravel sometimes. Not saying that's going to happen anytime soon but it's incredibly unlikely that we'd ever decide to stay up to date with the latest Laravel changes for every single release.

LukeTowers on 13 Jun 2019

👍8 👎2

That's why they invented semver

adrenth on 13 Jun 2019

👍4

@adrenth hope octobercms will be using that with new release because now only patch version is changing but with breaking changes or new features minor version should change too and major should change when laravel core will be updated. What you think @LukeTowers ?

Samuell1 on 13 Jun 2019

👍2

Cool thanks for answers.

ghost on 13 Jun 2019

Semver would help with a lot of issues but that's up to @daftspunk and I don't think he's a fan. We also don't really want to ever have to support multiple versions of October, we try our best to minimize the breaking changes that come from Laravel as much as possible to encourage people to remain up to date with October.

LukeTowers on 14 Jun 2019

👍3

@LukeTowers dont forget Carbon, now Laravel gives you an annoying message every time you update to use Carbon 2 instead of Carbon 1. What other framework were you looking at as a possibility if you were to move away from Laravel? Because I get where you're coming from.

Teranode on 14 Jun 2019

Move to another framework is not even remotely possible. So that would be out of the discussion. That would result in a total new product, which will throw years of work away.

My suggestion would be to build a stable version of OC with the next LTS version of Laravel and introduce semver so vendor packages and OC itself can be locked in a state everyone is familiar with nowadays.

adrenth on 14 Jun 2019

👍4

I'm not saying to move away, im asking what was the other option he was considering.

I think https://github.com/octobercms/october/issues/3683 needs to be resolved first before trying to add more workload by branching off.

Teranode on 14 Jun 2019

@adrenth @Teranode the idea that's been talked about lots by @daftspunk is basically forking Laravel and maintaining that. Personally, I'm not a fan of doing that as it would diverge from the Laravel community and limit our potential reach, so I don't see us doing that any time soon, if at all. I bring it up purely to communicate our frustration with their often nonsensical breaking changes.

@Teranode is there a good resource for any breaking changes from switching to Carbon 2?

LukeTowers on 14 Jun 2019

@LukeTowers
wew that idea sounds worse than just not using Laravel at all, but I do get that frustration as i tend to look at their codebase every now and then and see things that don't need to be there.

Nesbot got a documentation for their breaking changes:
https://carbon.nesbot.com/docs/#api-carbon-2

Teranode on 14 Jun 2019

wew that idea sounds worse than just not using Laravel at all, but I do get that frustration as i tend to look at their codebase every now and then and see things that don't need to be there.

You don't have this frustration when looking at the OctoberCMS codebase?

nathan-van-der-werf on 14 Jun 2019

@nathan-van-der-werf anything in particular? 😉

LukeTowers on 15 Jun 2019

@nathan-van-der-werf anything in particular? 😉

My biggest frustration (aside from not having semver and tags being made while the version is not "stable" yet) would be the lack of strict typing.

nathan-van-der-werf on 15 Jun 2019

You mean not setting strict type mode at the top of every file?

LukeTowers on 16 Jun 2019

You mean not setting strict type mode at the top of every file?

The code not being strict at all, some examples:

https://github.com/octobercms/october/blob/master/modules/system/classes/PluginBase.php#L93
https://github.com/octobercms/october/blob/master/modules/system/classes/PluginBase.php#L83
https://github.com/octobercms/october/blob/master/modules/system/classes/PluginBase.php#L43
No strict typing, while it should always return an array
https://github.com/octobercms/october/blob/master/modules/system/classes/PluginBase.php#L153
$schedule is not a string here... It's an object (not strict)
https://github.com/octobercms/october/blob/master/modules/system/classes/PluginBase.php#L260
Why aren't the $key and $class strictly typed to string when it has to be a string

(*and this is only 1 of the who knows how many files not being strict)

nathan-van-der-werf on 16 Jun 2019

some of that seems like nitpicky stuff someone could PR in if they were concerned about it.

Teranode on 17 Jun 2019

👎1 👍1

@nathan-van-der-werf We are looking to implementing strict typing on core files where possible. All new development will likely be strict-typed, but older code will need to be tested when converted to strict typing in order to ensure that everything still works as expected. We'd be happy to accept any PRs that improve the strict typing in files as long as its tested.

bennothommo on 17 Jun 2019

@bennothommo

"...to ensure that everything still works as expected."

Totally agree, but... By implementing strict types and use proper type hinting the change of breaking third party code will be bigger; because developers can throw in all garbage as of know. These major changes can all be part of the next big OC major release.

That's why semver is becoming more important when refactoring the base code. This allows OC to handle backwards compatibility better and communicate breaking changes.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

-- https://semver.org/

adrenth on 17 Jun 2019

👍1

some of that seems like nitpicky stuff someone could PR in if they were concerned about it.

I don't think strict typing is "nitpicky stuff"... it enforces "better" code instead of "you can throw any type into this method".

@nathan-van-der-werf We are looking to implementing strict typing on core files where possible. All new development will likely be strict-typed, but older code will need to be tested when converted to strict typing in order to ensure that everything still works as expected. We'd be happy to accept any PRs that improve the strict typing in files as long as its tested.

I agree that older code will need to be tested thoroughly.

I did some PR's with code optimisations already https://github.com/octobercms/october/pulls?q=is%3Apr+author%3Anathan-van-der-werf+is%3Aclosed but since many developers aren't using a decent IDE (PHPStorm) I could be doing this every month since we don't have any coding style / guidelines (CI).

nathan-van-der-werf on 17 Jun 2019

@adrenth Whilst I like the idea of semver, in theory, it does imply that we'll handle multiple branches of versions. Given that we've already got our hands full with just one stream of development as @LukeTowers said - it's probably too much for us. Just look at the horror that Magento has to deal with, working on semver.

@nathan-van-der-werf I saw @LukeTowers proposed if you could provide a CI guideline or config for using a service like PrettyCI to enforce some standards. Have you given any thought to helping us out with that? :)

bennothommo on 17 Jun 2019

@nathan-van-der-werf I saw @LukeTowers proposed if you could provide a CI guideline or config for using a service like PrettyCI to enforce some standards. Have you given any thought to helping us out with that? :)

Proposed some tooling to do it https://github.com/octobercms/october/pull/3690#issuecomment-413305893

Don't have the time to set it up, it's not a magical tool to fix all ugly code into clean and good looking code.

nathan-van-der-werf on 17 Jun 2019

I'm not saying strict types are bad im just saying after php 7 and october's move to laravel 5.5 some of the strict type implementations could have been implemented through people's PRs if they were concerned about it.

Teranode on 18 Jun 2019

@ayumihamsaki im still not getting any issues with that on #3893 in laravel 5.5

Teranode on 5 Jul 2019

@LukeTowers sorry if I sound I am repeating parts of this conversion.

As adrenth said about Semantic Versioning, when you do this major update will you be updating the version number like this:

Current Version as of today: v1.0.456 (with LTS 5.5)

LTS 5.9 Version would be: v2.0.0

(to signal MAJOR version when you make incompatible API changes).

That would be the correct way. Because you would be creating a _breaking change_ in the releases.

[edit]

Another example, let's say I update jQuery from V3 to V4. I'd probably say to do this:

Current Version as of today: v1.0.456 (with jQuery v3)

jQuery v4 would be: v1.1.0 (major code change but because of jQuery Migrate - no breaking changes)

That's how I do my repo's anyway.

ghost on 5 Jul 2019

👍3

@ayumihamsaki I get the concept and value of semantic versioning, I just don't know if @daftspunk is going to be on board with a change to that. He was pretty adamant when I first started with the project that there will never be an October 2.0. We'll see how the upgrade goes and go from there.

LukeTowers on 6 Jul 2019

Hi daftspunk if you could have a think about this issue with Semantic versioning it would be good. My next pr for october is to update the jQuery Migrate and it contains the following code deprecates. I'm wondering how best to communicate these changes to everyone, in regards of their themes and plugins code. The easiest solution would be Semantic versioning I think.

Please see screenshot from jQuery's repo on the commit I am talking about:

dafspunk

[edit] I will be linking two pr's together, the jQuery Update here: https://github.com/octobercms/october/pull/4317 and a forthcoming jQuery Migrate. (To update the jQuery in October CMS).

ghost on 6 Jul 2019

Maybe the topic about semver deserves a separate issue to take this discussion further ;-) However, I greatly appreciate the time that was spent to make things clear. I'll keep an eye on any updates regarding Laravel upgrades. Brings some good stuff!

adrenth on 8 Jul 2019

Is October now going to support v6 instead?

danharrin on 25 Jul 2019

@DanHarrin probably, waiting on more information about it.

LukeTowers on 25 Jul 2019

It will be nice to rework/refactor routes for backend and cms, for example now routes are added trough _App::before_ and they are not cached. Adding them in boot method in ServiceProvider allows them to be cached php artisan route:cache and list trough php artisan route:list.

Samuell1 on 16 Aug 2019

On that topic I would also like to propose a move of /backend/backend to /backend/dashboard and /backend/backend/media to /backend/media - URL looks messy in its current form imo.

On another note, (and I doubt this will be changed), but I would also like to see the CMS menu item renamed to Theme / Frontend or something similar. October is a CMS / CMF itself so it doesn't really make sense for a single feature of the system to reserve that name.

danharrin on 16 Aug 2019

@DanHarrin prefix for backend is passed here https://github.com/octobercms/october/blob/master/modules/backend/routes.php#L17 but why is double is maybe bug?

Same route name is weird with backend/backend/users or backend/backend/accesslog

Samuell1 on 16 Aug 2019

@DanHarrin @Samuell1 Some people are using other url for /backend. Some of my projects are using /web or /app. The backend prefix might be to make clear it's about the backend models

SebastiaanKloos on 16 Aug 2019

@SebastiaanKloos yeah I understand that they're backend services so were originally separated from other modules, but since the default backend URI is /backend I personally think this is a poor URL design choice. Some people may disagree, and that's fine :)

danharrin on 16 Aug 2019

@DanHarrin we're unlikely to change that TBH, you're always welcome to change that yourself through the configuration files.

LukeTowers on 17 Aug 2019

Would it be a good idea to use Laravel Shift?

See here: https://laravelshift.com/

Currently it's on 5.8 but end of aug 2019 they probably update it to 6.0

ghost on 18 Aug 2019

👍1

@ayumihamsaki Are you sure that’s a good idea? I doubt if laravel shift will work for OctoberCMS. They only make the changes based on the Upgrade Guide and also it needs to maintain the structure to an extend whereas OctoberCMS deviates the regular Laravel structure by quite a bit.

SaifurRahmanMohsin on 18 Aug 2019

Just thought it might help using their Automated Shifts to bug test the October Core when the Laravel 6 is added - just to speed things up and give a smoother transition. I'm sure there will be a ton of upgrade work in the modules folder.

ghost on 18 Aug 2019

@ayumihamsaki I wanted to try that few days ago but only few tests are free. But it can help with linting and stuff like that.

Samuell1 on 18 Aug 2019

Yah the linting page says: "Running the latest stable or LTS version of Laravel"

Link for people to checkout is here: https://laravelshift.com/opinionated-laravel-way-shift

ghost on 18 Aug 2019

So the date of the Laravel 6.0 release according to this document, is September 3rd, 2019! Taylor also mentioned that Laravel 6.0 is the next long-term service (LTS) release, replacing Laravel 5.5 LTS. Not to worry though, the 5.5 LTS will receive security updates until August 30th, 2020.

https://laravel-news.com/is-laravel-6-0-out-yet

prhost on 27 Aug 2019

👍2

Laravel 6.0 LTS Is Now Released

ghost on 13 Sep 2019

I'm booked up solid with cilent work for this month so I don't forsee me having the time to do anything on this until October unless someone sponsors it.

LukeTowers on 14 Sep 2019

Would it be a good idea to create an update guide for plugins, I'm pretty sure there are many breaking changes.

ghost on 14 Sep 2019

@ayumihamasaki2019 yes, an official release note on the website will be issued when it's ready to go.

LukeTowers on 15 Sep 2019

Laravel 6.0.3 was released that reverted few things, looks like its good to wait few weeks for more stable version.

Samuell1 on 18 Sep 2019

We are now seeing issues with some laravel packages. Packages are updated to latest versions of laravel in dependecies, and their use leads to fact that they bring version 2.0 of Carbon package. This generates error that is described in this task. We will all be happy if OcotberCMS will be updated to latest version of laravel.

kharanenka on 18 Oct 2019

👍1

@nathan-van-der-werf @kharanenka feel free to sponsor this update 😉 My time is taken up with paying clients until probably about mid November so unless someone wants to pay for me to work on this before then that's around when I'll have time to work on this.

LukeTowers on 18 Oct 2019

@nathan-van-der-werf @kharanenka feel free to sponsor this update 😉 My time is taken up with paying clients until probably about mid November so unless someone wants to pay for me to work on this before then that's around when I'll have time to work on this.

How much (payed) time do you guys need to do the upgrade? :)

ghost on 24 Oct 2019

I'd probably need 20 hours to justify working on this amongst other paying client work, which would be $3000. I'd accept $3000 CAD though which is like $2250 USD.

LukeTowers on 24 Oct 2019

considering your patreon, and the fact we're still debating on funding ideas. I doubt there would be anyone willing to cough that up. Not even sure how much the active userbase is.

Teranode on 24 Oct 2019

@Teranode there's ~30,000 active sites across the world using October as a CMS right now, and other operations that go untracked using it for SaaS offerings and internal web applications. I'm not expecting any one person to cough up that much, just saying that I'd need that much to dedicate time to dealing with the upgrade right now. Even fine with multiple people pitching in if they need it ASAP.

Otherwise they can either help with the upgrade process by throwing development resources at it or they can wait for it to become a priority for me to spend my own time freely on it, which should probably be before the new year at the latest.

LukeTowers on 25 Oct 2019

👍3

@joris-vdlp @petehalverson Our company uses October for some highly customized backend applications. It may be worth exploring a group contribution to help move this along? @LukeTowers mentioned Aspen Digital may be interested as well? I figure if the 3 of our companies pitch in, that's only $1k a piece for a substantial benefit/gain in value to the platform. Email me if you want to talk more.

LarryBarker on 25 Oct 2019

👍4

@joris-vdlp @petehalverson Our company uses October for some highly customized backend applications. It may be worth exploring a group contribution to help move this along? @LukeTowers mentioned Aspen Digital may be interested as well? I figure if the 3 of our companies pitch in, that's only $1k a piece for a substantial benefit/gain in value to the platform. Email me if you want to talk more.

@LukeTowers What i can do is clear up some capacity in my team to work on the Laravel 6 upgrade / update. Contact me on slack or by e-mail if you are interested.

ghost on 25 Oct 2019

👍2

Would Bountysource be an option to get some one-time funds for this together? We have successfully founded the froala license and other stuff in the earlier days this way.

tobias-kuendig on 19 Nov 2019

I'm fine with that @tobias-kuendig

LukeTowers on 19 Nov 2019

https://www.bountysource.com/issues/75392602-move-to-laravel-6

LukeTowers on 19 Nov 2019

👍1

Alright, 1750 USD to go. Let's fund this update, @joris-vdlp, @LarBearrr, @Teranode, @pvullioud, @seanthepottingshed, @Samuell1, @amdad, @alxy, @gergo85, @scottbedard, @vojtasvoboda, @DanHarrin, @kharanenka

https://bountysource.com/issues/75392602-move-to-laravel-6

tobias-kuendig on 19 Nov 2019

❤5

Hi Octoppl: I happened to see bountysource tweet this out, so I'm just here to seek clarification on whether the bounty is there primarily to be able to allow Luke (and perhaps others who have previously chimed in) to dedicate time to this objective?...

I am a Laravel developer, with only limited exposure and experience with OctoberCMS. So I'm not sure how much help I'd be. Is the opening description/list a good representation of the ground that needs to be covered, to clear the upgrade path?

emjayess on 21 Nov 2019

@LukeTowers Another breaking change: Input facade is no longer available. The general recommendation is that all Input method calls should be changed to the comparable Request method call instead.

bennothommo on 22 Nov 2019

👍1

@bennothommo we should reimplement the Input facade forwarding calls as applicable to the Request method calls. Note that we also have to make sure that input(), post(), get(), etc still work. Could you link to where Laravel documents that change?

LukeTowers on 22 Nov 2019

@emjayess Thanks for your interest! The bounty is for @bennothommo and myself to work on this and we'll be splitting it between ourselves once the work is done. If you're looking to help out, feel free to test the branches for this repo and library as well as submit PRs for the changes if you feel like it.

LukeTowers on 22 Nov 2019

@LukeTowers It is documented here: https://laravel.com/docs/6.x/upgrade#the-input-facade. The PR that dropped it is here: https://github.com/laravel/framework/pull/29599. If we do still make it available, I believe we should deprecate it, as apart from one method (get), it literally is the same as the Request facade.

bennothommo on 22 Nov 2019

@bennothommo I don't mind replacing references to it in our docs but I don't think adding a deprecation warning to it adds any benefit to anyone. It's pretty widely used within the October ecosystem so error logs would fill with those messages quite rapidly. We can also add a docblock comment to the facade as well for anyone browsing the API docs.

LukeTowers on 22 Nov 2019

@LukeTowers No worries

bennothommo on 22 Nov 2019

@LukeTowers (and anyone who is interested in preparing for the update)

Please refer to the following PHP docs pages regarding upgrading your PHP version. This will be especially important for any users still running PHP 7.0 or PHP 7.1, as Laravel 6 requires PHP 7.2.

Migrating from PHP 7.0 to PHP 7.1

Migrating from PHP 7.1 to PHP 7.2

Migrating from PHP 7.2 to PHP 7.3

Migrating from PHP 7.3 to PHP 7.4

bennothommo on 29 Nov 2019

👍8

@ayumi-cloud I think it will be because its already in laravel core.

I like to see if ocms can make something like Flare does but for free because to use Flare you need to pay monthly.

Samuell1 on 8 Dec 2019

👍1

@ayumi-cloud Ignition is one of the things on my list to look into further. I'm thinking that October is probably going to keep it's current error page unless it's incredibly easy to integrate ignition, but if we don't integrate it into the core then it could be released as a plugin.

LukeTowers on 10 Dec 2019

LukeTowers on 27 Jan 2020

🎉17 ❤3

When performing the upgrade, I get the warning message:

Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.

I'm assuming this can be ignored.

Also, Translate plugin is version 1.6.7 as indicated in the upgrade guide:

But I'm still getting the Missing required parameters for [Route: ] [URI: en/{slug}]. exception:

Edit:

For both of the above errors, I had the following require-dev in composer.json:

"require-dev": {
    "fzaninotto/faker": "~1.7",
    "phpunit/phpunit": "~5.7",
    "phpunit/phpunit-selenium": "~1.2"
},

I changed this to what is in the current version, as well as merged any other changes, ran composer upgrade, and now it works with no errors:

"require-dev": {
    "fzaninotto/faker": "^1.9",
    "phpunit/phpunit": "^8.0|^9.0",
    "dms/phpunit-arraysubset-asserts": "^0.1.0",
    "meyfa/phpunit-assert-gd": "^2.0",
    "squizlabs/php_codesniffer": "3.*",
    "jakub-onderka/php-parallel-lint": "^1.0",
    "laravel/dusk": "^5.8"
},

Perhaps this needs to be added to the upgrade instructions.

multiwebinc on 11 Feb 2020

@multiwebinc they are already in the instructions ;)

https://github.com/octoberrain/meta/blob/master/l6-upgrade-notes.md#october-cms-unit-testing

As for the Translate plugin issue, the fix for this is pending the L6 upgrade: https://github.com/rainlab/translate-plugin/issues/544#issuecomment-579611942

bennothommo on 12 Feb 2020

Updated the version number in the instructions to indicate it's unreleased (1.6.x). You can still apply https://github.com/rainlab/translate-plugin/commit/3e31cee945f3cde55cab0ebd0fa278555207302e manually to resolve the issue.

LukeTowers on 12 Feb 2020

@LukeTowers @bennothommo Out of curiosity, what is October's plan going to be going forward? Laravel is now using semantic versioning, and 7.x is expected to be released on March 3rd. I hope we're going to try and stay in sync with them. Maybe we could keep our stable release in sync with LTS, and then have an edge release that follows the latest Laravel?

scottbedard on 12 Feb 2020

👍3

@scottbedard right now we're going to be sticking with our existing process of just following LTS, but we'll be keeping our eye on what Laravel does and how many breaking changes they introduce how frequently. It's pretty unlikely that we'd be willing to support two separate versions of October at any rate.

LukeTowers on 12 Feb 2020

👍5

@multiwebinc please add that as a comment on the PR

LukeTowers on 25 Feb 2020

I just did a fresh install of October and tried to upgrade it to Laravel 6, and I am having some issues.

When doing composer update I get the following messages:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 0 removals
Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.
Package jakub-onderka/php-parallel-lint is abandoned, you should avoid using it. Use php-parallel-lint/php-parallel-lint instead.
Generating autoload files

In ClassMapGenerator.php line 69:

  Could not scan for classes inside "tests/concerns/InteractsWithAuthentication.php" which does not appear to be a file nor a folder  


update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

The abandoned packages messages are warnings (highlighted in orange), and the other one is an error (it's highlighted in red), and it appears to be aborting composer since it almost seems like when you call a script with invalid syntax at the end.

Then when going to a page, I get the following PHP error:

Fatal error: require(): Failed opening required '/home/mike/Seafile/www/laravel/october-test/vendor/composer/../symfony/polyfill-php70/bootstrap.php' (include_path='.:/usr/share/php') in /home/mike/Seafile/www/laravel/october-test/vendor/composer/autoload_real.php on line 66

multiwebinc on 11 Apr 2020

@multiwebinc what version of PHP are you using and what does your composer.json look like?

LukeTowers on 11 Apr 2020

I have a working install of October with Laravel 6 (not the one in my previous post), and I'm having an issue with the Rainlab Translate plugin. If I put the following in one of my twig files:

{{ '<b>Hello!</b> Please go to our :contact_page.'|_({contact_page: '<b><a href="' ~ 'contact'|page ~ '">' ~ 'contact page'|_ ~ '</a></b>'}) }}

This outputs:

<b>Hello!</b> Please go to our &lt;b&gt;&lt;a href=&quot;https://october.localhost/en/contact&quot;&gt;contact page&lt;/a&gt;&lt;/b&gt;.

However when using a fresh install of October with Laravel 5, the same code outputs:

<b>Hello!</b> Please go to our <b><a href="">contact page</a></b>.

multiwebinc on 11 Apr 2020

@LukeTowers PHP 7.2.24

Here is my composer.json, which is working for another install that I had previously updated to Laravel 6.

{
    "name": "october/october",
    "description": "October CMS",
    "homepage": "https://octobercms.com",
    "keywords": ["october", "cms", "octobercms", "laravel"],
    "license": "MIT",
    "authors": [
        {
            "name": "Alexey Bobkov",
            "email": "[email protected]",
            "role": "Co-founder"
        },
        {
            "name": "Samuel Georges",
            "email": "[email protected]",
            "role": "Co-founder"
        },
        {
            "name": "Luke Towers",
            "email": "[email protected]",
            "homepage": "https://luketowers.ca",
            "role": "Maintainer"
        }
    ],
    "support": {
        "issues": "https://github.com/octobercms/october/issues",
        "forum": "https://octobercms.com/forum/",
        "docs": "https://octobercms.com/docs/",
        "irc": "irc://irc.freenode.net/october",
        "source": "https://github.com/octobercms/october"
    },
    "require": {
        "php": "^7.2",
        "ext-mbstring": "*",
        "ext-openssl": "*",
        "october/rain": "dev-wip/laravel-6 as 1.0",
        "october/system": "dev-wip/laravel-6",
        "october/backend": "dev-wip/laravel-6",
        "october/cms": "dev-wip/laravel-6",
        "laravel/framework": "~6.0",
        "wikimedia/composer-merge-plugin": "dev-master",
        "ext-intl": "*",
        "ext-sqlite3": "*",
        "jacobbennett/laravel-http2serverpush": "^4.0"
    },
    "require-dev": {
        "fzaninotto/faker": "^1.9",
        "phpunit/phpunit": "^8.0|^9.0",
        "dms/phpunit-arraysubset-asserts": "^0.1.0",
        "meyfa/phpunit-assert-gd": "^2.0",
        "squizlabs/php_codesniffer": "3.*",
        "jakub-onderka/php-parallel-lint": "^1.0",
        "laravel/dusk": "^5.8"
    },
    "autoload-dev": {
        "classmap": [
            "tests/concerns/InteractsWithAuthentication.php",
            "tests/fixtures/backend/models/UserFixture.php",
            "tests/TestCase.php",
            "tests/UiTestCase.php",
            "tests/PluginTestCase.php"
        ]
    },
    "scripts": {
        "post-create-project-cmd": [
            "php artisan key:generate",
            "php artisan package:discover"
        ],
        "post-update-cmd": [
            "php artisan october:util set build",
            "php artisan package:discover"
        ],
        "test": [
            "phpunit --stop-on-failure --prepend ./vendor/october/rain/src/Support/helpers.php"
        ],
        "lint": [
            "parallel-lint --exclude vendor --exclude storage --exclude tests/fixtures/plugins/testvendor/goto/Plugin.php ."
        ],
        "sniff": [
            "phpcs --colors -nq --report=\"full\" --extensions=\"php\""
        ]
    },
    "config": {
        "preferred-install": "dist"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "extra": {
        "merge-plugin": {
            "include": [
                "plugins/*/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-dev": false
        },
        "laravel": {
            "dont-discover": [
                "laravel/dusk"
            ]
        }
    }
}

multiwebinc on 11 Apr 2020

@multiwebinc that's a result of a recent change to prevent XSS in the translate plugin. Use the | transRaw({contact_page: ''}) filter instead now. See https://github.com/rainlab/translate-plugin/commit/4a3d601920e1da3f9cb3ff31c91b90b25e7652ea

LukeTowers on 11 Apr 2020

@multiwebinc simplify that down to the following if you don't use automated testing. If you use automated testing make sure you update the tests directory and use the composer file from https://github.com/octobercms/october/tree/wip/laravel-6

{
    "name": "multiwebinc/october-project",
    "require": {
        "php": "^7.2",
        "ext-mbstring": "*",
        "ext-openssl": "*",
        "october/rain": "dev-wip/laravel-6 as 1.0",
        "october/system": "dev-wip/laravel-6",
        "october/backend": "dev-wip/laravel-6",
        "october/cms": "dev-wip/laravel-6",
        "laravel/framework": "~6.0",
        "wikimedia/composer-merge-plugin": "dev-master",
        "ext-intl": "*",
        "ext-sqlite3": "*",
        "jacobbennett/laravel-http2serverpush": "^4.0"
    },
    "scripts": {
        "post-update-cmd": [
            "php artisan october:util set build",
            "php artisan package:discover"
        ],
    },
    "extra": {
        "merge-plugin": {
            "include": [
                "plugins/*/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-dev": false
        },
    }
}

LukeTowers on 11 Apr 2020

@LukeTowers Thanks. That composer file worked with no error, only the following warning messages, so something else I had there must be causing the error:

Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.

Also, I am not sure what happened with the translate plugin because I seemingly had version 1.6.7 installed, and the change you mention appears it was merged in 1.6.10. I just removed the plugin and reinstalled it and it is working correctly now.

multiwebinc on 11 Apr 2020

👍1

@bennothommo could you look into those error messages and update them if relevant to us?

LukeTowers on 11 Apr 2020

Maybe a stupid question, but if this is going to roll out to production. Will it be as simple as hitting the update button in the OctoberCMS backend?

robinbonnes on 15 Apr 2020

@robinbonnes as long as you aren't using any super complex Laravel features then yes, it should just be that easy. See https://github.com/octoberrain/meta/blob/master/l6-upgrade-notes.md for the upgrade guide which has been broken down into sections based on the functionality that has been affected. If you're not using any of those sections you can update through the backend no problem. If you are it's recommend you take a quick look at them and make any required changes.

LukeTowers on 15 Apr 2020

👍4

It looks like the upgrade is coming along great! Is there anything specific we can help out with?

tobias-kuendig on 21 May 2020

@tobias-kuendig test it out on your sites! :) It should be pretty much production ready by now, we're just waiting to finish up 466 as the last 7.0-7.1 release and then the L6 will be the next one. I'm using it in production on all my sites with no issues (apart from headaches with the two main |resize plugins, but that's because of my hosting environment, not the L6 upgrade).

You could also check the 466 issues and see if anything on there you can help with.

LukeTowers on 21 May 2020

🚀1

In response to my previous comment, I looked into the abandoned package warnings I'm getting when running composer update:

Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.

These are caused by laravel/tinker which requires an old version of psy/psysh, which requires jakub-onderka/php-console-highlighter. This was fixed by psy/psysh in the following commit:

https://github.com/bobthecow/psysh/commit/2a7589525ee6583eb6a06d23db2e791b37dd44b6

So basically the only way to remove these warnings would be to use a newer version of tinker.

multiwebinc on 21 May 2020

@multiwebinc so they don't use that version in Laravel 6?

LukeTowers on 21 May 2020

@LukeTowers As of Laravel 6.8.0, Tinker was updated from v1 to v2. See: https://github.com/laravel/laravel/pull/5161

multiwebinc on 21 May 2020

👍1

@LukeTowers I'm guessing this could be updated in https://github.com/octobercms/library/blob/wip/laravel-6/composer.json ?

multiwebinc on 21 May 2020

👍1

It could be indeed, feel free to submit a PR to the L6 branch with the update. Just checked their changelog for 2.0 and it looks like it was just dependency updates that are all compatible with our 6.x changes so it should be fine to just merge it in no problems.

LukeTowers on 21 May 2020

@LukeTowers Sounds good. https://github.com/octobercms/library/pull/494

multiwebinc on 21 May 2020

👍1

I'm trying to install L6 branch i have after a composer udate

> php artisan october:util set build

In ServiceProvider.php line 128:

  Call to undefined method October\Rain\Translation\Translator::addJsonPath()

Am I the only one ?

shiftaltd on 24 May 2020

@shiftaltd can you report that in a separate issue along with the full stack trace (if you can get it) and the exact steps you took? I haven't encountered that issue myself and I've moved 10-20 production sites over to the L6 branch without any issues.

LukeTowers on 24 May 2020

@LukeTowers ok. there is probably something with my not so fresh install. I'll do a fresh one on a new vps to test. Thanks

shiftaltd on 25 May 2020

Sorry. It works. my error was due to laravel\cashier in composer.json. I have to find the L6 cashier version i guess

shiftaltd on 25 May 2020

👍1

I'm not sure if this is related to the move to L6 or not, but I am having a tough time updating my dependencies. I have been working with @LukeTowers to troubleshoot, and have yet to resolve the issue. I have removed modules, vendor, and all of my plugins, and running composer update is throwing the following error:

post-update-cmd: php artisan october:util set build
Executing command (CWD): php artisan october:util set build

In Container.php line 805:

  Target class [files] does not exist.  


In Container.php line 803:

  Class files does not exist  


Script php artisan october:util set build handling the post-update-cmd event returned with error code 1

I also cannot get the stack trace from the browser because I am getting a 500 error using Valet. Has anyone else had a similar issue?

UPDATE
Ok I was finally able to narrow this down to barryvdh/laravel-ide-helper. Still not sure what is causing it, so I'll investigate more and report back here.

LarryBarker on 31 May 2020

@LarryBarker I just tested adding that package as a requirement to a project running the L6 branch and had no problems, so not sure what's going on there for you. I did however run into that annoying issue with the invalid laravel cache files for the service providers / aliases after removing the package, and I think I've come up with a solution here: https://github.com/octobercms/library/pull/492#issuecomment-636434950

LukeTowers on 31 May 2020

@LarryBarker
I faced the same issue than you.
I found why the class "files" could not be found in this pull request .

So, i forked laravel-ide-helper and made a commit to fix the issue.

I'm using the fork like this in the composer.json file of my own plugin:

   "repositories": [
        {
            "type": "git",
            "url": "https://github.com/freddy38510/laravel-ide-helper/"
        }
    ],
    "require": {
        "composer/installers": "~1.0"
    },
    "require-dev": {
        "barryvdh/laravel-ide-helper": "master"
    }

Don't forget to set merge-dev to true in your root composer.json.

   "extra": {
        "merge-plugin": {
            "include": [
                "plugins/*/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-dev": true
        }
    }

freddy38510 on 1 Jun 2020

I was looking through the route caching item and testing to see if they worked with closures.
I noticed all of the route registrations happen inside of the App::before() calls and I was curious what the original reason for that was. As it stands with the routes for the different modules being registered in that way it causes the route:cache command to fail since it thinks there aren't any routes. However, if you remove the App::before() and just register the routes directly through the routes.php files, all of the routes are then able to be listed in the route:list command and also allows the routes to be cached as well.

This seems like an easy solution, however I just wanted to know what the original purpose of the routes being registered that was for and what issue it was solving since I imagine there was a reason for doing it that way.

ericp-mrel on 2 Jun 2020

@ericp-mrel it has to do with when the plugin routes get registered vs the module routes vs any routes added by third party packages. We had an internal discussion about it a few weeks ago and I'll be making some changes to it in the next month or so. Note that any plugin routes are still listed and cached just fine, it's just the module ones that aren't, which isn't really that big of a deal because there's like 6 total.

LukeTowers on 2 Jun 2020

can we use "wip/laravel-6" branch as a clean installation for new projects or is it too soon?

alireza-salehi on 27 Jun 2020

👍3

can we use "wip/laravel-6" branch as a clean installation for new projects or is it too soon?

@alireza-salehi I’m using this branch in a production environment. Just make sure you follow the upgrade guide completely.

LarryBarker on 27 Jun 2020

👍2

@LukeTowers even plugin routes arent cached too because they going trough main routing not trough ocms custom.

Samuell1 on 27 Jun 2020

@Samuell1 ?

LukeTowers on 27 Jun 2020

@LukeTowers forgot to mention iam responding to this msg, and i if you run route:cache it doesnt cache anything because of that issue with initializing of routes.

Note that any plugin routes are still listed and cached just fine, it's just the module ones that aren't, which isn't really that big of a deal because there's like 6 total.

Samuell1 on 27 Jun 2020

Was this page helpful?

0 / 5 - 0 ratings