Extension talk:SemanticQueryFormTool/Archive

New Storage Engine

Will there be support for the new Storage Engine and will there be a SVN Repository for this Extension? Because then I could use this Extension on WeCoWi. --DaSch 09:54, 8 September 2008 (UTC)

Hopefully yes at some stage. I'll try to keep this 'old storage engine compatible' version (with all its limitations) working with upcoming SMW versions but any new SQFT version would long-term anyway only make sense if its working with the new storage engine. Optimale 14:14, 8 September 2008 (UTC)

Dependent Selection

Is there a possibility to make several mselect-boxes dependend on each other? I'm trying to have a search form that incudes (among other options) a search for countries, regions and villages/cities. Now it would make great sense, if one couldn't choose first a land and then a region that's NOT in the land you chose in the first place, and in the next step one shouldn't be able to select a city that isn't in the selected region.

Thats my code so far, it's heavily stripped from your example:

<div id="nform-location">
{{#form:
       {{#input: type = hidden | name = content | value = {{#sask: type = articles | [[Country::{{#request:country}}]] [[Region::{{#request:Region}}]] [[Place::{{#request:Place}}]] | format=list | SearchLabel= }} }}
<table cellspacing=5><tr><td>
       Land: {{#sask: ?Country | any=(alle) | name = land | id = lfeld | return = mselect }} 
</td><td>
       Region: {{#sask: ?Region | any=(alle) | name = region |id = rfeld | return = mselect }}
</td><td>
       Ort: {{#sask: ?Place| any=(alle) | id=ofeld | name = ort | return = mselect }}
</td></tr></table>

       {{#input: type = ajax | value = Find | update = nlist-result-location }}
}}
</div>

----
Results:
<div id="nlist-result-location"> </div>
-----

(I'm using SMV-properties because I want to have a boolean AND within that search, and afaik that wouldn't be possible with built-in wikipedia categories.) Is there a way to make the mselect boxes dependend somewhat like this: Country A -> Regions in Country A -> Cities/Villages in Region B in Country A

Thx,

Simon -- 12:05, 15 September 2008 (UTC)

Sorry for the late reply.

Yes you can do something like that with the help of javascript functions which are attached to a field of the form with the 'js=' parameter. I use it in a very similar way like you describe (except in a different context - if a certain chromosome is selected from the 'chromosome' select element the values in another select element for 'bands' change accordingly to allow only those bands to be selected which are located on the selected chromosome(s)). It's however not very elegant as the javascript has to contain hardcoded the information e.g. which country has which regions and which regions has which villages/cities in order to enable the script to disable (gray out) or remove certain elements from the select list resp. add/enable them 'on the fly'. One can do some quite advanced stuff with the right javascript but it's basically not different at all from what one can do to control elements of a normal form in a normal HTML site using javascript.

I use the addscript extension to add javascript functions which I store in a file on the server. But in theorie the whole script could be added directly as value to the 'js' parameter. So {{#sask: ?Country | any=(alle) | name = land | id = lfeld | return = mselect }} would might have the extra parameter {{#sask: ?Country | any=(alle) | name = land | id = lfeld | return = mselect | js = onChange="select_disable(this.id,'region');"}} which calls the js function select_disable if the country is changed and which than can modify the region select element depending on the country value.

Btw to have 'any=(alle)' is not useful as SMW only understands '+' and '?' as wildcard characters for ask queries; this parameter is more useful to switch the display of '+' or '?' OFF e.g. in lists.

Optimale 17:01, 24 September 2008 (UTC)

Database error: table .cmw_smw_atts2 doesn't exist

Hi,

after installation, I get the following error:

A database query syntax error has occurred. This may indicate a bug in the software. 
The last attempted database  query was:
(SQL query hidden)
from within function "SQFTSMW::getSelectResult". 
MySQL returned error "1146: Table 'XXXX.cmw_smw_atts2' doesn't exist (localhost)".

-Bernhard

Sorry about that. It was a bug - the database prefix was still hardcoded from the initial test :(

It should work now with version 0.1.2 on the ftp site

Optimale 22:54, 12 October 2008 (UTC)

Problems with MW1.13.2 and SQFT0.1.3

Hi all!

I don't know what I did, but the newest version of this extension (it's very helpful, many thanks for it!) does not work for me. I have a new installed MW1.13.2 and created two simple pages:

• Page_one contains: [[Propertyname::one]]
• Page_two contains: [[Propertyname::two]]

and a third:

• Page_three contains: {{#sask: ?Propertyname}}

but the option list of select tag is empty. I set the $wgShowSQLErrors and $wgDebugDumpSql variables to true in LocalSettings.php, but there are no error messages. The select tag appears nice. The page id's are there in prefix_smw_rels2 table. My SMW version is 1.3.

Can anybody help me? Thanks: Pipi69e 13:50, 30 October 2008 (UTC)

PS.: with type=article it works (it finds the correct property-page relations). Pipi69e 14:13, 30 October 2008 (UTC)

Pagename attribute causes MySQL error

Using pagename attribute ({{#sask: ?Propertyname|pagename=Pagename}}) causes the next error message:

A database query syntax error has occurred. This may indicate a bug in the software. The last
attempted database query was:
   (SQL query hidden)
from within function "SQFTSMW::getSelectResult". MySQL returned error "1064: You have
an error in your SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near ')' at line 1 (localhost)".

The {{#sask: [[Pagename]] ?Propertyname}} form works fine. Pipi69e 15:21, 30 October 2008 (UTC)

I think I finded an unnecessary closing bracket ')' on the end of 265. line of SemanticQueryFormTool/includes/SQFT_SQLFunctions.php. Deleting it solves the problem. Pipi69e 19:10, 30 October 2008 (UTC)

I just uploaded version 0.1.5 which hopefully resolves all bugs connected with retrieving property values of all types w/out specified namespace and/or pagename

Optimale 13:43, 6 November 2008 (UTC)

Update for SMW 1.4?

SQFT is currently (SemanticQueryFormTool_01_5.zip) not compatible with the newest SMW version. Would be cool if you could update it to make it work again :)

Version 0.1.6 is the last version compatible with <= SMW 1.3

Version 0.1.7 is the first version compatible with >= SMW 1.4

Optimale 10:51, 25 November 2008 (UTC)

Great, thanks :) --Pnagel 02:52, 26 November 2008 (UTC)

Simple #sask query for property of type Page doesn't work

Until now I always used SQFT's #sask for properties of type String. Now I wanted to use it with a property of type Page (explicitly specified in the Property page), but I only get a dropdown with a + in it, although there are >30 pages using the property. The query I tried was:

{{ #sask: ?Belongs to organisation }}

What am I doing wrong? --Pnagel 06:34, 9 January 2009 (UTC)

Sorry again for the late reply but somewho I don't seem to get the notification emails when this page is modified :(

Anyway it was a bug. I forgot in one place to replace the spaces of property names with underscores for the sql query. I corrected that now in version 0.1.9

Optimale 12:35, 26 January 2009 (UTC)

Example

This extension looks like it could be very useful. However, I tried to look at the example on malariapedia just now, but the site seems to be down. Do you know when that site might be available again or indeed if there is another place I could see a working example of this extension?
Thanks
Pnelnik 18:10, 17 February 2009 (UTC)

Unfortunately I don't really know of any other wiki where one could see the extension in action but the help.malariapedia.info site is up and should be accessible. It might be slow at times as it is a test site on an old server but the wiki will be moving to a new and hopefully faster hardware soon. So please try again to connect. Optimale 22:10, 17 February 2009 (UTC)

Maybe it's a result of the unusual port (14195) the webserver at mbi.molgen.mpg.de is running on - many company's firewalls or proxies will block outgoing traffic to this port. --Patrick Nagel 02:51, 18 February 2009 (UTC)

Thanks for the prompt response. I seem to be able to see the web-site today. Pnelnik 16:24, 18 February 2009 (UTC)

Combine two query conditions?

I'm currently mainly using #sask to generate tables with two columns, one containing property values, the other containing the number of times this value has been used. Now I'm wondering if it would be possible to get such a table that only contains the number of times a value has been used together with another condition, for example only matching pages that are in one specific category. Is it possible? --Patrick Nagel 08:00, 23 February 2009 (UTC)

Right now only those criteria can be used which are directly accessible within the SQL queries for the property values. These criteria are pagename and namespace. Using Category restrictions would mean to retrieve each page associated with a property value and do an extra DB search if that page is within a certain category or not. That would take too much time as the SQL queries are already time consuming if the number of properties is very high. So you can only restrict the result to matching pages within a list of pagenames or to pages within a list of namespaces. The other 'filter' action is after the retrieval purely based on the actual property values.

Well thinking of it there could be a 'trick' to restrict for Categories but I have so far never tested nor used it - so it might not work in practice:

{{#sask: pagename={{#sask: type=article | [[Category:IncludeMe]] | [[MyProperty::+]] }} | ?MyProperty | return=count }}

In the 'article' mode a 'normal' #ask: query is used which can include Category: and it returns a list of linked pagenames. Most likely one has to somehow switch the linking off?

I'll see if I get it working and let you know. Optimale 13:44, 23 February 2009 (UTC)

I just made some modifications and from the next version it will be possible to feed a list pagenames to the pagename= parameter which is generated by a i.e. category specific #sask: type=article query e.g.:

{{#sask: pagename={{#sask: type=article | return=simple | [[Category:IncludeMe]] ....}} | ?MyProperty | return=count }}

but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)

Wanted links ?

Hi

I am using your great extension to display a list of values (keywords) from a property and provide links to pages for these keywords.

It is working fine except for one thing - all links are displayed the same way, whether the page exists or not.

Would you consider making link display aware of 'wanted pages' in a future version to make the display of links more consistent with the rest of the wiki ?

Regards

- Laurent Alquier

I assume you mean 'red' links to non-existing pages are blue? I haven't tested that so I have to look into it as I actually thought MW would take care of returning the correct link. Optimale 20:04, 28 March 2009 (UTC)

In the next version (0.2.1) links to non-existing wiki pages will show as 'red links'. Of course it makes only sense to add the 'link=' parameter (adding an internal link) if the property values are intended to be page titles, otherwise links will always be red.

It checks and tries to link to pages with the name of the property value in the 'Main' namespace. Only if the global variable '$sqftgAllowedNamespaces' is set, it checks through those namespaces first and uses the first namespace in which it finds a page with the name of the property value. If no page in any of those namespaces is found it shows a 'red link' to the page in the 'Main' namespace. Optimale 11:20, 30 March 2009 (UTC)

Only Property Values of Type 'Page' Returned After SMW Rebuild

Hi- I've discovered a very strange bug in SQFT (which is great! I've been using it extensively to enhance SMW.).

I have a large SMW installation.
Versions: MW 1.13.3, PHP 5.2.4, mysql 5.0.51, SMW 1.4.2, SimpleForms 0.4.10.1, SQFT 0.2.0
SQFT was installed normally (no caching, no SQFT tables or indexes created).

'#sask' worked just fine when I installed it a month or so ago, and has worked well during that time. I could build unique lists of whatever semantic property in my system...

Then, this week, my semantic tables got corrupted, so I used the recommended steps to rebuild everything from scratch using the SMW maintainance scripts:

1. delete old smw* tables.
2. rebuild smw* tables.
3. refresh smw* data for properties and types only.
4. refresh smw* data for everything else.

After doing this, the SMW stuff all worked again just fine, as did many other SMW related extensions(results format most importantly)... but I noticed that #sask stopped working. This hosed a lot of pages.

But, #sask did continue to work for Properties whose type was 'Page'? (where before the type of the property did not matter)
If I switched some of the properties failing to return value lists from 'number/string/etc' to 'Page' suddenly #sask would work again?!
And when switched back to 'number/string/date/etc' nothing would be returned.
(note- I did make sure the database updates all succeeded, and touched LocalSettings.php between each change).

Any help would be greatly appreciated.
Thanks-
User:iamh2o (Mar 28 2009)

As far as I know I use only the normal SMW tables to retrieve the data. I use SMW 1.4.2 (actually in Special:Version it says 1.5e-SVN), MW 1.14.0 and SQFT works for me for properties of type String and Number. I'll look into it on Monday. Do you have acces to the MySQL database, so you could enter some test queries directly? Optimale 20:39, 28 March 2009 (UTC)

Thanks for the quick reply! Yes, I have admin access on the box this wiki runs on, and would be happy to run test queries. This is indeed odd: I didn't change SMW code at all, so the tables and data which were rebuilt should be exactly the same as when SQFT was working pre-schema/data refresh(and are as far as #ask query results I've QC'd go the SMW stuff all works fine).

I'll check back Monday. User:iamh2o (Mar 28 2009)

I sent you an email Optimale 16:39, 30 March 2009 (UTC)

The problem is resolved. It was caused by the fact that SQFT only transformed the first letter of a property name in an #ask query to uppercase when the property was of type Page but otherwise used the name as written in the query. As all property names are stored with the first letter in uppercase this caused problems in SQL queries. From SQFT version 0.2.1a all property names are treated like the Page properties and the first letters of property names in #sask queries are now case insensitive. Optimale 09:35, 2 April 2009 (UTC)

Different id and name values

Hi Optimale!

If I add a name parameter to a select element, the value of id has got same value in HTML source. If I add an id, then the name follows it. But if I add an id and a name params together then they won't be different, but the value of name will be ignored and it will be the same as the value of id. How can I add different id and name values to a select?

Thank You for Your extension :) Pipi69e 19:18, 23 May 2009 (UTC)

PS - versions: MW 1.14.0 and SQFT 0.2.4

You are welcome. I'm really surprised that it doesn't keep the values of both if both are specified. It defenitly should and if not it is a bug. I'll look into it asap and fix it in the next release. Optimale 22:15, 23 May 2009 (UTC)

Yeah it is a bug. 'name' and 'id' are always added. If 'id' is not given, 'id' will equal the value of 'name'. If 'name' is not set 'name' will be the property name if a property is specified otherwise it will be the page title. I'll put up version 0.2.5 on Monday. Optimale 22:34, 23 May 2009 (UTC)

Many thanks for Your fast reply and help. I'm trying to use selects of Your extension in forms created by Semantic Forms extension and that's why I need correct id and name values. Pipi69e 08:34, 24 May 2009 (UTC)

I never used it myself in SF but select and multi-select form elements were the original purpose I wrote SQFT for. If you have any problems let me know. Btw the name and id values will all be forced to be lowercase (that's because by default it used the property name which usually starts with a capital letter and I thought it's less trouble if the id/name value case is independent how it was defined) so if you refer to those elements e.g. in javascript keep that in mind.

This next version will also have a new 'style' parameter which you can use for select elements too to i.e. define the text size if desired (e.g. style=font-size:90%;color:red) Optimale 10:57, 24 May 2009 (UTC)

I put now SQFT version 0.2.5 up for download which fixes this bug. Optimale 09:00, 25 May 2009 (UTC)

Call to undefined method SQSimpleForms::updateTemplates()

Hi Optimale!

Here are some reflections again. I use both your SQFT and Simple Forms. If I'm writing this:

{{#form:
{{#input: type=hidden|name=title|value=Something}}
{{#input: type=hidden|name=content|value=Some text }}
{{#input: type=submit}}
}}

and the page Something exists, your SQFT says:

Warning: in_array() [function.in-array]: Wrong datatype for second argument in 
.../extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php on line 506

Fatal error: Call to undefined method SQSimpleForms::updateTemplates() in 
.../extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php on line 514

I think, the line 506. of SQFT_SimpleForms.php is really bad, the second argument of in_array() function is $wgSimpleFormsAllowRemoteAddr instead of $wgSQSimpleFormsAllowRemoteAddr now. But where is the updateTemplates() function of the SQSimpleForms class ;) and why works SQSimpleForms class when I use parser functions of Simple Forms? Many thanks again :) Pipi69e 02:15, 27 May 2009 (UTC)

That was an interesting one. Good catch, thanks! I don't want to go too much into details but making a modified extension part of another extension is obviously more complicated than I anticipated. SQFT_SimpleForms is included within the SQFT_Settings file and the constructor function is called each time. It already calls a function to process an existing request using $_REQUEST variables. It didn't distinguish if the in both SimpleForms identical named variables where generated from a normal SimpleForms or a SQFT_SimpleForms form. As SQFT_SimpleForms is a simplified version made to deal only with the type of forms used for SQFT it didn't have all the functions necessary to deal with the request. I'm sure there is a proper way to solve those issues but for now the solution is to download version 0.2.5a of SQFT. It is sufficient to replace the SQFT_SimpleForms.php file in your existing installation and it should work. Optimale 13:52, 27 May 2009 (UTC)

Enter a property in SQFT and find what page it appears on.

I would like to select a value of a property with SQFT and then, on pressing the button, display the names of the pages where that property value exists.

Eg, I have tests displayed by test ID and each test has a name, giving the following table:

Test ID - Name

T1 - Roger

T2 - foo 123

T3 - Alice

When I Do {{#sask: ?Name}}, I get the list of values. How can I make it show Test ID when I select a value from that list?

-The reason for this is that users must enter test ID as it is a unique value but they cannot be expected to remember it, therefore a quick lookup query where they could find the ID from the name is necessary. Thanks

SQFT itself deals in this context only with values of one property at a time but from all pages of a wiki (not taking into account using optional restrictions to one namespace/category/page). To achive what you want you will have to combine SQFT's #sask: queries with a normal #ask: query. The only thing which springs to my mind right now is the use of a form which is what I routinely do for my queries. E.g. something like this (using Ajax to show the results):

 {{#sqform:
  {{#sqinput: type = hidden | name = content | value = <no wiki>{{#ask: [[Name::{{#sqvar:namevalue}}]] | ?Name }}</nowiki> }}
  Choose value: {{#sask: ?Name | name = namevalue | any=off | sort=asc }} 
  {{#sqinput: type = ajax | value = Show result | update = ask-result}}
 }} 
 The chosen 'Name' value can be found on these pages: <div id="ask-result">NO RESULTS TO DISPLAY YET</div>

You can customize the #ask query i.e. choose a different output format if you want

Note that 'value = <no wiki>' needs of course to be written without the space between 'no' and 'wiki' in the real code

Optimale 08:02, 1 July 2009 (UTC)

Thankyou very much Optimale for your fast response.

That looks like it should be doing what I want (i.e, the results appearing directly on the page) however I get the following error when i click the 'show results' button.
Error: 404 Not Found (There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.)

I am not sure if this is:

• my incorrect substitution of variables into your code;

The pages are in the category "Coupon Type" and it is the autogenerated page name that I wish to display as well as the property "Ctdesc" - (description). I wish to search by the property "Ctname". Simply substituting 'Ctname' where you have written 'Name' in the above example gives me a form that looks exactly how I want but the above error. I assume 'namevalue' is a variable and I can leave it.

• Ajax problem/other config? - I have put '$wgUseAjax = true;' into my localsettings. I have not done any of the optional steps mentioned in the main wiki page for the extension.

• Problem in above code??

Thanks Again Ben 2-July-09

Hmmm looks like an Ajax problem although I have never seen it before.

I just tried the exact code syntax on my wiki, just replacing 'Name' with one of my property names and it works as expected.

$wgUseAjax = true; should be sufficient.

What MW, SMW, SQFT version are you using?

Do normal #ask: and #sask queries work? I assume you get the pull-down list with the Ctname property values?

Might have somthing to do with SF although the error indicates that it wants to open a page which looks more like an Ajax problem.

If you add the above code on a normal test page and replace 'Name' with 'Ctname', does it work without SF involved?

Optimale 11:47, 2 July 2009 (UTC)

I am using: (from Special:Version)
MediaWiki 1.15.0
PHP 5.2.6-3ubuntu4.1 (apache2handler)
MySQL 5.0.75-0ubuntu10.2

Data Transfer (Version 0.3.1)
Semantic Drilldown (Version 0.5.7)
Semantic Forms (Version 1.7.1)
Header Tabs (Version 0.6.5)
Semantic MediaWiki (Version 1.4.2)
SemanticQueryFormTool (Version 0.2.5a)

I have discovered a problem with normal #sask with the following (on test page, nothing else on that page):

{{#sask:?Ctname|return=form}}

I get the drop down, but when I click the button, get the same error as in previous post.

When I use:

{{#sask: ?Ctname | name = namevalue | any=off | sort=asc }} 

I just get the select drop-down and no button. I assume that is normal.

Normal #ask queries such as:

{{#ask: [[Category:Coupon Type]] | ?Ctname }}

works fine.

Could it be a problem with MW 1.15??

I didn't have the time yet to install and test MW 1.15 but it all sounds like some Ajax issue with MW 1.15. I'll see if I can install 1.15 and test it out.

With normal #sask queries you don't get any buttons, that's ok (only with return=form);

Optimale 08:12, 3 July 2009 (UTC)

I now installed and tested MW 1.15 and it is till working on my test wiki. something like {{#sask:?Ctname|return=form}} works as expected.

I can't get the Ajax examples NOT to work, so I guess there is something different with your 'Ajax' compared to mine but I have no idea what it could be.

Do you use Ajax on the wiki in any other context? Maybe using the original SimpleForms extension?

When it gives the Error: 404 Not Found (There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.) what page name does it try to open or create when you try to edit the page?

Optimale 10:46, 3 July 2009 (UTC)

I am not using any other AJAX. The links in the error message point to

/index.php/Special:Search/UNTITLED

Ben 02:20, 6 July 2009 (UTC)

Hey, I possibly found a bug. I created a page called "UNTITLED" and now it seems to be working a bit better.

with return=form, I push the button and it returns "0" pages with that property value but the correct answer is "1". For another property, it returns "3" when the correct answer should be "1".

With the code that you gave me above, i now get the following error:

warning.png "" cannot be used as a page name in this wiki. Some use of "[[" in your query was not closed by a matching "]]".

The problem is with the substitution of #sqvar. When I directly specify a value such as:

value = {{#ask: [[Ctname::flat_Al]] | ?Ctname }} }}

it works perfectly. I think I am getting close now, thanks

203.5.217.3 07:41, 6 July 2009 (UTC)

Actually, Firefox 3.5 and chrome 2 work. Just Not IE7.

203.5.217.3 07:48, 6 July 2009 (UTC)

I have IE6 here and yes I get the same errors. If I don't use Ajax it works fine (you can try it if you replace '{{#sqinput: type=ajax | ...' with '{{#sqinput: type=submit | ...') but if Ajax is used then [[Name::{{#sqvar:namevalue}}]] ends up as

[[Name::]]]]

You can see it if you add to the '{{#ask:' query the parameter 'format=debug'

I never use IE so I didn't experience that problem before. I'll see what I can find out.

So using Firefox or Chrom everything works otherwise for you now?

Optimale 09:24, 6 July 2009 (UTC)

I found the problem!

In contrast to the other browsers IE doesn't understand options[selectedIndex].value if there isn't a value explicitly defined and for IE one has to use options[selectedIndex].firstChild.nodeValue. So it never assigned the selected value from the drop-down menu.

I have put SemanticQueryFormTool_02_5b.zip up for download which fixes that problem.

The above query form as well as #sask: with 'return=form' works now for me with IE6 as well as Firefox.

Thanks for finding the bug and helping to solve it!

Optimale 10:24, 6 July 2009 (UTC)

The fifth installation step

What does the fifth step mean?

create index p_s_val on $wgDBprefix_smw_atts2(p_id, s_id, value_xsd);
create index p_o_id on $wgDBprefix_smw_rels2(p_id, o_id);

what to do?

Hi, this is a step you have to perform in you MySQL database (see here for reference). Just access your database, most probably by using the application phpMyAdmin, select your database on the left side and klick on the tab SQL at the top of the page. Now you get a blanc field in which instructions are inserted. There you insert create index p_s_val on $wgDBprefix_smw_atts2(p_id, s_id, value_xsd); and press enter after exchanging „$wgDBprefix_“ by the prefix you used for the tables of your MediaWiki installation. E.g. if you prefix was mw_ you instert create index p_s_val on mw_smw_atts2(p_id, s_id, value_xsd);, if you somehow did not use a prefix for some bad reason you enter create index p_s_val on smw_atts2(p_id, s_id, value_xsd); etc. mw_smw_atts2 or smw_atts2 should be the name of one of the tables displayed on the left side. You do the same thing with the second instruction. Voilà! Cheers --kgh 20:48, 28 April 2010 (UTC)

Thank you for the detailed instructions. It helped! =)

It was a pleasure. :) --kgh 09:11, 29 April 2010 (UTC)

Thanks kgh for the excellent description :). I just want to add that these additional indexes are mainly for using SQFT with SMW versions before 1.5. As SMW changed its n-ary related code and DB structure completely SQFT has stopped to access the DB directly for SMW 1.5 and therefore those indeces are not used anymore in that case. Optimale 08:25, 29 April 2010 (UTC)

Hi Optimale, thank you for your praise. :) I am learning all of this self-taught. Thus I know how hard it is sometimes to understand simple instructions which are sometimes only easy if you have some level of knowledge. Besides, thank you for your hint. I will adjust the instruction a bit to reflect this for people like me. :) Cheers --kgh 09:11, 29 April 2010 (UTC)

After saving the page, query results disappear

Hello!

There is a problem with displaying query results. Inserting a query:

{{# Sask: ?City 
| Return = template 
| Template = sask 
| Any = no 
| Category = peaple 
}} 

When using "Show preview" all results are displayed correctly. After saving the page, query results disappear. Saved pages look as though it a query. The saved pages look as if though they are appear without query.

I have:

• MW 1.15.2
• PHP 5.2.12
• MySQL 5.1.40
• SMW 1.5.0
• Semantic Drilldown 0.7
• Semantic Query Form Tool 0.3.0

How to solve this problem? Thanks.81.200.217.106

I have never come across such a problem. Can you please show me the structure of the City property and the sask template? Does the #sask query show a result with another return format (e.g. return=text or return=ol)? Are you sure pages with the City property are in the category 'peaple' (or are they in sub-categories)? Optimale 08:36, 29 April 2010 (UTC)

1. the structure of the City property: [[Has type::String]]. the sask template: [[{{PAGENAME}}/{{{1}}}]].
2. With another return format (e.g. return=text or return=ol) is the same problem.
3. I have pages about some people. This pages have property "City" (e.g. city where he lives) Pages are in the category 'peaple' and not in the sub-categories.81.200.217.106 10:41, 4 May 2010 (UTC)

I had the same problem. Try to press to "Refresh" link.

Clicking on the "Refresh" does not solve the problem. I'm sorry, the "Refresh" link solves the problem. But there are another questions. Why is this happening this way? How to make the query results to display at once (without clicking on the "Refresh" link)?81.200.217.106

Strange phenomenon

I just noticed that the output of 'action=render' is stripped of all <br> tags when SQFT 0.3 is installed. This did not occur with 0.2.

Correction: It does not occur in some 0.2.x version I have here, but it does occur in the 0.2.9 that can currently be downloaded from http://functionalgenomics.de/SQFT/ --Patrick Nagel 06:11, 19 May 2010 (UTC)

Sorry for the late reply but I missed the email notification (or it wasn't working) for changes on this page.

The only 'action=render' I am aware of is within the SimpleForms extension which SQFT uses in a modified way for its forms. But I never used 'action=render' in connection with SQFT. SQFT doesn't use it at all and therefore I don't think that part of the code was changed in any way. Optimale 13:27, 20 August 2010 (UTC)

UNTITLED

Hi, I was wondering if it would be possible to give this page a more distinct name like "SQFT Setup" and additionally providing some more information like "Do not delete or edit this page.". This idea struck my mind after installing Semantic Project Management which also requires an extra page. They call it "SPM Setup" which I think is a good idea. Cheers --kgh 23:46, 26 November 2010 (UTC)

I'm not really sure what you mean with 'this page' and later with 'also requires an extra page'. I don't know the Semantic Project Management extension but it seems from the code that they provide some tool to change settings (resp. a project structure) via a special page. What equivalent in SQFT do you have in mind (as there isn't anything similar in the SQFT extension)? Optimale 13:49, 27 November 2010 (UTC)

Hi Optimale, ups, I meant the page UNTITLED which is automatically created by SQFT after installation. It is true that it is not a page to store settings as SPM does, in fact it is called dummy article, still it seems to be necessary for SQFT to work properly. Cheers --kgh 16:01, 27 November 2010 (UTC)

Hmmm I wasn't aware that SQFT creates such a page 'after installation' or that it is necessary for SQFT to work properly. The UNTITLED page/dummy article you probably mean is created by the code from the 'Simple Forms' extension which is in modified form incorporated in SQFT (from the Simple Forms code: "# If there is content passed in the request but no title, set title to the dummy "UNTITLED" article, and add a hook to replace the content"). Do you have a certain example in mind? One should be able to define a 'title' to avoid such an 'UNTITLED' page. If you can give me an example I have a look. Optimale 16:41, 27 November 2010 (UTC)

My observation was perhaps a bit crude. I directly linked this page to SQFT without doing further thinking. I am afraid that I do not have a certain example in mind. Perhaps my proposal was not such a good idea after all since I think that your thoughts for further development should go into this extension and not Simple Forms. Cheers --kgh 19:11, 27 November 2010 (UTC)

Hello, What can i do when i have erased this page? i have this internal error Detected bug in an extension! Hook RMForm::createRichMediaLinkAfterTidy failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

1. 0 /var/www/mydev/mediawiki-1.16.2/includes/parser/Parser.php(455): wfRunHooks('ParserAfterTidy', Array)
2. 1 /var/www/mydev/mediawiki-1.16.2/includes/Article.php(3279): Parser->parse('Dummy article u...', Object(Title), Object(ParserOptions), true, true, NULL)
3. 2 /var/www/mydev/mediawiki-1.16.2/includes/Article.php(1921): Article->prepareTextForEdit('Dummy article u...')
4. 3 /var/www/mydev/mediawiki-1.16.2/extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php(759): Article->doEdit('Dummy article u...', 'Dummy article c...')
5. 4 /var/www/mydev/mediawiki-1.16.2/extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php(140): SQSimpleForms->createUntitled()
6. 5 /var/www/mydev/mediawiki-1.16.2/extensions/SemanticQueryFormTool/includes/SQFT_SimpleForms.php(889): SQSimpleForms->SQSimpleForms()
7. 6 [internal function]: wfSQSetupSimpleForms()
8. 7 /var/www/mydev/mediawiki-1.16.2/includes/Setup.php(370): call_user_func('wfSQSetupSimple...')
9. 8 /var/www/mydev/mediawiki-1.16.2/includes/WebStart.php(132): require_once('/var/www/mydev/...')
10. 9 /var/www/mydev/mediawiki-1.16.2/index.php(42): require_once('/var/www/mydev/...')
11. 10 {main}

-- 195.221.117.28

My first bet would be to restore this page. Cheers --[[kgh]] 15:24, 16 March 2011 (UTC)

Thanks, Ok we do it, but we have first to log off the SQFT extension. This way is ok for a person who is in computers not for the others users -- 195.221.117.160

I am glad that it worked out for you. Cheers --[[kgh]] 09:57, 17 March 2011 (UTC)

Display of credits

Hi, it is me again. I found a thing that may be changed for the next version:

All extensions to Semantic MediaWiki are just moving to a new section on the version list of MediaWiki on Special:Version specially created for them. For consistency reasons it would be nice to see this one there too. I have looked at the source code of another semantic extension to see how it is done there:

$wgExtensionCredits[defined( 'SEMANTIC_EXTENSION_TYPE' ) ? 'semantic' : 'specialpage']

I do not know if this is all that has to be done to change it but at least this might give you a first hint for coding.

Cheers --kgh 00:05, 28 November 2010 (UTC)

Thanks, I'll have a look into that for the next release Optimale 12:54, 28 November 2010 (UTC)

Hi Optimale, this still has to be done for SQFTlight. Cheers --[[kgh]] 15:47, 9 March 2011 (UTC)

Well SQFTLight is not at the same version level as SQFT anyway. So the credit format is not really the most urgent problem. When SQFTlight will be updated it will also get its new wgExtensionCredits. Optimale 16:57, 9 March 2011 (UTC)

Yeah, you are absolutely right. I just wanted to give you a little hint. :) Cheers --[[kgh]] 16:59, 9 March 2011 (UTC)

Data base error after update to mw 1.16

using Version 0.3.1, after update I get:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

   (SQL query hidden)

from within function "SQFTSMW15new::getSelectResultCat". Database returned error "1146: Table 'aarsrapport.mbw_smw_ids' doesn't exist (localhost)".

thomas 25 jan 2011 16:03

Upps there I have forgotten to replace the hardcoded database prefix I use (mbw) with the variable. Thanks for letting me know.

It shouldn't, however, have anything to do with the MW version.

I'll correct the error in the code within the next hour and upload the corrected versions (without changing the version numbers)

If you want you can change in your copy of the file SQFT_SQLFunctions.php in the function sqftSMW_new the following line

$catsql = "select smw_id from mbw_smw_ids where smw_title=".$catname." and smw_namespace=14";

to

$catsql = "select smw_id from ".$wgDBprefix."smw_ids where smw_title=".$catname." and smw_namespace=14";

Optimale 15:26, 25 January 2011 (UTC)

I have now updated the SemanticQueryFormTool_03_1.zip and SQFTlight_02.zip file and corrected that error (plus two other sql queries where the same happened)

Optimale 15:36, 25 January 2011 (UTC)

Excellent this works! Thank you very much for the quick fix.

--Thomas 16:33, 25 January 2011 (UTC)

SQFT_Main.js

Hi Optimale, Firebug complains about Line 80 in the mentioned file and throws following message: "$ is not defined". I do not know if its bad and needs to be fixed. I just wanted you to know. Cheers --[[kgh]] 17:15, 5 April 2011 (UTC)

Problem with class autoloaders?

Apologies for posting this here instead of contacting the author directly, but I couldn't find author contact details...

We had an issue with autoloading classes as of at least MediaWiki 1.16.0/SMW 1.5.6 which required us to remove include_once() calls from one file in the extension - diff is below, generated against the most recent downloads for SQFTlight and SQFT.

Left base folder: C:\Users\pe\Desktop\SQFTlight_03_3
Right base folder: C:\Users\pe\Desktop\SQFTlight_03_3-Patched
--- includes\SQFT_GlobalFunctions.php	2011-06-17 10:51:56.000000000 -0700
+++ includes\SQFT_GlobalFunctions.php	2011-08-10 09:43:02.000000000 -0700
@@ -891,14 +891,15 @@
 
 
 function sqftfGetResult($rawparams) {
 	global $use_ns, $storage, $contributereplace, $smwgIP, $smwgDefaultStore, $sqftgIP, $pparams, $sqftgUseCache, $sqftgDefaultLimit, $sqftgDefaultArticleLimit, $wgContLang, $sqftgDefaultArticleParameter, $sqftgDefaultPropertyParameter;
 
         debugtxt(' sqftfGetResult START',true,-1);
-	include_once($smwgIP . "/includes/SMW_QueryProcessor.php");
-        include_once($smwgIP . "/includes/SMW_DataValueFactory.php");
+	// This causes problems due to class autoloading as of at least SMW 1.5.6 and MW 1.16.0.
+	//include_once($smwgIP . "/includes/SMW_QueryProcessor.php");
+    //include_once($smwgIP . "/includes/SMW_DataValueFactory.php");
 
         $storage = 'new';
         if ((isset($smwgDefaultStore)) && ($smwgDefaultStore == 'SMWSQLStore'))
            $storage = 'old';
 
 	$format = 'auto';

Problem with Semantic MediaWiki (Version 1.6)

Hi, I have Semantic MediaWiki (Version 1.6). After installing SemanticQueryFormTool 0.3.3 my "normal pages" work, but I get only empty pages for e.g. Spezial Pages. Also the Collapsible Menu on the left side (extension Vector) does not work anymore. What could be the problem? Any help is greatly appreciated. Eilan
12:13, 13 September 2011 (UTC)

Found the answer myself: This extension is not combatible with SMW 1.6. Also probably not with the Vector extension (probable jQuery incombatibilities). Eilan 08:38, 22 September 2011 (UTC)

Problem with Semantic MediaWiki (Version 1.7.1)

We recently upgraded to SMW 1.7.1 and after reading the above issues related to mine, I understand this isn't a problem with SMW. I receive the following error message:

Database errorFrom Enterprise Data Architecture Jump to: navigation, search A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "". Database returned error "1142: DROP command denied to user 'wikiuser'@'localhost' for table 'semantic_drilldown_filter_values' (localhost)".

This is also happening on 4 DataBrowse cattegories, but we have others that work fine. Any ideas?

content of ask-query disappears after re-editing

I've got a problem using the semantic mediawiki-query: part of a ask-query disappears after successfully saving and parsing. Take the following query (german wiki setup):

{{
#ask:
[[Kategorie:Buch]]
| format=table
}}

After re-editing it looks like this - main query-content disappeared:

{{
#ask:
|format=table
}} 

Set-up:

• Semantic MediaWiki Version 1.7.1
• Semantic Bundle Version 20120327

Any hints are much appreciated! (See also #After_saving_the_page.2C_query_results_disappear)

Hi, I'm not sure if this is the right place to post your questions.

* "... upgraded to SMW 1.7.1" - Please note that SQFT works only for SMW < 1.6

* "... for table 'semantic_drilldown_filter_values' (localhost) ..." - that sounds more that you have a problem with the Semantic Drilldown extension than with SQFT

Optimale (talk) 16:07, 15 October 2012 (UTC)

Thank you for the hint, copied the post to https://www.mediawiki.org/wiki/Talk:Semantic_Bundle

User:T-maios