Last modified: 2011-03-13 18:06:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T24651, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22651 - Backward compatibility for formlink when using "target=" in query string
Backward compatibility for formlink when using "target=" in query string
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
All All
: Lowest critical (vote)
: ---
Assigned To: Yaron Koren
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-26 00:10 UTC by Jack D. Pond
Modified: 2011-03-13 18:06 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patches to fix formlink error and php error for EditLink (1.28 KB, application/octet-stream)
2010-02-26 00:10 UTC, Jack D. Pond
Details
Fixes both SF_AddData.php and SF_EditData.php to allow "mixed" url for backward compatibility (1.28 KB, application/octet-stream)
2010-03-07 11:51 UTC, Jack D. Pond
Details
Allows use of "target=" in query string (707 bytes, patch)
2010-05-08 12:29 UTC, Jack D. Pond
Details

Description Jack D. Pond 2010-02-26 00:10:07 UTC
Created attachment 7169 [details]
Patches to fix formlink error and php error for EditLink

The following error returns when attempting to open a new form/page:

This is the page for editing data. You must specify both a form name and a target page in the URL; it should look like 'Special:EditData?form=<form name>&target=<target page>', or 'Special:EditData/<form name>/<target page>'.

>From Special:EditData

URL: http://wiki.montcopa.org/TestWiki/index.php?title=Special:EditData
(in this case it will also throw a PHP error: Undefined offset:  1 in TestWiki\extensions\SemanticForms\specials\SF_EditData.php on line 34)


>From a formlink using the new documentation in the code:
* 'formlink' is called as:
 *
 * {{#formlink:form=|link text=|link type=|query string=}}
 *

Wikitext: {{#formlink:form=Referral Forms | link text=Add Referral Form | link type=button | query string=target=REF:{{BASEPAGENAME}}&namespace=REF}}

URL: http://wiki.montcopa.org/TestWiki/index.php?title=Special:AddData/Referr
al_Forms&target=REF:Active%20Part-10019&namespace=REF
Comment 1 Yaron Koren 2010-02-28 15:29:47 UTC
Hi, if you already know the target page's name, #formlink is not the recommended approach - instead, it's better to link via a semantic property, that has a "default form" specified: that way, the link will work correctly both before and after the target page is created.
Comment 2 Jack D. Pond 2010-02-28 16:24:25 UTC
Interesting.  In this case though, the form name IS NOT a property - it is nothing more than an index to multiple pages of the same type in order to maintain unique identifier information.

For example in this case this is Participant information.  The numbers of particpants is constantly growing - and may have no single unique identifier (example 2 participants with same name).  Unique identifier information is deliberately NOT kept (e.g., SSN or other privacy identifiers).  While this solution would work in this particular case, the identifier is the same name as the page, but a different namespace.
Comment 3 Yaron Koren 2010-03-01 05:18:12 UTC
Setting to "WONTFIX" - the red-link approach turned out to work for this case, after an additional conversation.
Comment 4 Jack D. Pond 2010-03-01 11:52:11 UTC
Uh, no it didn't fix the problem, it gave me an alternate solution - which I can't use because I would have to go back and change every place #formlink is used - and the users like the "button" versus the link - they've specifically told me so.

I can (and will) maintain this as a branch.  In general, I think code should be "bullet proof", so that if someone uses a feature in compliance with the documentation, the code should not generate an error.

In this case, if you use the #formlink (as specified):

* 'formlink' is called as:
 *
 * {{#formlink:form=|link text=|link type=|query string=}}
 *

It will generate an error, and there is no other way to create an add via a button versus a link.
Comment 5 Jack D. Pond 2010-03-01 12:07:50 UTC
Oh, and I'm not the only one having this problem:  http://sourceforge.net/mailarchive/forum.php?thread_name=op.u8odx7sy7wtwxn%40mail.libero.it&forum_name=semediawiki-user
Comment 6 Yaron Koren 2010-03-01 14:33:11 UTC
Is using "target=" within #formlink part of the documentation? I don't believe it is. Also, in that email you cited, everyone else is talking about the "cancel" link - totally unrelated to this issue.
Comment 7 Jack D. Pond 2010-03-07 11:51:47 UTC
Created attachment 7183 [details]
Fixes both SF_AddData.php and SF_EditData.php to allow "mixed" url for backward compatibility

Created a patch that fixes both SF_AddData.php and SF_EditData.php to allow "mixed" url for backward compatibility for #formlink and direct URL access.
Comment 8 Jack D. Pond 2010-05-08 12:29:54 UTC
Created attachment 7356 [details]
Allows use of "target=" in query string

Simplified and moved into single area of SF_FormEdit.php
Comment 9 Jack D. Pond 2010-05-08 12:31:08 UTC
I'm reduced to flat out begging!  I'm re-opening this because it's raised its ugly head again - and there's simply to alternative because of its extensive use in so many of our wikis.

This new patch allows the use of "target=" in the query string.  It has no performance impact and does not add to the complexity of the existing code (it just moves the check for  "target_name" two lines down.

Most importantly, it provides for backward compatibility of a widely used feature (at least in our wikis) for which there is no other alternative other than a redlink (they REALLY like the buttons as it provides a visual cue to which information sets do not have completed associated sub-forms).

Patch attached (Above).

PLEASE, PRETTY PLEASE???
Comment 10 Yaron Koren 2010-05-09 17:20:03 UTC
Now that I think about it, the code in SF that transforms the red links could also add a CSS class to those links, so that CSS styling could be added to make those links look like buttons (see here, for example - http://www.webpelican.com/web-tutorials/css-buttons-tutorial/). How does that sound?
Comment 11 Jack D. Pond 2010-05-09 17:58:40 UTC
Uh, I guess, but it doesn't solve my backward compatibility problem. If it's that much trouble, I'll just maintain the patch.
Comment 12 Yaron Koren 2010-05-09 18:10:20 UTC
Setting back to "WONTFIX"; enjoy your hacks.
Comment 13 Jack D. Pond 2010-05-09 18:55:26 UTC
OK, it's your baby, and I'm screwed.

I was beginning to think that SF was a stretch for this application.  Documentation has always been weak, leading to innovative solutions for problems that are not fully documented - such as was done in this case.

I have no idea how many other places we may have "stretched" SF and frankly, it would be poor management to wait for other upgrades to find out.

Knowing forward compatibility is going to be a problem really reinforces looking for a more appropriate solution.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links