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


I have worked for some customizations of Q2A core, so I had to dig a lot through code.

I have couple suggestions for a potential future version, based on past experience with other web applications:

1) I think will be nice to re-build Q2A around of a small/fast PHP Framework (maybe Kohana or ZF 2.0). I think using a well known framework brings some advantages: more "standardized" platform, easier to understand by developers, keep up to date with new developments, be able to integrate easier a lot of other components (as many of PHP frameworks have support for useful features), let's give you a sample:easier integration with a data cache (XCache, Memcached, aso) or easier adding Twitter Integration, aso.

2) Get rid of structured programming and move to OOP

3) Move to MVC, is simply easier to understand and de facto web app pattern

4) Simplify the SQL calls, I found the current system, using lot of joins to be far away from optimal (performance)

This are just some suggestions...

2 Answers

+3 votes

Some interesting suggestions and it's great to hear from users who have played with the core code like me. On your suggestions...

1. Q2A doesn't need a framework behind it, just like Wordpress/Joomla don't. Q2A is its own framework! Adding something else there just adds overhead for no real benefit.

2. This is down mainly for speed. I do think it would be worthwhile for some sections, but most files would probably just boil down to static classes - instead of calling "qa_post_create()" you would just do "qa_app_posts::create()" which is again useless overhead. Can you suggest some examples how an OOP method would work with Q2A?

3. MVC is about separating the output and programming logic. This is already the case in Q2A, but because of the procedural style perhaps it's not as obvious. All output (well...90%) is done in the theme class and all SQL queries are confined to the qa-db-* files. That's exactly what MVC is, it doesn't need to be object-oriented.

4. Yeah I have trouble with this too. Q2A's early versions merged multiple SQL queries into one complex query, to cater for the event when the database server is separated from the web server. Currently there is an option to use multiple SQL queries instead, since most sites have web and database on the same server. Unfortunately, this makes the SQL building functions a little complex...

Hi DisgruntledGoat,

I don't think everything should go with speed ("we won 0.001" by not doing that thing or the other thing). Computation power can be bought, flexibility not.

I am working on web projects where parts are actual programs (written in C, compiled) or apache modules (writen in C as well) both for sake of speed, so I know very well what this means...

1) Many of the new projects starting are actually built based on a small and fast framework because not every project has a so large community like WP ;) and because would be much easier for more developers to get involved (as they know the pattern) and the project will progress faster (no need to build everything from scratch). Most of slowness in applications are because of developers work and not because of frameworks been slow.

And many of this frameworks have functionality which takes ages to build from scratch (+ probably not getting a benefit by writing once more "the wheel")... Which can be used just like plug and play...

2) A sample case: the "Controller" part of the q2a are large files. It would be much easier to be classes with  functions and instead of updating directly this large files to just extend the "Controller" class and write own code for only needed functions.

3) Mostly yes, but for digging for a certain thing I need to do lot of searches. View part should be more template like instead of spreading in too many functions and controller part as well would much better fit OOP/MVC.

4) I think many of the SQL functions are extremely slow. I haven't tested yet but to me the EXPLAIN could show very well this.
I think that not using a framework puts all developers on a level field. If you added, say, the Codeigniter framework, that may be beneficial for me since I've use CI quite a lot. However, I would still need to learn the Q2A codebase which I doubt would be much simpler than the current codebase. Other users not familiar with CI would need to learn the framework AND Q2A, which is even more work.
Just a voice in support... Please don't build Q2A around a framework. It's just another layer of yet another framework of the day to learn, that constantly changes, introduces unnecessary extra code that increases the attack surface area. I’ve just moved to our site to Q2A from a Django based Q&A system and I can’t tell you how much easier/nicer/understandable Q2A is. The code’s all in one place and everything just works. Brilliant!
+2 votes

Hi cbichis, and thanks for your thoughtful feedback. I agree with some of what you say, but let me add my personal perspective:

1) I can see the value of this, but it also a matter of speed and flexibility. Q2A has gotten to the point where it's quite framework-like itself, but specifically optimized for its own requirements. In the short run this will no doubt scare off some developers, but perhaps in the long run it will make for a better product. I know that if I was installing a big script on my site, I wouldn't want it to be based on a standard framework - too much extra weight that I don't need.

2) In the case of Q2A my two main problems with using OOP throughout are that: (a) for compatibility with PHP 4 this means defining every method for a class in a single PHP file, which means in turn that a lot more PHP will have to be compiled for every page request, creating a performance drag, and (b) apart from some specific cases (e.g. the theme class) where we need overloading, I can't really see what OOP would do except change the syntax slightly. And doing encapsulation properly would be a nightmare in terms of the numbers of getters and setters required for something like a post or user.

3) Q2A is MVC through-and-through, but I can see that might be hard to spot, since it's not implemented using the usual object-oriented pattern.

4) The JOINs are all there to enhance performance, relative to performing multiple SQL queries one after the next. Perhaps you can post a specific example of a query you feel could be improved? (Or maybe you're talking about the big UNIONs, which are used to reduce query latency - these certainly can reduce performance if your database is running locally, but can be switched off via qa-config.php.)

Anyway, thanks again for your constructive feedback. I hope at least the above explains my thinking, even if we agree to disagree :)

edited by
Hi gidgreen,

Thanks for your answer.

1) I was pointing to use a small and fast php framework because of benefits like: been able to run the site on different platforms (like non-MySQL), data cache support or other more features in a faster time. Plus "opening" a bit more the door to other devs. I don't feel there is a disadvantage by processing each request with 0.01 slower then with pure raw structured, all done by hand.

2) PHP4 should be dead by a lot of time, WP uses OOP+structured, Magento uses Zend Framework (all OOP), aso. I think is matter of code size as well, as big is an app it needs to go better than with oldish 1960-1980 code. I even coded in ASSEMBLER but i won't use/recommend that anymore...

3) Q2A attempts to mimics MVC but yes. is hard to spot/not close to anything usual. Please compare the View part with WP View part and you will see easily what I mean. Plus on how easily are to update the templates (took me 30 seconds to update something on a WP template; and many minutes to understand how calling this Q2A template functions works). Compare with WP, again.

4) A sample:

To modify the
function qa_db_search_posts_selectspec
to be by category I need not to add a WHERE, but rather to add 1 JOIN and 1 AND

           $selectspec['source'].=" JOIN (SELECT postid FROM ^posts WHERE ".qa_db_categoryslugs_sql($categoryslugs)." 1) w ON ^posts.postid=w.postid";

All this tends to create problems because the indexes won't be anymore used on queries thus resulting performance decrease. I am pretty sure I can find out other samples.
I could be wrong at 4) - haven't actually used an EXPLAIN for this - but looks totally odd to use such way to create a filtering.
All of this is way over my head, but just on ease of use - having developed for both q2a and wordpress, I find q2a more powerful and easier to understand than WP by far; yes, you can easily edit theme files in wp but in q2a, you can recreate every single part of the theme in each and every plugin; almost every plugin I've written modifies the theme structure in ways that I don't think would be possible using static theme templates.

Again, I don't really understand most of this discussion, and I may be wrong about what WP is capable of, not being a real programmer, but just two cents  from someone who's done quite a bit of q2a hacking - q2a is a great development platform, even more now that functions are pluggable as well.
One of reasons for having as core a fast and small (modular to add just the desired functionality) framework is the fact I feel somehow Q2A left behind in terms of features added, all needs to be designed from scratch (reinventing the wheel).

Sample: we only have Facebook login integrated. The top-est Q&A systems (See: Stackoverflow, Anova, aso) have much more options available. Some of the existing framework have itself the API to allow easier scale to other login options.
Actually, there is a login module api already:


Since I use WP integration, I don't need it personally, but I would (and have before) recommend someone making a Janrain engage plugin for Q2A just for that purpose.  Even WP doesn't have OAuth integration in the core... (I use the Janrain Engage plugin for Wordpress).

As for feature limitations, it's not really fair to compare a relatively new project with one core developer to something like Stack Exchange or WP...