[SaintPeter]

With your module, style and .css, I was able to use chdir commands to replicate all of the modifications that you made by changing paths.

Basically, at the top of index.php, add a chdir('modules/MediaWiki') and at the end of index.php add a chdir('../../') to go back. I was able to do this and made NO OTHER changes to the stock localsettings.php or index.php

The only other place to have to add two is around the include('header.php'), like such:

PHP:

	chdir('../../');
	require_once('header.php');
	chdir('modules/wiki/');

Makes the modification much simpiler and reduces the chance that any add-on would have hard-coded paths that would break anything.

[Hókipóki]

That sounds good! As I've said before, I've never used PHP so far, so this idea of using chdir to correct paths never occured to me

The very good news is that your method of only inserting chdir statements at specific points in index.php can probably be fully automated! Via patch, or creating somehow a wrapper .php, which contains only the chdir statements, and the call to index.php in MediaWiki.

I have LEO/SEO (or whatever its called in Dragonfly) disabled. I'm not sure that the slight rewriting of links I've done in wiki via the DragonflyModule extension won't interfere with LEO in Dragonfly.

In the evening I'll try out your modifications! (I'm GMT+2, in Central Europe, Hungary.)

Hókipóki

[Hókipóki]

SaintPeter: I'm trying your chdir solution at the moment. Some special pages don't work, and neither does editing the pages.

Can you check it out, does page editing works in your site with the chroot method? Perhaps I messed up something.

[SaintPeter]

I am able to edit pages just fine.

However, when I use a button to do a diff on the history, it pops me back to the main page, while when I use a link, it works fine. Not sure what is going on there.

[SaintPeter]

In fact, when I do anything that requires a button press, it also goes back to the main page. I think there is a redirect there, but I'm not sure if it's wiki causing it or Dragonfly.

[Hókipóki]

Edit works too in my case, it was a typo of mine

The diff doesn't work for me either, I'm looking onto it.

[SaintPeter]

Well, there is something odd going on with the forum link generation. Check out this:
<form action="/df/index.php?name=wiki&amp;amp;title=Special:Search"

I'm not quite sure what's causing that. I suspect it's a corner case of the replacement code. Gonna check it out.

[SaintPeter]

Ok, I'm on to what is going down.

I used the "debug_print_backtrace()" function in the fnLineHook portion of the DragonflyModule.php to see what was calling what when the bad URL was generated.

Code:

#0  fnLinkHook(Title Object ([mTextform] => Search,[mUrlform] => 
Search,[mDbkeyform] => Search,[mNamespace] => -1,[mInterwiki] => ,[mFragment] => 
,[mArticleID] => 0,[mLatestID] => ,[mRestrictions] => Array 
(),[mRestrictionsLoaded] => ,[mPrefixedText] => ,[mDefaultNamespace] => 
0,[mWatched] => ), /df/index.php/Special:Search, ) 
#1 call_user_func_array(fnLinkHook, Array ([0] => Title Object ([mTextform] => Search,[mUrlform] => Search,
[mDbkeyform] => Search,[mNamespace] => -
1,[mInterwiki] => ,[mFragment] => ,[mArticleID] => 0,[mLatestID] => ,[mRestrictions] => Array (),
[mRestrictionsLoaded] => ,[mPrefixedText] => 
,[mDefaultNamespace] => 0,[mWatched] => ),[1] => 
/df/index.php/Special:Search,[2] => )) called at 
[F:\webpage\df\modules\wiki\includes\Hooks.php:114] 
#2  wfRunHooks(GetLocalURL, 
Array ([0] => Title Object ([mTextform] => Search,[mUrlform] => 
Search,[mDbkeyform] => Search,[mNamespace] => -1,[mInterwiki] => ,[mFragment] => 
,[mArticleID] => 0,[mLatestID] => ,[mRestrictions] => Array 
(),
[mRestrictionsLoaded] => ,[mPrefixedText] => ,[mDefaultNamespace] => 
0,[mWatched] => ),[1] => /df/index.php/Special:Search,[2] => )) called at 
[F:\webpage\df\modules\wiki\includes\Title.php:870] 
#3  Title->getLocalURL() 
called at [F:\webpage\df\modules\wiki\includes\Skin.php:790] 
#4  Skin->getSearchLink() called at [F:\webpage\df\modules\wiki\includes\Skin.php:794] 
#5 Skin->escapeSearchLink() called at 
[F:\webpage\df\modules\wiki\includes\SkinTemplate.php:245]

Basically, it looks like in the fuction escapeSearchLink in Skin.php, the resulting URL is run through "htmlspecialchars()". It takes any '&' and turns it into a '& amp;'. However, it appears that this maybe happens TWICE, somehow, taking the '& amp;' and making it into a '& amp;amp;'

[Hókipóki]

It looks like something is using htmlspecialchars() on the action url

EDIT and you found out who!

[Hókipóki]

A dirty fix for it: replace $this->text('searchaction')
with $this->html('searchaction') in the skin code.

Looks like the QuickTemplate->text call make one htmlspecialchars call, and the escapeSearchLink() makes another hhtmlspec... call.

It was not apparent before, because the original search link what I replaced via the hook didnt contained any ampersend. It was a forward slash using url, like this: wiki/Special:Search or something like this.

But even changing the url generation, search doesnt work for me

[SaintPeter]

Make sure that your user is set to the Dragonfly theme. I adjusted the theme as you described above (I found it about the same time you did) but my user had a default Skin of Monobook. I also modified the function escapeSearchLink() function in Skin.php to get rid of the htmlspecialchars().

Once I had the URL genreration working correctly (verified in view source), it still was not working.

I think I found the crux of the problem. First, I made up this file:

PHP:

<head>
</head>
<body>
<pre>
<?
echo "GET: \n";
var_dump($_GET);
echo "\nPOST: \n";
var_dump($_POST);
?>
</pre>
<form action="testme.php?name=wiki&title=Special:Search" id="searchform">
<input id="searchInput" name="search" type="text" accesskey="f" value="" />
<input type='submit' name="go" class="searchButton" id="searchGoButton"	value="Go" />&nbsp;
<input type='submit' name="fulltext" class="searchButton" value="Search" /></form>
</body>

What I discovered is that if you do not specifiy a 'method' for the form, it defaults to GET. If you do a GET, the two variables passed on the URL do NOT get parsed by PHP. If you use method='post', however, both the GET and POST variables get set.

I added the method='post' in the Dragonfly.php theme file and was able to make it work.

I suspect that a similar solution will work throughout the codebase, even if it is painful. It's just (haha) a matter for finding all instances of <form tags and fixing them. Sigh.

I havn't looked into how good MediaWiki's code/data seperation is yet. Maybe we'll get lucky

[Hókipóki]

I have trouble reaching this site now and then B(

Investigated the search form a little. I have a little theory about it. If anyone with good html knowledge can help me out I would be grateful.

So. In the skin source, the form doesn't specify if its a get or post form. So its handled as a GET form. Now, the problem is, the original search action URL doesnt contain any & characters, but the URL rewritten by the link hook DOES contain amps, at least for the name=MediaWiki part. (Which instructs Dragonfly to pass the whole thing to MediaWiki module, so its absolutely necessery.)

Now, it seems to me that while the browser constructs the url which it will call when sending in the form variables, it simply strips any previous variables from it. So the name=MediaWiki now disappeared from the action URL.

Sincerely I have just a vague idea how forms work.

If I explicitely specify method="POST" in the skin source, so the form morphes into a POST form, the search is working.

If I'm correct, we might be in trouble. But my html knowledge is minimal

[SaintPeter]

Haha - we both posted within a minute of one another. See your answer above.

[Hókipóki]

But you type faster B(

[SaintPeter]

Hókipóki wrote:

But you type faster B(

Sorry

Ok, here is a list of all of the occurances of '<form' in where 'get' was specified or nothing was specified, the /includes directory. There was only one instance of a <form in the Skins directory and we already got that one.

Code:

modules\wiki\includes\SpecialAllpages.php/62:
$out = "<div class='namespaceoptions'><form method='get' action='{$wgScript}'>";

modules\wiki\includes\PageHistory.php/197:
$s .= '<form action="' . $wgTitle->escapeLocalURL( '-' ) . '" method="get">';

modules\wiki\includes\SpecialLog.php/361:
$out->addHTML( "<form action=\"$action\" method=\"get\">\n" .

modules\wiki\includes\Skin.php/1047:
$s = '<form id="specialpages" method="get" class="inline" ' .

modules\wiki\includes\SpecialSearch.php/408:
return "<br /><br />\n<form id=\"powersearch\" method=\"get\" " .

modules\wiki\includes\SpecialRecentchanges.php/594:
$out = "<div class='namespacesettings'><form method='get' action='{$wgScript}'>\n";

modules\wiki\includes\SpecialContributions.php/344:
$f = "<form method='get' action=\"$wgScript\">\n";

modules\wiki\includes\SpecialWatchlist.php/175:
$wgOut->addHTML( '<form action=\'' .

modules\wiki\includes\SpecialWatchlist.php/283:
$wgOut->addHTML( '<form action="' .

So, once we make all those changes (and verify that they work), we ought to be able to concentrate on makeing things look pretty.

Unfortunatly, if we're going to release this, it would need to be as a complete, modified wiki install, I guess. Either that or a set of deltas against a known wiki version. I personally am using the 1.7 line, but I can understand why you'd pick the 1.6 line.