Last modified: 2008-12-02 03:27:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14314 - Special:AddData should catch PHP error when template specified in form is invalid (not a title)
Special:AddData should catch PHP error when template specified in form is inv...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Yaron Koren
http://dev.wiki-tools.com/wiki/Specia...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-28 17:06 UTC by Daniel Friesen
Modified: 2008-12-02 03:27 UTC (History)
1 user (show)

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


Attachments
AddData failed because fromHTML does not generate correct title replacement (1.04 KB, patch)
2008-12-01 23:42 UTC, Li Ding
Details

Description Daniel Friesen 2008-05-28 17:06:59 UTC
Setting Form:Infobox in my case, to an invalid title (In this case I was attempting to try using a parser function in forms... Technically could be valid) results in a PHP error, rather than SMF noticing that the data it is passing to the Article class is illegal and sending out a Wiki error or attempting to do this in some other way.

Since I have PHP's error displaying disabled since that's a half production server, here's the error in the log:
<pre>2008/05/28 12:59:37 [error] 23625#0: *27680 FastCGI sent in stderr: "PHP Catchab
le fatal error:  Argument 1 passed to Article::__construct() must be an instance
 of Title, null given, called in /var/www/mediawiki/sources/extensions-wikimedia
-alpha/SemanticForms/includes/SF_FormClasses.inc on line 89 and defined in /var/
www/mediawiki/sources/mediawiki-alpha/includes/Article.php on line 46" while rea
ding response header from upstream, client: 75.155.167.56, server: dev.wiki-tool
s.com, request: "GET /wiki/Special:AddData/Infobox/Template:Test HTTP/1.1", upst
ream: "fastcgi://127.0.0.1:9000", host: "dev.wiki-tools.com", referrer: "http://
dev.wiki-tools.com/wiki/Special:AddPage?page_name=Test&form=Infobox&namespace=Te
mplate"</pre>
Comment 1 Li Ding 2008-12-01 23:42:14 UTC
Created attachment 5550 [details]
AddData failed because fromHTML does not generate correct title replacement

I encountered the same problem too. In my case, my form and template share the same name "lod.dataset", and the reported bug occurs.

<pre>
Catchable fatal error: Argument 1 passed to Article::__construct() must be an instance of Title, null given, called in .../extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 253 and defined in /var/www/html/tw.rpi.edu/wiki.proj/includes/Article.php on line 47
</pre>

Below is the call stack 

/includes/SF_GlobalFunctions.php  line 253	
<pre>
        $article = new Article($title);
</pre>

/include/SF_GlobalFunctions.php   line 252 
<pre>
function sffPrintRedirectForm($title, $page_contents, $edit_summary, $is_save, $is_preview, $is_diff, $is_minor_edit, $watch_this, $start_time, $edit_time) {
</pre>


/specials/SF_AddData.php   line 168
<pre>
			$text = sffPrintRedirectForm($target_title, $data_text, $wgRequest->getVal('wpSummary'), $save_page, $preview_page, $diff_page, $wgRequest->getCheck('wpMinoredit'), $wgRequest->getCheck('wpWatchthis'), $wgRequest->getVal('wpStarttime'), $wgRequest->getVal('wpEdittime'));
</pre>

/specials/SF_AddData.php   line 22
<pre>
 function printAddForm($form_name, $target_name, $alt_forms) {
</pre>


After some investigation, I found that, in the following code, $generated_page_name was set to empty value, and therefore  $target_title was set to empty.

/specials/SF_AddData.php   line 127-136
<pre>
		list ($form_text, $javascript_text, $data_text, $form_page_title, $generated_page_name) =
			$sfgFormPrinter->formHTML($form_definition, $form_submitted, $page_is_source, $page_contents, $page_title, $page_name_formula);
		if ($form_submitted) {
			if ($page_name_formula != '') {
				// append a namespace, if one was specified
				if ($wgRequest->getCheck('namespace')) {
					$target_name = $wgRequest->getVal('namespace') . ':' . $generated_page_name;
				} else {
					$target_name = $generated_page_name;
				}
</pre>

Further investigation found the cause.

/include/SF_FormPrinter.inc   line 229-234
<pre>
          $tif->template_name = $template_name;
          $query_template_name = str_replace(' ', '_', $template_name);
          // also replace periods with underlines, since that's what
          // POST does to strings anyway
          $query_template_name = str_replace('.', '_', $query_template_name);
</pre>

/include/SF_FormPrinter.inc   line 229-234
<pre>
          $tif->template_name = $template_name;
          $query_template_name = str_replace(' ', '_', $template_name);
          // also replace periods with underlines, since that's what
          // POST does to strings anyway
          $query_template_name = str_replace('.', '_', $query_template_name);
</pre>


/include/SF_FormPrinter.inc   line 635-636
<pre>
              $true_input_name = str_replace('.', '_', $input_name);
              $generated_page_name = str_ireplace("<$true_input_name>", $cur_value_in_template, $generated_page_name);
</pre>


Finally, there is a fix.
<pre>
              $generated_page_name = str_replace('.', '_', $generated_page_name);
              $generated_page_name = str_replace('.', '_', $generated_page_name);
              $generated_page_name = str_ireplace("<$input_name>", $cur_value_in_template, $generated_page_name);
</pre>
Comment 2 Li Ding 2008-12-01 23:44:14 UTC
I hope my patch works
Comment 3 Yaron Koren 2008-12-02 01:33:47 UTC
Hi, thanks, although I don't quite understand the patch - if it's the last three lines, the first two lines are identical.
Comment 4 Li Ding 2008-12-02 02:12:30 UTC
well, below should be the correct ones, they changes '.' and ' ' to '_'.
-------------------------------
$generated_page_name = str_replace('.', '_',$generated_page_name);
$generated_page_name = str_replace(' ', '_',$generated_page_name);
$generated_page_name = str_ireplace("<$input_name>",$cur_value_in_template, $generated_page_name);
---------------------------------

The problem is related to the use of ' ', '.', and '_'. 
* $input_name is extracted from an escaped string $query_template_name, which is escaped
* $generated_page_name, however, is directly copied from param, which has not bee escaped.
Comment 5 Yaron Koren 2008-12-02 03:27:10 UTC
Okay, thanks, that looks better. I hope it works too. :)

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


Navigation
Links