headers
Andreas Gohr | 1 Sep 2006 04:00
Favicon
Gravatar

darcs changes 2006-09-01


Good Morning!

This are the darcs changes for DokuWiki committed
yesterday. Please test them and report bugs.

---------------------------------------------------------------------
Thu Aug 31 11:21:46 CEST 2006  chris[at]jalakai.co.uk
  * add unittests for bug#891

Thu Aug 31 02:34:13 CEST 2006  chris[at]jalakai.co.uk
  * search improvements

  ft_snippet()
  - make utf8 algorithm default
  - add workaround for utf8_substr() limitations, bug #891
  - fix some indexes which missed out on conversion to utf8 
    character counts
  - minor improvements

  idx_lookup()
  - minor changes to wildcard matching code to improve performance
    (changes based on profiling results)

  utf8
  - specifically set mb_internal_coding to utf-8 when mb_string
    functions will be used.

---------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guy Brand | 1 Sep 2006 07:54
Picon
Picon

Re: search improvements

On 31 August at 14:35, Guy Brand wrote:

>   How about merging the index.idx and word.idx files to:

  Forget this stupid idea :-)

>   Maybe the page.idx file should store a unique number (id) for each
>   page, instead of using the line number in this file as the pageid
>   (pid). This could let us call a page by its id (pid) and shorten
>   very long URLs.

  This one was incomplete: by unique the writer wanted to say a number
  we can rely on to designate the page.

-- 
  bug

--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Permalink | Reply | 0 comments |
headers
Andreas Gohr | 3 Sep 2006 11:17
Favicon
Gravatar

New changelog system

Hi Ben and interested ones!

I just took a deeper look at the new changelog system and as promised
here are my nitpicks. But first: I absolutely love it. It's really
elegant. Good work!

Here are my few minor points:

set_time_limit should be replaced by  <at> set_time_limit to supress any
errors

I like it how the changelog conversion is implemented as action plugin.
One minor thing I'd add: the plugin should try to disable itself after
finishing the conversion. There is no need to instanciate the whole
plugin when it does nothing anymore. This of course only works if the
plugin directory is writable, so in addition the ?do=check command
should check if the import was finished but the plugin is still enabled
and issue an warning about it.

You use filectime in some places which is probably not what you want:

  "In most Unix filesystems, a file is considered changed when its inode
   data is changed"

It should be replaced with filemtime which also works on Windows
systems.

All calls to unlink() should be prefixed with an  <at>  to suppress possible
errors. I usually do the same for file_exists to compensate for a bug in
one certain PHP version where this prints an error as well.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Andreas Gohr | 3 Sep 2006 12:09
Favicon
Gravatar

Re: New changelog system


Just another addition: Maybe we should move all the changelog code
from common.inc to it's own file?

Andi
Permalink | Reply | 9 comments |
headers
Andreas Gohr | 3 Sep 2006 12:18
Favicon
Gravatar

Two action plugin hook suggestions

Hi Chris and *!

I'd like to get your feedback on two more action plugin hooks. I'm
thinking about a few plugins that would need the following hooks:

one around tpl_metaheaders to add new html meta headers or modify
existing ones. What I wonder about is how the data should be passed.
Should we treat the whole <head> area as one string to be passed in
$data or would some array structure be more useful?

Another hook I'd like to add is in pageTemplate() which would allow
plugins to add certain intelligence into the page creation process.

Chris what do you think?

Andi
Permalink | Reply | 14 comments |
headers
Ben Coburn | 3 Sep 2006 18:42

Re: New changelog system


On Sep 3, 2006, at 2:17 AM, Andreas Gohr wrote:

> Hi Ben and interested ones!
>
> I just took a deeper look at the new changelog system and as promised
> here are my nitpicks. But first: I absolutely love it. It's really
> elegant. Good work!
>
> Here are my few minor points:
>
> set_time_limit should be replaced by  <at> set_time_limit to supress any
> errors
>

Ok.

> I like it how the changelog conversion is implemented as action plugin.
> One minor thing I'd add: the plugin should try to disable itself after
> finishing the conversion. There is no need to instanciate the whole
> plugin when it does nothing anymore. This of course only works if the
> plugin directory is writable, so in addition the ?do=check command
> should check if the import was finished but the plugin is still enabled
> and issue an warning about it.
>

Sounds good, but how do users re-enable it if they need to re-run the 
import. I put 'importoldchangelog' in the $plugin_protected list of the 
plugin manager. This disables all the plugin manager form elements for 
the 'importoldchangelog' plugin. Should the plugin manager be changed
(Continue reading)

Permalink | Reply | 8 comments |
headers
Anika Henke | 3 Sep 2006 18:46
Picon
Favicon

Re: Spam to mail adress despite mailguard

Anika Henke wrote:

> No, I am (and most probably will) not. But I think I will implement the 
> combination of 'visible' and 'hex'.

Just an information for anyone who is interested in doing this: I tried 
to combine the two mailguard options and failed. I am not a real (PHP) 
programmer, and I thought this would be really simple. But I've been 
thwarted by the (too late and too early) rawurlencoding of the address 
in inc/parser/xhtml.php. Sorry, that's too complicated for my poor PHP 
skills ... :-/

So, if anyone feels like doing it, go ahead.

Anika
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Permalink | Reply | 0 comments |
headers
Andreas Gohr | 3 Sep 2006 20:55
Favicon
Gravatar

Tester needed: IE + https

Hi list!

I just pushed a fix for a problem I read on [1], but I don't have a
HTTPS server running so I can't test it. Can anyone here with an HTTPS
server test the current development version and see if (s)he gets a
security warning in IE with the JavaScript?

Andi

[1] http://dean.edwards.name/weblog/2006/06/again/#comment5776
Permalink | Reply | 4 comments |
headers
Anika Henke | 3 Sep 2006 21:07
Picon
Favicon

Re: New changelog system

Andreas Gohr wrote:
> Hi Ben and interested ones!
> 
> I just took a deeper look at the new changelog system and as promised
> here are my nitpicks. But first: I absolutely love it. It's really
> elegant. Good work!
> 

Hi Ben and all!

I cannot tell if I absolutely love it, because ... mee nod speek goot 
PHP. ;-) But I very much like the general idea and tested a few things 
and can give everyday user feedback (ie. "bugreports" ;-)):

* When I remove a page, it is still listed in the Old Revisions. Which 
is definitely good (and also covers FS#745).
* But the link to that removed page is green (probably not that bad as 
it first seems) and links to a revision which says "No such revision" (bad).
* And the diff button is beside the latest change (only if it was a 
deletion!), which compares the deleted page with itself ...
* The Recent Changes behaves a bit differently from the Old Revisions: 
red link (like before) and comparison of the current page with the 
current page (still, only when the page has been deleted).
* If I want to "restore the deletion of a page", ie. I remove a page, 
then I restore it again and then I restore that deletion by going to the 
revision that says "removed" on the Old Revisions and "No such revision" 
on the page itself: I click "Create this page", get an empty edit 
textarea (as expected), click "Save" and (not as expected) get ...

Warning: Invalid argument supplied for foreach() in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Gohr | 3 Sep 2006 21:16
Favicon
Gravatar

Re: New changelog system


> > I like it how the changelog conversion is implemented as action
> > plugin. One minor thing I'd add: the plugin should try to disable
> > itself after finishing the conversion. There is no need to
> > instanciate the whole plugin when it does nothing anymore. This of
> > course only works if the plugin directory is writable, so in
> > addition the ?do=check command should check if the import was
> > finished but the plugin is still enabled and issue an warning about
> > it.
> >
> 
> Sounds good, but how do users re-enable it if they need to re-run the 
> import. I put 'importoldchangelog' in the $plugin_protected list of
> the  plugin manager. This disables all the plugin manager form
> elements for  the 'importoldchangelog' plugin. Should the plugin
> manager be changed  to allow protected plugins that are disabled to be
> re-enabled?

Hmm. Why should a user want to re-run the import if it finished
successfully the first time? I think there is no need to set this plugin
to protected. 

> No, this is exactly what I want. I use this when checking if the
> recent  changelog cache needs to be trimmed. The cache is updated on
> every page  edit so filemtime is useless (for this purpose). To ensure
> that the  inode change time reflects the time when the recent
> changelog cache was  last trimmed, I explicitly unlink the file before
> saving the newly  trimmed version.

Okay. My mistake.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane