Petko did something clever with the Thumblist recipe which also faced a
similar issue with generating many thumbnails.
It now seems to be virtually unlimited by the number to process as long
as each uses 30 second to render
Simon
Christophe David wrote:
I've just updated the import.php script
On Thursday 31 May 2007, Simon wrote:
Petko did something clever with the Thumblist recipe which also faced a
similar issue with generating many thumbnails.
It now seems to be virtually unlimited by the number to process as long
as each uses 30 second to render
To create a number of
On Sat, May 26, 2007 at 11:08:36PM +0200, Christophe David wrote:
However, when you have **many** files to import (as when you have one
page per record in an emulated database, your often reach the server
timeout when importing.
May I suggest to add one more configuration variable to specify
I've just updated the import.php script with an $ImportTime variable
to indicate the maximum amount of time (in seconds) that the script should
spend importing files. The default is 15 seconds.
Thanks a lot for further improving this very useful recipe.
If time expires before import has
On Mon, May 28, 2007 at 10:24:14AM +0200, Christophe David wrote:
If time expires before import has finished processing files, it attempts
to change the timestamp of the .lastimport file so that it will continue
processing more imports on the next browse request. (Regardless, it will
check
On Mon, May 28, 2007 at 05:35:45PM +0200, Christophe David wrote:
This isn't entirely accurate. The visitors never see their requests
taking 15 seconds, as the pages are updated in the background _after_
each visitor's normal request is handled. In other words, visitors
never see a delay in
By the way, there is one more action that would ideally complement the
import... ;-) Guess what ? action=export. This would take the
content of the page and copy it as text in an export directory.
If you consider using action=source for that, the feature is already
available... ;)
On Sun, May 27, 2007 at 08:28:32AM +0200, Christophe David wrote:
By the way, there is one more action that would ideally complement the
import... ;-) Guess what ? action=export. This would take the
content of the page and copy it as text in an export directory.
If you consider using
A simple answer might be to simply extend ?action=source so that
it not only returns a copy of the source to the browser, but
optionally exports a copy of the text to an export directory
somewhere.
This would be perfect indeed: action=export could run the same code as
action=source and save
On Sun, May 27, 2007 at 09:34:13AM -0500, Patrick R. Michaud wrote:
?action=source would seem to work pretty well for this.
A simple answer might be to simply extend ?action=source so that
it not only returns a copy of the source to the browser, but
optionally exports a copy of the text to
This already exists in import.php, as $ImportFilePattern (no 's').
I am using the new import feature extensively now, and it works great.
However, when you have **many** files to import (as when you have one
page per record in an emulated database, your often reach the server
timeout when
On Sat, May 26, 2007 at 11:08:36PM +0200, Christophe David wrote:
However, when you have **many** files to import (as when you have one
page per record in an emulated database, your often reach the server
timeout when importing.
May I suggest to add one more configuration variable to specify
May I suggest to add one more configuration variable to specify a
maximum script running time or a maximum number of files to import in
one run ?
Sure, we can do that. But note the caveat below...
This way, the first request could import a first batch of files
without reaching the
On 5/27/07, Christophe David [EMAIL PROTECTED] wrote:
[...]
By the way, there is one more action that would ideally complement the
import... ;-) Guess what ? action=export. This would take the
content of the page and copy it as text in an export directory.
I have many pages that are quite
Let's say not passwords but permisions.
What if the imported text starts (optionally) with some options e.g.
ImportOptions
[keyword=value]
...
Author=Xyz
[EMAIL PROTECTED]
Summary=Pricelist valid from 24.5.2007
...
ImportOptionsEnd
.
Regards,
Jiri
Mike Bishop napsal(a):
On Wed, May 23, 2007
http://www.pmwiki.org/wiki/Cookbook/ImportText
Whenever this script detects that the import/ directory has changed,
or at intervals given by $ImportFreq (in seconds), it scans the
import/ directory to see if there are any new files to be imported.
Could you please explain how this works ?
On Thu, May 24, 2007 at 10:13:24AM +0200, Christophe David wrote:
http://www.pmwiki.org/wiki/Cookbook/ImportText
Whenever this script detects that the import/ directory has changed,
or at intervals given by $ImportFreq (in seconds), it scans the
import/ directory to see if there are any
On Thu, May 24, 2007 at 08:13:20AM -0500, Patrick R. Michaud wrote:
On Thu, May 24, 2007 at 10:13:24AM +0200, Christophe David wrote:
If I want to have the files imported as soon as possible, is there a
drawback in setting $ImportFreq=1 knowing that pages are only imported
once ?
Setting
Following up to my previous post, I should go ahead and
outline the other ways to get things imported quickly
without setting $ImportFreq to a low value.
Thanks a lot, Patrick. It is very helpful indeed.
While you are at it, I have one more suggestion for this new recipe:
On Thu, May 24, 2007 at 06:16:05PM +0200, Christophe David wrote:
While you are at it, I have one more suggestion for this new recipe:
SDV('ImportFilesPattern', '.*'), and a check when importing that this
pattern is met.
This would allow things like $ImportFilesPattern =
This already exists in import.php, as $ImportFilePattern (no 's').
I should have checked the source ;-)
Wonderful !
Christophe
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
On Thu, May 24, 2007 at 10:30:25AM -0500, Patrick R. Michaud wrote:
On Thu, May 24, 2007 at 08:13:20AM -0500, Patrick R. Michaud wrote:
On Thu, May 24, 2007 at 10:13:24AM +0200, Christophe David wrote:
If I want to have the files imported as soon as possible, is there a
drawback in
However, the $EnableDrafts capability was always disabling the HTML cache,
as well as any recipes that happen to call the CondAuth() function.
I've now fixed this in pmwiki-2.2.0-beta50, just released.
For long pagelists, it's pretty dramatic.
That was it ! Indeed, the improvement is really
On 23/05/07, Kathryn Andersen [EMAIL PROTECTED] wrote:
A question, though: what if the page one is importing already exists in
the wiki? Would it simply overwrite it, or would it be treated as a
conflict?
I would suggest to treat an imported file exactly like a manual edit,
so that versioning
On Wed, May 23, 2007 at 10:17:14AM +0200, Christophe David wrote:
On 23/05/07, Kathryn Andersen [EMAIL PROTECTED] wrote:
A question, though: what if the page one is importing already exists in
the wiki? Would it simply overwrite it, or would it be treated as a
conflict?
I would suggest
On Wed, May 23, 2007 at 10:17:14AM +0200, Christophe David wrote:
On 23/05/07, Kathryn Andersen [EMAIL PROTECTED] wrote:
A question, though: what if the page one is importing already exists in
the wiki? Would it simply overwrite it, or would it be treated as a
conflict?
I would suggest
Could the long-dreamed-of email to wiki feature somehow piggy-back on this
development?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
On Wed, May 23, 2007 at 09:25:20AM +0200, Christophe David wrote:
One more question:
The BreakPageList recipe
(http://www.pmwiki.org/wiki/Cookbook/BreakPageList) creates urls like
Group1/Name1?p=10.
As far as I can see, the page Group1/Name1 is cached, but going from
one subpage to
On Tue, May 22, 2007 at 04:33:06PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
I don't want to push you, but if you could tell me how many nights I
still have to
On Wed, May 23, 2007 at 05:26:08PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 04:33:06PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
I don't want to
On Wed, May 23, 2007 at 04:35:18PM -0800, Mike Bishop wrote:
On Wed, May 23, 2007 at 05:26:08PM -0500, Patrick R. Michaud wrote:
http://www.pmwiki.org/wiki/Cookbook/ImportText
Note that this recipe requires pmwiki-2.2.0-beta51 (just released).
Initial tests (?action=import)
On Wed, May 23, 2007 at 08:36:27PM -0500, Patrick R. Michaud wrote:
On Wed, May 23, 2007 at 04:35:18PM -0800, Mike Bishop wrote:
On Wed, May 23, 2007 at 05:26:08PM -0500, Patrick R. Michaud wrote:
http://www.pmwiki.org/wiki/Cookbook/ImportText
Note that this recipe requires
Also, it would help to know which you think is more important:
- getting an import feature to work
- getting pagelist to work properly with HTML caching
Apparently you get both. :-)
This is really great. Thank you so much for your help.
To add something significant in 2.3 you
Oh, I think I might have misread the original. There are two
steps needed for indexing: first, the page file needs to
have an appropriate target= value (this normally occurs when
the page is saved); second, the target= values go into the
.pageindex file.
I was thinking that a reindexall
I am using beta 49, and have wiki pages created dynamically from
external applications (say Group1.Name1, Group1.Name2, etc.), and a
simple (:pagelist group=Group1:) fails to list them.
Deleting .pageindex does not help.
When creating a page with PmWIki in Group1, pagelist sees it.
Part of
On Tue, May 22, 2007 at 02:55:29PM +0200, Christophe David wrote:
I am using beta 49, and have wiki pages created dynamically from
external applications (say Group1.Name1, Group1.Name2, etc.), and a
simple (:pagelist group=Group1:) fails to list them.
Deleting .pageindex does not help.
On Tue, May 22, 2007 at 03:40:00PM +0200, Christophe David wrote:
Could you please explain how (:pagelist:) works internally in order to
take the neccessary steps to get externally generated pages listed ?
Are the caching options related somehow ?
In particular, PmWiki does not seem to cache
On Tue, May 22, 2007 at 08:40:27AM -0500, Patrick R. Michaud wrote:
If yes, then the problem is that PmWiki can't
see that a page has been created by an external program, and
therefore doesn't realize that the pagelist cache it's already
created is invalid.
One way that we could improve
On 05/22/07 09am, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 08:40:27AM -0500, Patrick R. Michaud wrote:
If yes, then the problem is that PmWiki can't
see that a page has been created by an external program, and
therefore doesn't realize that the pagelist cache it's already
One way that we could improve things here would be to provide
an avenue whereby an external application could create a plain
text file somewhere, and then issue a command to PmWiki telling
it to update the page with the contents of the text file. Then
PmWiki could handle generating all of
On Tue, May 22, 2007 at 06:09:17PM +0200, Christophe David wrote:
One way that we could improve things here would be to provide
an avenue whereby an external application could create a plain
text file somewhere, and then issue a command to PmWiki telling
it to update the page with the contents
It could also check the timestamp of the import directory itself,
to perhaps detect the import more quickly. So then we'd have both,
a check every n minutes, and a check whenever the import/ directory
obviously changed somehow.
Indeed.
We'd probably need to do the actual conversion as a
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
Speaking for myself, I prefer the import feature quickly and possibly
some small delay sometimes that having to wait until an elegant
background solution can be found.
Doing things in the background isn't a really a problem --
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
snip
But if I get a lot of me too requests for this feature, its
priority goes up accordingly. :-) And it'll undoubtedly be a
recipe, not a core feature.
Pm
Okay, I’ll add a me too (but it’s not urgent).
I
On Tue, May 22, 2007 at 11:44:43AM -0800, Mike Bishop wrote:
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
But if I get a lot of me too requests for this feature, its
priority goes up accordingly. :-) And it'll undoubtedly be a
Okay, I’ll add a me too (but
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
I don't want to push you, but if you could tell me how many nights I
still have to sleep before seeing it ;-)
Could happen tonight (small probability),
On Tue, May 22, 2007 at 04:33:06PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
I don't want to push you, but if you could tell me how many nights I
still have to
On Tuesday 22 May 2007 23:33, Patrick R. Michaud wrote:
Also, it would help to know which you think is more important:
- getting an import feature to work
- getting pagelist to work properly with HTML caching
Oh, certainly (2) will benefit immediately to more sites, even those that do
On Tue, May 22, 2007 at 02:33:40PM -0500, Patrick R. Michaud wrote:
On Tue, May 22, 2007 at 09:27:17PM +0200, Christophe David wrote:
[snip -- import feature]
I don't want to push you, but if you could tell me how many nights I
still have to sleep before seeing it ;-)
Could happen tonight
On Wed, May 23, 2007 at 12:14:01AM +0200, Petko Yotov wrote:
On Tuesday 22 May 2007 23:33, Patrick R. Michaud wrote:
Also, it would help to know which you think is more important:
- getting an import feature to work
- getting pagelist to work properly with HTML caching
Oh,
This is correct. The problem is likely that the page is missing
the targets= attribute; PmWiki uses this to determine which pages
link to the corresponding Category page.
I updated http://www.pmwiki.org/wiki/PmWiki/PageFileFormat .
Could you please check if the information I added is
This is correct. The problem is likely that the page is missing
the targets= attribute; PmWiki uses this to determine which pages
link to the corresponding Category page.
There is still something missing...
I populate now the targets attribute myself, so that my page contains
version
On Thu, May 10, 2007 at 09:45:12PM +0200, Christophe David wrote:
This is correct. The problem is likely that the page is missing
the targets= attribute; PmWiki uses this to determine which pages
link to the corresponding Category page.
There is still something missing...
On Thu, May 10, 2007 at 10:00:40PM +0200, Christophe David wrote:
Did you also remove the .pageindex file?
No. That was it.
Everything works OK after deleting it. The first call takes some time to
re-generate it, then everything works fine and fast.
Great !
Doing a re-index currently would require loading and re-saving each page,
which would
take a fair amount of time. Or, we'd need a marker in the page files that
says no need to reindex this one
ExpirediffAll does something similar (agreed, without parsing the text=
attribute) in a reasonable
Patrick R. Michaud wrote:
On Thu, May 10, 2007 at 10:00:40PM +0200, Christophe David wrote:
Did you also remove the .pageindex file?
No. That was it.
(A ReindexAll function and/or action would be nice.)
Agreed it would be nice -- unfortunately, it's not the simplest
thing to
On Thu, May 10, 2007 at 08:25:09PM -0400, Sandy wrote:
Patrick R. Michaud wrote:
On Thu, May 10, 2007 at 10:00:40PM +0200, Christophe David wrote:
Did you also remove the .pageindex file?
No. That was it.
(A ReindexAll function and/or action would be nice.)
Agreed it would
As suggested in http://www.pmwiki.org/wiki/PmWiki/PageFileFormat , I
generate PmWiki pages from external applications, in order to produce
reports and other things while taking advantage of all the PmWki features.
Everything works fine, except that I cannot get categories to work properly
:
1)
On Wed, May 09, 2007 at 11:23:59PM +0200, Christophe David wrote:
As suggested in http://www.pmwiki.org/wiki/PmWiki/PageFileFormat , I
generate PmWiki pages from external applications, in order to produce
reports and other things while taking advantage of all the PmWki features.
At present there's not a re-index function other than editing the
page... but I might be able to come up with one.
It might turn out to be as simple as (untested!)
if ($action == 'reindex')
{ $action = 'edit'; $_POST = array('post'='1'); }
Thanks a lot for your quick reply.
I
60 matches
Mail list logo
