Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+67 votes
in Q2A Core by
closed by

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:

  • Switch to mysqli (already done).
  • Speed up loading of questions with many answers/comments.
  • Upgrade to latest CKeditor (v4.3).
  • Make default theme responsive (I believe Jatin will be working on this).
  • More flexible custom HTML areas (e.g. something similar to my Widget Anywhere plugin).

Thanks in advance for the feedback!

closed with the note: Old version
I want QandA to be avaivable for godaddy shared hosting.
To complete the list:
8. Feature Request: META description for custom pages http://www.question2answer.org/qa/35237/feature-request-meta-description-for-custom-pages
9. Make "Delete" Post procedure clear to all users - using the tooltip http://www.question2answer.org/qa/35259/make-delete-post-procedure-clear-all-users-using-the-tooltip
10. Implement the open source plugin on-site-notifications http://www.question2answer.org/qa/33712/free-plugin-notifications-facebook-stackoverflow-testing
11. Adding a date field to qa_uservotes http://www.question2answer.org/qa/35295/adding-a-date-field-to-qa_uservotes
@Juli Fier

Did you mean provided by GoDaddy or just usable period.  I am using GD as my hosting provider and it works great.
edited by
# little contribution. I have been searching for the language php files that contain the language but couldn't find them.
# The script is hardest and badest writing to understand. I was wondering if I can use this script for other purpose other than question and answers. I wanted to use it  for classified Ads site. just to change the languages. Any help on this?
# Also recent topic is not a good ideal for someone who has opposite categories.
Example Like math category, english category,  physics category.
And someone who is only interested in math category the home will be mess. As he will be seeing threads on recent topic that does not warrant the attention and it might it might not be topic he really don't want to see.  There for while not including subscribe to categories that should be on recent topic.
I have seen a forum that has this on user profile to select and mark from with check box.
This subscribe category will be on recent topic.
# again a more mobile friendly and easy rich test editor area, as it is currently its not good.
Invite web crawling that scan user email address book and send friend request. Hey your friend is on xxx.com you might want to try it out. Just like linkedin.
# Statistics for total guest and user currently online and their current location. Total number of user visit for each day in a data base static view in form of calendar,  mention of user id. And there user will get notifications that his name has been mention.
# sticky. Sticky of topics
# announcement, admin global and category announcement
# 'New' in hyperlink at the end on each topic to take you down to the new post of the topic since you last visited the topic.
# Simple image attach.

119 Answers

+15 votes

Wow !

Ordered by my priority smiley

  • ability to merge 2 user accounts (see here )
  • comment voting (+ points system integration) (see stackoverflow)
  • custom plugin pages managed as standard pages (so to be able for example to add easily a widget to a custom page using standard q2a features) ( see here )


Thanks Scott 

Merge 2 accounts is great. Is it same as merge a facebook connect account with another account?
Yes. It's about having a unique q2a profile and using multiple authentication methods to access to it.  Users can "connect" to q2a with their social profiles, and have the possibility of using a unique account linked to multiple social logins (---> here the need of merging a new account with an existing account instead of deleting it). Once you have the authorizations from the user's social profiles, you could think of beginning to push/pull data to/from social sites ... Presently only some basic profile infos are pulled. An "open" q2a... :-)
NoahY did a plugin for comment voting: https://github.com/NoahY/q2a-comment-voting
Thanks Kai.
I had installed it, but it's full of issues and it's not integrated in the q2a core mechanisms (mainly : points system, events).
However I think that this should be a core feature....
+1 for full comment voting.
+5 votes

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!


I got intrigued about your comment. It makes sense that the number is fixed. However, it doesn't make sense that you can't change that number in the core. I took a quick look at the code and, indeed, all my previous guesses were right. However, in DB terms it is absolutely possible to have a high number of categories by just joining again with the categories table.

HOWEVER, the core is not designed to work that way. To give you an example of why this is not easy to implement in the core think about a chain of categories where only one child is allowed but you can have infinite levels of depth. You also have category names and category levels that are explicitly input by adding parents/children, as you do now. Now suppose you call the first category LEVEL "1" (note the level is not the category NAME), the second "2", etc. If I asked you "what is the tenth category NAME called?" You'd say: "First I will look for the LEVEL '10' category and then get its NAME". That would easily solve the issue.

Now, same example as before. Only difference is that instead of "1" I call the first category "parent", the second one "grandparent", etc. In order to answer the same question you'll have to know how I named the tenth LEVEL... and, as you can imagine... it would even be hard to write.

For some reason, this has been the approach in which the core has been developed. You can see that in line 879 of the file qa-db-selects.php. Split the lines on JOIN and WHERE. You'll see that there is a repeated JOIN there: "JOIN ^categories AS parent ON" and for the next level there is a "JOIN ^categories AS grandparent". These 2 are so similar... that could be written this way: "JOIN ^categories AS level_X" where X stands for the depth level that each join is fetching and then you can dynamically add more JOINs one for each level requested.

You could change that behaviour... however you'll need to also modify every piece of code that uses it (eg: the recalculations and who knows where else it is used). Anyway... I'd go for nested sets or any other alternative (http://stackoverflow.com/questions/4048151) rather than adding more joins.

Hopefully this is clearer now :)
Thanks for giving this more thought pupi...

Your eloquent explanation has clarified several points for me and I can see clearly, how the scenario in naming the categories 'parent/grandparent' (para' 3) would play out in terms of complexity. Effectively, a dog chasing it's tail?

Your suggestions in 4&5 do seem 'doable' for sure. But as you imply, any changes would have to be done everywhere the 'calls/joins' were made... Pretty daunting!

Thanks for the time put into explanation and also the link... I'll look into that later.
I haven't looked into categories too much but the problem with infinite nesting is basically the recursion problem. Currently the qa_posts table stores the 3 levels of categories in 3 fields. With infinite nesting you can only store the bottom category, but then you need to run query after query trying to find the parent, grandparent, great-grandparent category and so on.

Are you sure you really need 10+ levels of nesting? That seems like it would be ridiculously complex to use, even for advanced users.
Thanks for the query on this Scott...

In some respects, I was attempting to crack a nut, with a sledge-hammer. So, I will explain the reason behind what I now see as an absurd request, following pupi's reasoning. Test experiments and now your mentioning recursion in respect of deeply nested categories.

Firstly, rather than a Q&A site, per se. I am 'adapting' the software to act as a poetry read and review site e.g. Q = Poem & Answer = Review with comments and replies remaining as provided.

In an ideal world. I have been trying to figure a way to provide users with their own 'work area' and inherently, the core structure doesn't allow for that? As a possible work-around. It looked like I could rename 'All Categories' to something like (Site Poets) and from 'admin' I could assign a user to his/her user name (as a category name) and thus provide a box, or work space into which only they could post their work.

In a test sense. This works (to a degree) but I realise now. That (1) There would be a horrendously long 'All Categories/Site Poets' list. (2) My idea of using category sub-navigation to lessen the visual effect of implementing point one is untenable, even if I discount what has been discussed here, since I made the request... I was quite naive enough to think that I could simply think in terms of: Parent=Nature, Sub Cat=a,b,c to whatever assigned to user A, B, and C under the respective parent.

Initially, I thought that to have asked for the ability to assign effective user space was a bit much to ask for and decided, that my request was asking for the lesser of two evils. Instead, I have inadvertently drawn attention away from other 'doable' and far more reasonable requests... I should apologise for that at least.

I am sincerely grateful for pupi's input on this and of course for your own now. It is reasonable to say my request for category expansion, is both unreasonable and invalid for the purpose of your original posting.


+7 votes
edited by

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 do wont this to. as some of my question and answer are over 800
Did you mean you want to do this to  ?
Id like to see a check box to allow default and text field to enter max char limit  to answers would be best, definately placed in Admin section.  Not unlimited, but larger.
+14 votes
One of the most important features I want in q2a is a notification system. Q2A offers points system and many times visitors don't even get to know that they are actually getting points and badges for their participation on q2a websites. So it is one of the most needed feature.

I know that there is a plugin for this but that is paid and it costs too much. And if someone else is making a plugin for this then that's also good. But if would be real good if notification system would be an integral part of q2a core instead of a plugin.
yes its strongly  needed. Please do some thing for notification.
I agree its needed too!
NoahY has a free plugin called "Q2A history" for this.
Well now a one more plugin is there ie. On-site-notification and I am using that as well. But it would be better if notification system is a part of core instead of a plugin.
+7 votes
edited by
  • Ability for user to select how to sort answers, by time or by votes in question page.
  • More flexible questions sorting (i think it's really hard to do that becouse of logging ?):
Category, tag, search etc... pages > Most votes, Most answers Most views > ...of week, of three  months, of year, all time.
  • Tags descriptions with ckeditor.
  • Threaded comments. And comment voting maybe ?
  • CKeditor for custom pages.
Whant the same!
+2 votes
Thanks, Scott.  Maybe this already exists but I am looking for a way to block hourly spam answers and comments where the sender keeps changing ip and username and most post data.  The only common repeated content seems to be for "Michael Kors" a clothing label.  I banned the word "Kors", and continue to block ip's after the fact, but haven't found a way to block a post with the banned word (or a banned link).  If you don't add some feature like this could you advise where to insert some kind of filtering code.  I might be able to stumble through to a solution.
You can set up a filter plugin for post contents. For user accounts, see here: http://www.question2answer.org/qa/27723/dont-allow-people-to-register-with-some-usernames-like-admin (sounds like you're already doing this).

You can do something similar using filter_question or filter_answer, see the Q2A docs for more details.
Thanks, Scott.  I'll try this.
+9 votes
edited by

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.

More detail

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).

4. Formalize conventions somewhere. Underneath all the technological and missing feature issues there is this cultural issue. Everybody does what they want and that only leads to more troubIe. Related to the previous item, we can still have issues with repeated PHP class names, repeated variable and function names in JavaScript, repeated HTML name attribute for input fields, repeated CSS class names as well as ids, etc. First thing a developer MUST DO when writing a plugin is choosing a plugin id/prefix. That should be a somehow short piece of text that will prefix every piece of shared code so that all the previosly mentioned repeated element do not get repeated (eg: there could be 2 plugins using the id save_button but the developers would prefix it with their plugin prefixes avoiding duplication plugin1_save_button and plugin2_save_button.

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.

For the first part, do you have any examples?
For the last part, do you mean something different to the theme layers already possible with plugins?
I've added the "More detail" section to clarify this a little bit more :)
edited by
Thanks for expanding on your answer, pupi. In response to the points:

1. The HTML returned in your voting example *is* using the theme.
However there are a few other places where HTML is actually in the core (such as some of the <span> elements around the when/who metadata) so I'll look into rooting those out.

2. The problems here seem to be different for every type of plugin. Widget plugins for example, return HTML from the output_widget function, but page plugins basically add content to $qa_content['custom'] or $qa_content['form']. I suppose there might be a way to utilize layer plugins to keep all HTML output in there (e.g. as if the function was already in qa-the-base.php).

3. This is really something plugin authors should fix.
The proper solution would be namespaces but we are not supporting PHP 5.3 yet. For now separate functions should be kept to a separate file, inside a (static) class. Then theoretically they can be included and called from any other plugin.

4. Again this would be solved with namespaces. Luckily so far there have not been many (if any) naming clashes. Most plugins tend to use prefixes but maybe there could be something in the docs about it.

5. The current favourite in the PHP community seem to be Twig, which I have briefly used and it's good. However, there is a big issue with structure - currently we have the theme class which can be overwritten at a very fine grained level, which a templating system isn't able to accomplish. I've discussed this with Gideon and we haven't found a good solution as yet.

6. Absolutely, this is something I plan on doing.

7. It's fine to post architectural changes in here, but feel free to start a new question if you need more room to explain your ideas. BTW at some point I'm planning to reorganise the file structure in qa-include/ a bit.
Oh, "edited 6 days ago". I had the chance to complain before and I didn't! That's so not me. I must be getting old :) JK

1. I take your word on that :) Anyway there are more "silly" examples about uncomfortable HTML code in the core. Just try to remove the plus sign before votes (which I personally hate) directly from the core and then try the same using a plugin (not overrides or jQuery allowed!).

2. You have a good point on the fact that plugins are different. However, I don't think the type matters. They just need to be consistent. IMO, plugins should be clear in what they input and what they output (even if they output to the qa_content array). EG: An API-layer (to call it some way) might take as input the core (without HTML...) as the qa_content array and operate on that data. The output would be the modified qa_content array. Those changes will not be HTML code but rather more raw data. Once all API-layers modules are done then the process goes more or less how it is designed now. The theme and the (Frontened) layers execute and their input is raw data and their output is the HTML code. It is possible to fake this behaviour, though. It is not the same but you could split your theme method override in 2 parts: one for the backend that updates the qa_content and another one for the frontend to handle the HTML output (ideally using a template engine). I've been doing this and is proven to be considerable comfortable to work with.

3. Yes, I agree. What I was saying is that in order to avoid including those classes the old way, probably the core would have some way of registering them and the plugin, when loading, would send the core the strings of the directories to look for classes, when needed. Nevermind, silly request particularly considering the fact of the namespaces.

5. Twig, I've heard of it. I guess the theme class is not the issue itself. Without giving it a deep thought I'd say the main issue is plugin handling, and how they integrate in the theme by overriding methods. Let's go by parts, as Jack the Ripper said. Firstly, there could be a template engine included in the core for plugin developers to use. That would help a lot to separate backend and frontend and would allow users to customize plugins. The core could progressively start using it later. Secondly (from now on consider the following as extended brainstorming), you could go for an approach that would not destroy the whole base theme class. It could be something like turning each base theme function into a call to a single and simple template. The PHP theme would, apart from calling the template, receive the HTML generated by the plugin layers. This could be done by means of the qa_content array. Then, the template called by each function of the PHP theme class would also be sent this additional HTML code to include. Regarding positioning, the plugins could specify if they expect their code to be added after or before the template (anyway, the template decides what after or before means for it). I think that would be the least radical change into using templates that actually work on layers that I can think of right now. The downside is that plugins will still have to be somehow modified to properly adapt. So I bet throwing away the theme class and providing hooks on templates that plugins will adapt to (such as positioning) seems to be a better way to go.

7. I like how that sounds. Just don't bring an include path hell :) I wonder if this is time to start turning all those included files into classes and, at least, static method calls. It smells like sooner or later that will have to be done.
+4 votes
edited by

My hope:

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

+4 votes

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.



+9 votes
edited by

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.

  • Overriding layer with the priority like something qa_html_theme_base::the_function($params, $priority). I am not sure how practically it is possible, but just for an idea if every methods has $priority parameter than developer may can stack the methods.
  • Allowing to create own user group/role
  • Allow to register custom event
  • Flexibility for adding forms fields and own action
  • Managale navigation system.
  • Better Admin UI (I can contribute on this part)

Probably will add some more later.

Thanks for your effort :)


EDIT: I believe you will modify markup from HTML4 to HTML5

+5 votes
Good news indeed ! Thank you Scott !

What I need is to improve the selecting performace when QA_ALLOW_UNINDEXED_QUERIES is set 'true'.

On my website, We really need to browse hot/unanswered questions per category.
+8 votes

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....

Great idea...I like this
This is actually very interesting. It adds a unique feature to Q2A.