Re: [pmwiki-users] making browser adding ?action=... to URL?
Oliver Betz wrote:
Hans wrote:
besides adding a certain action to Site/PageActions, I could imagine
to have the browser adding the ?action=somewhat to the URL.
This would be useful for actions which shouldn't be visible to
everyone.
Has anyone such a solution ready for one of the popular browsers?
I don't quite understand. You add ?action=myaction to the url, by
either typing it into the address bar, or using a link markup like
I want to avoid typing it manually, my browser shall append it by a
single keysteoke or mouse click. And I want to have it available for
arbitrary pages, e.g. for maintenance purposes.
In the mean, I found it myself, it's really simple with a bookmarklet,
for example:
javascript:location.href=location.href+'?action=source'
The other way to do something like this is to have the appropriate links
available as nav menu items once someone with the appropriate privileges
is logged in.
Here, for example, is my Site.SideBar:
(:if auth edit:)
* [[ Team.SiteTools | Admin]]
(:ifend:)
* [[ {*$FullName}?action=searchq=link={*$FullName} | BackLinks ]]
* [[ {*$FullName}?action=search | Search ]]
* [[ {*$FullName}?action=print | Print ]]
(:if auth attr:)
* [[ {*$Group}.GroupAttributes?action=attr | ACL ]]
(:if auth edit:)
* [[ {*$FullName}?action=edit | Edit Page ]]
* [[ {*$FullName}?action=diff | History ]]
* [[ {*$Group}.RecentChanges | Changes ]]
(:if auth upload:)
* [[ {*$FullName}?action=upload | Upload ]]
(:if auth edit:)
* [[ Main.HomePage?action=logout | logout ]]
(:ifend:)
(:if false:)do not add extra items or delete the logic mark-up!(:ifend:)
I then use CSS in the appropriate skin to convert the bulleted list into
a row of navigation buttons.
Cheers
Steve
--
Steve Glover: SDSS, EDINA, Causewayside House, 160 Causewayside EH9 1PR
e:steve.glo...@ed.ac.uk t:0131 650 2908 f:0131 650 3308 m:07961 446 902
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] making browser adding ?action=... to URL?
Steve Glover wrote: [...] In the mean, I found it myself, it's really simple with a bookmarklet, for example: javascript:location.href=location.href+'?action=source' The other way to do something like this is to have the appropriate links available as nav menu items once someone with the appropriate privileges of course. But I was looking for a solution where I don't need to change the wiki. Currently I'm revisiting a lot of pmwiki.org pages and I want to have quick access to the source. Instead of adding this capability to the pmwiki.org installation (useful for few, impacts many), I prefer the bookmarklet. Oliver ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] making browser adding ?action=... to URL?
Hi Oliver, of course. But I was looking for a solution where I don't need to change the wiki. Currently I'm revisiting a lot of pmwiki.org pages and I want to have quick access to the source. Instead of adding this capability to the pmwiki.org installation (useful for few, impacts many), I prefer the bookmarklet. Oops. That'll teach me to read the thread before diving in - I hadn't noticed you were talking about the pmwiki.org wiki. Apologies, Steve ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users -- Steve Glover: SDSS, EDINA, Causewayside House, 160 Causewayside EH9 1PR e:steve.glo...@ed.ac.uk t:0131 650 2908 f:0131 650 3308 m:07961 446 902 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Site/Preferences not working?
Hello All, Site/Preferences seems to have no effect in pmwiki.org and also a local installation I tried. Can someone confirm this? Oliver ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Missing accesskey definitions
Hello All, Site/PageActions contains these access keys nowhere defined (e.g. prefs.php): ak_attach ak_backlinks ak_logout Should these removed from Site/PageActions or get some defaults in the distribution? Oliver ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Site/Preferences not working?
[...]
Site/Preferences seems to have no effect in pmwiki.org and also a
local installation I tried.
RTFM (PmWiki/SitePreferences) helped - pmwiki.org and the distribution
out of the box don't have the required
XLPage('prefs', Site.Preferences);
entry in one of the config files.
Oliver
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Re-thinking Intro to markup pages
As a general comment to this thread, I'm in general agreement with using the Creole approach as a general guideline for our own markup documentation. Indeed, I expect that future core markup changes will occur with an eye towards convergence with Creole, at least for the basics. This is also why Creole went from being a recipe to part of the core. So, using Creole's documentation structure as a model for our own seems like a good approach to me. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Missing accesskey definitions
On Mon, Feb 09, 2009 at 12:45:49PM +0100, Oliver Betz wrote: Hello All, Site/PageActions contains these access keys nowhere defined (e.g. prefs.php): ak_attach ak_backlinks ak_logout Should these removed from Site/PageActions or get some defaults in the distribution? Neither. I think they're fine the way they are now. If an XLPage, skin, or local customization chooses to define values for these access keys then they will work, so I'm against removing them from Site/PageActions. I'm also against adding arbitrary defaults to the distribution -- if there are some obvious choices we can add them, but I don't want to give them values just to keep them from being empty. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Feature request - selecting between multiple templates for new pages
Hi All, Here is a feature that will help me with my web site (I will explain below why), and I wonder if it is already implemented or should be added to a feature list for the future. The feature: I would like to be able to choose between several (existing) templates when I create a new page in my wiki. Explanation: I started my wiki (link below) with the idea of documenting gps tracks and points of interest in Costa Rica. I created groups based on context. Tracks include bus routes, hikes and car rides. Points of interest are broken up into restaurants, sights, hotels, stores and POI which includes everything else (cemeteries, city parks, etc.) Each group has its own template page. Now I am finding that I am adding data from other locations - the US, Nicaragua, Panama, Israel, Europe - all grouped together under a single group 'Misc.' I have no way of having different templates based on the type of point in these countries, except to create a separate wiki for each one. So what I do right now is add the content under the main wiki, than manually copy the page to the Misc. group. I also have a user-edited group, but because it can only have one template, I limit it to points of interest. What I would like to have multiple templates, and be able to choose when I create a new page which one to use. This way, I can easily regroup the pages based on countries, without losing the ability to match the template to the page content. Thanks. Z. -- Check out my web site - www.words2u.net ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] User registration redux
I have not followed up completely with the discussion about automatic user registration, but here is where I see my personal needs: At one time I implemented on a web site a user registration page, using php, mysql and a guide by Kevin Yank (I think). An interested user would enter a user name based on his email address, and would receive a confirmation by email with his password. There was the ability to request a password reminder via email. There was a check to see that the email address was not already in use. Login compared the user name to the known list of users, and if it existed compared the encrypted password to the encrypted original. There was also some captcha feature to prevent spam, which was not part of the original Yank guide. I assume that all these features can be implemented without mysql, using a text page. I would like to use registration for is to let users add themselves to a list of people who can edit pages on a group, without having to deal with them in person, but also without letting everyone edit or add pages anonymously. Z. -- Check out my web site - www.words2u.net ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Markup() in a Markup() call, or conditionally loading a recipe
Peter, thanks for the reply. Unfortunately, your method doesn't seem to
work quite correctly either. The method you specified (and several
variations on it that I tried) works for suppressing the sop markup on
pages that don't have (:sop:) specified, but it removes all sectioning on
the pages on which (:sop:) is specified.
It still seems to me that the most straightforward and sensible way to do
this is to allow a Markup() call within a Markup() call, but that
doesn't seem to work.
So I'm still banging my head over this one.
Scott
On Sat, Feb 7, 2009 at 9:30 AM, Peter Bowers pbow...@pobox.com wrote:
On Fri, Feb 6, 2009 at 8:33 PM, Scott Diegel scottdie...@gmail.comwrote:
I want a Markup() call to apply only to a given type of page, specifically
if (:sop:) is included on a wiki page. The Markup will affect section
numbering, but I still need the standard section markup to be used.
...
Loading the file in which this is defined via config.php results in the
section formatting being changed for all pages. I tried the following, and
checked using ?action=ruleset whether the 'sop' rule was being applied;
'sopheaders' is being applied, but 'sop' is not.
/*
function SOPheaders(){
Markup('sop','include','/^(!{2,4})(?:\s*)(.*)$/e',
MkSopNumTitle(strlen('$1'),PSS('$2')));
}
Markup('sopheaders','directives','/\\(:sop:\\)/e',SOPheaders());
*/
Is this the right approach? Is there another approach I can try?
That looks fine to me. And if SOPheaders is always active but sop only
active on the appropriate pages then that's exactly what you want, right?
My only concern is whether a markup that gets defined *during* markup will
get applied correctly (i.e., will it get put in the right order, etc. -- is
all that done inside the Markup() function or is it done separately in
pmwiki.php after config.php). I'd say if it works then you've got a great
solution.
If, on the other hand, it's not working then this is what I would suggest:
function MkSopNumTitle($arg1, $arg2, $MakeMeActive=false){
static $MarkupActive = false;
if ($MakeMeActive) {
$MarkupActive = true;
return(true);
}
if (!$MarkupActive) return;
... /* the rest of the code for MkSopNumTitle */
}
Markup('sop','include','/^(!{2,4})(?:\s*)(.*)$/e',
MkSopNumTitle(strlen('$1'),PSS('$2')));
Markup('sopheaders','directives','/\\(:sop:\\)/e',MkSopNumTitle(false,
false, true));
However, your rule-based solution is superior as long as it actually
works. It's better to not even have a rule to process when you don't need
it...
-Peter
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Missing accesskey definitions
Patrick R. Michaud wrote: Site/PageActions contains these access keys nowhere defined (e.g. prefs.php): ak_attach ak_backlinks ak_logout Should these removed from Site/PageActions or get some defaults in the distribution? Neither. I think they're fine the way they are now. I don't know whether it's only a cosmetic issue that these access keys resolve to their full name in hmtl, e.g. a accesskey='ak_backlinks' Other access keys are defined to '' - maybe that's not better or worse. If an XLPage, skin, or local customization chooses to define values for these access keys then they will work, so I'm against removing them from Site/PageActions. Wouldn't it be nice to have them added to Site/Preferences to remind anyone making customizations of the actions? I'm also against adding arbitrary defaults to the distribution -- if there are some obvious choices we can add them, but I don't want to give them values just to keep them from being empty. there are already several actions set to '' (at least view and print). IMO that's clearer than leaving them undefinded. Oliver ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki in AJAX
Hi,
I'm new on the list, and I discover PmWiki. Sorry if my question is
frequently asked. I'm also a french-user speaking so sorry for my english.
Here is my problem.
I would like to integrate PmWiki to my site (homemade with php, mysql,...)
with AJAX requests. But I can't retrieve the informations I need in a
PmWiki page and JSON encode it and send it to the browser.
My AJAX engine (homemade also) should receive an array like this:
$myArray = array(
idOfTheTagOfTheBodyContent = array(
innerHTML = 'this is the body of the PmWiki page that corresponds to
!--PageText-- in .tmpl file'
),
idOfTheTagOfTheTitleOfMyPage = array(
innerHTML = 'this is the title of the PmWiki page that corresponds to
$WikiTitle | {$Group} / {$Title} in .tmpl file'
)
)
This array must be JSON encoded and sent to the browser like this:
echo json_encode($myArray);
Here's my question:
How can I (in a php file like a cookbook recipe) retrieve both elements
of my page like !--PageText-- and $WikiTitle | {$Group} / {$Title}
It should be great just to add ?action=ajax in the url of a page and then
the output is my JSON string.
I have read a lot of documentation and tried to understand the php code of
the PmWiki engine, but I didn't find.
Could you help me?
Thanks a lot,
etco
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Markup() in a Markup() call, or conditionally loading a recipe
I've managed to get the result I want by editing the return value of
MkSopNumTitle based on whether or not (:sop:) was found. I still think it
seems reasonable to allow Markup() in a Markup().
Scott
On Mon, Feb 9, 2009 at 9:56 AM, Scott Diegel scottdie...@gmail.com wrote:
Peter, thanks for the reply. Unfortunately, your method doesn't seem to
work quite correctly either. The method you specified (and several
variations on it that I tried) works for suppressing the sop markup on
pages that don't have (:sop:) specified, but it removes all sectioning on
the pages on which (:sop:) is specified.
It still seems to me that the most straightforward and sensible way to do
this is to allow a Markup() call within a Markup() call, but that
doesn't seem to work.
So I'm still banging my head over this one.
Scott
On Sat, Feb 7, 2009 at 9:30 AM, Peter Bowers pbow...@pobox.com wrote:
On Fri, Feb 6, 2009 at 8:33 PM, Scott Diegel scottdie...@gmail.comwrote:
I want a Markup() call to apply only to a given type of page,
specifically if (:sop:) is included on a wiki page. The Markup will affect
section numbering, but I still need the standard section markup to be used.
...
Loading the file in which this is defined via config.php results in the
section formatting being changed for all pages. I tried the following, and
checked using ?action=ruleset whether the 'sop' rule was being applied;
'sopheaders' is being applied, but 'sop' is not.
/*
function SOPheaders(){
Markup('sop','include','/^(!{2,4})(?:\s*)(.*)$/e',
MkSopNumTitle(strlen('$1'),PSS('$2')));
}
Markup('sopheaders','directives','/\\(:sop:\\)/e',SOPheaders());
*/
Is this the right approach? Is there another approach I can try?
That looks fine to me. And if SOPheaders is always active but sop only
active on the appropriate pages then that's exactly what you want, right?
My only concern is whether a markup that gets defined *during* markup will
get applied correctly (i.e., will it get put in the right order, etc. -- is
all that done inside the Markup() function or is it done separately in
pmwiki.php after config.php). I'd say if it works then you've got a great
solution.
If, on the other hand, it's not working then this is what I would suggest:
function MkSopNumTitle($arg1, $arg2, $MakeMeActive=false){
static $MarkupActive = false;
if ($MakeMeActive) {
$MarkupActive = true;
return(true);
}
if (!$MarkupActive) return;
... /* the rest of the code for MkSopNumTitle */
}
Markup('sop','include','/^(!{2,4})(?:\s*)(.*)$/e',
MkSopNumTitle(strlen('$1'),PSS('$2')));
Markup('sopheaders','directives','/\\(:sop:\\)/e',MkSopNumTitle(false,
false, true));
However, your rule-based solution is superior as long as it actually
works. It's better to not even have a rule to process when you don't need
it...
-Peter
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Is quiet redirect broken?
On 2/9/2009, Neil Herber (nospam) nos...@eton.ca wrote: The docs at http://www.pmwiki.org/wiki/PmWiki/PageDirectives indicate that quiet=1 works, but the docs bundled with the distribution ... It is in the SVN version, it is added to the core but not yet released as a stable. Soon, hopefully. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] User registration redux
You might want to check out http://www.pmwiki.org/wiki/Cookbook/AuthUserSignup -- it has all the capabilities you are looking for except for the captcha. -Peter _ From: pmwiki-users-boun...@pmichaud.com [mailto:pmwiki-users-boun...@pmichaud.com] On Behalf Of Steven Benmosh Sent: Monday, February 09, 2009 4:48 PM To: pmwiki-users@pmichaud.com Subject: [pmwiki-users] User registration redux I have not followed up completely with the discussion about automatic user registration, but here is where I see my personal needs: At one time I implemented on a web site a user registration page, using php, mysql and a guide by Kevin Yank (I think). An interested user would enter a user name based on his email address, and would receive a confirmation by email with his password. There was the ability to request a password reminder via email. There was a check to see that the email address was not already in use. Login compared the user name to the known list of users, and if it existed compared the encrypted password to the encrypted original. There was also some captcha feature to prevent spam, which was not part of the original Yank guide. I assume that all these features can be implemented without mysql, using a text page. I would like to use registration for is to let users add themselves to a list of people who can edit pages on a group, without having to deal with them in person, but also without letting everyone edit or add pages anonymously. Z. -- Check out my web site - www.words2u.net ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Feature request - selecting between multiple templates for new pages
You can add a template=Mygroup.Mypage to specify which template you want to use. You could do this manually by putting it in your URL in the address bar: http://www.example.com/pmwiki/pmwiki.php?n=Mygroup.Mynewpage?action=edit?tem plate=Mytemplates.USPOI Or you could create a quick little form in your sidebar (or on a page), I'm thinking vanilla pmwiki forms without any script at all would work (just action=pmwiki.php, I'm thinking). Just have a text field named n where you enter the new pagename, a hidden field named action with edit as the value, and a field named template which allows the user either a radiobutton or select option to choose one of a number of templates that you specify. Then a submit button and you should be good to go. You can see documentation on all those form elements at http://www.pmwiki.org/wiki/PmWiki/Forms if you want to go that direction. Note that with either of these elements you are ending up with orphan pages - i.e., they are pages without any link anywhere to them. As long as you are using pagelists to access them this isn't a problem, but if you are used to a more traditional link-to-the-page type of approach then you would need to get a little fancier on the above solutions. -Peter _ From: pmwiki-users-boun...@pmichaud.com [mailto:pmwiki-users-boun...@pmichaud.com] On Behalf Of Steven Benmosh Sent: Monday, February 09, 2009 4:42 PM To: pmwiki-users@pmichaud.com Subject: [pmwiki-users] Feature request - selecting between multiple templates for new pages Hi All, Here is a feature that will help me with my web site (I will explain below why), and I wonder if it is already implemented or should be added to a feature list for the future. The feature: I would like to be able to choose between several (existing) templates when I create a new page in my wiki. Explanation: I started my wiki (link below) with the idea of documenting gps tracks and points of interest in Costa Rica. I created groups based on context. Tracks include bus routes, hikes and car rides. Points of interest are broken up into restaurants, sights, hotels, stores and POI which includes everything else (cemeteries, city parks, etc.) Each group has its own template page. Now I am finding that I am adding data from other locations - the US, Nicaragua, Panama, Israel, Europe - all grouped together under a single group 'Misc.' I have no way of having different templates based on the type of point in these countries, except to create a separate wiki for each one. So what I do right now is add the content under the main wiki, than manually copy the page to the Misc. group. I also have a user-edited group, but because it can only have one template, I limit it to points of interest. What I would like to have multiple templates, and be able to choose when I create a new page which one to use. This way, I can easily regroup the pages based on countries, without losing the ability to match the template to the page content. Thanks. Z. -- Check out my web site - www.words2u.net http://www.words2u.net/ ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Feature request - selecting between multiple templates for new pages
On Mon, Feb 9, 2009 at 4:41 PM, Steven Benmosh word...@gmail.com wrote: What I would like to have multiple templates, and be able to choose when I create a new page which one to use. This way, I can easily regroup the pages based on countries, without losing the ability to match the template to the page content. Since I urgently need to do something I don't want to do g I went ahead and tested out the form. This (below) seems to work fine: ===(snip)=== (:input form pmwiki.php GET:) Page Name: (:input text n:)\\ (:input hidden action edit:) (:input radio template Test.Foo:) Foo\\ (:input radio template Test.Foo2:) Foo2\\ (:input submit create Create New Page:) (:input form end:) ===(snip)=== I haven't tested it in the sidebar, but I don't think it should make any difference. You may want to surround it with some sort of conditional if you don't want every user seeing this in the sidebar all the time... -Peter ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Delete EditGettingStarted, CharacterMarkup, LineMarkup (and more)? (Oliver Betz)
On Tuesday, 10 February 2009 4:41 AM, pmwiki-users-requ...@pmichaud.com wrote: From: Oliver Betz list...@gmx.net Subject: Re: [pmwiki-users] Delete EditGettingStarted, haracterMarkup, LineMarkup (and more)? John Rankin wrote: BTW: Why do you change (slightly) the subject each posting? This breaks thread view in my newsreader. I'm sorry about that; I receive a Digest and reply to that, so copy the title from the digest into the subject line. I make mistakes. If you cc me in your reply to the list, I can reply directly and this will retain the subject line. [...] splitting hairs According to this definition, lists and paragraphs would be block markup - both are described in LineMarkup. /splitting hairs Not true. As defined, a line ends with a return character followed either by a second return character or by a line markup character. simply avoid the word line. It's misleading. OK, thanks -- any suggestions for an alternative? paragraph doesn't seem quite right. [...] I would be very happy to see the PmWiki documentation factored to use the Creole set as an introduction, with branches to more advanced markup features. This does not require PmWiki to adopt the Creole standard, just use the Creole thinking. I think I would also refactor EditQuickReference to present only the Creole markup I support this as an option. Since there are only few entry points to the existing documentation (e.g. EditQuickReference and the sidebar), an administrator could simply replace these to Creole versions. I think it may be bigger than this. At least the following pages will need to be re-factored: - DocumentationIndex - TextFormattingRules - BasicEditing - EditQuickReference - MarkupMasterIndex Maybe this could be even configurable. The i18n mechanism (XLPage) could be also used. Sounds good to me. There should be an appropriate naming scheme for the Creole pages, what about CreoleQuickReference? I don't think that it's worth another group. Choosing the wrong names could cause confusion. We need to make sure we distinguish the Creole markup set as a structure for documentation from the Creole markup rules themselves. My inclination, I think, would be to reserve the word Creole for pages that refer to Creole markup rules. However, I strongly agree that as the documentation is being re-factored, we need an easy way to distinguish pages being worked on from the current stable versions. One way would be to use a category: use [[!creole]] to refer to pages structured around the Creole-based core markup set and use a Creole name prefix to refer to pages that describe Creole markup rules. However, then we couldn't use XLPage to switch. OTOH, I'm reluctant to embark on a path that requires maintaining 2 sets of docuemntation. I would rather see one set, structured around a Creole core set. JR -- John Rankin Affinity Limited T 64 4 495 3737 F 64 4 473 7991 021 RANKIN john.ran...@affinity.co.nz www.affinity.co.nz ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Feature request - selecting between multiple templates for new pages
On Mon, Feb 9, 2009 at 9:41 AM, Steven Benmosh word...@gmail.com wrote: Hi All, Here is a feature that will help me with my web site (I will explain below why), and I wonder if it is already implemented or should be added to a feature list for the future. The feature: I would like to be able to choose between several (existing) templates when I create a new page in my wiki. Explanation: I started my wiki (link below) with the idea of documenting gps tracks and points of interest in Costa Rica. I created groups based on context. Tracks include bus routes, hikes and car rides. Points of interest are broken up into restaurants, sights, hotels, stores and POI which includes everything else (cemeteries, city parks, etc.) Each group has its own template page. Now I am finding that I am adding data from other locations - the US, Nicaragua, Panama, Israel, Europe - all grouped together under a single group 'Misc.' I have no way of having different templates based on the type of point in these countries, except to create a separate wiki for each one. So what I do right now is add the content under the main wiki, than manually copy the page to the Misc. group. I also have a user-edited group, but because it can only have one template, I limit it to points of interest. What I would like to have multiple templates, and be able to choose when I create a new page which one to use. This way, I can easily regroup the pages based on countries, without losing the ability to match the template to the page content. Have you looked at http://www.pmwiki.org/wiki/Cookbook/NewGroupBox http://www.pmwiki.org/wiki/Cookbook/NewPageBox http://www.pmwiki.org/wiki/Cookbook/NewPageBoxPlus http://www.pmwiki.org/wiki/Cookbook/NewPageForm And the rules for defining your own templates: http://www.pmwiki.org/wiki/Cookbook/EditTemplates ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Re-thinking Intro to markup pages
On Monday, 9 February 2009 12:19 PM, Tegan Dowling tmdowl...@gmail.com wrote: On Sun, Feb 8, 2009 at 3:04 PM, john.ran...@affinity.co.nz wrote: ... I would be very happy to see the PmWiki documentation factored to use the Creole set as an introduction, with branches to more advanced markup features. This does not require PmWiki to adopt the Creole standard, just use the Creole thinking. I think I would also refactor EditQuickReference to present only the Creole markup set, with links to other markup features. Or at least separate the Creole set from anything else that may be on the quick reference page. JR ... What's more, I'm hoping that we'll have a wysiwyg interface for the creole set, some day. While we are waiting for this day to arrive, we could give due consideration to reviewing the current GUIButtons behaviour and: - omitting from the default set any that are not part of the Creole set - providing a GUICreole option that displays buttons for all (or most) of the Creole set - providing a separator between Creole and non-Creole buttons Then the core documentation and the user interface would be mutually consistent. Indeed, one could then choose (if one wished) to offer either a set of Creole GUI buttons, or an EditQuickReference, but not both. This would also make it much easier to switch between PmWIki and Creole markup rules. JR -- John Rankin Affinity Limited T 64 4 495 3737 F 64 4 473 7991 021 RANKIN john.ran...@affinity.co.nz www.affinity.co.nz ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Markup() in a Markup() call, or conditionally loading a recipe
On Mon, Feb 9, 2009 at 7:00 PM, Scott Diegel scottdie...@gmail.com wrote: I've managed to get the result I want by editing the return value of MkSopNumTitle based on whether or not (:sop:) was found. I still think it seems reasonable to allow Markup() in a Markup(). Glad you got it working. Note that the markup rules in pmwiki are the inner DNA structure of the whole system and thus have to be set up just right for the system to work. And the order of them is hugely (!) important. I'm not too surprised that inserting a markup late (during page processing) doesn't take effect. I looked into manipulating things via BuildMarkupRules() or incrementing $RedoMarkupLine but unfortunately (or perhaps fortunately?) $markrules is local to MarkupToHTML() and so inaccessible for this type of manipulating. (It would have been an ugly hack anyways...) If you really wanted to do said ugly hack and were willing to edit your pmwiki.php (something that is strongly recommended against for very good reasons) you could make $markrules a global in MarkupToHTML() -- that's the change in pmwiki.php. Then in your SopHeader() function you would call your Markup() and then say $markrules = BuildMarkupRules(); and then increment $RedoMarkupLine. (Obviously making sure that $markrules and $RedoMarkupLine are globals.) I'll close now so 10 people can post explaining why that's a really bad idea. It really is a bad idea to alter pmwiki.php. You shouldn't do it. I didn't do it even to test the dirty hack. So probably even if you did do it it wouldn't work. That's how bad an idea it is... :-) -Peter ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Re-thinking Intro to markup pages
On Tuesday, 10 February 2009 4:20 AM, Patrick R. Michaud pmich...@pobox.com wrote: Indeed, I expect that future core markup changes will occur with an eye towards convergence with Creole, at least for the basics. This is also why Creole went from being a recipe to part of the core. So, using Creole's documentation structure as a model for our own seems like a good approach to me. Given that this will have a significant impact on many existing pages in the PmWiki group, do you have any advice or preference on how to structure the approach? For example: - edit the pages directly and re-factor them - create a separate group (e.g. PmWikiCreole) - use a page prefix or suffix (e.g. PmWiki.BasicEditing-Creole) - add a special category to such pages (e.g. [[!creole]]) JR -- John Rankin Affinity Limited T 64 4 495 3737 F 64 4 473 7991 021 RANKIN john.ran...@affinity.co.nz www.affinity.co.nz ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmWiki in AJAX
Hi again,
I found a piece of the solution of my problem. Maybe it would inspire
someone to help me ;-)
In config.php I added:
if ($action == 'ajax') include_once($FarmD.'/cookbook/etco_AJAX.php');
In 'etco_AJAX.php' (recipe in cookbook directory):
ob_start();
HandleBrowse($pagename);
$content = ob_get_clean();
$toAJAX = array(
'titleOfMyPage' = array(
'innerHTML' = PageVar($pagename,'$Titlespaced')
),
'contentOfMyPage' = array(
'innerHTML' = $content
)
);
echo json_encode($toAJAX);
exit();
For the titleOfMyPage I found with PageVar($pagename,'$Titlespaced') =
OK, it is what I expected
I would like to do the same with the content of my page.
But:
1) in $content I do not have an html output... How can I do to have the
HTML translation of a $page['text']?
2) I would like to not have exit(); at the end and to continue the
process of the page, but if I don't do that, I have logically a warning
'Headers already sent...'. How can I do to output json_encode($toAJAX)
in place of my *.tmpl file at the end of the process?
In a simple-code I would like to do this:
$content = toHTML('!--PageText--'); but it seems to be not possible
Thanks a lot for helping me,
etco
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Fox - allow/disallow posting directives per form
Hi, I'd like to give authors the ability to decide whether directives can be posted on a form-by-form basis. Currently, I'm dealing with this by allowing the posting of directives by default, but giving authors the option of using a fox filter which scrubs directives. What I'd prefer, though, is the reverse the posting of directives disallowed by default, but could be allowed on a form via a foxfilter (or something). I tried creating a foxfilter that would reverse this: $item = str_replace((:, (#x3a;, $item); $item = str_replace(:), #x3a;), $item); but, of course, the filter is preprocessing the data, so that doesn't work... Is there any way to do this? Maybe some way to process the form data after rather then before the strings are replaced? I'm guessing not, but thought I'd ask. Thanks -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmWiki in AJAX
Monday, February 9, 2009, 10:31:35 PM, Etienne Convié wrote:
1) in $content I do not have an html output... How can I do to have the
HTML translation of a $page['text']?
2) I would like to not have exit(); at the end and to continue the
process of the page, but if I don't do that, I have logically a warning
'Headers already sent...'. How can I do to output json_encode($toAJAX)
in place of my *.tmpl file at the end of the process?
In a simple-code I would like to do this:
$content = toHTML('!--PageText--'); but it seems to be not possible
function MarkupToHTML should be your friend!
you could try
$text = $page['text'];
$content = MarkupToHTML($pagename, $text);
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmWiki in AJAX
On Monday 09 February 2009 23:31:35 Etienne Convié wrote:
In config.php I added:
if ($action == 'ajax') include_once($FarmD.'/cookbook/etco_AJAX.php');
In 'etco_AJAX.php' (recipe in cookbook directory):
ob_start();
HandleBrowse($pagename);
$content = ob_get_clean();
...
In a simple-code I would like to do this:
$content = toHTML('!--PageText--'); but it seems to be not possible
Hi. There is MarkupToHTML().
You can check out how existing recipes or core scripts handle different
actions, for a simplest example, see pmwiki/scripts/crypt.php.
You can do something like this (tested it, seems to work) :
# I recommend an action more specific than 'ajax':
$HandleActions['json'] = 'HandleJSONcontent'; # for ?action=json
function HandleJSONcontent($pagename, $auth='read')
{
$page = RetrieveAuthPage($pagename,$auth,1, READPAGE_CURRENT);
$toAJAX = array(
'title' = array(
'innerHTML' = PageVar($pagename,'$Titlespaced')
),
'content' = array(
'innerHTML' = MarkupToHTML($pagename, $page['text'])
)
);
echo json_encode($toAJAX);
exit();
}
Hope that helps.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fox - allow/disallow posting directives per form
Monday, February 9, 2009, 10:59:56 PM, James DeVain wrote: I'd like to give authors the ability to decide whether directives can be posted on a form-by-form basis. Currently, I'm dealing with this by allowing the posting of directives by default, but giving authors the option of using a fox filter which scrubs directives. What I'd prefer, though, is the reverse the posting of directives disallowed by default, but could be allowed on a form via a foxfilter (or something). Ha, you wish to keep the prison locked but hand the prisoners the keys? ;-) I don't recommend this, but you could try to reset the Fox config variable in a fox filter function to $EnablePostDirectives = true; Fox filter functions are called early in the process, before the FoxDefuseMarkup function which rewrites some characters so the directives won't function. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Fwd: I cannot get the sitewide password to work for pmwiki
-- Forwarded message --
From: akimbomidget akimbomid...@gmail.com
Date: Tue, Feb 10, 2009 at 2:06 AM
Subject: I cannot get the sitewide password to work for pmwiki
To: pmwiki-users@pmichaud.com
I've been trying for hours to get a simple task to work in my site
http://reactiveframes.com/wiki/
Essentially i've been trying to get pmwiki to prevent anyone without the
password from editing it.
Despite putting this
$DefaultPasswords['admin'] = crypt('A example password');
into config.php
it still doesn't ask me for a password to edit...
The other other option of action=attr also doesn't work... i don't
understand... and i got the latest pmwiki download...
If you can help me, that would be really great
Sincerly
Akimbomidget
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fwd: I cannot get the sitewide password to work for pmwiki
On 2009-02-09 7:28 PM, akimbomidget wrote:
From: *akimbomidget* akimbomid...@gmail.com
mailto:akimbomid...@gmail.com
Date: Tue, Feb 10, 2009 at 2:06 AM
Subject: I cannot get the sitewide password to work for pmwiki
To: pmwiki-users@pmichaud.com mailto:pmwiki-users@pmichaud.com
I've been trying for hours to get a simple task to work in my site
http://reactiveframes.com/wiki/
Essentially i've been trying to get pmwiki to prevent anyone without the
password from editing it.
Despite putting this
$DefaultPasswords['admin'] = crypt('A example password');
into config.php
it still doesn't ask me for a password to edit...
...snip...
You need to set a default edit password as in:
$DefaultPasswords['edit'] = crypt('A example password');
Or if you only want the admin to be able to edit, then set:
$DefaultPasswords['admin'] = crypt('A example password');
$DefaultPasswords['edit'] = '*';
This does not set the edit password to '*', rather it sets the crypted
value of the password to '*', but crypt will never return a one
character value. So the effect is that no-one can edit, except for the
admin.
--
Neil Herber
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] markup parse issue
All,
I have the following markup:
(:div2 class=header-content
style=height:84px;background-image:url({$SkinDirUrl}/garden_bg.jpg);:)
(I've added background-image to the $WikiStyleCSS[] array)
But PmWiki is parsing the image fragment as an element, and creates an
embedded image element thus:
background-image:url(img
src='http://parkcommons.ca/shared/wiki/app/pub/skins/FoldersCMSBase/garden_bg.jpg'
alt='' title='' /)
...which of course is a css error.
Is there anything I can do to just get
background-image:url(http://parkcommons.ca/shared/wiki/app/pub/skins/FoldersCMSBase/garden_bg.jpg)
?
(I thought I had this working, but just noticed it isn't)
Thanks,
- Henrik
--
Henrik Bechmann
bechmann.ca
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] pagelist templates, categories
Hi, all.
Could somebody help me with the following problems?
1. Should markup expressions/page variables work with
(:template defaults:)? I wanted to define a simple template with
(:template defaults group={$Group}:), but I couldn't make it work...
2. I want tags that do not show in the output, can be used in pagelists
and automatically create self-named pages after editing.
Categories would perfectly fit here, but I do not know how to hide
them from output. I have used $LinkCategoryFmt=' ';, but this doesn't
seem right. I could specify (:if false:) with Markup('[[!',..., but
I do not know how.
Thanks.
--
-- Rogutės Sparnuotos
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Gui Buttons. Looks like underline, gives Internal Link, in the core program.
This is on the current pmwiki.org installation. The gui button on the edit page, just to the right of Bold, looks like Underline, but the tooltip says Internal Link. The actual markup gives [[zzz]]. The button beside it shows the usual globe with chain links. It has a tooltip of External Link. The actual markup gives the same as the other button, [[zzz]]. So, 1. The underline button needs to put in underline code. 2. If there are to be separate buttons for internal and external links (which is a good idea, but if we put in every good idea we'll have three lines of buttons, and not every skin distinguishes between them), they should do something different. Sandy ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] markup parse issue
Henrik Bechmann wrote:
Is there anything I can do to just get
background-image:url(http://parkcommons.ca/shared/wiki/app/pub/skins/FoldersCMSBase/garden_bg.jpg)
I had this exact problem. I *think* the solution was to define a markup
using Keep. This is what I used for my case, and might help give you
some ideas:
Markup('^Country:', 'fulltext',
'/^Country\\s+([a-zA-Z][a-zA-Z]):(.*?)gt;gt;lt;lt;/isme',
Keep('div class=\'country\'
style=\'background-image:url(\'.\$GLOBALS['PubDirUrl'].'/skins/dropdown/flags/'.
strtolower($1). '.png\)\''. PSS('$2'). '/div')
);
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist templates, categories
You can hide Category from the output using this on the categorized
page:
comment [[!MyCategory]]
Randy
On Feb 9, 2009, at 8:07 PM, Rogutės Sparnuotos wrote:
Categories would perfectly fit here, but I do not know how to hide
them from output. I have used $LinkCategoryFmt=' ';, but this
doesn't
seem right. I could specify (:if false:) with Markup('[[!',..., but
I do not know how.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] How to adjust width in Horizontal Vertical Menu recipe
I'm using the Horizontal Vertical Menu recipe and would like to adjust the width of the top level menu. I peaked at the CSS file, but it's all greek to me. Does anyone know how to adjust the width? Because the width is automatic, I currently have room only for three items: A | B | C When I hover over A (it's actually an icon) the following drops down: A Option #1 A Option #2 I want to change the top level horizontal menu to be: A | B | C | D | E | F | G | H The drop down menu should remain at its current width. Randy___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Delete EditGettingStarted, CharacterMarkup, LineMarkup (and more)? (Oliver Betz)
On Tue, Feb 10, 2009 at 09:52:21AM +1300, John Rankin wrote: On Tuesday, 10 February 2009 4:41 AM, pmwiki-users-requ...@pmichaud.com wrote: One way would be to use a category: use [[!creole]] to refer to pages structured around the Creole-based core markup set and use a Creole name prefix to refer to pages that describe Creole markup rules. However, then we couldn't use XLPage to switch. OTOH, I'm reluctant to embark on a path that requires maintaining 2 sets of docuemntation. I would rather see one set, structured around a Creole core set. Please don't use [[!creole]] for this; it is too ambiguous, and thus confusing. Something like [[!creole features]] would be better. Or perhaps [[!features like creole]] if one wanted to get wordy. Kathryn Andersen -- _--_|\ | Kathryn Andersen http://www.katspace.com / \| \_.--.*/| GenFicCrit mailing list http://www.katspace.com/gen_fic_crit/ v | | Melbourne - Victoria - Australia - Southern Hemisphere Maranatha! | - Earth - Sol - Milky Way Galaxy - Universe ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
