# Concrete CMS 9.0.2 Coming Next Week
**URL:** https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199
**Category:** Announcements
**Created:** [January 18, 2022, 11:44pm UTC](https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199 "2022-01-18T23:44:21Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@andrew](https://forums.concretecms.org/u/andrew)
#### Post date: [January 18, 2022, 11:44pm UTC](https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199/1 "2022-01-18T23:44:21Z")
We wanted to do something we don’t do very often – give you a heads up about an upcoming release!
We’re happy to announce that Concrete CMS 9.0.2 is scheduled for release next Monday. This release has many bug fixes, improvements to localization under version 9, and many other minor improvements.
If you have any pull requests for minor items that you’ve been sitting on that are ready, now would be a good time to open them up. Can’t promise they’ll make it into 9.0.2 but I’m actively reviewing a number of still open items.
---
### Author:  [@401digital](https://forums.concretecms.org/u/401digital)
#### Post date: [January 19, 2022, 2:09pm UTC](https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199/2 "2022-01-19T14:09:56Z")
Thanks for the updated Andrew. I think I’m going to wait till 9.2 to build out new sites with V9. That way most major bug fixes should be found.
---
### Author:  [@mnakalay](https://forums.concretecms.org/u/mnakalay)
#### Post date: [January 20, 2022, 7:24pm UTC](https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199/3 "2022-01-20T19:24:28Z")
@andrew here’s one I just posted.
>
>
> This one was found totally by accident thanks to Jack Vanson.
>
> If you enable a…dvanced permissions and use a container that wraps its areas in a list and list items \ the area edit menu is broken.
>
> If advanced permissions are not enabled or the areas are wrapped in DIVs there is no problem.
>
> Screenshots below. Full explanation and fix in the PR I'll be pushing in a few minutes.
>
> !\[area-menu-error\](https://user-images.githubusercontent.com/1488833/150406551-146fb20f-b7fe-4251-858a-40421d523943.png)
>
> !\[area-menu-error2\](https://user-images.githubusercontent.com/1488833/150406613-5a0bf289-85f6-436d-ba4a-44588c4061b1.png)
And here’s the fix
>
>
> As explained in #10257 the area edit menu is broken when advanced permissions ar…e enabled and the areas are wrapped in a list and list items \
>
> When advanced permissions are enabled the permissions item appears in the area edit menu. That's the culprit so without advanced permissions we can't see the problem.
>
> The divider just before the permissions item in the menu is wrapped in a left-over \\ that doesn't belong to any \\ so when it ends up inside a list it breaks it.
>
> Removing the extra \\ fixes the problem. Screenshots below. The third one shows the menu fixed.
>
> !\[area-menu-error\](https://user-images.githubusercontent.com/1488833/150407632-f4245ff9-dfed-45b8-aed4-1aa3d9ce4dec.png)
>
> !\[area-menu-error2\](https://user-images.githubusercontent.com/1488833/150407669-2ee9cd27-9ff0-49c6-a0e5-45c3f1ea09d3.png)
>
> !\[area-menu-fix\](https://user-images.githubusercontent.com/1488833/150407692-8e4a1572-6eca-4ff9-9afe-6ca92fd592af.png)
I’m double posting it here since time seems to be of the essence.
---
### Author:  [@mnakalay](https://forums.concretecms.org/u/mnakalay)
#### Post date: [January 24, 2022, 5:58pm UTC](https://forums.concretecms.org/t/concrete-cms-9-0-2-coming-next-week/2199/4 "2022-01-24T17:58:15Z")
Another one
>
>
> Fix to the issue discussed in #10267
> !\[usage-tracker-error\](https://user-image…s.githubusercontent.com/1488833/150837038-8ce16c33-9d87-4c69-bc75-e093566fa353.png)
>
> What happens is the Usage Tracker expects an integer file ID but in the content block images are identified by their UUID.
>
> What's more the block's controller incorrectly typecast the ID as an integer turning the alphanumeric UUID into an integer.
>
> Often it doesn't throw any error although it saves the wrong values in the Usage Tracker table.
>
> In this case, the resulting ID ((42000000000) was too big for the table.
>
> One thing I can't explain is the same UUID turned into 42000000000 on a live server but to a much smaller integer on my local environment. I'm not sure what PHP setting would do that.
>
> This fix does 2 things:
>
> \- it makes sure the block's controller doesn't convert the file ID to an integer
> \- it adds a check in the Usage Tracker class to verify whether we have a UUID or a normal file ID