moved from BugReports, see also OldBugs, FixedBugs, *OtherBugs, ...

BUG#6171 duplicate definitions of ewiki_page_index()

Samat: When I installed ewiki-R1.01e1 and tried to upgrade my script, I got a PHP error that ewiki_page_index() was declared twice. I'm not sure where it's supposed to be, but the default config.php includes "plugins/page/pageindex.php" which contains this function, and it also is now inside ewiki.php as well.

I'm thinking a developer accidently committed a MonsterWiki version of ewiki.php to CVS.

I simply deleted the duplicate copy of this function in ewiki.php to make my installation work.

milky: No, it's simply that the PageIndex recently became a core feature. However, I think we suddenly forgot to replace the _pageindex script/plugin with an empty stub to prevent exactly that error. You still had the old plugins/page/pageindex.php online, so there's the problem. Whatever, your fix does basically the same - and your next update will simply overwrite the redundant pageindex script and reinsert it within ewiki.php; no need to worry - but thank you for the note!

BUG#9278 userdb_sql.php

elias:

1. Problem with ewiki/plugins/auth/userdb_sql.php
   • detail - PHP can't execute mysql_fetch_array because the param isn't valid
   • solution - add parantheses to if condition, like following example:
   • line 59 if (($result = $sql_query("SELECT $ROW_PW FROM $TABLE WHERE $ROW_USER='$username'")) && ($row = $sql_fetch($result))) {

i tried the user permissions too, but at the moment it makes no difference if a user is set with 0,1,2 or 3. all users can edit except unlogged users. i use this auth plugin config:

include("plugins/auth/userdb_sql.php");
include("plugins/auth/auth_perm_ring.php");
include("plugins/auth/auth_method_form.php");

however it works well except the user permissions

UPDATE by elias:

i fixed the problem by removing lines 64-68  in plugins/auth/userdb_sql.php
which contains two nested if branches. i dont know what they for but now the 
user permissions works good. (looks like that plugin a bit buggy?)
now im seeking a way to set access to a page for certain permission
levels. (requested this in sf.net/forum too)
i think there was an idea of this, but its not implemented.
kick my ass if im wrong ;)

Andy: It seems like you're looking for a full user/rights system, why don't you try my auth-liveuser plugin set? I've been running it in production and it holds up pretty well. Drop me and E-mail ( Andy>>burgiss.com ) or post here if you have any trouble.

BUG#1384 Tool checklink-feature leads to an 404 error

Wolfgang: A checklink leads to an 404 error and I don´t know why and what I have to submit: A 'WikiPage' or similar or a complete URL? It is a tool-function called check link directory (check all external links of a link directory wiki page) and I use the Version checklinks.php rev. 1.1 (9 month old. Is that the Problem?) from your download page. I think, this is a very usefull feature to control invalid links. My Configuration: I installed first the major release R1.01d with standard features as monster-file with your web-installer and then I overrided the ewiki.php with your latest development-version. Then I build in some actual plugins I needed from your download-site.

milky: Wolfgang, our latest release was R1.01d4 which I'd recommend to you. Your installation path also sounds very interesting - but you could also simply select the "CVS version" in the WebInstaller, which will also give you the latest and greates. For the *file:tools/t_checklinks.php plugin I've also fixed the code now, as I mentioned on the mailing list. If you find it useful, then we could eventually extend it to do the URL check on all pages. I agree that this may be an important task (hence there are so many tools which do exactly that), so we may wish to have something like that in the future. Thanks for sharing your ideas!

BUG#3398 Problem with pre-formatted text in R1.01d1

Jeroen: When I use HTML entities (like < to display < ) they work fine, unless somewhere higher up on the same page <prE> </pRe> is used. The HTML entities are then not seen as HTML-entities anymore.
Note that this happens below the closing </pre>.
This page is a good example, the above < is not displayed as <
I need the HTML-entities however, for explaining code below a pre-formatted part.
I hope you can help me with this.
Regards,
Jeroen

milky: The whole htmlentities() story is a whole mess :( I know. As a workaround I would recommend to enclose parts of the page in <hTml>...</htMl> tags (lowercase then!), because ewiki does not touch such blocks then (entities should work fine then). However, it is possible that there is a new bug in the formatting kernel, because the entities are controlled by a flag setting, which could be hurt by other blocks (like <prE>...</ ones).

As a last resort, you could force back-conversion of all entities (easy thing). But I'd first like to find the real mistake in the code...

milky: I've checked my setup, and it worked quite well for the current R1.01e, so you may wish to update at least the "ewiki.php" core script (I can't remember any major incompatibilites between those two versions). But I also first try to update the version running on this demo site (currently R1.01d5) to verify that entities work again.

Jeroen: As always you are swift. Thank you Mario. I tried <hTml>...</htMl> tags (lowercase of course) but it didn't work, probably these chars are interpreted to be <prE> as well....
I'll upgrade to R1.01e soon and let you know the result.

Jeroen: I upgraded to version R1.01e and yes, the problem is solved! Thank you very much, this is great.

milky: No problem, and it tells me that the project is on the right direction. :)
If the </html> tags don't work you could enable _ALLOW_HTML (or whatever it was called?!) - which may lead to problems if you really have misbehaving users. However generally I would now consider HTML support to be a good thing, especially if you have a lot of place, where it could help and where you really need better page content layout capabilities. It is also possible to put such content snippets into the spages/ directory as .html file and then use the MpiPlugins "include" or "embed" to get that page content into some other page - as drawback it only then was uneditable.

Jeroen: Good tips, thanx. I was not yet aware of these possibilities.

(meanwhile milky finally managed to call the update script to fix it here too)