Umbraco 15, bad idea? Is it another case of far fr...
# help-with-umbraco
j
I'm just wondering what people reckon, would it be a good idea to stay on Umbraco 13? I'm trying using 15 at the moment for a scoping build, but it seem lovely and fast, but also very... rough, a classic Umbraco "new" release so am used to it, but I was a bit taken aback by some of the things that are still not working, like the blocklist clipboard there's no copy button?
Oh dear to add to that, the RTE tiptap doesn't work either... starting to think this is another jump before walking situation ๐Ÿ˜ฆ
s
What's not working with the RTE? I was using it okay. But headlessly
a
Well the change between 14 and 15 is quite little, as 15 is a few extra features that could've released normally, but also a .net upgrade to 9.0
in anyway, if you use any of the features that aren't working properly atm, definitly go for 13, thats why 13 is also the LTS ๐Ÿ™‚
k
Honestly, if your current setup works just fine, steer clear of Umbraco 15 like you would a timeshare salesman lurking in a hotel lobby. The back office UI is in such rough shape it feels like a half-baked beta, and youโ€™ll find yourself dealing with missing features, clunky navigation, and bugs galore. Copy-pasting block grid items? Gone since version 14. Bulk uploading media files? Nope. The new UFM syntax is as flexible as a steel beamโ€”no conditional logic, no access to settings properties, no child item access, no fun. And thatโ€™s not to mention the endless little UI glitches that turn everyday content editing into a scavenger hunt for working functionality. In short, unless youโ€™ve got a high tolerance for frustration, itโ€™s safer (and saner) to stick with Umbraco 13 for now. Version 13 is a polished, beautiful and intuitive product; the opposite couldn't be more true for 15. Hopefully future updates bring relief, but for the moment, version 15 isnโ€™t exactly a five-star experience.
c
I personally wouldn't use Umbraco 15 for a client site yet. In my opinion it is still a work in progress. It is much better than 14 but still not ready for me. The copy-paste block grid is a big one, and I agree the UFM needs more work. I love v13 so will stick with that for a good while until 17. I just hope they fill the gaps in the mean time.
k
We use STS for our own website and LTS for all client stuff. And hoping the next LTS will be "the new 13". ๐Ÿ™‚
s
@CodeSharePaul does that mean Clean Starter Kit is not production ready? ๐Ÿ˜‚
c
Erm, definitely ๐Ÿ˜ƒ, unless it is for your own stuff. It was just meant to be a demo site anyway, as an alternative to the Default Starter Kit from Umbraco
d
Everything @CodeSharePaul said.
s
Thanks for the starter kits folks ๐Ÿ™
j
Yeah totally agree Kevin, seems not much difference in behaviour since the v5 days, I get there will be bugs, but not when they are this glaring. Literally sums it up perfectly a half baked beta and very rough. I knew something was up as soon as I can see the icon to paste an item but not the icon to copy one.. they don't seem to understand that releasing this half done nonsense and expecting the users to test it all etc is not the right way to do it.
d
That's a bit harsh James. They are simply following the release cadence that was decided long ago to follow the .Net releases. This allows the community to use the latest versions of .Net and any new features that it may include. This is especially useful for package developers. Nobody is forcing anybody to use the latest version of Umbraco. Most agencies advise their clients to stick with long-term support if they have complex sites that rely on a number of extensions.
b
Upgrade from v13 to v17 will be rough AF. 15.1 squashed many bugs, but more of them are still over there. Missing features also.
j
Perhaps I expressed my frustration in a bit of an excessive way compared to meaning, but I've been stung by this before. I get that about the LTS versions but that shouldn't mean the STS versions are so broken regardless of significance of changes, think of a dev working in an agency if they released something littered that badly with obvious bugs they'd be fired on the spot... I agree with your sentiments but this is what the RC versions should be used for ๐Ÿ˜€
d
I'm not sure that missing functionality that was available in an earlier version is "broken", just backlog items not completed yet e.g. copy/paste blocks, markup etcโ€ฆ and therefore imho can be released as 'versions' without the rc. It's clearly a massive undertaking to rewrite the entire back office but I'm already seeing a lot of package devs reporting a positive experience compared and definitely glad to move away from Angular JS. I'm sure it would be welcomed if anyone wants to submit a pr with copy and paste blocks ๐Ÿ™‚
k
Hmm, rough why? Disregarding backoffice customizations of course. Or do you mean "rough for editors"?
s
Hey y'all, thank you for the feedback both good and bad, and a for all of you aiming for a positive mindset while talking about a difficult topic like this. I just want to drop few insider nuggets that will hopefully inspire all of you to believe in v15+ as much as we do. - Copy/Paste blocks is coming soon, we have been working on it for a while but it was postponed a few times to make time to remedy some critical bugs. Another reason for it's delay is that it's a bigger feature than before so it can be used outsides of the blocks systems in the future too. - The first cycle (6 weeks) of 2025 will almost exclusively be used by the CMS team to tackle the Issue tracker. This is not just to reduce the amount of bugs remaining in both v13 and v14+ but also to create clarity on the issue tracker so we can tackle new (and old) issues faster once this focus period has ended. One of the big things we are currently losing a lot of time on regarding the issue tracker is reproducing bugs because of lacking descriptions/reproduction steps or figuring out whether something that was reported in i.e. 14.x is still an issue in 15.x We are looking at ways to improve this so when the next big release happens, we will be able to handle a similar big influx of tickets.
s
@Sven Geusens great to hear. Maybe you could a label or similar to issues you need to revalidate in 15.x? Then the community can pitch in and help verify
s
Yeah, we are looking into ways for the community to help us if they feel like it. The biggest help I personally see is: taking an untouched issue that gets reported for v14+ and verify it in the latest 15, adding additional reproduction steps where needed. The biggest things in reproduction that often get overlooked are - The starting point, or the setup of the document/doctypes/datatypes (I have seen the difference a single checkbox can make more than I can count) - Complete drop in code examples that showcase the issue instead of some method names here and there, or an image of the code example. Both of these have to do with the intrinsic nature of people to assume things because they are familiar with their way of doing things. This might seem small but it adds up over 100s of issues, especially if you consider the extra effort in having to keep track/revisit/retry tickets that were incomplete. In an ideal world we would have a unit/integration/e2e tests that shows the issue so we can add it to the testsuites to also make sure it doesn't happen again. But this is asking to much i think, although there will be some who get a kick out of it.
b
just my 2 cents: i tried today umbraco 15 just to take a look to the new custom backoffice sections and so on...i admit, i was disappointed when i discovered that 2 major releases were made in so little time, i thought that the release plan was to follow .net releases, but for the new backoffice was added another middle release. Found missing and lacking documentation with a lot of 404 pages on linked guides to get knowledge of new mode to create section and dashboards. We own several middle to big project with umbraco as CMS backoffice with a lot of customizations, now we can't move to 14 and 15, not only cause of the new backoffice but cause of the big amount of bugs we found around, and we can't move to .net 9 cause there will not be a .net 9 version that will follow v13 (that i found a pretty good and strong release). I'm using umbraco till v4 and I am saddened to see that decisions on how to carry out releases and updates over time continue to create obstacles for those who use the CMS beyond just a simple small site. In my opinion, you should have considered maintaining a 'legacy' version updated on new frameworks at least to cover this situation. We'll see how it goes in the future, but as always, I am very frustrated by this behavior.
a
You all know how the releases work.. and its a good approach imho
Especially for people who use umbraco for large websites
Now you have your LTS that safe
It makes it better then ever
In the old days you had major upgrades everytime a version was bumped and the difficulties associated with that
Upgrading from 4 to 6/7... to 8.. to 9 all lots of changes
And the new backoffice is probably the biggest change since moving to away from xslt, effecting the very core of your umbraco sites
So yea.. it needs work, it needs testing, hence the v14/15/16 path
k
AFAIK you can use net9 with U13 just fine. We do this. Is that officially unsupported?
m
You might find some packages use .net versions as a way of multi targeting. But the as you say won't effect 13
l
As an agency, by default we are sticking to the LTS versions. However, when we start a new project, we cannot start a new project in an old LTS version when a new LTS version is on the horizon. If we deliver a new site to a customer and in a few months or half a year they would have to invest again to upgrade to the next LTS version, they wouldn't really like it. So by default, if a custom is on LTS, they by default stay on LTS unless they decide otherwise. New projects are done on the latest Umbraco to make sure we're not developing anything that is already outdated. Once that project is delivered and upgraded to the latest LTS it's up to the customer. Our packages follow the release cadence of Umbraco. So once a new major version is released, we more or less stop feature development on older packages.
b
Right, never happened in the past that umbraco team rolled out versions that shouldn't be rolled out (v5?). The complain is not about updating the backoffice, is about "why roll out a major between 13 and 15 with the new backoffice and .net 8 that is totally unreliable (and as i read probably v15 too is still not reliable). I really don't see advantages about doing this, why not keep it on a beta (or alpha) version and roll out when all is fine? they waited so long to port all the CMS to .net core, why now be in hurry releasing this version? i really don't understand, i only feel from old time umbraco user that this does not care about professionals use of the CMS...this make me feel like they don't care about causing problems to the real and final users...yes we have an LTS, but LTS and and STS it doesn't mean the STS is "experimental", i should be able to upgrade to the STS without worries about stability and realiability. And another storically problem was about documentation and incomplete/missing/outdated informations...this will not help that problem for sure. @kdx-perbol yes probably, i will try that, the thing is that now i know we'll be stucked to version 13 for indefinite time
y
An issue which is not being discussed here, is that the V13 security phase ends in less than a year, and the end of life is less than 2 years away.... They have created a huge problem for themselves where by next to no one will want to create a site in Umbraco this year ๐Ÿคทโ€โ™‚๏ธ Can't use V13 as it's about to be dropped. Can't use the new version because it's not ready (And a lot of people don't like it ๐Ÿ˜‰). I have no idea why V13 cannot be updated to .Net9. This would be a great thing to do, and we would get a decent performance improvement for free (Then bump both security and EOL back a year).
j
@Sven Geusens > The starting point, or the setup of the document/doctypes/datatypes (I have seen the difference a single checkbox can make more than I can count) What's the best way to do this? Its a lot of work to clone and start a project, then create document types and configure them to repro and then type out what you did in text. It would be nice to be able to make minimal reproduction or have a starter template with all the different editors created for quicker issue creation/common starting point
s
If you use uSync or Deploy they both have means of exporting an entire site. Other than that, you can temporarily install this package: https://marketplace.umbraco.com/package/umbraco.community.schemex.exporter This lets you easily export an entire site as a package.xml, which can be installed in any site using either code or other third party packages.
j
@skttl - yeah, that would work (should probably not be Deploy if Umbraco wants open source contributions). I think this should be included in the contribution/issue template with a minimal starter package. This way the quality of future bug reports could maybe be improved
k
just because someone said uSync ;) - if you are building v13 sites with the latest features (e.g blockgrid not grid, block lists no nested content) then the upgrade path to the v14/15 versions shouldn't be to bad when you need it to happen, there are very few diffrences, the core migrations in Umbraco do stuff, and uSync will also migrate the small changes 'inline' so you can in theory pick up the v13 uSync files and use them on a v15 site (we've tested this, and it 'works' but obviously iof there are edge cases, we would also fix / take pr's to fix them).
l
@Kevin Jump would you say that uSync for Umbraco 15 is just as good and stable as on 13? And what is your opinion on 15 so far?
t
@Kevin Jump thanks for your work on usync! Any guidance on if/how it can help with migration of RTE Macros to the new RTE blocks? Hoping to do an in place v13 migration in prep for moving to v16 (given 15 still has some ground to cover). Figure this could be a challenge for others in this thread too.
s
I know it can be a lot of work to get the setup just right, now imagine how much harder it would be when you don't even have correct instructions ๐Ÿ˜… Like others said you can use certain tools to export a full site. Or you can give a video recording (with some 1s pauses on each screen after configuring for easy pausing). I don't think using a starter template, outside of the dotnet new template gives a lot of value. It might even have settings/code different from the default that might alter the outcome.
j
Would it not help to document/suggest how you would prefer repro instructions? I would imagine that you would get higher quality issues if you provided users with a recipe. As a issue reporter, I would not be comfortable using uSync for repro instructions, if its not documented in the issue creation instructions - as I would assume maintainers would not use a 3rd party tool.
j
Well this certainly blew up! Obviously I was in a rather frustrated state when I made this topic, although it seems to have created some valuable discussion so I am glad about that, I will be looking to see what I can do to help for sure, also can I just say @Kevin Jump as ever we've spoken back when uSync Migrate was the out of this world idea, uSync and the Migrations along with it are such a fantastic lifesaver its unreal, so just wanted to expose some gratitude as towards the end of last year I used it on a project which was far more complex than initially it was lead to be and uSync made things so much easier ๐Ÿ™‚
s
The recipe is right there when you create a bug report. https://github.com/umbraco/Umbraco-CMS/issues/new?template=01_bug_report.yml We explicitly don't want to be too prescriptive as overwhelming people with all kinds of ways to make the "perfect" bug report actively stops them from even trying. I've certainly entered GitHub issue sections where the instructions were just too much work and I gave up on reporting as I assumed I'd just get yelled at for not doing it "correctly". When a report comes in and we don't immediately get enough information we can always ask for more and suggest ways to provide a better reproduction.
j
Yeah, I was just responding to this: > One of the big things we are currently losing a lot of time on regarding the issue tracker is reproducing bugs because of lacking descriptions/reproduction steps or figuring out whether something that was reported in i.e. 14.x is still an issue in 15.x We are looking at ways to improve this so when the next big release happens, we will be able to handle a similar big influx of tickets. Totally agree that forcing people to do specific ways is not a good idea, for the reasons you write. I was just hoping for some guidelines on how we, as issue reporters, could make your life easier by using specific tools/workflow for reporting issues (ie usync export or whatever tool you prefer).
459 Views