Re: [pmwiki-devel] PostPage in recipe
I added this to http://www.pmwiki.org/wiki/PmWiki/Functions Typically, the functions of pmwiki.php should ''not be called directly'' in a cookbook recipe which is executed as include file in config.php. At this early stage of PmWiki processing, many internal global variables are not yet properly initialized, and these functions will behave unexpectedly. To execute them timely, use the handler functions described in the articles about [[Custom Markup]] and [[Custom Actions]]. Frank Hans wrote: Monday, March 30, 2009, 9:00:04 PM, Frank wrote: I couldn't understand the role of $AuthorLink yet... and I have to go on with my project now... $AuthorLink is a wiki link to an author page in the Profiles group, defined in scripts/author.php like SDV($AuthorLink,($Author) ? "[[~$Author]]" : '?'); so if the current $Author is 'Adam' $AuthorLink is [[~Adam]], pointing to page $AuthorGroup.Adam, by default Profiles.Adam PmWiki uses $AuthorLink in RecentChanges entries Hans -- ___ Dr. Frank F. Schweickert AMSTEL Institute, Faculty of Science, University of Amsterdam Kruislaan 404, Amsterdam, 1098 SM, Netherlands Room 1.09 Phone: +31 20 525-5969, Fax: +31 20 525-5866 http://www.science.uva.nl/amstel http://www.natsim.net ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Typically, the functions of pmwiki.php should ''not be called directly'' in a cookbook recipe which is executed as include file in config.php. While this is true for UpdatePage() I'm not convinced it is a general rule... This general rule was my initial question to this mailing list. As long as one cannot be sure about the appropriate context, using handlers are the safe way, aren't they? I, for instance, would have destroyed all my page histories otherwise ... BTW I documented the custom action business on a different page at http://www.pmwiki.org/wiki/PmWiki/CustomMarkupAlt#customaction after Hans wrote and before you posted here. I suppose having it in 2 places is better than none... Is it possible to move http://www.pmwiki.org/wiki/PmWiki/CustomMarkupAlt#customaction to http://www.pmwiki.org/wiki/PmWiki/CustomActions ? (by leaving a link, of course) Because I was looking into actions when I felt that Markup was just NOT what I wanted. I suggest promoting Custom Markup and Custom Actions as the two main customization features for add-on scripts. My own earlier naive approach of scripting effectively during execution config.php (albeit in cookbook includes) is not the way that "layman" add-on authors should be guided too. Frank -- ___ Dr. Frank F. Schweickert AMSTEL Institute, Faculty of Science, University of Amsterdam Kruislaan 404, Amsterdam, 1098 SM, Netherlands Room 1.09 Phone: +31 20 525-5969, Fax: +31 20 525-5866 http://www.science.uva.nl/amstel http://www.natsim.net ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Tuesday, March 31, 2009, 11:30:31 AM, Frank wrote: I suggest promoting Custom Markup and Custom Actions as the two main customization features for add-on scripts. My own earlier naive approach of scripting effectively during execution config.php (albeit in cookbook includes) is not the way that layman add-on authors should be guided too. I think it is great to have those documentation pages. Thanks everyone! We should also not forget custom markup expressions as a special markup for custom commands. The documentation for this is scattered over various cookbook pages at present; actually, i don't think there is a description of how to create custom markup expressions, we just got collections of ready built ones. Hans ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
On Tue, Mar 31, 2009 at 12:10:03PM +0200, Peter Bowers wrote: 2009/3/31 Frank Schweickert f.schweick...@uva.nl I added this to http://www.pmwiki.org/wiki/PmWiki/Functions Typically, the functions of pmwiki.php should ''not be called directly'' in a cookbook recipe which is executed as include file in config.php. At this early stage of PmWiki processing, many internal global variables are not yet properly initialized, and these functions will behave unexpectedly. To execute them timely, use the handler functions described in the articles about [[Custom Markup]] and [[Custom Actions]]. While this is true for UpdatePage() I'm not convinced it is a general rule... Indeed, it's not a general rule, so I've taken the note out. BTW I documented the custom action business on a different page at http:// www.pmwiki.org/wiki/PmWiki/CustomMarkupAlt#customaction after Hans wrote and before you posted here. I suppose having it in 2 places is better than none... I'd rather have it in just one -- otherwise it's more places to update (or refer people to) when we make changes or answer questions. Pm ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
On Tue, Mar 31, 2009 at 12:30:31PM +0200, Frank Schweickert wrote:
Typically, the functions of pmwiki.php should ''not be called
directly'' in a cookbook recipe which is executed as include file in
config.php.
While this is true for UpdatePage() I'm not convinced it is a general
rule...
This general rule was my initial question to this mailing list. As long as one
cannot be sure about the appropriate context, using handlers are the safe way,
aren't they? I, for instance, would have destroyed all my page histories
otherwise ...
I think the likely reason why your page histories weren't being
preserved is that PmWiki had not had an opportunity to load
scripts/phpdiff.php (the module responsible for calculating the history).
So, UpdatePage() was indeed working from incomplete information.
In general the way to get PmWiki to complete its standard initialization
is to load the stdconfig.php script:
include_once('scripts/stdconfig.php');
I suggest promoting Custom Markup and Custom Actions as the two main
customization features for add-on scripts. My own earlier naive approach of
scripting effectively during execution config.php (albeit in cookbook
includes)
is not the way that layman add-on authors should be guided too.
Keep in mind that custom markup is _far_ more common than custom actions.
Pm
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Patrick R. Michaud wrote: I added this to http://www.pmwiki.org/wiki/PmWiki/Functions Typically, the functions of pmwiki.php should ''not be called directly'' in ... While this is true for UpdatePage() I'm not convinced it is a general rule... Indeed, it's not a general rule, so I've taken the note out. I can still my note on http://www.pmwiki.org/wiki/PmWiki/Functions Please just leave something to warn people not to use PmWiki's built-in functions out of context! (or else include 'scripts/stdconfig.php') Frank -- ___ Dr. Frank F. Schweickert AMSTEL Institute, Faculty of Science, University of Amsterdam Kruislaan 404, Amsterdam, 1098 SM, Netherlands Room 1.09 Phone: +31 20 525-5969, Fax: +31 20 525-5866 http://www.science.uva.nl/amstel http://www.natsim.net ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Tuesday, March 31, 2009, 3:27:17 PM, Patrick wrote:
The CustomMarkup page isn't sufficient for how to create custom
markup expressions?
I think there is a misunderstanding of what constitutes markup and
what markup exressions.
I just looked at http://www.pmwiki.org/wiki/PmWiki/CustomMarkup
It describes how to create custom markup, but nothing about custom
markup expressions as the core expression explained in
http://www.pmwiki.org/wiki/PmWiki/MarkupExpressions
Moreover http://www.pmwiki.org/wiki/PmWiki/CustomMarkup
has a heading
Define a markup to call a custom function that returns content
which has as example the creation of markup for generating
a random number. This is now usually done with the markup expression
{(rand)}.
Hans
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
On Tue, Mar 31, 2009 at 04:14:42PM +0100, Hans wrote: Tuesday, March 31, 2009, 3:27:17 PM, Patrick wrote: The CustomMarkup page isn't sufficient for how to create custom markup expressions? I think there is a misunderstanding of what constitutes markup and what markup exressions. Oops, you're correct, I didn't see expressions there. Sorry about that. Pm ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
You'll need
global $Author;
at the top of any function in which you want to change the value of that
global variable.
I add my thanks to Hans on this explanation for custom actions. If it's
somewhere in the docs I've never seen it -- very nice feature easy to
implement...
-Peter
2009/3/30 Frank Schweickert f.schweick...@uva.nl
Thank you, Hans, this was the missing link: How to set up custom page
actions properly!
- First question: Did I overlook this crucial information for recipe
authors on pmwiki.org somewhere?
So it works in principle! Only the author doesn't come out right in the
history.
See http://www.natsim.net/ejswiki/Test/Page1
It would use the last name from the browser cookie, even if I set $Author
like below.
(Unlike the production site, my test installation hasn't got restrictions
for users as with scripts/authuser.php, author.php)
$HandleActions['convert'] = 'HandleConvert';
$HandleAuth['convert'] = 'frankobot2';
function HandleConvert($pagename, $auth) {
$old = RetrieveAuthPage('Test.Page1', 'read');
if ($old) {
$new = $old;
$new['text'] = x.$old['text'];
$pn='Test.Page1';
$oldAuthor = $Author;
$Author='frankobot3';
UpdatePage($pn,$old,$new);
$Author=$oldAuthor;
HandleBrowse($pagename);
}
}
Frank
Hans wrote:
Sunday, March 29, 2009, 10:43:08 PM, Frank wrote:
As to my understanding right now, UpdatePage is NOT a
function that is safe to be used directly in config.php includes.
but you don't need to.
You can create an action 'ejselements'
and have everything in one function HandleFrankobot(), which
gets called with ?action=ejselements from the url, or from a
link somewhere on a site admin page perhaps.
$HandleActions['ejselements'] = 'HandleFrankobot';
$HandleAuth['ejselements'] = 'admin';
function HandleFrankobot($pagename, $auth) {
.
UpdatePage(.);
HandleBrowse($pagename);
}
Hans
--
___
Dr. Frank F. Schweickert
AMSTEL Institute, Faculty of Science, University of Amsterdam
Kruislaan 404, Amsterdam, 1098 SM, Netherlands
Room 1.09
Phone: +31 20 525-5969, Fax: +31 20
525-5866http://www.science.uva.nl/amstelhttp://www.natsim.net
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Monday, March 30, 2009, 6:08:14 AM, Frank wrote:
$HandleActions['convert'] = 'HandleConvert';
$HandleAuth['convert'] = 'frankobot2';
function HandleConvert($pagename, $auth) {
$old = RetrieveAuthPage('Test.Page1', 'read');
if ($old) {
$new = $old;
$new['text'] = x.$old['text'];
$pn='Test.Page1';
$oldAuthor = $Author;
$Author='frankobot3';
UpdatePage($pn,$old,$new);
$Author=$oldAuthor;
HandleBrowse($pagename);
}
}
I should add that setting $HandleAuth['convert'] is entirely
optional, and in the example you give does do nothing.
Setting
$HandleAuth['convert'] = 'admin';
for instance will result that 'admin' is passed as default
authorisation level to the HandleConvert function via the second
parameter $auth, so $auth will become 'admin'.
But the function needs to exploit this with for instance
$old = RetrieveAuthPage($pagename, $auth);
only then will the 'convert' action be restricted to users with admin
authorisation, and not others (others will get a login prompt in this
case).
Hans
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
This is because you also need to set $AuthorLink to whatever you want.
It's actually kind of backwards, and I think it would be a good idea
to discuss the way this works. UpdatePage should include a check for a
new $AuthorLink based on $Author.
Avast!
Daniel Roesler
diaf...@gmail.com
On 3/30/09, Frank Schweickert f.schweick...@uva.nl wrote:
Thank you, Hans, this was the missing link: How to set up custom page
actions properly!
- First question: Did I overlook this crucial information for recipe authors
on pmwiki.org somewhere?
So it works in principle! Only the author doesn't come out right in the
history.
See http://www.natsim.net/ejswiki/Test/Page1
It would use the last name from the browser cookie, even if I set $Author
like below.
(Unlike the production site, my test installation hasn't got restrictions
for users as with scripts/authuser.php, author.php)
$HandleActions['convert'] = 'HandleConvert';
$HandleAuth['convert'] = 'frankobot2';
function HandleConvert($pagename, $auth) {
$old = RetrieveAuthPage('Test.Page1', 'read');
if ($old) {
$new = $old;
$new['text'] = x.$old['text'];
$pn='Test.Page1';
$oldAuthor = $Author;
$Author='frankobot3';
UpdatePage($pn,$old,$new);
$Author=$oldAuthor;
HandleBrowse($pagename);
}
}
Frank
Hans wrote:
Sunday, March 29, 2009, 10:43:08 PM, Frank wrote:
As to my understanding right now, UpdatePage is NOT a
function that is safe to be used directly in config.php includes.
but you don't need to.
You can create an action 'ejselements'
and have everything in one function HandleFrankobot(), which
gets called with ?action=ejselements from the url, or from a
link somewhere on a site admin page perhaps.
$HandleActions['ejselements'] = 'HandleFrankobot';
$HandleAuth['ejselements'] = 'admin';
function HandleFrankobot($pagename, $auth) {
.
UpdatePage(.);
HandleBrowse($pagename);
}
Hans
--
___
Dr. Frank F. Schweickert
AMSTEL Institute, Faculty of Science, University of Amsterdam
Kruislaan 404, Amsterdam, 1098 SM, Netherlands
Room 1.09
Phone: +31 20 525-5969, Fax: +31 20 525-5866
http://www.science.uva.nl/amstel
http://www.natsim.net
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
It works for me now, so following Peter's suggestion I have put here what I have learned from you: http://www.pmwiki.org/wiki/PmWiki/CustomActions Please correct it before I try to link this page elsewhere. I couldn't understand the role of $AuthorLink yet... and I have to go on with my project now... Thank you all for your patience! Regards, Frank Daniel Roesler wrote: This is because you also need to set $AuthorLink to whatever you want. It's actually kind of backwards, and I think it would be a good idea to discuss the way this works. UpdatePage should include a check for a new $AuthorLink based on $Author. Avast! Daniel Roesler diaf...@gmail.com On 3/30/09, Frank Schweickert f.schweick...@uva.nl wrote: ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Thank you, Hans, I will try out UpdatePage. There must be a clear cut between functions that can be reliably called - directly from config.php includes - only via Markup() - only within pmwiki.php or other scripts http://www.pmwiki.org/wiki/PmWiki/Functions is a good start, but somehow I found it hard to find, because I was looking for more prominent a function reference of PMwiki. And it is not complete for it doesn't tell us how to fetch a page like via RetrieveAuthPage (or ReadPage?) in the first place. So I started relying on Google more than on pmwiki.org. Actually, I had already found http://www.pmwiki.org/wiki/PmWiki/UpdatePage via Google but I found it too complex, because I was missing the information from page PmWiki.Functions for instance. (So I've just copied that relevant paragraph to page PmWiki.UpdatePage) My point being that one should start more general a reference for PMwiki's functions in sort of JavaDoc style, with indication about their usability in cookbook recipes. Or does this exist anywhere already? Then pmwiki.org should point to it on more prominent a place. Frank Hans wrote: Sunday, March 29, 2009, 10:43:01 AM, Frank wrote: I'm also grateful for general recommendations for further reading into pmwiki's internal workings... Have you considered using function UpdatePage instead? UpdatePage calls all the relevant edit functions in turn, so history and attributes are processed etc. You can, if need be, specify which edit functions should be used, by passing a functionlist array along in the UpdatePage call. UpdatePage was specifically introduced to give more flexibility for recipe authors than what PostPage provided. Hans -- ___ Dr. Frank F. Schweickert AMSTEL Institute, Faculty of Science, University of Amsterdam Kruislaan 404, Amsterdam, 1098 SM, Netherlands Room 1.09 Phone: +31 20 525-5969, Fax: +31 20 525-5866 http://www.science.uva.nl/amstel http://www.natsim.net ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
On Sun, Mar 29, 2009 at 11:59 AM, Hans desi...@softflow.co.uk wrote: Sunday, March 29, 2009, 10:43:01 AM, Frank wrote: I'm also grateful for general recommendations for further reading into pmwiki's internal workings... Have you considered using function UpdatePage instead? UpdatePage calls all the relevant edit functions in turn, so history and attributes are processed etc. I have run into difficulty running UpdatePage() from config.php. In my own trouble-shooting I determined there were just too many things uninitialized, but perhaps I was wrong in that conclusion. If someone has successfully run UpdatePage() from config.php I would be very grateful for any pointers. -Peter ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
2009/3/29 Frank Schweickert f.schweick...@uva.nl http://www.pmwiki.org/wiki/PmWiki/Functions is a good start, but somehow I found it hard to find, because I was looking for more prominent a function reference of PMwiki. And it is not complete for it doesn't tell us how to fetch a page like via RetrieveAuthPage (or ReadPage?) in the first place. So I started relying on Google more than on pmwiki.org. ... My point being that one should start more general a reference for PMwiki's functions in sort of JavaDoc style, with indication about their usability in cookbook recipes. Or does this exist anywhere already? Then pmwiki.orgshould point to it on more prominent a place. The beauty of a wiki -- if you have concerns about the documentation, fix it. ;-) (At some point it would probably be good to divide pmwiki documentation into developer docs vs user docs in separate groups (pmdev or pmwikidev?)...) (And, yes, someone should probably tell me to go ahead and fix it myself... :-) ) -Peter ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Sunday, March 29, 2009, 12:33:17 PM, Frank wrote: http://www.pmwiki.org/wiki/PmWiki/Functions is a good start, but somehow I found it hard to find, because I was looking for more prominent a function reference of PMwiki. And it is not complete for it doesn't tell us how to fetch a page like via RetrieveAuthPage (or ReadPage?) in the first place. So I started relying on Google more than on pmwiki.org. Re: RetrieveAuthPage() use that generally in preference to ReadPage since it respects the authorisation of the user, i.e. it checks the authorisation level before loading the page, or it can be set to do so. ReadPage() reads a page regardless of permission. Hans ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
I hope I did a good deed by adding
http://www.pmwiki.org/wiki/PmWiki/Functions#RetrieveAuthPage
---
But I still don't get it:
Using UpdatePage, pmwiki.php now complains in line 1650: $keys =
array_keys($new);
that $new should be an array. I did
$old = RetrieveAuthPage('Test.Page1', 'read');
if ($old) {
$new = $old;
$new[text] = "x".$old[text];
$pn=('Test.Page1');
UpdatePage($pn,$old,$new);
}
And do we need to call the first argument $pagename in UpdatePage by
reference anyway?
Frank
Hans wrote:
Sunday, March 29, 2009, 12:33:17 PM, Frank wrote:
http://www.pmwiki.org/wiki/PmWiki/Functions is a good start, but
somehow I found it hard to find, because I was looking for more
prominent a function reference of PMwiki. And it is not complete for
it doesn't tell us how to fetch a page like via RetrieveAuthPage (or
ReadPage?) in the first place. So I started relying on Google more than on pmwiki.org.
Re: RetrieveAuthPage()
use that generally in preference to ReadPage since it respects the
authorisation of the user, i.e. it checks the authorisation level
before loading the page, or it can be set to do so.
ReadPage() reads a page regardless of permission.
Hans
--
___
Dr. Frank F. Schweickert
AMSTEL Institute, Faculty of Science, University of Amsterdam
Kruislaan 404, Amsterdam, 1098 SM, Netherlands
Room 1.09
Phone: +31 20 525-5969, Fax: +31 20 525-5866
http://www.science.uva.nl/amstel
http://www.natsim.net
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
2009/3/29 Frank Schweickert f.schweick...@uva.nl This is what I get when using UpdatePage: http://www.natsim.net/ejswiki/Test/Page1 The new text gets where it should but the whole markup process is broken halfway! I didn't see exactly what you meant about the markup process being broken, but I did see the error about needing an array on line 1650 and 1651. That comes from $SaveAttributes not being initialized. You can initialize that and then there is some other error that comes up -- this is what I was referring to when I said UpdatePage() can't be run directly from config.php. Hans was saying that with a custom action handler you could take care of it. I don't know how that works, but if it allows you to do something after all the other initializations are done then that sounds promising. -Peter ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
On Sun, Mar 29, 2009 at 04:13:07PM +0200, Peter Bowers wrote: On Sun, Mar 29, 2009 at 3:57 PM, Hans desi...@softflow.co.uk wrote: but perhaps I was wrong in that conclusion. If someone has successfully run UpdatePage() from config.php I would be very grateful for any pointers. I am not sure what you mean by running UpdatePage() from config.php. Surely you don't want to call that function with every page load. I don't remember the exact scenario... Maybe trying to log actions users? But, yes, the desire was to write to a page based on certain conditions within config.php. Maybe this was trying to set a PTV in a user's profile to indicate their last action along with a timestamp -- I think that was it... Keep in mind that using UpdatePage on every page request is likely to run into page locking issues, or at least seriously slow things down because things can no longer be processed concurrently. Pm ___ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Thank you, Peter and Hans, for your help!
Peter Bowers wrote: I didn't see exactly what you meant about the
markup process being broken,
Sorry, in the meantime I put exit; after my convert page action with
UploadPage() , for I actually don't need to see the page. My action
would correct wiki markup on some hundred pages at once on behalf of an
administrator.
(Without exit, I would run into the rest of normal view action, but even
Sidebar, GroupFooter or PageActions had been processed only halfway
leaving raw wiki markup in the template)
Hans wrote: Perhaps you need to call HandleBrowse or HandleDispatch
to see the page after the update.
Peter Bowers wrote: but I did see the error about needing an array on
line 1650 and 1651. That comes from $SaveAttributes not being
initialized.
Also, this sounds complicated for what I thought was a simple task of
rewriting raw markup of existing pages via script. UpdatePage calls all
these $EditFunctions, why not proper initialization? I mean from the
description of UpdatePage (mimic the behavior of editing wiki pages via
the browser) I would expect that it could create the correct context by
itself... As to my understanding right now, UpdatePage is NOT a
function that is safe to be used directly in config.php includes. And
since I need to change the whole page I wouldn't know how to use
Markup() to call it later in the view process.
Markup('/(.*)/se','fulltext,...) didn't do the trick, for instance.
$old = RetrieveAuthPage('Test.Page1', 'read'); $new = $old;
$new['text'] = x.$old['text']; $pn='Test.Page1';
UpdatePage($pn,$old,$new);
Hans wrote: I does look okay to me.
But the history is still not being updated as you can see from my example
http://www.natsim.net/ejswiki/Test/Page1
I was hoping to leave some trace as user frankobot or so. That would
make it easier to recover in some ambiguous cases of my conversion
(luxury indeed - I actually strive for grasping the correct usage of
internal PMwiki functions)
Frank
--
___
Dr. Frank F. Schweickert
AMSTEL Institute, Faculty of Science, University of Amsterdam
Kruislaan 404, Amsterdam, 1098 SM, Netherlands
Room 1.09
Phone: +31 20 525-5969, Fax: +31 20 525-5866
http://www.science.uva.nl/amstel
http://www.natsim.net
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-devel] PostPage in recipe
Thank you, Hans, this was the missing link: How to set up custom page
actions properly!
- First question: Did I overlook this crucial information for recipe
authors on pmwiki.org somewhere?
So it works in principle! Only the author doesn't come out right in the
history.
See http://www.natsim.net/ejswiki/Test/Page1
It would use the last name from the browser cookie, even if I set
$Author like below.
(Unlike the "production site", my test installation hasn't got
restrictions for users as with scripts/authuser.php, author.php)
$HandleActions['convert'] = 'HandleConvert';
$HandleAuth['convert'] = 'frankobot2';
function HandleConvert($pagename, $auth) {
$old = RetrieveAuthPage('Test.Page1', 'read');
if ($old) {
$new = $old;
$new['text'] = "x".$old['text'];
$pn='Test.Page1';
$oldAuthor = $Author;
$Author='frankobot3';
UpdatePage($pn,$old,$new);
$Author=$oldAuthor;
HandleBrowse($pagename);
}
}
Frank
Hans wrote:
Sunday, March 29, 2009, 10:43:08 PM, Frank wrote:
As to my understanding right now, UpdatePage is NOT a
function that is safe to be used directly in config.php includes.
but you don't need to.
You can create an action 'ejselements'
and have everything in one function HandleFrankobot(), which
gets called with ?action="" from the url, or from a
link somewhere on a site admin page perhaps.
$HandleActions['ejselements'] = 'HandleFrankobot';
$HandleAuth['ejselements'] = 'admin';
function HandleFrankobot($pagename, $auth) {
.
UpdatePage(.);
HandleBrowse($pagename);
}
Hans
--
___
Dr. Frank F. Schweickert
AMSTEL Institute, Faculty of Science, University of Amsterdam
Kruislaan 404, Amsterdam, 1098 SM, Netherlands
Room 1.09
Phone: +31 20 525-5969, Fax: +31 20 525-5866
http://www.science.uva.nl/amstel
http://www.natsim.net
___
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
