I am not fully aware (yet) how this will impact how I use Composr now (very early in my deployment) or into the future (which will be forum intense), but I hope you keep in mind I switched from Drupal as the forum functions there where not strong, where they appeared to be very strong here.
What impact will this have on forum function, and hence useability, I hope little?
This is not related to our forum, it is related to our optional integration with other forums (phpBB etc).
By Guest,
By Guest,
posted
Good.
By Guest,
By Guest,
posted
I think this is an excellent idea as the current situation just wastes resources better spent elsewhere. As noted, there are converters for most the major forum systems and people with budgets will be able to pay to have any necessary changes made or to add a new importer for a foreign forum system. If there is much demand for forum drivers or converters not already available, this could be a great business opportunity for a third-party service (i.e., a paid service).
By Guest,
By Guest,
posted
I think if keeping it hampers development then drop it however I think it is a feature that really separates Composr from all the competition and if possible it should remain no matter how little it is utilized. I started out with the thought of using the integration product and ended up just using Composrs own forum but it was the choice that attracted me.
By Guest,
By Guest,
posted
I agree with Bob entirely on this.
Furthermore, the concept of a CMS is to manage content and there is nothing more massive than forum posts which requires perfect integration with the rest of the bits and pieces of information scattered on a vibrant website. The existing ability of Conversr to handle all this magnificently is rendered inefficient by using a third party forum. In fact it goes against the grain of what is Composr in the first place. I can appreciate situations such as the one Doc is referring to when there is little choice but to integrate a substantial existing forum with Composr as a first porting step, and in those cases I would advocate also using third party integration tools made by users interested by this functionality with some limited template guidance from Composr.
This is not going to be implemented for now. v10 still works very well with the forum driver system, it doesn't really cause any harm. The use case of people wanting a CMS for a third party forum still exists. There are new forums out there that we don't support, but we potentially might.
So I am happy to leave it all as a special case. We will generally talk about the forum and mean Conversr (which is actually being renamed in v10). i.e. preference will be given towards Conversr users in our documentation when we're trying to simplify our explanations.
I think the best approach is to mark them all non-supported. Then people are on their own (or can find a developer) if they want it. The forum driver layer is useful in principle, but the ongoing maintenance of all the drivers, for what is a poor user experience compared to current user expectations, can't really be justified anymore.
Why keep them bundled in the system in the first place is beyond me. When I first came to Composr so many years ago I was looking for the forum drivers in the downloads - only to find out that they were built into the system which I thought was odd. Wouldn't it be possible to not have them embedded automatically but as part of an optional module that can be added either via downloading it or during installation? And to open it up so that third parties can make their own forum drivers if they want to work with Composr/ComposrCMS?
I think it is insane how much code you guys maintain on your own as it is...
Well, it's a lot easier to just keep them in git, otherwise we need some way of the installing them during the installer, or some custom installer building system that is quick/easy for maintainers to use. Also keeping them in git makes maintenance easy as they are subject to any search and replaces etc we have to do in the wider codebase.
What could happen is they could become 'unsupported', like the non-MySQL database drivers are, and then it would be discretionary whether bugs were fixed etc.
What impact will this have on forum function, and hence useability, I hope little?
Furthermore, the concept of a CMS is to manage content and there is nothing more massive than forum posts which requires perfect integration with the rest of the bits and pieces of information scattered on a vibrant website. The existing ability of Conversr to handle all this magnificently is rendered inefficient by using a third party forum. In fact it goes against the grain of what is Composr in the first place. I can appreciate situations such as the one Doc is referring to when there is little choice but to integrate a substantial existing forum with Composr as a first porting step, and in those cases I would advocate also using third party integration tools made by users interested by this functionality with some limited template guidance from Composr.
Remove most use of the term 'Conversr' from UI and documentation.
So I am happy to leave it all as a special case. We will generally talk about the forum and mean Conversr (which is actually being renamed in v10). i.e. preference will be given towards Conversr users in our documentation when we're trying to simplify our explanations.
I think it is insane how much code you guys maintain on your own as it is...
What could happen is they could become 'unsupported', like the non-MySQL database drivers are, and then it would be discretionary whether bugs were fixed etc.