Concrete 9.0 Release Candidate 2 Now Available!

Announcements
1

That was fast! After all the very helpful feedback and reports from our first announcement just two days ago, it became clear that we needed to fast-track our second release candidate. It is now ready for download on our downloads page: Download :: Concrete CMS - Org

Additionally, for all add-on developers who are working on getting your add-ons and themes ready for version 9, I’ve put together an in-progress tutorial. Add-On Developers: Get Your Add-Ons Ready for Concrete CMS 9.0 :: Concrete CMS . I’m sure there will be more to add to it, but hopefully it’s helpful.

You can read all about all the exciting new features in 9.0 on the original announcement, here: Concrete 9.0 Release Candidate 1 Now Available!

3 Likes
2

Just Installed Release Candidate 2 on my local dev box, no problem with the installation until I try to sign back into the site at which point the following error is thrown…

GuzzleHttp\Exception\RequestException thrown with message “cURL error 60: SSL certificate problem: unable to get local issuer certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)”

I overcame this by altering the url in the browser from ‘root/index.php/dashboard/welcome’ to ‘root/index.php/dashboard’, this showed me as signed in on the dashboard page.

I then navigated to Dashboard > System & Settings > Login & Registration > Login Destination and changed ‘Redirect to user’s Desktop’ to ‘Redirect to Home’ and saved it.

I can now sign in and out without issue as long as my system is not trying to connect to the ‘Welcome’ page.

1 Like
3

Very nice. All issues I initially encountered in rc1 are resolved!

4

Even though this is still a RC, overall everything is looking and feeling fantastic with V9.
The new file manager is great, the addition of features like a gallery block and containers is really exciting, and the dashboard really feels more consistent and refined.

The interface feels free and clean, but still very familiar.

Really looking forward to building sites with V9! Nice work! :beer: :beers: :beer:

1 Like
5

@ConcreteOwl did you make a Github issue about this?

6

No @Myq I thought it would be picked up by Andrew by responding to his post.

7

A new Github issue has now been created.

1 Like
8

Ok, I’ve installed RC2, installed my package - seems some Illuminate exceptions are gone.

Following this doc:

https://documentation.concretecms.org/tutorials/add-developers-get-your-add-ons-ready-concrete-cms-90

seems to have fixed the errors so far. Will keep trying.

9

I have an exception “Unable to get permission key for allowed_file_extensions” using the following:

$fs = FileSet::getGlobal();
$fp = $this->app->make(Checker::class, ['fs' => $fs]);
$extensions = $fp->getAllowedFileExtensions();

So how do I fix that for v9?

10

@linuxoid try with this code

use Concrete\Core\File\Set\Set;
use Concrete\Core\Permission\Checker;

$fp = new Checker(Set::getGlobal());
$extensions = $fp->getAllowedFileExtensions();
11

@mlocati , I know that works. But the PRB told me to avoid the use of ‘new’ instantiations and to move everything to ‘app->make’. So I’m wondering how to instantiate all classes with various variable names there.

12

The Checker class can be created by using new.

If you still want to use the “make” approach, you have to:

  1. check the constructor of Checker
  2. there you can see that it accept one parameter, named $object
  3. So, you have to call $app->make(Checker::class, ['object' => $fs])
13

@mlocati , So the key name must be the same as the constructor variable name, not the passed variable name! Got it. Thank you.

14

Yep: that’s the general rule when you use make: check the argument names in the class constructor (function __construct(...)), and use them (without the leading $).

15

Well, with the app->make out of the way, now I’ve got another exception but with useless log info. It doesn’t say what caused it, which file, which line. I have no clue where to even start looking:

Screenshot_20210817_174725
Screenshot_20210817_1747251377×841 95.8 KB

16

With these release candidates I’m noticing that there’s something a bit misaligned with the full error/whoops page, the error line highlighted appears too high on the page, and you can’t scroll up to see it.

I thought it might have just been me experiencing this, but linuxoid’s screenshot above is a good example of this happening.

17

I am also seeing the whoops page being misaligned, with the important part being off the top rather than in the middle.

Perhaps a BS3->BS5 style issue on the way the code block is vertically centered.

18

I’ve actually reported that as a bug on github

1 Like
19

Just going to reply with some hopefully helpful advice:

There’s really nothing too magical about $app->make(). You don’t have to use it. In general, it’s useful when you have some dependencies that are globally registered that you don’t want to have to retrieve yourself in order to pass in.

So, for example, let’s say we want to use the Concrete\Core\Filesystem\FileLocator class, in order to search the file system for some element or block templates. The class requires Illuminate\Filesystem\Filesystem and Concrete\Core\Application\Application in order to do its business, and it obtains those classes in the constructor.

Instead of having to somehow instantiate the Filesystem and Application classes in order to pass them into your new FileLocator class, you can just run

$app->make(FileLocator::class);

Which will then auto-magically pass in the appropriate versions of those classes, either by just automatically instantiating them or by looking into one of the service provider classes and then figuring out how to build the classes.

I mention this because if there’s a class that you need to use that only takes an object that you always have on hand, there’s absolutely no reason to use $app->make(). The permissions checker class is a perfect example of this. The checker class only takes a single object – whatever object you want to check permissions on. So it doesn’t make sense to run it through $app->make() because it’s just adding overhead. This

$permissions = new Checker($block);

Is exactly the same as this

$permissions = $app->make(Checker::class, ['object' => $block]);

But the second one is a lot harder to read.

Just thought I’d mention this. If you want to read up more on why we use this approach, this document still holds up (even though it talks about Core::make() a lot – that’s exactly the same as $app->make(), it’s just you don’t have to have a $app object to work on.)

http://andrewembler.com/2018/03/automated-dependency-injection-using-containers/

20

Just wanted to let everyone know that a new release candidate has been posted. Here’s a new thread: