- Posts: 296
- Thank you received: 50
Kunena 126.96.36.199 Released - Security release (22 Apr 2019)
The Kunena team has announce the arrival of Kunena 188.8.131.52 [K 184.108.40.206] which is now available for download as a native Joomla extension for J! 3.9.x. This version addresses most of the issues that were discovered in K 5.1 and issues discovered during the development stages of K 5.1. This is a security release.
Please use other categories for questions about problems that you may be having with your website.
Merged When will K 3.1 be released?
You are correct we are not focusing on any tagging mechanism at this time, although that does not mean we have not investigated it.
There is a bit of technical reasoning regarding API, Database Queries, Potential Database Size, Performance, and Security issues as a few topics of why we have not officially attacked the issue of including Tagging. In a less detailed analysis the biggest problem is in regards to performance. Joomla did not implement some parts of the tagging optimally. That is not to say the implementation is horrible and can be useful for specific types of content. Problems exists in the facts that the code design was tested for a specific use-case. At most you usually will have a maximum on a semi-busy site about a few thousand articles over a 5 year lifespan on a semi-busy site. Topics in Forums are different. We can have a amount up to 5,000+ on a semi-busy website because the nature of the content is different. If we use Joomla tags as they are now, the site would come to a crawl in loading times. Joomla tags was just not built for this consideration, it was built for com_content.
As an estimate about the amount of work involved to get a tagging feature done is a lot of time. Please understand implementing a solution will take an estimation of no less of 40-60+ hours of implementation, testing, and optimizations on the current database from a fully versed experienced developer. On a fully volunteer project, something that our few developers are working on at any given moment, that is time and money coming out of our own pocket for FREE. Imagine if that was all billable hours for my colleagues and I, that is a lot of time and money we are giving up to maintain an open source project. Of course our team does not think this way. We are here to work together and have fun building a project, we are here to meet new contributors, and work and meet with people around the world. Our developer and support alone exists in about 10 different countries.
That leads me to a separate part of this topic, the release of Kunena 3.1. Kunena 3.1 suffers from the same issues above, time and money. If I could give a very rough estimate, and this is very rough, for a beta release alone Kunena will take a combined effort of about 60+ hours of work, and that is being extremely optimistic. That is not even to tackle the work during the beta which will take even more time.
As a general suggestion to making General Feedback, especially in regard to an incoming Kunena 3.1 release, it is important to look at the current scope of what is currently being worked on. We do not want to discourage ideas, we all love hearing about them. However our received feedback has always been about things that are very difficult to obtain in a short periods of time and not things that are currently available that can be improved. This leads to issues for us because it creates a "Scope Creep" for our developers because of the focuses of the feedback are elsewhere. This creates a line of questioning and discussion our developers must spend time to analyze, document, and implement, which takes a lot of time in itself. We rather hear suggestions and ideas about the current items the community knows we are working on, but we hear very little of these types of ideas. To emphasize I fully understand that it is hard to give feedback without a beta to test, however it is not that difficult to join the tester team and volunteer your feedback that way.
That leads me to my final remark on the status of Kunena 3.1. We have only had one or two new volunteers in the past year. Before that we would have a few off and on every few months, but never really had new volunteers that commit to help for the long term. As such, there is no denying we need to help, and everyone can help. If you know someone that has experience that can help in a specific area of Kunena bring them our way. We are all friendly here and really want to meet anyone that is interested in Discussion based software. We especially need more experienced developers. The more help the faster we can get the ball rolling.
Overall we are committed to a Stable and Secure project, one that we want the community to enjoy just as much as we enjoy imagining and building it. Hope that puts things in a clearer perspective.
waiting for 3.1 since Q2 2014... looking every 2 weeks or so for new infos. but no chance
i thought the coop with rockettheme and the announcement of special payed plugins would lead to some more specific announcements but no chance...
i ll keep on looking here every 2nd week until its done.
Like I have stated in the past, we are interested in bring people in the project. We are looking for someone that has an ambition for PHP 5.4+ oriented projects regarding experience, and an ability to navigate and understand architecture based code rather than fronted oriented code manipulation.
Why Kunena is too complicated ? Most of the Kunena logic is in /libraries/kunena and extend JObject class, you mean by forward looking by using namespaces and composer ?
I don't provide support by PM, because this can be useful for someone else.
coder4life wrote: We are looking for someone that has an ambition for PHP 5.4+ oriented projects regarding experience, and an ability to navigate and understand architecture based code rather than fronted oriented code manipulation.
Do you have an email or url for the recruitment process?
I will share that info with a couple of developers here in Dominican Republic.
It had better, if we have a „thin” Kunena (like Joomla! 3.4, 3.5, 3.x without main components), which make maximum use of the services of Joomla! (users, topics, editor management), and if we need more features these functions as plugin connect to the system and not in the main code.
Just as a general note, we are already using many Joomla specific classes and extending them for additional functionality (so already simple like you described as we are reusing code.) Unfortunately this is not the case for all code, but again most code was designed with a specific purpose in Joomla. In some areas some classes would perform horribly if we used some of Joomlas specific coding practices with categories for example. We rather take initiatives based on usecase, not because something Joomla is using for specific purpose.
- Not Allowed: to create new topic.
- Not Allowed: to reply.
- Not Allowed: to edit your message.