OldBugs

These snippets were removed from BugReports after discussions finished or bugs got fixed (or almost fixed at least) - some discussions however never seem to come to an end. This is also a repository for bugs that were reported but will not be fixed (works as designed/configuration problems etc.)

milky: Eventually we should split this page again in smaller pieces (or better write a *AutomaticPageSplit plugin...)

Andy: We could even date them, but I think the new *BugReportForm will cover that aspect and add better options.

BUG#8316 RecentChanges may trick you

ver R1.01e4
os NT (2K,XP)
db db_flat_files
php 4.3.x

Jochen: RecentChanges lists a (diff) at first which is quite handy. This link lists the last changes to a page - very good.

But RecentChanges lists each page only one times. If page a is edited yesterday, tonight, today in the morning and half an hour ago you will only see the changes from half an hour ago. You probably wouldn't notice all the other changes (no need to use the "changes"-link, who would click it?).

Personally I'd think that recent changes would (and should) show me _all_ changes done to all pages in the requested period! Perhaps marking the last change to a page for styling it bold or something.

milky: Short answer: known issue. Longer answer: haven't found the time to fix it.

It's a problem because of the way it prepares the output. It first looks for RecentChanges (over the last week), and then counts together multiple on one page; this is were the (15 changes) comes from. Appearantly it then only sorts this into the very last date a page was changed. I was a bit disturbed by that too, and I'm onto fixing this...

Btw, PhpWiki has a similar page, and they link to the actual mentioned version for older dates, even if the page was already reedited after that - this is also somewhat frustrating as I found out. And also: our RecentChanges was even better, if we just replaced the "diff" with "qdiff" - check it out (simply change it in the URL), really nice.

Henner

Current CVS version, flat file systen. After editing a page i get:

An error occoured while saving your changes. Please try again.

Any idea?

milky: It is still not fully fixed, try to get it once more; I've uploaded a few fixes today. Else it will take a bit more time.

BUG#8314 *RandomPage doesn't work with db_flat_files?

ver R1.01e
os NT (2K,XP)
db db_flat_files
php 4.3.x

Jochen: Calling $id=*RandomPage results in

Warning: array_keys(): The first argument should be an array in ...\plugins\page\randompage.php on line 20

Fatal error: Call to a member function on a non-object in ...\plugins\page\randompage.php on line 21

If *RandomPage doesn't work with db_flat_files it would be nice to be more verbose in the docs (currently: "Shows up a randomly choosen page from the database.")

milky: Appearantly that plugin was stuck in the days of our older database API (we now have that ObjectOrientedDatabaseInterface). Fixed it now, should appear in the CVS tomorrow. Thank you for the note.

So it had nothing to do with db_flat_files - the _files databases aren't just a low-end sibbling, they're really as powerful as the SQL backends (just a bit slower for ::SEARCH requests though).

Jochen: Yes, flat files are fine. That's why I want try with them:o) Btw: Did you notice that the SearchHighlighting is still broken? And to make me (and others?) happy for now with this toc thing without rewriting it please see my UserSuggestion.

milky: Our CVS-tarball wasn't updated automatically: the fix for *SearchHighlighting is to change ", $l)" into ", $l + 1)" in the first substr() call you see in it.

If it is allowed that way, I'll change the #anchor generation code to no longer emit any  .

For db_flat_files: it is a very fine format if you enjoy hacking the pages with an ordinary text editor (a version-less backend was also once in planning) - else give the db_fast_files format or EWIKI_DB_FAST_FILES:=1 a try!

Jochen:

  • no, sorry, changing ", $l)" into ", $l + 1)" was not the fix to *SearchHighlighting. See above, I set a Marker for you:o)
  • *RandomPage seems still broken, it reads now Fatal error: Undefined class name 'ewiki_db' in ...\plugins\page\randompage.php on line 20 Maybe I'm just too stupid, but what did I missed now?
  • Disclaimer: I can't guarantee that empty anchor tags are allowed:o)

milky: Ok, then removing the ", 1 + " should really fix it. It's in CVS now too. For the *RandomPage plugin the error is because I have rewritten it now with the new database API in mind, you needed to upgrade completely first to make use of it now (if you update the core script and your database plugin, you'd have to update all other plugins too). I think a finished new release will be out in two weeks.

BUG#5339 parse error in admin/control.php

ver R1.01e
os Linux
db mysql
php 4.3.x

Stephan Hochdoerfer: In the admin/control.php plugin please change in line 79 ewili_log to ewiki_log.

milky: Thanks for the hint!

  • Lists followed by indented text

Andy: Run together as one line. Shouldn't indentation end the list and force a new paragraph?

milky: No, this is a feature. It is now possible to continue list entries on a second (third, ...) line, if it starts with enough spaces (2 minimum). Other Wikis already supported this syntax for a long time (PhpWiki: for example).

So you must place an empty line between lists and indented paragraphs.

horizontal bars broken

Putting a horizontal bar,

some text, and another horizontal bar

results in two bars at the top of the enclosed text.

Putting

any
number
of horizontal bars

within a paragraph
stacks them all up at the top of the paragraph.

I think HBars should close the paragraph that preceeds them.

Andy

milky: A bug of course. This is probably related to the mixing of $buffered (paragraphs) and direct output (tables,lists).

milky thinks its fixed now - I've simply changed $out .= into $s["para"] .= now, so <hr>s don't make up new paragraphs but simply are put into flowtext <p>aragraphs as usual. This seems to work at a first glance.

Andy thinks Missouri is onto something and can't wait to see the new version deployed here.

15 March 2004: I've discovered a minor bug in tools/t_holes.php . On line 35, .htmlentites is a typo, and it needs to be .htmlentities That's all really :)

milky: Thanks, fixed now. (my favourite typo ;)

Reference detection not the same as the Wiki link callback and the active link vs inactive link code

Andy: LiveUserFiles -- the page exists but it shows up in refs as "UserFiles". The "?" link goes to the actual page.

milky: The ~ and ! here seem to escape just the very first word, and the {link_pre_scan_regex} detects the next possible wiki word as link, while the real/rendering {wiki_link_regex} usually gets it well. The effect now just seems to be a ghost page in the "refs" database field.

milky: This now (feb'04) appears to be almost fixed again.

BUG#5740 PHP5 and Erfurtwiki - error with array_merge

ver R1.01d
os NT (2K,XP)
db mysql
php 5.0b1

Jeroen:
Hi Mario! Long time since I visited this site - it wasn't necessary as the Wiki performed without any problems :-)

However - I do have a problem now, due to an upgrade I made to PHP5 (the latest version - Release Candidate 1). I got warnings (details follow below) on my installed Ewiki version R1.01b1. I upgraded to Ewiki version R1.01d1 to see if that would make a difference. But unfortunately, I still get the same warnings. These are the warnings I get:

Warning: array_merge() [function.array-merge]: Argument #2 is not an array in ewiki.php on line 187
(and the same warning for the lines 192, 290 and 366 in ewiki.php)
Warning: Invalid argument supplied for foreach() in ewiki.php on line 1643

Due to these warnings, the page-action EditThisPage is not shown. I hope you can help me with this. I know php5 is as yet an experimental release, so maybe that's the causer of the problem. However, due to the comment of the warning, I think the function array_merge is more strictly checked in php5.

To put things in perspective - the Ewiki I use that is live will continue to run on php4 for a long time, so there is no stress as to having this fixed for me on some short term or anything like that - the live situation remains the same, and is stable.

Still, I hope you can help me with this. It would be okay for the development situation I have to have the Ewiki run with php5.

Best regards,
Jeroen

btw - nice bug form :-)

milky: Hey Jeroen. Yes, the form is funny - not that it was neccessary or so ;)

Thanks for your notes about the current bugs, very insightful. The problem itself however was already expected to happen, see PhpFiveBetaTwo. The PHP team changed language semantics a lot, the upcoming PHP5 is working hardly towards a fixed typing system.

Earlier beta versions of PHP5 broke with the array_merge() function - however the error message you've shown here, suggests that they overhauled it a bit, and don't exit() the PHP interpreter at that point anymore. I'm still hoping enough people will complain so they fix it before the final release. Meanwhile you could use the patch from our 'fragments/php-patches/' to fix php5 (yours at least).

If the PHP team refuses to fix it, it isn't that a big deal to work around the bug (one of their favourite "won't fix" bugs) in ewiki. It in fact boils down to adding some typecast statements into the code - everywhere a reference to array_merge() was: 

  $r = array_merge( (array)$a1, (array)$a2, ...

This then did the type conversion on behalf of the current array_merge() function (which currently does not recognize NULL as empty array as it should by the PHP language spec).

So, this will be fixed, just not with release of PHP5.0.0 (first versions are always bug-prone); I'd like to wait and see them fix that issue, instead of blowing up the ewiki code base unneccessarily. -- mario

Jeroen:
Hello Mario!
Thank you for your swift and clear response.
I used the (array) typecasting as you described in your answer to solve the problem. This works absolutely fantastic! I've put (array) everywhere where needed in ewiki.php, and the problems are gone. Also the warning Invalid argument supplied for foreach() in ewiki.php on line 1643 is gone.
Thank you very much!
Jeroen

milky: I guess this could even be automated with a tiny script; and I'll just put one into the tools/ dir with the next version, so there would be no need to do this by hand. (Eventually this script then evolves into a standalone forwards compatiblity language syntax converter or so).

*DB_FAST_FILES slow and inreliable

*DB_FAST_FILES may not be. If you turn on the 'HIT' code, the computer must open, decompress, then update, and recompress the whole page. Compression is not faster of course. In addition, this is done with no locking! So it puts the data at risk, as a corrupted compressed file is hard to recover much from, while at least a corrupted text file could have most of the data recovered.

milky: All too true. But dbff was always just a pseudo-database backend, and whoever uses it (in favour of dba/dbm or sqlite) problaby knows that.

For the curruption problem: I don't think this is likely, because the data files are written at once. So the worst thing that could happen here was that only one of two concurrent file content updates would succeed.

Well, that would be true if the calls used the unix write() call directly. They
don't though, they go through the buffered fopen calls which write things out in chunks internally. After some more review of this code I can see some race conditions in files that are not compressed as well.

In addition, it is not fast to have all the files in one directory. At least each 'page' should have its own directory. Probably even better is a hash for the top level, then each page having a directory. Or at least have a top level directory based on the first letter of the page. Then in each page directory should be a META file for storing the meta information, the actually page version files, and a count or hits file so the hit counting operation can be as isolated and fast as possible.

milky: Multiple subdirs were not much faster, because instead of 500 files, you would have 300 subdirs then - And this had additionally a very large impact on disc space!

But whatever, there are already plans to add an advanced dbff, which for example keeps track of pages with a cache file (pagename and versions index). And it is probably also possible to split pages into first-letter subdirs also, for speed purposes. Likewise there could be a separate cache file for hit counting.

However it's probably better to create a database plugin, which itself could mantain a dba/dbm like binary database file (FAT64 format or so ;)

But eventually a RCS database backend comes into existence before.

Well, on UFS directory searching is a quadraticly scalling operation, so as the number of files and revisions gets larger, eventually the readddir() stuff becomes very slow. I am suprised subdirs had a large impact on disk space though. What file system was this on?

Is there anywork done on the advanced dbff yet? It looks like the anydb can use postgresql directly without a db abstraction library? Is that true? I am still trying to pick a storage routine to use for a public wiki.

milky: anydb itself is an abstraction layer and can reuse existing abstraction layers (dbx, ADO, PEAR), but it can access postgres or mysql by their native functions. However with postgres you cannot upload binary files. Whatever, thanks to ewikictl --backup and --insert you can convert at any time later - and I personally start using dbff but switch to mysql on occasion. So my recommendation is to use whatever you like best. If you ever encounter problems, you could easily switch, or better: let us fix the bugs!

I think directories take up much space on every filesystem, including ext2/ext3. For "SEARCH" and "GETALL" database subcalls you won't however get much speed advance, because those then needed to scan in 26 (or 255) subdirs instead of one.

An advanced version of dbff is probably easily done, as it only involves fixing the internal filename conversion subfunctions ("DSR", "FN" and "ID"), the "FIND" and "GETALL" then however needed a bit more attention. So this will take a while until a version gets ready, and if you want to upgrade (there then will be two dbff versions, no integration) you have to go the --backup --all and --insert conversion way.

So far no implimentation of dbff past dbff has been done or worked on? Asking another way, would it be a waste of time for me to start on one?

wm_indent has by default a '<div ...' string. I want to change this and try to make it a <blockquote>, which I think would work in more browsers, but there is no code for setting the close tag. The code assumes it is to be '</div>'. Also, is there a way to have it not put a '<p>' for the item in the blockquote? I think it should become <blockquote>text..., and not <blockquote><p>text...

milky: The <p> thing must remain unfixed for the moment (only solution was to throw

, like all other Wiki:WikiEngines do). The <div> code is however corrected now, you can just set "wm_indent" to "<blockquote>" (get the CVS tarball).

You should then adjust the space counting code - search for 2.65 in the _format() function. Else you'd get too much indentation with the emitted <blockquote>s.

Thanks, I noticed that about the spacing also, I guess you do not like the idea of the blockquotes enough to make them the default? One could always then use css to change the spacing of them I think.

milky: Oh, I'd really like to see intendation work even in lynx and my w3m, but I probably won't set this up per default, as both abusing <blockquote> or <ul> is in clear violence of the HTML spec. Even if ewiki never reached for XHTML compliance, I also don't like to make code output as worse as that of other engines.

Though I'm going to note the <blockquote> idea somewhere in the README, because others would likely find this useful too.

Well, the html 4.01 spec says "Visual user agents generally render BLOCKQUOTE as an indented block."

as well as

"However, as some authors have used BLOCKQUOTE merely as a mechanism to indent text, in order to preserve the intention of the authors, user agents should not insert quotation marks in the default style."

It also says, that "the prefered way to do indents is with style sheets", however the blockquote is shorter and work in more browsers today. Since it is rendered from the wikitext each time, it is not as bad as authoring static pages using it. In any event, the html spec while depreciating this usage of the block quote, clearer acknowledged it, and codifies it as the way a browser should render it, so it is not quite against the html spec, but is against the intent of SGML and semantic tags. All, my long winded way of saying it is valid html 4.01 at least.

Hi there ! Don't know if it is a bug or what, but the PowerSearch doesn't work. ?id= is empty when called the second time (containing the query). I've edited page_powersearch.php and replaced .$id. with .PowerSearch. -> now it works. Maybe someone fixes this ?

Greetings, Joern

milky: Thanks for the note! This bug was already detected (thursday on the MailingList), and should now also be fixed in the CVS tarball or with the latest bugfix release (which is R1.01c2). -- That plugin occours to have been broken for at least a month (it was a small but bad variable name issue).

Hyperlinks not visible in editable page

Hallo!

I installed the ErfurtWiki, which went very easy actually. I use a MySQL database and an Apache webserver. The wiki is shown allright and works - that is, I only get to see the first editable page. When I enter a WikiWord in that page, no hyperlink appears. I read the readme and the forum over and over, but I can't find neither the problem nor a solution. I would hope very much you can help me with this. I think the Erfurtwiki is a fantastic wiki, and I hope I can really get it operational on my site.

Best regards, Jeroen

milky: Sounds bad :( There were some changes during recent development, and the regular expressions were also broken in one of the latest snapshots, so please try to use the latest-CVS-tarball now again, and see if it helps. Additionally you should first try to use square

brackets notation to see if this creates valid [HyperLinks] - if even this fails there would be something really broken. -- I've currently got no other good idea, why you could have that problems.

Dear milky.

Thank you for your fast response. I downloaded the latest tarball and installed it. Everythings works fine now :-)

In hindsight, I think the installation was not complete, thus causing the problem. It has nothing to do with the Erfurtwiki itself, I think it is good for you to know that.

Installation was a breeze, it is now fully integrated in my website :-)

It is a great product!

Best regards, Jeroen

milky: The notify: makes us respond that fast ;) - For the installation thingi, I already discovered the problem too this afternoon (Andy caused it!! *argh*). However the whole package gets more stable now, we target a major relase end of the week. And thanks for the product praising, but don't forget to visit our WishList from time to time!

READONLY flag inoperative

Jeroen: That 'notify' is a great feature indeed! I have the Wiki operational now, it runs okay, stable and fast. It really is a fine Wiki. I'm tailoring it a bit to my own requirements, and with the well detailed README this goes just fine. However, there is one thing I just don't get a grip of. I would like some pages to be readonly, depending on the value of 'flags'. When I use the /tools to set a certain page to RO, 'flags' gets the value '17'. But the page still remains editable. I also tried the 'PROTECTED_MODE' option, but that seems to account for all pages, whereas I want only some pages to be readonly. Hence, the 'flags' seemed to me the perfect place to handle this. I would much apreciate it if you can give me some advice on this. Best regards, Jeroen. BTW - I just entered a small contribution in the WishList, see pre-formatted text. Best regards.

milky: Nobody noticed this until today: there was a bug in the edit/ action handler which ignored the _READONLY flag for pages, because it didn't see the internal var $ewiki_ring (which indeed comes from the PROTECTED_MODE you mentioned). However it is fixed now, and the next release (tomorrow) will contain a working version.

Hallo milky.

I'm glad to read there is a solution coming so soon :-)

I'll install the new release then, when it arrives.

Regards, Jeroen

Andy: milky, I'm always amazed how quick you are on the patch. What did I do to that poor tortured link Regex anyway?

milky: If your talking about the bug (below) regarding the link problems with anchors and LiveUserFiles, there was also a problem with spaces returned from the simpler {link_pre_scan_regex}, what I just fixed with an trim() now (always better than fiddling unneccesarily with the regex).

Andy: No, actually I was talking about the one above that I got blamed for...

milky: *laugh* Yep, I found the note again. After studying the CVSlog I now remembered the reason for the temporary problems with the regex - the fix for the anchors and hash signs broke some other things (one fixed bug leads to two others...) That was what made me crying "Andy caused it!!".

However, to make this little issue look less critical, I'd like to admint, that it was me who broke the binary/image thingi, caused various rendering bugs and made most utils unuseable throughout the dev versions of the last two weeks :(

Jeroen: Ehm, sorry fellows, I feel I want to add something here, because the problems I experienced with the first installation I made with the Erfurtwiki were NOT caused by the Erfurtwiki itself at all. I made the first installation not with a sourceforge package, but from a copy I got from someone else. The copy turned out to be incomplete, the /tools were missing, and maybe some other files too.

At the time I installed it, I did not know the copy was incomplete, I found that out later, when I installed a Wiki from the sourceforge pages. So, the fault was all mine, I should have checked things better.
The installation of the package from the sourceforge site really gave no problems at all, everything went very easy, including the integration with my own php-based site.

Best regards, Jeroen

milky: The main package was broken nevertheless, and even if the initial reasons and assumptions to check it were wrong, we found a few other bugs and fixed them. So you actually got a stripped package version from someone else, but the package on which this was based was also broken in the first place.

escaping, database error

Jeroen: Ah, that clears a lot. Good to read a bug was detected and solved as a result :-)

I installed the new release (R1.01b), and it functions okay. The read-only flag works fine now, I'm very happy with that.

I noticed a small difference to the handling of the pagename. In release R1.01a, I could use ' in the pagename. But in R1.01b that gives a MySQl-error. I suppose a ' in a pagename is not escaped anymore in R1.01b for use in a MySQL-query?

It's no big deal, I simply adjusted the pagenames, problem solved. But as it is different behaviour in comparison to R1.01a, I thought it was worth mentioning here.

While I'm at it, I noticed a -- very small -- bug in the /tools: whenever I use the /tools to set a page flag, an extra record is created in table ewiki, with an empty 'pagename'.

Well, that's it for now. I'm going to fill and test the Wiki a little more.

Best regards, Jeroen

milky: I haven't experienced either of the problems yet (neither on sf.net nor on my local setup). Could you say which PHP version you are using. We are escaping apostrophes and the like with mysql_escape_string() now (in R1.00a it was still the cheaper addslahes), which may be broken in some PHP versions(?)

For the tools/t_flags.php I'm also not aware where the problem could arise from. ewikictl would at least tell what it did. We previously had the problem with the empty page "" showing up, which is not critical of course. This could have been caused by a browser(?)

Jeroen

Hallo milky :-)

Here is what I use: Erfurtwiki R1.01b, PHP 4.3.1.1, Apache 1.3.28, MySQL 4.0.12, on both a Windows 2000 Professional and a Linux RedHat 8.0 platform.

I just tested this again (on the Windows platform), and indeed /tools made an empty line in table ewiki when I set a page-flag. But because you mentioned the escaping of ', I looked further and saw I still had one pagename with two ' characters in it! This record was also [set] by the /tools, although I had not set a flag there.

I removed the ' characters from that pagename, and tried again. This time everything went okay :-) So indeed it was the escaping of ' !

I think this explains both problems. Still, I wonder why I can't use ' in a pagename. Maybe mysql_escape_string() does not work on my system. Haven't tested this on the Linux platform yet though.

Best regards, Jeroen.

milky: pages like *'with'apostrophes' seem to work even on sourceforge.net, so here's nothing wrong with mysql_escape_string(). Does it print any MySQL error message if you use ' within of your pagenames? You should add some error_reporting(E_ALL) and "echo mysql_error()" at the end of ewiki_database_mysql() to help tracking that down. I currently still haven't any idea, why and where these problems could arise.

milky: I found a possible reason now! In the tools/t_flags the pagenames weren't encoded (htmlentities) correctly for the html <form>, so eventually the t_flags script received wrong parameters and thus saw an "empty page" instead. I tried to use a strong_htmlentities() fix, but now decided to use rawurlencode(), because this looks more controllable and reliable with any browser and PHP version combinations.

But, have you meanwhile a copy of the mysql error message?

Jeroen

Hallo milky.

Took me a while to react, I've been very busy lately. Too bad...

And I owe you a BIG apology because the mysql error was my own fault!

I've put some mysql statements in the wiki, which I tested of course, but I've overlooked one completely! That gave the error.

The error message was a general 'You have an error in your MySQl syntax' message. Should have made me suspicious...

I'm sorry!

Regards, Jeroen.

milky: No problem, it's anyhow good to hear, that there weren't all that much bugs this time :)

Uploaded Images are only 1 Pixel small

Hartmut: I run the actual major-release (b) of the excellent Erfurt-Wiki. Image-Uploading works, but the pictures are all shown with a size of 1 Pixel and are sort of invisible then.

Image-Uploading and showing worked fine until I installed the mentioned release.

I could reproduce the error in the Sandbox of this Erfurt-Wiki-Installation.

Many greetings from Austria, Hartmut

milky: Hmm, strange, I've uploaded a picture onto here (sf.net) yesterday and it seemed to do fine. Could you say which graphic format it was (.jpeg and .png are handled totally diferent in libgd). What database interface do you use at home (mysql or flat_file)?

It would help if you could make a backup of the saved file using ewikictl --backup --format flat or tools/t_backup respectively (the uploaded image has a filename like "internal:\\md5md5md5md5md5..."); this would reveal if the image got already corrupted during upload, or if only the page renderer now is broken about it. The backup file then contains a line called "meta:" where two values "width" and "height" were encoded, go and find them, to see if they also tell something about the 1 pixel.

There are many reasons (including PhpFiveBetaTwo) why this may fail, so it takes a little bit more of investigation. Possibly the rescaling plugin is broken (plugins/imgresize_gd) or so...

milky/update: found the problem; the rendered pages read <img src="..." width="a" height="a"> which obviously isn't a good thing (I didn't see the effect, because my browser usually doesn't care about such things). The problem now lies in how the {meta} was unserialized() or not. A bugfix release will follow tomorrow.

Hartmut:

Many thanks for the prompt response!

page names made up of integers

Do pages containing numbers (i.e. *2003) work here? THey don't on my install.

milky: Looks like a serious bug in the "link_pre_scan_regex". But it's fixed now! (was a problem with PHPs array_merge() function)

2004-Jan-08: problems with "homepage" example

There is in the example section / subdirectory a version of a protected ErfurtWiki using cookies and passwords.

Using the www.apachefriends.org WAMPP implementation, I can not get this runnning at all. Maybe I am blind but it looks like whatever password I use or define, I can not get this working.

I know that this is not the way users want me to use Wikis but I fear I need to protect notes that way - or could I use .htaccess methods for that?

Did I overlook something? Thanks in advance for your kind support. ///Stefano.

milky: I don't see any problems with having such a PersonalWiki, but it is possible (though more complex to setup) to have a small subset of pages still available for editing by anyone else.

The homepage example is rather old, and I haven't checked it out for a longer period of time, so guess it's time to do so now...

Your problem seems just to be, that your password isn't recognized at all (it is transmitted via Cookies, but set via Javascript). You could in fact use some sort of .htaccess authentication (see also .../fragemnts/funcs/auth.php for the easy way) and the method described in the README as "simple usage restrictions via WikiWrappers". Basically you just would first create a "index.php" (for anybody else) with code like unset($ewiki_plugins["action"]["edit"]); to disallow editing, and second an "admin.php" script for yourself, which then included() the fragments/funcs/auth to require a password.

Eventually the example homepage script is guessworking, because some of ewikis` ProtectedMode code which it partially depends on is currently a bit broken. (You could test the CVS tarball then, where it eventually works correctly again.)

Andy: For a more complex system you can look at the auth-liveuser plugin set. These plugins allow for arbitrary numbers of groups and users and for arbitrary rights to pages.

the old version deletion tool doesn't seem to delete the versions it claims to

Andy: I ran tools/t_holes.php on one of my pages with 52 versions and got this as output: 

create page version holes
purging page versions:
'*EmployeeLiveWebHome' versions 2..42

After the cgi ran all versions of the page were still present in the database. I haven't checked farther but ewikictl from the command line worked properly.

mario: A variable name mismatch inside tools/t_holes! I fixed that now, but also reworked parts of ewikictl.

lists are not closed nor properly continued after a table starts

Andy: Depending on your template, major problems can arise from following a list with a table without a blank space. I suggest we fix this next time we are working on formatting. -- *ListTableBugDemo

milky: Thats definitely just to consider markup abuse. One really should leave spaces there of course, because tables are meant to be in separate paragraphs. There should also be spaces between a lists beginning asterisk and the text, there should be space after an headline exclamation mark, and so on... (just a doc failure)

Behavior change in anchors

Andy: It appears that anchor links no longer work as documented at ExtendedWikiMarkup#AnchOrs. On an older version of ewiki (ewiki_link_regex_callback() from EWIKI R1.0f6) the following two items are anchors as documented but are not rendered as such in the current rendering engine:

and the following three are not(view source text for clarity):

  • #*IsAnAnchor
  • is this #ananchor what about #*ThIs

Apparently the lines: 

   if ($str*0=="#") {
      $states["define"] = 1;
      $str = substr($str, 1);
   }
   if ($str*0 == "[") {
      $states["brackets"] = 1;
      $str = substr($str, 1, -1);
   }

do not properly handle [#anchorname] links, which are the only proper anchor links. I suggest instead that the above section be written as: 

    if ($str*0 == "[") {
        $states["brackets"] = 1;
        $str = substr($str, 1, -1);
        if ($str*0=="#") {
            $states["define"] = 1;
            $str = substr($str, 1);
        }
    }

milky: Yep, seems we have a difference in what the doc says and the regexs actually do. The hash before the brackets was the old syntax, having a hash after the opening square bracket make an anchor is the proposed new syntax. I think we should support both, but maybe allow to disable the new one. And after all, square brackets should be mandatory - see your examples above!

We could just add the if("#") two times to support both, and make ewiki work really like the documentation already tells it would. But maybe there arise some problems with the regexs (your wikiwords preceded with an hash example) - we'd like to allow WikiPage#WikiAnchor, but should forbid omitting a real page name.

Andy: I suggest we support only the [#anchor] syntax. This is seems to me a rarely used feature and I don't think we should support it two ways nor add heavy complexity to do it. #[anchor] would be slightly worse in my eyes because--to the best of my knowledge--the only modifier we support before open brackets is "!" for escaping.

milky: We'll have the "!" modifier, but also the "~" and the "^". For the anchor thingi it is about how one uses a wiki. While I would suggest using *WikiLinks only, there may be the need for higher quality (long) documents with multiple internal references. There it comes to the question if you prefer creating anchors or linking to anchors. The latter one is superiour (there must be more jumps than anchors, else it was senseless), and the current [# just feels contraproductive to this. read: this needs further discussion

New default layout uncompatible with Konqueror Browser

With the new style (since 25.07.03) the ewiki default layout causes the menus to be displayed on very right of page in Konqueror browser (3.0.4). Probabely problem w/ table-tag. Maybe the same mistake causes main part of page when using the nuke-layout to be displayed very wide (same browser). -- MassenMensch

The New style is also screwed up under mozilla. The nuke layout is fine however.

milky: It looks as it should in all my Mozilla versions, and it also works in Opera and IE (less nicely of course). The Konqueror really breaks thinks a bit (has problems with the "float:" as I figured out). However the menu on the right side is a good thing and intended to be there, it is more comfortable for lynx- and screenreader-users.

APF: It sounds like you are describing the intended look. Personally I'm not sure it's an improvement but it is usable and I expect most users design their own layout anyway.

I hope they do, this is the reason that lead to the new layout.

*anonymous: sorry, but looks like hell in Safari.

milky: That's because of the KHTML (KDE *WebCore) rendering engine. It has some trouble with CSS layouts (which utilize the "float:" thingi to work completely without tables).

Too much OrphanedPages?

I suppose this plugin should find pages which are not linked to by other pages. However, I've found such pages as Mateusz or NewPage there, which, when checked, show to be linked to by other ones. - Mateusz

I think there might be a bug in the GETALL call in the database plugin. Could you see if you have similar issues with aview_linktree?

If it's a bug in GETALL, nearly all plugins were affected. milky

Here's what I'm seeing; when the new getall query is run (I think as added in ewiki.php cvs version 1.17) a SQL query is generated that looks like this: 

  SELECT pagename AS id, 
    MAX(version) AS version, 
    {other fields} 
  FROM ewiki 
  GROUP BY id

the problem seems to be that the {other fields} are being returned with values based on version 1. Particularly important to OrphanedPages and aview_linktree is the refs array. Take the CVS page as an example. It is linked now but not from version 1 of any page. The old approach was to GETALL by first retrieving all of the versions with a query like: 

   SELECT pagename as id, 
     version, 
     {other fields}
   FROM ewiki 
   ORDER BY version DESC

and then add the first version encountered with each page id like this: 

  while ($result && ($row = mysql_fetch_array($result, MYSQL_ASSOC))) {
    if (empty($r[$id=$row["id"]]))
    $r*$id = $row;
  }

I suggest we go back to the older method or query for current version and then retrieve pages. A sub-select would also work but it's not universally available the MySQL Manual has some comments. APF

milky: Yes, I think Andy is right on this. The only real problem I could imagine was the GETALL query (there is nothing wrong in the OrphanedPages plugin). GETALL really should only return the latest version for every page, which the current version obviously fails on. The solution is to fix the SQL statement, and to add the ORDER BY again where it was before, so only the latest entry from the database was returned.

milky: The current MAX(version) did not work as intended, the problem however was solved with stripping the additional "version" from $args, before building the SQL query statement: 

  case "GETALL":                                 
     unset($args*version); 
     $result = mysql_query("SELECT pagename AS id, "...

So all work is now done in the database, which is much faster than the old if(empty(...)) approach.

Andy: Sorry, we still don't have a fix here, with or without "ORDER BY version DESC" the query(from CVS 1.57): 

SELECT pagename AS id,
   refs, flags, 
   MAX(version) AS version 
FROM ewiki 
GROUP BY id 
ORDER BY version DESC

returns the refs corresponding to the version 1 of the pages, not the current version as these two plugins require.

milky: According to the MySQL manual the "MAX(version)" and the "GROUPY BY id" should return only the latest entries from the table. However I also experienced problems until I found out that MySQL got bogus because of a misbuilt SQL query - the {version} entry was noted twice = once as MAX(version) and second from $args. The most recent CVS fixed it, but probably just did not appear in anonymousCVS yet (that's annoying!!)

With the wrongly built query my mysqld returned a page version of 4 with the old SQL query, where there was a version 1 available and 19 being the latest ... just one example

Btw, Andy, where do you always get the fancy CVS version numbers from??

milky: The OrphanedPages problem persists.

Andy: I diff like mad. :-)

db_flat_files` data directory ([internal:\\])

*anonymous: If you transfer files from a UNIX to a Win/DOS/Netware server then there will allways occour in any case an "550 Prohibited file name" error message.

milky: Which files? That files in "./files/" are THE DATABASE, these are no files, you should not access them, and you cannot transfer them with any stupid FTP program. Please see the sf.net forum on a discussion about that.

Andy: Is this in the backdown utility? The way I move databases is to back them up one place and back them down (restore) them in another. For progam files I advise installing ewiki on the new machine as normal and moving the data via backup/backdown.

HL: ""The ":" and the "\\" make trouble on Win4 systems. While the files are nowadays still stored in 8.3 format on your hard disk and the things you see in Explorer are "Visual Filenames" (that, btw, would support 16-bit-Unicode characters) Redmonders didn't managed to allow you to use all characters (which also results from the DOS ABI/API)." (by milky in Forum

My workaround ist to replace "internal://" in ewiki.php with "internal.". 

LINE 109: define("EWIKI_IDF_INTERNAL", "internal.")
LINE 140: ewiki_plugins["idf"]["url"] = array("http://", "mailto:",
"internal.", "ftp://", ...);

I have no problems using it.

milky: You have problems, because then cached images to not emit their sizes, and thus will make rendering of the final page (in browsers) rather slow.

milky: A much better solution, btw, provides *EWIKI_DBFILES_ENCODE (if set to 1, will yield the same boring filenames under UNIX and DOS/Win systems).

Problems with urlencoded EWIKI_PAGE_INDEX

/Tobias: I am setting up an ErfurtWiki in swedish and want the Page index to include the swedish character 'ä'. I figured out that to have this I have to set the constant EWIKI_PAGE_INDEX to its urlencoded counterpart. This works BUT some plugins does not. For example aview_linktree need to be modified on line 25 to: || $dest = urldecode(EWIKI_PAGE_INDEX); ||

MarioSalzer: What were your problems with including the character as is into the constant. How did it break things? - I have to admit, that I haven't tested this yet...
Passing around the page name urlencoded() is not a good idea, as obviously all functions expect it to be in real string representation (some urldecode() calls however wouldn't break anything, so that could be a good idea). Did you have all the _URLDECODE and _ENCODE constants set to 1? This should usually also encode the name of the page index, whenever links were generated.

I fear this is much like the backslash problem from earlier ErfurtWiki days!! Greets, I'll investigate on this.

Tobias: If I include the character as is it will be urldecoded before it is cecked against the database. And of course this page does not exist, there will be an imediate redirect to edit a page with a very strange name. My _URLDECODE and _URLENCODE have default values i.e. 1.

milky: I did some fixes in CVS, and later had more success with a "*MyPäge" for example. But I haven't yet seen anything that yielded your described problems.

milky: The CVS version (see downloads/) can now be much easier changed, regarding those issues, because there is now a ewiki_script() funciton which handles URL generation and urlencode() things. I think it works around most problems, and you should really check it out, as it propably makes working against any URL problems much more reliable!

Does the database entry (id/pagename field) of your previosly generated page contain the pagename urlencoded() - if so this is wrong, only the db_flat_files names` should contain urlencoded() chars, whereas the content should be in real-string always. Please do a mysql "SELECT pagename FROM ewiki" to check it out, or open the dbff file containing the data.

Tobias: The latest version I tested (f8) did not have the problems I encountered earlier. I think they have been fixed :-). Good job! As for the details. At first, when i set "_PAGE_INDEX" to a string with an 'ä' the urlencoded string ended up in the database. When I defined it to the urlencoded version I had to change the entries in the database manually. After that it worked. But with your fixes I have now returned to the unencoded string.

Has anyone else noticed a bug in multiword pages? It seems that when a page name has multiple words it cannot properly reload after being edited. At some point only the first word is referenced. I suspect lack of quotes but I only see the behavoir on my production deployment, not the test setup nor here. The production deployment runs on flat files while the test setup is already on MySQL so this maybe related to that. Any ideas? APF

The database abstraction will always receive the correct page names (including spaces and both words - or that's at least how it should be). However the db_flat_files has actually two modes, one for UNIX systems and another for DOS filesystems. You should have a look into your "/tmp" directory to see how the pagename got mangled on your system. Encoding spaces as "+" is the default for Win, if there is a "%20" instead something probably went wrong. No better ideas right now. -- milky

I finally came back to this bug and tracked it down some. I believe that in the refresh header style operation somehow they are not being quoted or escaped properly but the issue is being hidden somewhere in my test system because it is sending headers early.

urlencoding the $id seems to work, though some web servers/php versions seem to handle the encoding where needed. The change is from: 

$url = EWIKI_SCRIPT . $id . EWIKI_ADDPARAMDELIM . 'thankyou=1';

to: 


$url = EWIKI_SCRIPT . urlencode($id) . EWIKI_ADDPARAMDELIM . 'thankyou=1';

in ewiki_page_edit() within the if(*EWIKI_EDIT_REDIRECT) block.

-- APF

There was a bug in ewiki_binary_save_image whereby filenames for uploaded images were not properly generated. This is fixed in the later snapshots.

Notify E-mail addresses are not protected on information pages

If an E-mail address is used in a notify link it appears in plain text in the refs section of the "Information about page" page. - Andy

This is back. Does the E-mail protect plugin now let me through because of the cookie? - Andy

milky: The previous fix did something useful to ordinary adresses, but as I actually reviewed that code - I couldn't figure out how it does that. There is however a new version in CVS, which successfully strips all emails from the {refs} array - this however does not strip the mail adresses from the existing database (only impacts new entries), I'll put a small util on sf.net do this.

Great, I'll see if CVS is working for me today. Can you tell me where to look for this code? What do you think about moving the notify records to the metadata array? Andy

milky: I guess the notify: does not work on sourceforge.net, because of "No space left on device". Moving the adresses into {meta} could be possible, but may involve further administration stuff. And after all the current solution is working rather well - except on sf.net of course! The changes where just inside of 'ewiki.php', regarding the address hiding.

Email not protected on diff page

When looking at the diff between versions of a page, the email addresses are not protected from spambots. -- KitzelHoover

milky: now fixed in CVS (also for info/ action).

case-sensitivity

caseinsensitivity or no CaseInSensitivity ?

Attachments broken

Tobias: Attachments seem to be broken in the code that runs this site. I get the following error:

Fatal error: Call to a member function on a non-object in /home/groups/e/er/erfurtwiki/htdocs/plugins/downloads.php on line 216

milky: Yep; The database layer is currently reworked and a typing error lead to that errormessage; it's already fixed in CVS, but as the CVS is unstable right now the installation on this site isn't updated automatically any longer.

The MainMenu as mentioned in LatestNews doesn't seem to work. In Mozilla I see the link to MainMenu on the right but if I hover over it the entire set of menus jumps down the page. -APF

Yep, I failed to get correct 'position:relative;' settings into the involved style settings, therefore it looks that horrible. However anybody is free to contribute a patch; I'll rework it if I find some time.

Complex Table Markup Missing <tr> tags

*markup_complextbl.php does not render the <tr> at the beginning of a row. This is because, in line 40 of the source:

if (!isset($line))

But $line is set to the empty string just before this, so the <tr> portion is skipped. Instead, it should check for an empty variable:

if (empty($line))

Then the opening <tr> tag is rendered properly. -- KitzelHoover

Fix looks right to me, thanks. Andy

Hi... I'm not able to decompress any of the files from sourceforge for your project. Is there any way someone can stuff or zip the package and email it to me? ewiki {at] sc-fa * com 

*stimpsonjcat:/downloads steve% tar xvzf ewiki-R1-1.01a
tar (child): ewiki-R1-1.01a: Cannot read: Operation not permitted
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error exit delayed from previous errors

Stuffit Expander says there's an error

Gnutar just hangs...

milky: Does sound like an empty file. What was the downloaded files size? Did you still have read permissions when trying to unpack it?

Link trees run together

The R1.00f6 aview_linktree plugin in default configuration uses the new flat treeview. On pages that can be reached by multiple, equal-length paths this plugin does not separate the end of one tree from the beginning of the next.

Upgrade to R1.00f8 or later for the fix.

There are errors on the examples 'wiki homepage' and 'parse(README)'

Fixed the stupid 'homepage' example (probably random file deletion at sourceforge's). But I couldn't find anything guessworking with the parse() thingi. -- milky

plugin aview_control2.php

Tobias: Misspelled define on line 9:
define("*EWIKI_CONROL_LINE", 0);
should be
define("*EWIKI_CONTROL_LINE", 0);

milky: Ooops, true! I've corrected it in CVS, thank you for the notice.

Links with vertical bars within tables glitch like this

[test link http://www.yahoo.com/]

Use the new link entitling scheme using double quotes. to avoid this. Double quotes is no *WikiStandard and very specific to ErfurtWiki but handy.

New layout Problems - Reloding again and again

When saving a changed page the thankyou-Site does'nt stop reloding. HL

milky: does not sound like a layout problem, I'll investigate

Problems with "Pages Linking to"

/Tobias: The function "Pages linking to" does not seem to work. No pages are shown at all. (Try clicking on the title of this page). I am no SQL hacker but I think there is an error in the SELECT statement in ewiki_database(). For the SEARCH clause the order of GROUP BY and ORDER BY should be changed. Anyway it works if I do that.

milky: You're right. I already noticed this bug (appeared of course also with SearchPages and PowerSearch), and it's already fixed in CVS. But the bugfix release will appear not before the end of this week. The ORDER BY thingi was intended to do something very different, but now I've got it hopefully -- the MySQL backend is now as stable as the flat files one ;)

Milky,

I looked into the file uploading problem I was having, some more. What we noticed was that no matter what file you upload, it reports that the file has a size of zero. Therefore, it pretty much ignores it completely unless you comment out the code that checks for filesize. And when you do that, if you go and look at the new entry in the database, it has no content, just a filename.

This is in plugins/module/downloads.php and in the binary_save function in ewiki.php.

I'll be gone for a few months. Hope this helps--will talk to you more this summer, hopefully.

Thanks for all the help. --Aciel

PS: I notice that the image files in the snapshot you have running on sourceforge, at erfurtwiki.sf.net, aren't displaying either...so I assume it's not just my configuration.

milky: Possible, we have a very unstable development release running here, and we lately introduced a lot of ProtectedMode calls into the _binary() part. I believe that some things are broken, but because I personally use a text-only browser favourably, I don't notice this usually. But thanks for the note, I'm imediately going to find the problems...

Andy: I probably have some uncommitted fixes to those ProtectedMode calls, but I've been doing a code review of EWiki, LiveUser, and internal code and haven't been able to connect to the CVS since it was reorganized.

milky: You should completely delete your current CVS working directory, AFTER you have checkedout a new one (into a different dir). Then copy all your changed files over into your newly created working dir and try to upload changes then.

There is still one of your files list in the /contrib/ directory, but I'll address this later (or we just delete it, and upload it somewhere else).

Andy: Still out of CVS, in Eclipse all I see is an "ewiki milky" branch. I should probably send some E-mails this afternoon to effect a merge.

milky: I've lately seen a "milky" revision tag (1.1.1) for ewiki.php, but I have no idea what this means. Hopefully sourceforge.net migrates to SubVersion soon...

*Hartmut: I use the latest major-release (version 1.01d). Since the upgrade, the upload of images doesnt work correctly any more. It seems, that the uploaded pictures are stored on the server correctly because they show up in the image gallery. But: the uploaded image isn´t stored on the edited page because of an Javascript Error (IE 6.028). Mozilla 1.6 shows the same error but doesn´t print any error-messages.

milky: - the latest experimental release! ;)

Whatever, this convinces me to finally get rid of the JavaScript and integrate image uploading with the text save function. Also I yet haven't looked up that JS bug. - Thanks for the note!

milky: I think I fixed that again, just grab the CVS tarball. (There were backslash escapes missing for the double quotes used in the JS call.)

*Hartmut: Thank you for the prompt answer. [...] InThePress

BUG#3066 "-" Lists with more than three levels of depth hide levels after 3.

ver CVS last week

AndyFundinger:

  • "-" Lists
    • with more than
      • three levels
        • of depth
          • hide levels
            • after 3.

This is reproducible on the Erfurtwiki.sourceforge.net site.

milky: The <hr> markup and the "-" are incompatible, maybe we could workaround that, but I don't know if that's worth the effort. However the <hr> ---- dashes shouldn't kill the remaining text anyhow.

Andy: Can we just give list markup precedence over hr markup or have hr markup require the rest of the line to be blank/spaces?

milky: That's what I've just done now (little fix). <hr>s can no longer occour inside of lists (make no sense there anyhow). I've also prepared the formatting kernel to filter out bogus list markup.

The ---- dashes killing the remaining text on the line was intention, but we could change that back.

BUG#4795 Pages with WikiWords in link titles render with markup in the output

ver CVS today
os Linux
db mysql
php 4.2.x

AndyFundinger: example:

  • The Hoboken Swing Scene - the dance in Hoboken isn't always that well attended, but it is nice and it's on my way home so I can be found at Willie McBrides most Wednesday nights.

renders as:

  • The ["Hoboken Swing Scene" http:www.hobokenswingscene.com/ ] - the dance in Hoboken isn't always that well attended, but it is nice and it's on my way home so I can be found at ["Willie McBrides?"http:www.williemcbrides.com/] most Wednesday nights.

milky: I've tried to verify that in my personal installation, but everything worked fine. Nevertheless I think it is possible, that WikiWords and URLs can cause havoc against each other, because the rendering kernel is optimized for speed and not necessarily reliability. But then I can't imagine how it could prevent markup parsing, if there was just a WikiWord in a page title? (no idea at all)

Andy: I couldn't reproduce it on my other installations either, but you can see the bug in situ at http://s87660678.onlinehome.us/Andy/?id=view/AndyFundinger&version=33.

BUG#5952 White space lines do not split paragraphs.

ver SF Site

AndyFundinger: Paragraphs

seperated by

lines with spaces

are combined.

I'll work on this unless you know the solution mario.

Andy:I just committed a fix to the CVS as ewiki.php 1.206.

milky I'm currently disconnected, so it's too difficult to check it out, or work on the other bugs.

BUG#5307 E-mail encoding and linking glitches on wiki words

db mysql

AndyFundinger: E-mail addresses with wiki links inside them are neither properly protected by the markup email-protection plugin nor linked with mailto: , Examples:

milky: This could be fixed by rearranging the regexen in *link_regex, but I'm not sure if we should do that really - because the simply mail @ recognition is a hack to make ewiki a bit more userfriendly. People should really use the square bracket syntax and the mailto: prefix. It is only convinience to get mail addresses recognized that easily.

I'm unsure if we should fix this, and if it then is a disadvantage for ordinary page links (in some rare -can't-think-of-one-currently- cases).

milky: Simply changed it now, since the mailto: prefix didn't help with the problem as tests revealed. If someone really needs to write the text "WikiWord@WikiWord" the square brackets notation would save the day ;)

EditThisPage BackLinks PageInfo Pages like this RSS/Atom last changed on Thu Sep 1 00:29:01 2005
bottom corner