I will be setting aside some time in a few weeks to work on Q2A some more. The few changes I already made will be part of 1.7 (instead of 1.6.4) as there is a change in the mimimum PHP version requirement (now 5.1.6).
So as with previous threads, please post the top features you wish to see in Question2Answer!
I do have a few ideas already planned, so there is no need to suggest these, unless you have a particular comment on them:
Thanks in advance for the feedback!
Ordered by my priority
1. I'd like to see an increase in category depth, say to 10 or even unlimited?
2. it would be good if there were a means to 'assign' a category, to a specific 'user' rather than for example, any Joe Bloggs with the same number of points/rank level etc...
3. Can the 'fluidity' (user experience etc.) of the PM and Wall messaging systems be improved. Perhaps brought out of the dark depths and into the light of the logged in user's home page?
Not sure if any of the above is even 'doable' (esp' No2/3) But thanks for asking for ideas to potentially include and thanks too, for the hard work put into this project!
1 Where you ask the first line of your question box the box expand as you type so you can see what you type instead of running off the edge where you cant see anything...
2 Built in spell checker that works in (all) areas that you type
3 users have the ability to delete their own questions and comments no time limit
4 users have the ability to totally block other users
5 admin's can creates private question areas for selected groups...
6 remove 800 characters restriction and increase to 2500 or more...
7 also if you update to the ck editor please make certain there is no time limit on how long a person has to edit their files ...
I know this is not directly answering the question but is very related. I will provide a more detailed suggestion later but now I have to run. However, I strongly believe, regardless of the features you add, avoid the output of HTML from the core. That only leads to issues, complexity, and worse, such as HTML parsing :'(
HTML should be handled in the theme talking in an API-like way with the core. I'd like to see that in Q2A 2.0 but the more HTML is output from the core now the more HTML will be removed in the future.
Another related architectural change (this one could be aimed at 1.7) is being able to do so in a plugin. I mean, writing an API-layer that talks with a Frontend-layer. That way, the API-layer will modify the qa_content data and send it to the the frontend-Layer, allowing for extremely further plugin customisation and even allow 3rd parties to provide different look and feel for plugins :)
Hopefully, you know what I mean... gotta run now.
1. Regarding an API-Like core, it can be better explained with an example. See this comment. As you can see, the core is returning HTML which is not allowing easy and appropriate customization of how to respond to that change. Removing that voting delay is, IMO, a great improvement. Also think that (I haven't looked at that part of the code but I guess this should apply) if the core returns HTML then the core is telling the theme HOW things should look like, while, the theme is the one it should be in charge of that. Any piece of HTML returned by the core is actually an example of this situation.
2. Regarding the second part, the one about the plugins, it aims at applying a similar logic to the one above to the plugins. When you write a plugin that uses a module (I'm thinking particularly on a layer, actually), you code your plugin logic, as well as your front end logic, inside the same function. Now, if I wanted to change how the output of the plugin looks like (not just CSS, think even about HTML) then I should have to rewrite the layer that the plugin logic inside in order to make frontend changes. If I had a 2-level processing here I could first apply plugin logic into the qa_content array and then consume whatever I have added or changed there from the second step layer which would only be in charge of generating frontend from the previous input.
Having this 2-level layers would allow users to write their own look and feels on the plugins (not only CSS but also HTML) so that plugins have a close look and feel to the users websites. This would be a similar feature as a theme but applied to a plugin. But why doesn't the current layers allow this? It is just a matter of order. API-Layers need to be executed before Frontend-Layers and it is not possible to control this order right now. I can't think of an appropriate fix for this situation... the most flexible, and probably easiest one, would be adding something similar to a CSS z-index to advice plugin loading order. That way I could use currently existing layers and load them in my specified order to make sure the API-Layer executes before my Frontend-Layer.
3. A serious issue is encapsulation. I took a few random plugins (not the ones distributed with the core) and I couldn't believe the huge amount of code that was present in the qa-plugin.php file. That is not good because every function there is accessible everywhere. That can lead to plugins defining functions that already existed. I even saw someone checking if the function already existed before defining it. That is indeed a pain in the neck. However, I understand that from the point of view in which there is certain logic that should be shared among all the modules. However, how can you share functionality (and even data) among different modules an a simple and up to date way? Using classes. I use the qa-plugin.php file to include all paths my plugin will need and in each of them I have my plugin model (the view and controller are handled by the modules). This approach could be used by the core and in your qa-plugin.php file you would only register which paths you want to load classes/files from (check spl_autoload_register function por more info).
5. Related to item 1 and 2 a template engine should be included in the core. Most popular, AFAIK, is smarty but might be harder to install (I haven't used it for many years, though). Anyway, any template engine will result in view separation from the core.
6. Deprecation is our friend. Deprecation means saying Hey! This has been improved and hence, will be removed in a future version. Of course, if a plugin uses that it will stop working in a future version. However, the core will be cleaner and easier to mainting and, of course, more up to date as it won't have to cope with old ways of doing stuff. Without deprecation we would still have our brand new electric cars but they would still have holes in the floor just in case people want to push them like the Flintstones. IMO, there are functions in the core that should be deprecated (I've actually made a pull request for one in the past). Now, in order for developers to be able to update their plugins, deprecation should first be notified (IMO, the changelog is the best place... by far), e.g., a 1.6.x changelog could state Function qa_blah_blah has been deprecated in favor of qa_improved_blah_blah. The function will be removed in v1.8. A double version step I think that should be enough for developers to make the (usually small) changes.
7. I believe you should ask an additional question, similar to this one, but strictly related to architectural changes as I don't think any non-developer would understand any of the points I've mentioned before but would, of course, benefit from them much more than adding a small feature to the core. Also take into account that, as gideon has stepped aside, you (Scott) have more weight on your shoulders and you just can't add even half of the features that have already been requested in this question. Only option would be for plugin developers to handle them. Making things easier for plugin developers will lead to more variety and features, not in the core, but as plugins.
Hopefully this helps clarify the ideas I've proposed.
1. Development policy
Q2A should be breaked the spell of WP. I thinks Q2A should aim big system located in the high rank (not low rank !) of WP like Facebook and Twitter, Quora, Stackoverflow.
2. Change of handling of EXTERNAL USER
I want to abolish QA_FINAL_EXTERNAL_USERS and to change processing. I like code of Gid very much, but do not like codes of this part. This part obstructs addon development. And it causes very many obstacles.
3. API feature
I overlap with pupi1985. I think that API feature should be strengthened. I suggested it to Gid from old days, too, but do not come true. I want SORP (XML) interface to exchange data with another system.
4. Websockets interface
Great News...Thank You.
Please add easy upgrade method to this new 1.7. Because current method is little difficult and confuse (for me). It will be marvelous if we have one click upgrade method for this new version.
Great news Scott!,
Very first thing you already metnion about the Responsive theme, Yes I will be working on this.
Here below few more things I would like to see in next version. Not sure how much it would be doable in terms of time and effort.
Probably will add some more later.
Thanks for your effort :)
EDIT: I believe you will modify markup from HTML4 to HTML5
Different types of questions (like multiple choice - true/false - fiil the blank etc).
Of course the answers must be hidden from any user until he/she answer on the question....
Welcome to the Q&A site for Question2Answer.
If you have a question about Q2A, please ask here, in English.
To report a bug, please create a new issue on Github or ask a question here with the bug tag.
If you just want to try Q2A, please use the demo site.