PhpWiki

I have a working version for 

Task "Reimplement Backlinks page"
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=25971&group_id=6121&group_project_id=7691

and some more, but my current problems are:

1) no time until early september.
2) interwiki links are falsely stored in the backlink table.
3) I have too much additional features in my search.php to extract this one.
   esp. I extracted the output code for generated lists of all kinds 
   (search, index, wanted, orphan, ...) into a seperate list.php to support
rows, limit, 
   offset, accelerators, date and sorted by.
   however the advanced search features (regex, and/or, ...) would be nice to
have. 
   I'll do that in september.

Steve Wainstead schrieb:
> I've started a new task list on SF for a 1.2.1 release. There are a
> handful of patches that need to be applied.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

On Aug 17, 2001, Steve Wainstead said:> 
> 
> Jeff, some months ago didn't we receive a patch for Dutch and you
> mentioned on the list that it should be applied to 1.2?
> 

Jan Nieuwenhuizen submitted a bunch of patches (on the development
branch) at the end of May.

I applied the patches to the devel branch, but did not back-port
them to the stable version.

At the time, we had this discussion:

On 31 May, 2001 Jan Nieuwenhuizen wrote:
>Jeff Dairiki <dairiki@...> writes:
>> (I have not back-ported any of your translation fixes to the stable
>> branch of the CVS --- should they be?)
>
>Nah, not worth the effort imo.

Given that at present, a real beta release of the devel branch still
seems a ways away, maybe it is worth reconsidering...

Jan, are you interested in taking a look at it?  (If not I can try,
I suppose --- but I don't speak Dutch.)

Jeff

On Aug 17, 2001, Reini Urban said:
> I have a working version for 
> 
> Task "Reimplement Backlinks page"

This appears be in the 1.3.x (devel branch) task list, not the 1.2.x 
(stable)
task list.  (BTW Reini: is there a reason it's marked 'deleted' now?  
Should
I undelete it?)

I've been planning on doing this (though you're welcome to, Reini) in 
the
devel branch, but have been waiting until the database API stabilizes.

On the other hand, I would like to fix this (now) in the stable branch.
(I know there's a "feature freeze", but I consider this more of a bug 
fix,
than a new feature.)   If you only use WikiWords for page names
the current scheme works okay, but currently the "backlinks" search for
[names like this] will hit every page containing the words "names",
"like" and "this" anywhere within the entire page text.

Fixing this will require non-trivial changes to each of the database
backends, so I can also understand arguments that it should be left as
it is, for now.

If there are no objections, however, I will work on this over the next
few days.



Another issue which is probably worth dealing with is the case
insensitivity in page names bug.
 http://sf.net/tracker/index.php?func=detail&aid=233898&group_id=6121&at
id=106121

Fixing this properly, however, would require schema changes.  Is this
acceptable?

Jeff

On Aug 17, 2001, Reini Urban said:
> isn't this already fixed in 1.3.x ?
> At least I have a trivial fix for this in main.php.
> 
> // enforce anonical "case insensitive bRaCkeT links". 
> // For DOS flatfiles and mysql and "bad queries"
> if ( IsWikiPage($dbi, $pagename) and function_exists('WikiPageName') ) 
>    $pagename = WikiPageName($dbi, $pagename);
> 
> // Enable the output of most of the warning messages.
> // The warnings will screw up zip files and setpref though. 
> ...
> 

That's one way to fix the problem.  I don't really like it though.
(I don't think it's made it's way into the CVS yet either.)

I'd rather fix it so that pages with different capitalization are truly
different pages.  ('PageOne' and 'PagEone', I think should be different 
pages,
with different content.)  (I think we've had this discussion before:
 http://phpwiki.sf.net/phpwiki/index.php?case%20insensitive%20bRaCkeT%20
links
).

This has been fixed for the mysql backend by David Marsh --- notes about
what he did are on the SF bug report page:
 http://sf.net/tracker/index.php?func=detail&aid=233898&group_id=6121&at
id=106121
His fixes haven't made it into the CVS (either branch) yet though...
 ... and they do require a schema change.

Cheers,
Jeff

On Aug 17, 2001, Jeff  said:
> On Aug 17, 2001, Reini Urban said:
> > 
> > Task "Reimplement Backlinks page"
> 
> I've been planning on doing this ...

Okay, well, I just did it.

There is now a real back-link page in the _stable_ branch 
('release-1_2-branch').

It "should" be working with all the database back-ends.  I've 
more-or-less tested the mysql, dba, dbm, and flat-file back-ends.

The msql and pgsql back-ends are, at this point, completely untested.  
(And therefore, likely to be broken.)  If any of you are able to test 
either, please do!


I would still like to fix the page name case-sensitivity issues, but 
would first like to hear from Steve and others how kosher you think 
schema changes are within 1.2.x.

Jeff

On Fri, 17 Aug 2001, Jeff Dairiki wrote:

> The msql and pgsql back-ends are, at this point, completely untested.
> (And therefore, likely to be broken.)  If any of you are able to test
> either, please do!

In two weeks I will be back in Manhattan, where my other Linux box is with
msql... I will test it then. (Don't feel like installing it yet again and
recompiling && etc.)

> I would still like to fix the page name case-sensitivity issues, but
> would first like to hear from Steve and others how kosher you think
> schema changes are within 1.2.x.

How drastic?

cheers
~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

On Aug 17, 2001, Steve Wainstead said:
> 
> In two weeks I will be back in Manhattan, where my other Linux box is with
> msql... I will test it then. (Don't feel like installing it yet again and
> recompiling && etc.)
> 

That's fine.

> > I would still like to fix the page name case-sensitivity issues, but
> > would first like to hear from Steve and others how kosher you think
> > schema changes are within 1.2.x.
> 
> How drastic?

I've really only thought about the MySQL backend so far.
There, columns which hold pagenames need to have the 'binary'
attribute set (their type needs to be changed from
'VARCHAR(100) NOT NULL' to 'VARCHAR(100) BINARY NOT NULL'.)
I think this can be done without necessitating a full
dump/restore of the database.  If someone "forgot" to do
this when they upgraded to 1.2.1, I think the worst that would
happen is that his/her wiki would continue to have case
insensitivity bugs.

 
I don't think the dbm/dba backend is broken, so no problems there.

The flat-file back-end has problems on Win32 systems, because
the stupid filesystem is not case sensitive.  The best fix
I can think of for that is to urlencode() the capital letters
in the page names when forming file names.  (This would
probably require a full dump/restore of the database when
upgrading.)

I'm no expert on pgsql and msql --- they may not even be broken.
If they are, I suspect they could be fixed in a manner similar
to the mysql back-end.

Jeff

On Fri, 17 Aug 2001, Jeff Dairiki wrote:

> > How drastic?
>
> I've really only thought about the MySQL backend so far.
> There, columns which hold pagenames need to have the 'binary'
> attribute set (their type needs to be changed from
> 'VARCHAR(100) NOT NULL' to 'VARCHAR(100) BINARY NOT NULL'.)
> I think this can be done without necessitating a full
> dump/restore of the database.  If someone "forgot" to do
> this when they upgraded to 1.2.1, I think the worst that would
> happen is that his/her wiki would continue to have case
> insensitivity bugs.

Sounds fine... as long as it doesn't require hours of work on your part,
I'd say go ahead.

> The flat-file back-end has problems on Win32 systems, because
> the stupid filesystem is not case sensitive.  The best fix
> I can think of for that is to urlencode() the capital letters
> in the page names when forming file names.  (This would
> probably require a full dump/restore of the database when
> upgrading.)

It's so painful to support Windows systems regardless of type. I'm
inclined to say "You're on your own" if you run it on Windows... sigh. Of
course it's not fair to them. A lot of people have no choice in the
matter.

> I'm no expert on pgsql and msql --- they may not even be broken.
> If they are, I suspect they could be fixed in a manner similar
> to the mysql back-end.

I haven't set up 1.2 on pgsql in a while and I'm having problems vis. the
pgsql setup. Hopefully I'll work it out tomorrow or Sunday. Gotta go scuba
diving early tomorrow morning.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC