Button links broken on IIS installation
- Status
- Closed
- Subject
- Button links broken on IIS installation
- Version
- 3.x
4.x - Category
- Usability
- Support request
- Consistency
- Feature
- Administration
OS independence (Non-Linux, Windows/IIS, Mac, BSD) - Submitted by
- clicc
- Volunteered to solve
- Philippe Cloutier
- Lastmod by
- Philippe Cloutier
- Rating
- Description
I have installed TikiWiki 3rc1 on an IIS (Windows Server 2003) installation with PHP 5 and MySQL. This is a root-level installation. For some reason having to change PATH_TRANSLATED to SCRIPT_FILENAME in line 31 of lib/setup/tikisetup.class.php, which if I don't do I get errors relating to directories not existing and the site not loading at all; this is not the purpose of the support request.
Once I make these tweaks, as well as after setting the tweaks identified in tiki-filter-base.php (that is, changing forward slashes to double-backslashes in quotes), I get the site up and running. ***But*** on administration pages, the buttons created by lib/smarty_tiki/function.button.php (such as "CLEAR CACHE" on the Modules admin page) don't seem to work when accessing the site from Safari or Firefox (Internet Explorer works fine for this).
Instead, in Safari, the clicking on the button will load the script name where the domain name is supposed to go; if my site was on http://site.com/somescript.php?something, it would load http://otherscript.php?something. I don't have my machine handy, so I can't get the Firefox results up at the moment, but IIRC they involved the format http://site.com/\/otherscript.php?something (with a backslash and forward-slash inserted).
A Linux installation of TW3 works fine in Safari and Firefox, so my guess is that it's an IIS issue that has something to do with backslashes and root-directory determination, but I'm somewhat clueless here. I've examined lib/smarty_tiki/block.self_link.php and some tweaking there has produced no viable results.
Also note that this goes away when TikiWiki 3 is placed into a non-root directory; it only affects a root installation at /, rather than at a server subdirectory.
- Solution
- This should be fixed in branch 5.x for Tiki 5.0. See ticket 2250.
- Importance
- 7
- Priority
- 35
- Demonstrate Bug (Tiki 19+)
-
This bug has been demonstrated on show2.tiki.org
Please demonstrate your bug on show2.tiki.org
Version: Create show2.tiki.org instanceAbout show2.tiki.orgTo help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
- Ticket ID
- 2505
- Created
- Friday 15 May, 2009 01:56:54 GMT-0000
by Unknown - LastModif
- Tuesday 25 May, 2010 05:02:10 GMT-0000
Attachments
| filename | created | hits | comment | version | filetype | ||
|---|---|---|---|---|---|---|---|
| No attachments for this item | |||||||
;){kind=link}
;){kind=link}
- Wiki argument variables, Documentation; The help tools of Tiki for Wiki argument variables redirect to the wrong page
- Plugin List, Wiki Argument Variables; Admin should see a warning when the Wiki Argument Variables is not enabled and he tries to use it.
- General, Navigation; Endless loop, too much redirect error, if a wiki page is the value of the option
- Tiki tag ~ hs ~ is lost on wiki page duplication
- Kanban_Board_25 profile produces non-working setup
;){kind=link}
;){kind=link}