Extension talk:Page Forms/Archive September 2015

From mediawiki.org
Latest comment: 8 years ago by Yaron Koren in topic Problem with "checkbox"

Adding a list of existing pages names and link into a form results page

Hi Yaron, Hi All,

I want to insert an autocompletion search field into a form to let the users search for existing pages and who "tokenizes" the page name in the field.

In the results page, I should be able to display the name of the pages that have been tokenized in the form. Each page name has a link to its page.

In other words, this functionality will link a page to others.

Any idea how to do that ?

Thanks for your great support.

BR,

I don't really understand the point of this, but it sounds like you could do it with Special:RunQuery, where the template would not call a query but instead just display links to all the pages, using #arraymap. The form would presumably use the "tokens" input type. Yaron Koren (talk) 14:02, 24 September 2015 (UTC)Reply

Inserting a simple popup (modal) in a form

Hello there,

I would like to insert a popup (like a Bootstrap modal) into a form.

Do you know how I can do that ?

I know how to insert a Tooltip and to Enhancing query forms. But I didn't find anything about inserting a simple popup with simple text in it without using HTML.

Thanks a lot

What about a tooltip instead? For that you could use #info, if you have Semantic MediaWiki installed, or if not you could use the SimpleTooltip extension. Yaron Koren (talk) 16:50, 15 September 2015 (UTC)Reply
Hi Yaron, a tooltip is to small for all the content that I want to insert in the popup (image + text) plus, it doesn't fit well in my webdesign. :( is there a way to insert a boostrap modal ? I use Chameleon skin by the way. Thanks.
I fixed the problem. To anyone that might be interested : I used [shortcode of Chameleon] and I remplaced the <button> that is not interpreted by mediawiki by a simple div.

Horizontal code output from form?

Hello Does anyone know whether its possible to force a form to create horizontal code eg.

{{Freigabe|Datum=01.09.2015|Version=01|Variante=1|Teil=00|Signatur=DL}} 

instead of

{{Freigabe
|Datum=01.09.2015
|Version=01
|Variante=1
|Teil=00
|Signatur=DL
}}

I don't want this on every form, so im not looking for a global setting. any ideas?

I don't think it's possible, unfortunately. Yaron Koren (talk) 18:14, 1 September 2015 (UTC)Reply

Save And Continue breaks multi instance forms with divs

Just a heads up, though this might be a bit specific... I have a form with multiple instances. Additional fields appear/disappear depending on your choice from a dropdown. Pressing save and continue and then changing your choice from the dropdown will load the fields as it should, but they're greyed out and not editable until you reload the page. SMW 1.6.2, SF 2.2.1

Automatic page creation "broken" with SMW's php rebuildData.php

On our wiki pages get created automatically with SMW's rebuildDate.php (previously called SMW_refreshData.php) and runJobs.php. We use the ExternalData extension to load customer data into the wiki. When a customer is new the page will then be created automatically. This worked fine but stopped working in SMW 1.9.2. In this release the move was made from SMW_refreshData.php to rebuildData.php. I tested this on MW 1.23.9 and different SF versions, 2.8 and master.

Testing this in my home wiki (MW 1.24.1, SMW dev-master and SF 3.3.1) the same thing happens. Example with a property page called Property:Testname with the following content:

* Has type:[[Has type::Page]]
* [[Creates pages with form::Testcaseautofill]]

== Test pages ==
* [[Testname::Testcase1]]
* [[Testname::Testcase2]]
* [[Testname::Testcase3]]
* [[Testname::Testcase4]]

After saving the page and running php runJobs.php the 4 pages get created automatically.

When I then delete Testcase1 and rebuild with:

php rebuildData.php --no-cache -v

and

php runJobs.php

The page Testcase1 does not get created. The property Testname actually has the value Testcase1 but with a red link. Even when I use the Data repair and upgrade function and run php runJobs.php the page Testcase1 does not get created.

I am pretty sure that SMW_refreshData.php added pages to be created to the MW job Que which you could then "empty" by using runJobs.php. I am not sure why this is not working any more. It seems that SMW's php rebuildData.php is "ignoring" [[Creates pages with form::Testcaseautofill]] or SF as a whole or SF is not doing its "job".

Because of this "problem" it is not possible any more to get pages to be created automatically. The only way to do this in the example above is to refresh the Property:Testname page and run php runJobs.php. I already reported this on GitHub (half way the discussion) because I noticed this behaviour during testing. It would be a shame when this "functionality" is lost. Is this something that can be fixed in SF or in SMW or both? Regards, --Felipe (talk) 12:27, 3 September 2015 (UTC)Reply

The discussion on GitHub has progressed. Yaron, when time permits could you have a look at the comment from MWJames on GitHub? Is this part of a possible "solution" for the problem discussed here, if so is it something that can "easily" be achieved with SF? Thanks, and regards. --Felipe (talk) 12:26, 4 September 2015 (UTC)Reply
Actually, I'm planning to replace the "Creates pages with form" special property with a parser function, like was done with "Has default form" and "Has alternate form". That will remove the SMW-related issues, and will enable Cargo support as well. I'll try to get to that soon. Yaron Koren (talk) 13:34, 4 September 2015 (UTC)Reply
OK, thanks. --Felipe (talk) 14:30, 4 September 2015 (UTC)Reply

I think I found a bug during testing {{#formredlink:...}}. On a Property page (but it can be any page) when you use:

== heading ==
* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}

When you save the page and Testcase1 does not exist the page gets saved but on your screen you get:

[03b02c65] /mediawiki/index.php/Property:Testname MWException from line 86 of /var/www/html/mediawiki/includes/parser/ParserOutput.php: Bad parser output text.
Backtrace:
#0 [internal function]: ParserOutput->{closure}(array)
#1 /var/www/html/mediawiki/includes/parser/ParserOutput.php(97): preg_replace_callback(string, Closure, string)
#2 /var/www/html/mediawiki/includes/OutputPage.php(1854): ParserOutput->getText()
#3 /var/www/html/mediawiki/includes/OutputPage.php(1873): OutputPage->addParserOutputText(ParserOutput)
#4 /var/www/html/mediawiki/includes/page/Article.php(617): OutputPage->addParserOutput(ParserOutput)
#5 /var/www/html/mediawiki/extensions/SemanticMediaWiki/includes/articlepages/SMW_OrderedListPage.php(67): Article->view()
#6 /var/www/html/mediawiki/includes/actions/ViewAction.php(44): SMWOrderedListPage->view()
#7 /var/www/html/mediawiki/includes/MediaWiki.php(458): ViewAction->show()
#8 /var/www/html/mediawiki/includes/MediaWiki.php(255): MediaWiki->performAction(SMWPropertyPage, Title)
#9 /var/www/html/mediawiki/includes/MediaWiki.php(682): MediaWiki->performRequest()
#10 /var/www/html/mediawiki/includes/MediaWiki.php(476): MediaWiki->main()
#11 /var/www/html/mediawiki/index.php(41): MediaWiki->run()
#12 {main}

SMW's php rebuildData.php also won't run BUT When you don't have the heading:

* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}

or there is no heading before {{#formredlink:...}} like:

* [[Testname::Testcase1]] {{#formredlink:form=Testcaseautofill|target=Testcase1|create page}}
== heading ==

It works, the page gets saved without any faults and php rebuildData.php also works. Maybe I am doing something wrong here but that MWException should not come I think. There are also some other strange things happening but that could be me, not understanding {{#formredlink:...}} in combination with create page:). It seems that it is not possible anymore to tell the wiki to create pages for a certain property like Creates pages with form in the past. --Felipe (talk) 08:30, 19 September 2015 (UTC)Reply

That indeed sounds like a bug. But I don't understand why you have that particular text - won't it print the page name twice? Maybe you should use #set to do the setting of the property - and maybe doing that won't lead to the same error. Yaron Koren (talk) 00:22, 21 September 2015 (UTC)Reply
Hello Yaron, yes it will print the text twice. I was just playing around with an "old" template. I did some more testing and below is what is happening when the page that needs to be created does not exist yet.
Example 1 with heading
== heading ==
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
A. This breaks php rebuildData.php, it will fail on the specific page with [7c3c6468] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null. I can send you the Backtrace if you want.
B. When you refresh the page it shows:
If you refresh again the page looks normal and Testcase1 is created.
Example 2 heading below
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
== heading ==
A. This breaks php rebuildData.php, it will fail on the specific page with [e4129d6a] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null.
B. When you refresh the page it looks normal with a redlink for Testcase1.
If you refresh again the page looks normal and Testcase1 is created.
Example 3 no heading
{{#formredlink:form=Testcaseautofill|target=Testcase1|create page}} {{#set:Testname=Testcase1}}
A. This breaks php rebuildData.php, it will fail on the specific page with [465ec2a4] [no req] MWException from line 1662 of C:\Apache\htdocs\mediawiki-1.25.2\includes\OutputPage.php: Title is null.
B. When you refresh the page it looks normal with a redlink for Testcase1.
If you refresh again the page looks normal and Testcase1 is created.
In combination with ExternalData
I also converted our template to use {{#formredlink:...}}. It uses externaldata to generate pages automatically but it is not possible to save the page, you get a blank screen. This is because it uses {{#for_external_table::
{{#get_db_data:db=data
|from=datatable
|data=Testname=Testname
}}

{{#for_external_table:<nowiki/>
* {{#formredlink:form=Testcaseautofill
|target={{{Testname}}}
|create page
}} {{#set:Testname::{{{Testname}}}}}
}}
When we use {{#display_external_table: it works.
{{#get_db_data:db=data
|from=datatable
|data=Testname=Testname
}}

{{#display_external_table:template=Testname
|data=Testname
}}
But the same faults appear as in the earlier examples. When a page does not exist yet php rebuildData.php will fail and if there are headings before {{#formredlink:...}} you get faults on the actual pages. I hope this helps to fix this. Regards, --Felipe (talk) 13:18, 21 September 2015 (UTC)Reply

[SOLVED] Query for the page title in a query form

Hello,

how can I query for the page title in a query form? Since the page title is created via the first form field in the two-step-process, there is no manually created property behind it. I need to have a form field where I can search in the page titles. – I have the feeling I might just be missing something very obvious. –Zabien (talk) 16:52, 3 September 2015 (UTC)Reply

You just need to have the template store the page name via a property (if you're using SMW) or field (if you're using Cargo). In either case, you can use the {{PAGENAME}} magic word. Yaron Koren (talk) 20:10, 3 September 2015 (UTC)Reply
So I have to use e.g. [[Has page title::{{PAGENAME}}]] to be able to query for it later? Okay, that seems to be the obvious I've missed. Thought there might be an even more direct way. Thank you for the quick help! –Zabien (talk) 21:36, 3 September 2015 (UTC)Reply
I think that's the easiest way. Although using #set might be preferable, since you don't want to display a value to the screen. Yaron Koren (talk) 23:16, 3 September 2015 (UTC)Reply
Good point! I'll give this a try! Thanks heaps! –Zabien (talk) 10:21, 4 September 2015 (UTC)Reply

Missing values in "Semantic Property" dropdown box

I am using Mediawiki 1.25.2, Semantic MediaWiki 2.2.2, Semantic Forms 3.3.2 (2e5712c). I tried to create a template. The semantic property dropdown box only list 14 values. Even I add additional properties via Special:CreateProperty. Does it happen to your version? Any fix? --153.20.95.74 08:24, 15 September 2015 (UTC)Reply

I had restarted php-fpm and the problem went away, i.e., there is a cache issue. Is there a mean to force the update of cache? Also renamed properties (redirects were deleted too) also showed up in the list of values of Semantic Property --153.20.95.74 08:29, 15 September 2015 (UTC)Reply
I don't know - this might be a Semantic MediaWiki issue. The SF code is just calling an SMW function to get the list of properties. Yaron Koren (talk) 13:37, 15 September 2015 (UTC)Reply
I would like to confirm that even the property is deleted, the SWM function (please point me to the file or function as I am new to mediawiki and php) still return the deleted property.
That is a known SMW issue - I'm guessing that you can also see that same deleted property on the page Special:Properties. If so, you should ask the SMW developers about it. Yaron Koren (talk) 14:37, 15 September 2015 (UTC)Reply
For a discussion about deleted properties/subjects (and its apparent reappearance), please have a look at the #1100 issue.--MWJames (talk) 14:59, 15 September 2015 (UTC)Reply

Using query string in #forminput

I have a form which has a property "Student ID" and I want this property to be filled from #forminput via query string and using value from the title of the page.

 
  {{#forminput:form=Student|placeholder=Student ID|query string=Student[Student ID]={{PAGENAME}}}}

  </noinclude><includeonly>
  <div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
  {{{for template|Student}}}
  {| class="formtable"
  ! Student ID: 
  | {{{field|Student ID|mandatory|restricted|class=student_name|rows=1|cols=9|maxlength=9}}}
  |}
  {{{end template}}}
  

If I use form name "12345699A", the immediate URL is

 http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=Student
 

What I want is

 http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=12345699A
 

I do not know how to get or parse URL using the existing standard extension as I did not install Extension:UrlGetParameters.

I'm not completely sure I understand, but it sounds like you'd be better off using #formlink instead of #forminput, and a page name formula. Yaron Koren (talk) 14:40, 15 September 2015 (UTC)Reply
I tried #formlink just now, do not know how to enter the "Student ID". My original question can be simplified to

1) Enter 123456789A into the textbox


2) I want $forminput to generate the url

 http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=12345699A
 

instead of

 http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=Student
 

--Yoonghm (talk) 14:59, 15 September 2015 (UTC)Reply

The specific thing you're asking about can't be done. However - if the student ID is always the page name, why do you need a form field for it at all? Can't you just always use the page name? Yaron Koren (talk) 15:03, 15 September 2015 (UTC)Reply
The problem for beginner likes me is that there are too many features within mediawiki and its extensions, there is no other good reference except your book. I want to put the Student ID as a property as I cannot prevent people from changing it and can be used for semantic query. Okay, I will consider your suggestion. --Yoonghm (talk) 15:30, 15 September 2015 (UTC)Reply

Max size for properties

I would like to start a review site and store the reviews in properties. Yet even a comparably short review (800 words, 4500 signs) breaks the parser. What would be the recommendation in order to deal with this? I would like to add interviews with the length off 12(!) A4 pages into a property. Currently, I had to move all into a standard input field in order to avoid broken parser tags.

To give an example of what I talking about: http://adsol.oneyoudontknow.com/index.php/wiki/Anticosm_-_Anticosm

  • Top: the text added as a property (text)
  • Below: text added as a free field.

The lack of formatting is due c/p it from the bottom.

--Temptuousinsolence (talk) 18:17, 15 September 2015 (UTC)Reply

Is this a Semantic Forms question? Anyway, I don't think it's the size of that text that's causing the problem, but rather the fact that it contains square brackets. Yaron Koren (talk) 01:21, 16 September 2015 (UTC)Reply

Group pages (created via Semantic Form) in Category:<category_name> according to other properties instead of page name

I have created several pages using Form:Student with the following page names.

  • 1111111A
  • 1111112B
  • 2222222C
  • 3333333D

These pages are in Students category.

Form:Student uses Template:Student which has the following properties

{{Student
|Student ID=
|Student Name=
|Tutorial Class=
|Admission Year=
|Accumulative GPA=
|Attendance=
|Advisor=
|Acad Program=
}}
In the Category:Students page, these pages are grouped under 1, 2 and 3.

How can I use Tutorial Class property to group them? --Yoonghm (talk) 02:18, 16 September 2015 (UTC)Reply

This isn't a Semantic Forms question, but: you should be able to use DEFAULTSORT for that. Yaron Koren (talk) 13:13, 16 September 2015 (UTC)Reply

Constraining the user to use forms to create a page.

I want to constrain users the use the forms to create a new page.

In other world, users can't create new pages on my wiki. They can ONLY add new pages thought the form. Is there an easy way to do that ?

Thanks a lot.

I don't know of any. Yaron Koren (talk) 13:14, 16 September 2015 (UTC)Reply

#default_form parameter to hide "This category uses the form ..."

Is there a way to hide the "This category uses the form ..." text that is inserted automatically by #default_form? Like [[Has default form::myform| ]]...

--Planetenxin (talk) 11:47, 17 September 2015 (UTC)Reply

Unfortunately, not at the moment - other than putting it in a hidden div or some such. Yaron Koren (talk) 12:56, 17 September 2015 (UTC)Reply

Semantic forms and Translate

Hi,

I'm trying to use Semantic Forms and Translate extensions. My problem is that I can't modify an existing page containing the Translate's tags <translate><!--T1--> with Semantic Forms (big red message when saving "Modifying Page failed").

As the page can safely be modified with the tags using the edit tab, I'd like to know if there is something I can do to force Semantic Forms to save a page with those tags ?

Best regards. LS.

That's unexpected... what versions of MediaWiki and SF are you using? And are the "translate" tags contained above or within the infobox template, or just below it? Yaron Koren (talk) 16:25, 17 September 2015 (UTC)Reply
Thanks for your reply. The versions are the last stables (1.25.2 for Mediawiki) downloaded tuesday. The tags are in the wikicode produced by the form. For example, I create a page containing :
 {{Multi
 |Title=<translate>Blabla</translate>
 |...
 }}
 
by writing <translate>Blabla</translate> in the Title field of a Semantic Form. All goes right until I try to effectively translate the content : as soon as the <!--T1--> appears, it's no more possible to modify the page with the form. If I try to change (with the edit tab) say <translate> in <translat> or <!--T1--> in <!--V1-->, the Semantic Form returns to its normal operation.

--Ludovic Strappazon (talk) 20:57, 17 September 2015 (UTC)Reply

That's unfortunate... I have no idea why that's happening. It sounds like a bug in either SF or Translate, but I don't know more than that. It might be worth creating a Phabricator ticket for it. Yaron Koren (talk) 01:47, 18 September 2015 (UTC)Reply
Hi, I've just seen that if I remove the Translate extension, Semantic Forms returns to its normal operation and save the contents with tags. I'm going to create a ticket. Thanks again.

Best regards, --Ludovic Strappazon (talk) 07:21, 21 September 2015 (UTC)Reply

Wrong format date output

First I want to congratulate you on this great script. I am Spanish, and here the usual format is day / month / year. When I create a page with form, the date field appears in this format. When I edit the property of the field is also used properly displayed in this format. But the end result is always the created page Year / month (with numbers) / day.

I have read through everything and I have tried everything without getting any results. I'm not sure that the problem is in your script, because if I put on any page

{{CURRENTTIMESTAMP}}

also shown year/month/day. But I insist that the property is properly displayed.

Can you help me solve this ?. Thank you very much for your time and help: Luis.

I don't think there's any way to get a form to output day/month/year. But you can have the template display dates in this format to the user, using the #dateformat parser function - see Help:Magic words. Yaron Koren (talk) 16:32, 17 September 2015 (UTC)Reply

Thank you very much for your quick reply. I'm clear that the problem has nothing to do with his script. Anyway, I had already tried this method I have even tried to define it manually in LocalSettings.php simply ignored by my wiki. You can see an example here: [1] Thanks again

I don't understand the syntax you're using in that template - you should be calling #dateformat. Yaron Koren (talk) 01:38, 18 September 2015 (UTC)Reply

solved

Explain the steps if they can be of help to someone: First I tried his method and works but it has any drawbacks:
- Does not accept the format xx / xx / xx so must first replace the "/" with "-"
- The system does not recognize it as date format and has an error, so that the property can not be "date" it must be "text"
- You can not add words to date like (typical in Spanish) "02 de enero de 2010"

The solution I've found to not have any of the above three problems is to use

{{#time:}}

(requires ParserFunctions).

For example

{{#time:d \d\e F \d\e Y|{{{Nacimiento|}}}}}

Where "Nacimiento" is the name of the property that I used to date in my template, It produces output (if such date is 2010/01/20):

20 de enero de 2010

and the system is no problem recognizing it as date. Thank you very much for your support that has helped me a starting point and hope it can be useful to someone. Greetings: Luis

Problem with #default_form

When you transclude a page that uses #default_form through a template, then the page which embeds this transcluded content also inherits #default_form: as a result, that page becomes editable using the wrong form. I'll just stick to the old SMW approach (which lets you embed content without inheriting its annotations). Is there anything else that can be done about this? Best, Cavila 12:18, 21 September 2015 (UTC)Reply

I can't think of anything. Yaron Koren (talk) 13:53, 21 September 2015 (UTC)Reply
Alright, thanks. It's no problem for me as long as that special property is supported. Cavila 18:59, 21 September 2015 (UTC)Reply

Problem with "checkbox"

When i use input type "checkbox" with russian as main wiki language, it stores value "Yes" like "Đ´Đ°". But when I try to edit existing page with this value checkbox shows unchecked. If I manually change value from "Đ´Đ°" to "Yes" the checkbox shows ckecked.

Is it possible to disable this localisation interchange for checkbox and have only Yes?

No... but that's a bug that should be fixed. What versions of SF and MW are you using? Yaron Koren (talk) 14:10, 25 September 2015 (UTC)Reply
I was actually asking about your MW version, not your SMW version, but anyway, I think I have enough information to solve this bug. The issue seems to have been due to a combination of a change I made two months ago and the fact that PHP's regular lowercasing function doesn't work for Cyrillic. I think I just fixed it; if you get the latest SF code, the problem should go away. If not, please let me know. Yaron Koren (talk) 23:21, 11 October 2015 (UTC)Reply
  • I had MW 1.23 but today I've completely updated MW to 1.25, SMW to 2.2.2 and SF to 3.4 (90cb2b3) (latest version including patch with mb_strtolower). It still not shows checkbox checked when template has "Да" as "Yes". I'll send You login data to my wiki (I guess it may help).
  • One important add: I've not set any value to mbstring.internal_encoding, so when I try execute mb_strtolower('Да') I show 4 black diamonds with ask sign into (utf-8 to iso 8859-5). When I execute mb_strtolower('Да','utf-8') I recieve 'Đ´Đ°' (correct).