Revision [2858]

This is an old revision of WikkaBugs made by JsnX on 2004-12-05 14:48:26.

 

Bugs/Issues discovered in Wikka!


Related pages:
  • for issues related to Wikka layout refer to: WikkaCSS
 




Please post recently discovered bugs on the top of this page.



Expanded Text Search fails

I tried an expanded Text-Search after +parameter +link and got the following error:

Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33

for every page.
--NilsLindenberg

Yet more formatter bugs

Looking at formatters/wikka.php to find the cause of the two bugs listed below (found one), I notice to my horror that a lot of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: demo in the SandBox, and in the list below!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
,Note: see also ,My,Page - yup, that's a real page now. ;-)

Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
,-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
,-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
,-now use only these building blocks when using REs anywhere in the Wikka core.
This should make it much easier to create both correct, and consistent regular expressions; any (near)duplicates will be much easier to discover, and fix.

Probably best to leave this to just after the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
--JavaWoman


List parsing bug?

Have a look at the source of WikkaDevelopment, you will see that tabs and unordered lists for some reasons are not correctly parsed (actually after one edit, tabs were added at the beginning of each line). I'll try to figure out why this happens...
-- DarTar

Possible clue:
I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) HomePage had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default HomePage (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.

No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.

And, BTW, if you look at the preview when editing, the HTML source of the preview actually contains a lot of Wiki code that shouldn't be there!

I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
--JavaWoman


MySQL issue


MySQL 5+ isn't supported as it requires PHP to use the mysqli extension instead of plain old mysql. I hoped there would be a single file to change this, but there seems to be no database abstraction in this project at all.

-- DavidCarrington

I do not have access to a MySQL 5 server for testing. And judging by the feedback that I see here on Wikka, most other Wikka admins are using older versions of MySQL. However, I do like progress, so I looked at the documentation for the mysqli extension. I don't see any major issue here. It looks like the function calls are the same, they just have a different name. Instead of calling mysql_connect, you call mysqli_connect. Instead of calling mysql_query, you call mysqli_query. So on and so forth.

It seems that we would just have to do a simple version check and call "mysql" functions for older versions, and "mysqli" functions for newer versions.

Please correct me if I'm missing something. -- JsnX 26 Nov 2004


Login Problem

I have several users that have trouble staying logged in using ie 6.0.XX.

I have no problems with IE 6.0.xx. Perhaps they don't accept cookies? The login is stored in (one?) cookie. So if you don't allow them, the status as logged in simply wouldn't be stored.
--NilsLindenberg
PS: I tried it with the IE. If you block cookies, you can't login.

More info: I checked with two of the users, both have their "Privacy" set to "Medium" (tools/internet options). This seeme to be a default setting of ie, and perhaps the Wikka Cookies should be able to work with that.
I worked around the problem by setting their Ie to allow all cookies from my wiki host... Not ideal, i know..

I'm using a freshly installed copy of Windows XP SP2 with Privacy set to medium--and all other settings are at the defaults--and it works. There must be another cause in your environment beyond having Privacy set to medium. -- JsnX


User search - should be case-sensitive
I was going through user pages, and looked at the homepage by user DaN; clicking on the name does the TextSearch thing: http://wikka.jsnx.com/TextSearch?phrase=DaN which brings up a surprising number of pages, none of which have actually been touched by DaN, it seems (at least non of the ones I checked). Using the browser to search in some of the listed pages (and their revision history) I found hits on words like "dangerous" - and nothing else. This way, the user search feature isn't all that useful, I'm afraid. A whole-word search may be difficult, but could we at least make it (optionally) case-sensitive so that a search for a user name or page name doesn't bring up a host of spurious results?

(That homepage looks at least marginally like spam to me - has DaN done anything else but post a link to an obviously commercial site? Just wondering...)
-- JavaWoman

Actually it is really easy to do a whole-word search--just include the item in double quotes. This info can be found at the bottom of the text search page in the Tips section. To address your issue, I added a regular expression to the search function:
 if (preg_match('/[A-Z]/', $phrase)) $phrase = "\"".$phrase."\""; 

If a capital letter is found in the search phrase, the search phrase will be automatically enclosed in double quotes for you. This seems to fix what you didn't like, but shouldn't cause too much unexpected behaviour for others. Let me know what you think. -- JsnX 27 Nov 2004



Problem with "History"??
I ran across this on another wikka implementation....
http://elvito.sv-city.de/wikka.php?wakka=RecentChanges
if you look at Sun, 22 Aug 2004 the second item down says
[ (20:46 CEST∞) [history∞] - TextSearch?phrase=ElVitoWakkaWiki∞ ⇒ ppp-82-135-6-82.mnet-online.de ] which seems kinda wrong. -- Mike (aka GmBowen)



Email Addresses
Found several issues with how email addresses are validated / accepted / used; outlined on WikkaAndEmail - and I'm working on solutions. (Email is complicated and there's a whole bunch of standards (RFCs) involved.)

First part of the solutions now in WikkaEmailToolkit; while the toolkit is still incomplete, what's there now can be used as presented there (no dependencies on later components).
-- JavaWoman


Bugs I've found:



Thanks - Sam






CategoryDevelopment
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki