Question2Answer Q&A - Recent questions tagged compatibility

Is a q2a database upgrade backwards compatible?

Fri, 19 Jun 2015 08:44:35 +0000

Current situation:

1. I have an old installation of q2a, 1.5.x with some mods of 1.6.3 on domainA.com

2. I have setup a fresh installation with v1.7 on domainB.com

3. I want to test on domainB.com and get "please upgrade the database"

When doing so, can will q2a 1.6.1 on domainA.com still work? Because that is the production site with ~100 users per minute online =)

---

Update: The upgrade went through and the 1.6.1 could use the upgraded db of 1.7.1.

Compatibility issue of Q2A V1.7-beta

Sun, 21 Dec 2014 18:27:13 +0000

Two functions in qa-filter-basic.php were deleted in Q2A V1.7-beta. Users who are using these functions will lost compatibility. You need to create the same function in your addon. This is ridiculous.

https://github.com/q2a/question2answer/issues/182

BuddyPress Integration and BuddyPress version 2.1

Thu, 18 Sep 2014 15:09:09 +0000

BuddyPress version 2.1 is out and there is no word about BuddyPress Integration plugin for years.

Has anyone tried updating it ?

Is it safe to update to BuddyPress version 2.1?

Thanks.

[Convention] Plugin identifier naming

Sun, 09 Feb 2014 13:13:19 +0000

If you have developed a plugin or are planning to develop a plugin I think you should consider the following situation.

When you are developing your plugin you usually need PHP classes, functions, global variables (hopefully not... it is 2014!), as well as CSS classes and identifiers, HTML name and id attributes or even JavaScript functions and variables. It is almost impossible to write a useful plugin that doesn't need at least one of them. And things usually work the way they should. Particularly, if you are using a clean (without any plugins) core in the development process.

As time goes by, you have your big-button CSS class, your nice-button id attribute, your PHP function in the qa-plugin.php file named userid_to_userhandle, your element JavaScript variable and your toggle JavaScript function. And, of course, everything works. So you release your plugin... not knowing it is a matter of time for things to stop working.

Things work until any other developer (or maybe yourself) write a different plugin that uses the big-button CSS class, the nice-button id attribute, etc. If 2 plugins use the same identifier and happen to be in the same scope then that only means things will break. So how can this issue be prevented?

Without asking core developers to do magic in the core, we can solve this by just communicating and being proactive. This issue can be easily addressed by prefixing each element that is part of a shared scope with a string. In order for that string to work as PHP class names, PHP functions, PHP varaibles, CSS class names, CSS identifiers, HTML name attribute values, HTML id attribute values, JavaScript function names and JavaScript variable names they can all contain letters, numbers and underscores (_) but should all start with a letter. There are also other identifiers that can be added to the list such as the plugin folder name and the title of your plugin settings stored in the ^options table.

I thought on the following guideliness to be applied. Prefixes should:

Be unique and not re-used between different plugins
Be applied to all shared scope elements including, but not limited, to the aforementioned ones
Be at least 4 characters long
Not use underscores
Be separated from the rest of the element identifier by an underscore
Be case-insensitive

This way these could be some valid names for elements prefixed with the myplugin prefix:

PHP class: MYPLUGIN_User
PHP function: myplugin_show_profile()
CSS class: .myplugin_big_button
CSS id: #myplugin_save_button
HTML name attribute: myplugin_user_input
HTML id attribute: myplugin_terms_agreed_checkbox
JavaScript function: myplugin_toggleVisibility(e)
JavaScript variable: myplugin_countryArray
Table name: myplugin_countryArray
Plugin folder (note it could only be the identifier itself): myplugin
Title of element in ^options table: myplugin_enable_user_feature

An approach that is actually included in the previous guideliness is adding a developer prefix, so to speak. So you could have plugins with the prefix MyDevId and, on your own, avoid plugin duplication by adding the second level of identification with the plugin id MyPluginId. This would result in elements identified by MyDevId_MyPluginId_identifier.

I think getting to a certain degree of agreement is needed and, as time goes by, this is becoming more necessary. Please, let me know your thoughts on this.

Now, in order to be able to satisfy guideline #1 it is needed to let others know what plugin ids you have used. Even if you don't want to follow this convention at least refer to this list to know which plugin prefixes not to use if you want to make a fully compatible plugin.

Note that while writing this, I've decided to use the developer prefix approach in the future. I'm planning to use the prefix pupi.

If you like the idea, feel free to add yours in order to centralize future lookups.

AntiBot Captcha not working in 1.6.2 version

Tue, 14 Jan 2014 08:00:37 +0000

I have installed AntiBot Captcha and it is not showing the Image of the captca. My version is 1.6.2. Could somebody help

i have upgrade 1.6.2 still it's showing old version look? and style

Sun, 27 Oct 2013 02:58:09 +0000

HI Team

My site name ( www.techiespoint.com )

1. i have upgrade 1.6.2 still it's showing old version look? and style

2. In the Ask question page it's not showing any category in the category drop down box?

please give some solution..it's killing my site performance?i lose my users?

Does the old Snow Theme version work with Q2A 1.6.2 or does it bug?

Mon, 09 Sep 2013 18:41:07 +0000

I'd also like to know what I'm missing if I don't update the theme.

Users: Handling with users using an External database

Mon, 25 Apr 2011 16:50:23 +0000

My installation of Q2A uses an external database for the users, and to get their ID's/Usernames/HTML/etc... I use the functions defined in the external file. My question is: does this work both with external providers installations and normal installations?