There have been several bugs breaking the Lucee admin lately which could only happen because the Lucee developers are not using Lucee’s most strict configuration settings when developing the admin code. They probably have it set to the legacy defaults you get with a fresh installation. I have to frequently disable Lucee’s modern features and switch off security features just to get the admin features to work. Sometimes they still don’t work, so I wonder why is so much broken admin code being accepted into the git project. It’s too fragile the way it is being developed right now. The Java is much higher quality then the CFML in the admin. I think that’s because it doesn’t use any of the things that help make CFML cleaner.
I don’t think it makes sense for Lucee core to be written in legacy CFML code styles to make itself work. Switching all of those urls with .cfm to .cfc with functions that always have localmode=“modern” or using lucee dialect would go a long way towards fixing the problem.
I think the authoring of the Lucee admin cfml code could should be based off the most strict version of the Lucee compiler and internal validation configuration settings.
For example, info.bundle.list.cfm has #createdAsString# in it right now instead of #bundles.createdAsString#. This prevents us from disabling “Search Resultsets” on the Scope admin page. The page just fails to load when you do. A minor issue, but numerous times, I’ve been unable to use features of the admin without going back to default configuration on almost every release in the last year or two. Almost every page has been broken at one point from this same pattern of bugs. I try to run off the newest snapshots all the time, which is part of why I see these issues, but it would make sense for people to commit work that is in a better state of polish for the admin code. I want to help fix the bugs and keep it cleaner. I submitted a fix for the security page and the debugger so far. The whole thing could use a syntax modernization effort though.
Sometimes people have used createobject(“java”) instead of using/making a cfadmin equivalent. Direct access of java member functions when the user has java disabled is also bad. There have been several quality/incomplete work issues creeping into the admin pages. I try to adopt the more modern Lucee style features, but the admin code is fighting against being modern & secure currently.
It would be better if this pattern of bugs was prevented from coming up again through some kind of management decision to establish a uniform environment configuration for all the Lucee developers so we all build changes according to a single standard configuration that is most compatible with all configurations. For example, there could be documentation of the right settings on each lucee admin page or strictly write new code in lucee dialect and translate them all to it. You could also refuse to accept new code that does direct java access when it is committed. And work to eliminate all the bugs that are incompatible with this new configuration as time permits.
The only other way to get the admin to stay working and compatible would be to make the admin code able to run in a separate context that the developers can’t modify the configuration of which is then given permission to write to the xml out to any of the other contexts. This wouldn’t be modern, but it would sweep the dirt under the carpet really well.