As a current Composr v10 user, I was initially excited about v11 when it entered development nearly a decade ago, but my v10 site's been chugging along mostly fine (with many modifications to suit the needs of my individual site) the entire time I've been waiting.
As v11 has been in a broken state for quite some time, with the homesite showing users as deleted, not keeping logins, and just looking very wonky; combined with v11 seeming to move in directions that I don't particularly care about (like the complex XML configuration system to allow configuring a dozen different minimum ages for sign-up); I've been considering my options if Composr development were to be abandoned and reached the conclusion that I'd likely prefer to try and incrementally improve on v10 than attempt to deal with the unknowns inside the thousands of commits leading up to the current v11 beta. The bottom line is that I trust v10 to be a stable base, but if I were to take v11 and try to solve all the problems I find with it, I wouldn't necessarily trust that there aren't more problems I'm not seeing in v11.
Firstly, I'm wondering if there are any other v10 users active in the community who are also feeling no particular rush to get to v11 after all this time.
Secondly, I'd like to know if anyone's aware of objective issues with v10 that v11 was meant to address. I'm not talking about hypothetical legal things like the aforementioned sign-up controls (which no major CMS I'm aware of seems to be worrying about quite as much as Composr); I'm talking things like "v10 relies on this PHP function that's going to be removed in PHP 9," or "v10 has a performance issue with this JavaScript that can't be solved without a massive re-write." Security issues can pop up at any time as an unknown, but are there any reasons why v11 would be more future-proof against future exploits than v10?
This isn't meant to disparage any of the Composr developers (particularly Patrick) who've been dutifully working on v11. It's more of a thought experiment and contingency plan, since I wouldn't see a reason to spend the time and effort rebuilding my website on Drupal or something if Composr was to be formally discontinued (but maybe I should see a reason? That's sort of what I'm asking about.)
might have some insight as he's expressed a preference for v10 over v11.
Here are a few issues that v11 addresses about v10 that I can think of off the top of my head:
XSS injection: Composr v10 is quite secure, but v11's new JavaScript framework makes XSS injection attacks very difficult to pull off.
Responsive theme: v10 is not compatible with modern accessibility standards because it is not mobile-friendly. Sure, it has a mobile version. But this design does not automatically respond to different screen sizes. The default theme in v11 does (with a few bugs that still need fixing).
PHP code: The syntax in v10 does not conform to modern PHP standards. It is not type-strict (leading to the potential of many bugs down the road). It uses deprecated methods. And, if people thought the code in v11 was archaic (a comment I get often), v10 is much worse. That means good luck finding people willing to develop in v10's code. Most developers now expect projects to be written in modern frameworks like Laravel or Symphony.
Session handling: Session handling in v10 has always been buggy. I would frequently get logged out when trying to navigate the Admin Zone. I could never fix this. It works better in v11, aside from that cookie issue.
Secure cookies: v10 does not use secure or session cookies where it needs to do so. That's a *huge* security risk in today's age of the internet.
Legal compliance: Please don't brush off the importance of legal compliance. The risk of getting in trouble is low. But the consequences are massive (huge fines that will send any small hobbyist bankrupt). Composr v10 is not GDPR compliant. Any sites running v10 and serving anyone in the EU are technically in violation unless they wrote their own custom Privacy Policy and are diligently enforcing the Online Safety Act themselves. This isn't just limited to the EU; this is the common example. More laws are popping up across the United States and the world.
If someone is willing to develop a better interface for the parental controls system, please do so by all means. XML is not that user-friendly. I chose it because it was the quickest to implement, considering the emerging laws.
The same goes for the menu management system in v11. In the upcoming update, that was also changed to XML. More information is here about why I did that. Again, if someone can make a better interface, please do so. I understand the old one was probably better. However, there was a persistent bug in ordering menu items that I could not fix. This was the best I could come up with to solve the issue.
As you mentioned, PHP 9 will be removing things that v10 relies on. I don't have the time to list all of them out at this time. Of course, this isn't exclusive to v10. I'm sure v11 would need revisions as well.
While it is your choice, please try to give v11 a chance and change what you think needs to be changed. Chris spent many thousands of dollars on developers (including myself) to make it happen. And we spent many hours on it. I feel like starting with v10 without giving v11 a chance is disrespecting all of that effort we put into v11. I'd say consider forking off of v10 only if v11 proves completely unusable and unfixable for you and the community.
Edit 2025-11-15 07:11 EST also:
Less important, but the code overriding system in v10 is much less robust than in v11. In fact, Chris often had to make edits to the original Composr code for custom functionality in his clients' websites despite Composr v10 having a code override system. This makes upgrading to newer versions of Composr much more complicated. My goal with v11 is to make it so that you never have to edit the original Composr code directly (except maybe in very rare circumstances).
Version 10 does not support MySQL/MariaDB InnoDB storage engine. It uses the deprecated MyISAM engine. v11 will almost fully support InnoDB as of 11 beta9.
Version 10 does not have a fully-functioning and legally compliant cookie consent notice. Version 11 will as of beta9.
I will continue to provide updates in the coming weeks. I hope I will find employment somewhere very soon. If that happens, chances are that I can return to Composr on a limited basis.
In the event I do return, obviously, I would be focused on v11. But if you like, instead of forking v10 (as the project wouldn't be dead in that case), we can consider a tag-team of developers; one team supporting legacy Composr v10 (your team) which would also change its status from Long-term maintenance back to "Supported", and the other team supporting v11.
Patrick, thank you for taking the time to break down some of those points.
In my opinion, falling back from an existing GUI to an XML editor for the menu system is a complete failure of UX. If I wanted to write XML, why would I not just have a template for the menu and use HTML in the first place? There was a single bug that you were unable to fix, which seems like it'd be logically feasible to solve in several ways– for example, keeping a flattened index of the menu items as well as a depth value, so when an item is moved, you can just change the position within the main index and then determine the new depth value based on the next item higher in the list. The fact that you were unable to make any solution work because of a single bug despite logically knowing how it should work (and having a working example in v10) suggests the JavaScript "re-structuring" resulted in JavaScript that is fundamentally limited/broken.
The fact that you were unable to make foreign keys work and fell back to "soft keys" also does not inspire confidence. The entire point of foreign key restraints is to prevent bugs. Having to write a separate tool just to scan for and correct bugs that were made possible because of the decision to use soft keys seems overly complex.
These are the kinds of things I'm worried about regarding v11 as a base.
The default theme being responsive will be a great improvement, but I'm fairly confident I could turn off v10's mobile version and make a v10 theme responsive if I wanted to. And the homesite's theme is not very pretty at the moment. Browsing news looks borderline broken as the article images that are really just symbolic icons are stretched to more than double their actual size on the archive page. The loading bars that you've implemented are technically interesting, but in practice make the website feel slower since the bar appears far longer than the visible part of the page needs to render. The logo looks messier than the previous one, and I don't understand why you didn't just keep the previous, professionally created one when nobody entered the logo contest (I did attempt to make a design back then and attempted another more recently, by the way, but I'm no graphic designer, either). As a long-time user, I know how to make Composr look however I want, but I'd imagine prospective users simply comparing the homepages for different CMS's could be turned off by what things currently look like.
Again, I absolutely don't mean to discredit you for all the work you've done towards at least making v11 happen, and I understand that with your current situation, we have what we have unless someone else (myself included) steps up to the plate. I apologize if any of this comes across as rude, as I really do respect the work you've done/are doing and I understand my place as a mostly consumer of the project. I'm just airing my honest thoughts about how I'd view v11 versus v10 in a vacuum today, especially if you were no longer able to work on Composr (and if that doesn't end up being the case, that's great; it's just something I need to consider each time I hear that you might need to stop).
I apologize in advance if I sound grumpy in this reply. I'm quite upset that I still haven't been able to get the issue tracker working (at least I made a lot of progress). But I'm spending more time than I wanted (or should be) trying to fix it. Please do not take my grump as directed towards you. I appreciate your feedback. And discussions like this are important for improving the software for the future.
In my opinion, falling back from an existing GUI to an XML editor for the menu system is a complete failure of UX.
I get that. However, the amount of time I spent trying to resolve the original bug far exceeded what I was willing to give. And frankly, I gave up trying to fix it with the previous UI. In my current state of affairs, I don't have much patience. I can't afford to have much patience. Therefore, I need to cut corners (that's also why I'm pulling Mantis in favour of a native issue tracker; I've had a lot of bugs with trying to integrate Composr v11 with Mantis over the last couple of years). If something takes too long for me to fix, I'll either leave it broken or I'll find an alternative. In the case of menu management, it needed to be fixed. Using XML was the only way I knew how to fix the bug quickly. Once Composr is in a better position regarding developers, we can consider a better UI. I'd rather have an ugly UI than a broken one.
…suggests the JavaScript "re-structuring" resulted in JavaScript that is fundamentally limited/broken.
You are correct. The bug was in the JavaScript. I tried everything I could think of to fix it. And I even tried to have AI check it out. But nothing worked. I still stand by the new JavaScript framework because it's more secure than what was in v10; it made v11 more future-proof to modern XSS threats. The issue is that the developer who worked on it (it was a former developer) made a number of bugs in it. Chris and I have been cleaning it up over the last few years. Unfortunately, Chris knows more about it than I do because he was the one who worked with the former developer; I did not have regular contact with him. So sometimes, it's a guessing game for me.
The fact that you were unable to make foreign keys work and fell back to "soft keys" also does not inspire confidence.
It's not necessarily that I couldn't make them work; I probably could if I wanted. But to make it work, I would have to fundamentally restructure how Composr performs database operations (with constraints, Composr would have to be extremely specific about what order it performs every database operation). There's no way in hell I'm doing that for free in my financial situation; it would take many hours to do.
The next best thing for now is soft keys. You can run the data integrity tool in the upgrade script. And it will clear out most orphaned data for you quickly. The health check will also let you know if any data integrity issues exist (unfortunately, it is more often than I would like, but 99% of it is just Composr not cleaning everything up after deleting something). That took much less time than it would have to implement foreign key constraints.
Having to write a separate tool just to scan for and correct bugs that were made possible because of the decision to use soft keys seems overly complex.
That's not what the tool does. It doesn't fix bugs from the soft keys; the soft keys make it possible for the tool to remove orphaned data that otherwise would sit in your database indefinitely (soft keys tell the tool what fields are related).
Soft keys were actually much less complex than foreign key constraints for the reasons I mentioned in the previous quote. The caveat is that it doesn't prevent data integrity issues on the spot (and right now, that's impossible without restructuring Composr as I mentioned).
Browsing news looks borderline broken as the article images that are really just symbolic icons are stretched to more than double their actual size on the archive page.
I created a tracker issue for that a long time ago. Right now, it's low priority because it's not breaking anything. But I do understand.
The loading bars that you've implemented are technically interesting, but in practice make the website feel slower since the bar appears far longer than the visible part of the page needs to render.
The bar can be disabled in the theme options. It doesn't indicate when the paint is complete; it also accounts for all pending AJAX requests and background resources being loaded. That's why it appears that way.
The logo looks messier than the previous one, and I don't understand why you didn't just keep the previous, professionally created one when nobody entered the logo contest (I did attempt to make a design back then and attempted another more recently, by the way, but I'm no graphic designer, either).
The logo can be changed at any time if anyone wants to contribute alternative designs. I changed it because all of the icons in v11 were redesigned to have a flat appearance. I did not want to reuse the old v10 logo for that reason; it does not suit the look and feel of the v11 default theme.
You don't sound grumpy at all. You're also under no obligation to reply in your current situation. So no worries.
PDStig said
The logo can be changed at any time if anyone wants to contribute alternative designs. I changed it because all of the icons in v11 were redesigned to have a flat appearance. I did not want to reuse the old v10 logo for that reason; it does not suit the look and feel of the v11 default theme.
The main reason I'm able to reply is that I'm online and still working on the new issue tracker. Almost everything is working (basic features, that is). The one thing I cannot get working is migrating attachments over from Mantis, but everything else migrates successfully. I may just have to use the File and Media Library instead of attachments.
The version you used at
Image
(Click to enlarge)
was already much flatter (not sure where it came from)
Honestly, I did not know that existed. The only one I was aware of was the rounded and shiny one. That does look better. But in order for me to incorporate it in v11, it needs to be a PNG with a transparent background. Additionally, I would need a monochrome version (go to the home page on Desktop with the page scrolled at the top… look at the logo when the menu bar is dark).
Are you able to do this? If so, I can plug it into the site and see how it looks.
Yes I am happy with v10 running my website for the next few years. I am happy to remain on PHP8. I was looking forward to v11 as it had many of the issues/features I mentioned on the tracker fixed or added to the v11 branch. I had hoped they would be pushed to v10, but I didn't mind given v11 was just around the corner (so to speak).
I have had a look at v11 (not in depth) and tried to recreate some of the things I have in v10 with no luck. Simple changes are not so simple anymore. A lot of reported v10 issues are still present in the v11 branch and will likely be fixed in v11 despite v10 being the version most people are using right now.
When v11 is finally released I will of course take a look and think about upgrading, but it is no longer something I am in any way relying on. I think ending support for v10 before v11 is anywhere near stable was a mistake, even though I understand the reasons.
I very much appreciate Patrick's efforts since Chris stepped aside, but there is nothing to really congratulate until v11 is production ready. When will that be? Past caring to be honest. It's not that I prefer v10, it's that fact that v10 is what I am relying on today and likely for many tomorrows.
I think ending support for v10 before v11 is anywhere near stable was a mistake, even though I understand the reasons.
I agree. This was a decision made by Chris. I was against it; I wanted to maintain both versions. But I understood his reasons, given that he knew he wouldn't be able to develop Composr anymore (for now).
And given my situation now, I wouldn't have been able to do it anyway.
When will that be? Past caring to be honest. It's not that I prefer v10, it's that fact that v10 is what I am relying on today and likely for many tomorrows.
I've stopped saying when it will be out. I've also stopped making predictions. As you are aware, Chris and I made several predictions. Every single time, life happened, and we could not meet that prediction. I wish it weren't this way, but it is.
0 guests and 0 members have recently viewed this.
Leader-board Top Weekly Earners
The top 3 point earners from 23rd Nov 2025 to 30th Nov 2025.
Last edit: by PDStig
