Re: [pmwiki-users] Screen-reader friendly PmForm captchas

[Crisses]

That's what I'm already using and no, it's not screen-reader friendly because 
the images are made server-side. So the server isn't changing what it does 
based on whether the browser can see the images or not.

> On Apr 14, 2019, at 11:48 AM, Dominique Faure  
> wrote:
> 
> The Cookbook/Captcha recipe should be able to provide some help here, no?
> 
> Regards,
> Dominique
> 
> 
> On Sun, Apr 14, 2019 at 2:36 AM Crisses  wrote:
>> 
>> Without using ReCaptcha — because Google data-mines everything so I don't 
>> even want to load tech from them on my site — is there a way to fallback to 
>> a text-based code on forms for captcha when someone is using a screen reader?
>> 
>> I know this may defeat some of the purpose of using captchas to stop bots. I 
>> also use a honeypot which can be frustrating when using assistive tech 
>> because only upon getting an error does it tell the user that they need to 
>> ignore the "Subject" field that sighted people cannot see.
>> 
>> However, I have blind website viewers since my site is about mental health 
>> disabilities, it needs to be accessible to the disability community as a 
>> whole. I was informed of the issue today by someone using assistive 
>> technology who could not submit comments on my site.  Usually they get an 
>> audio captcha on other sites. I thought it would fall back to text, but that 
>> only happens if the server side fails to create images — not if the client 
>> side doesn't perceive images.
>> 
>> A question captcha might be the best solution that would work with all 
>> technology :/ a rotating question would be best so it's not always the same 
>> answer.
>> 
>> Thanks,
>> 
>> Thank you,
>> Crisses
>> ___
>> pmwiki-users mailing list
>> pmwiki-users@pmichaud.com
>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Screen-reader friendly PmForm captchas

[Crisses]

Without using ReCaptcha — because Google data-mines everything so I don't even 
want to load tech from them on my site — is there a way to fallback to a 
text-based code on forms for captcha when someone is using a screen reader?  

I know this may defeat some of the purpose of using captchas to stop bots. I 
also use a honeypot which can be frustrating when using assistive tech because 
only upon getting an error does it tell the user that they need to ignore the 
"Subject" field that sighted people cannot see.

However, I have blind website viewers since my site is about mental health 
disabilities, it needs to be accessible to the disability community as a whole. 
I was informed of the issue today by someone using assistive technology who 
could not submit comments on my site.  Usually they get an audio captcha on 
other sites. I thought it would fall back to text, but that only happens if the 
server side fails to create images — not if the client side doesn't perceive 
images.

A question captcha might be the best solution that would work with all 
technology :/ a rotating question would be best so it's not always the same 
answer.

Thanks,

Thank you,
Crisses
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Redirect group recipe

[Crisses]

You can do this with your .htaccess file...

You can do a permanent web address redirect statement.

https://coolestguidesontheplanet.com/redirecting-a-web-folder-directory-to-another-in-htaccess/

> On May 28, 2018, at 5:32 AM, Simon  wrote:
> 
> Does anyone have a redirect group recipe?
> 
> I want to rename a large group and want every page in the group to redirect 
> to the new group without having to specify every page?
> 
> tia
> 
> Simon
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] PmWiki standard AuthUser

[Crisses]

Right now, an admin has to change passwords in AuthUser.  Some people don't 
want to tell the admin their password.

I am working on a membership site where members will log in and need edit 
permissions to their own profile information (name, contact info, description, 
etc.), can change their own passwords, are in a group @members so that 
permissions can be doled out around the website, some members can be @admin (or 
other permission group) privileged.  And I'd like to avoid using a database.

I'm looking through PmWiki documentation, recipes, etc.  So many recipes are 
old, haven't been maintained in 4+ years, are not PHP5 (much less 5.5) 
compatible, etc.  I was trying to get .htpasswd files working, spent a whole 
day on that, got it working -- but the recipe I was going to use to handle 
password updating and group management is 
http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm -- and it's broken (and too 
complicated for an easy fix).  I put the (:command:) in the page, and the page 
comes out blank when it should come up with password updating and group 
permissions forms.

In all honesty, I love the simplicity of AuthUser.  It would be lovely if 
PmWiki finally got -- a little -- more sophisticated on user/password 
management.  Here's my thought on how it can be set up for users to edit their 
own password:

Similar to SiteAdmin there could be a locked-down group, perhaps (to keep with 
$BaseName tactics) Profile-Data.  This would be a PmWiki data page hidden 
from the world.  In it could be profile data (page $Name = username, crypt'd 
password, email address, phone number, member expiration date, whatever...).

What I need:

I would like to be able to tell SiteAdmin/AuthUser to use 
Profile-Data/{$username}$:passwd for username/password auth.  So just like it 
would grab a username/password from the SiteAdmin/AuthUser page, I want it to 
grab the passwd: encrypted password from their Profile-Data page.

I also need a way to set group access attributes so that only id:{*$Name} (i.e. 
the current wiki page name) could edit their own pages (plus admins of course). 
 That might be configurable already via local/Profiles.php 

This I can probably do, although I'm rusty:

The user corresponding to the Profile, when logged in, can either directly edit 
their Profile-Data page, or (when one has edit permissions) there can be a form 
for updating their Profile-Data/$username data that saves data and the 
encrypted password to the corresponding Profile-Data/$Name page (cf how PmForm 
saves data to another page) while visiting their own Profile.

Then the only case in which an admin is needed is if a user forgets their 
password, not if they just want to change it.  This means admins can set an 
initial password and the users can change their own password after their first 
login.

Crisses___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Comments-UseCases page

[Crisses]

On May 27, 2014, at 1:01 AM, Petko Yotov wrote:
 I'm trying this:
 (:template defaults where=below#{$$anchor} :)
 
 This is not implemented.
 
 Petko

Then I have a simple request for change to how PmForm implements entering data 
on a page:

Do not add a line break.

It's much easier to add a line break in a template if you want line breaks 
between comments or data entered than it is to get rid of it if you want the 
form to create a continuous bullet list. Case in point:

[@
[[#goingform]]
(:input pmform target=going :)
(:input default request=1:)
(:input default author {$Author} :)
Please RSVP for the event:
(:messages:)
Name: (:input text author:)
||width=50%
||(:input radio anchor I'll be there.:) Yes ||(:input radio anchor I can't 
make it.:) No ||(:input radio anchor I might be there.:) Maybe ||
(:input submit post Submit:)
(:input end:)
[[#goingformend]]

[[#goingpost]]
(:template defaults where=below :)
(:template require author errmsg=$[Missing name]:)
*{$$anchor} ~{$$author}
[[#goingpostend]]
@]

Produces the markup:
(:pmform going:)

*I might be there. ~crisses

*I can't make it. ~crisses

*I'll be there. ~crisses


It's adding an extra newline/return between the bullet points.  I tried this:
*{$$anchor} ~{$$author}\\
And it does work, but that makes for sloppy markup and is non-intuitive for 
people implementing the recipe.  If the extra newline is removed, it leaves 
formatting up to the form and post templates, as in:

(:pmform going:)
*I might be there. ~crisses
*I can't make it. ~crisses
*I'll be there. ~crisses

Thank you for your time,
Crisses
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Comments-UseCases page

[Crisses]

Security issue in the comment template in PmForm.Templates:
(:template require text match=-*http:* errmsg=Please don't post external 
links:)

This will still allow https:// links, and other naughty entries.  I think it's 
best to eliminate if there's a colon in it and @ i.e. -*:*,-*@*,-**,-** so 
that it also covers all PmWiki InterMapped services and email addresses.  It 
doesn't stop www.example.com but at least then it's not clickable (unless you 
have a plugin that changes www-link).  One could also eliminate . depending 
on which field it is (on my RSVP form it's a Name field so it would prevent 
someone from saying Rev. Criss or Ms. Fuller, P.C.).  I took out angle 
brackets just for good measure -- it will stop much spam dead in its tracks.  I 
may also add a honeypot to the form (a hidden field like Subject that spam 
software would attempt to fill in and an error message that says please leave 
Subject blank in case someone real tries to fill it in).

Crisses

 [...]
 Thank you for your time,
 Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Comments-UseCases page

[Crisses]

I think the Comments-UseCases page related to an RFC on how PmWiki would move 
forward with more blogging support in the core installation (per the RoadMap 
circa 2006-7, now planned for 2.3 release argh!).  The question was how the 
commenting system should behave so that the changes needed in PmWiki (or PmForm 
in this case) could be implemented.  The problem being that unauthorized users 
(web visitors) would be able to plant content on web pages either via comments 
or in this case could be used for recording RSVPs for events.

My implementation for (Cookbook/)XESBlog is to save data to a separate group 
and require admin approval before comments are displayed publicly.  This means 
I can make sure there are no naughty injections and that people have followed 
proper netiquette before the public can see the comments.  It works fairly well 
and I have low comment spam on sites using it.  It uses PmForm.  I just don't 
remember how I did it :)

On May 25, 2014, at 2:37 AM, Petko Yotov wrote:

 Chris Knadle writes:
 I was on the hunt for some way of using PmWiki for doing RSVPs and found this
 page via a search and which is listed under cookbook in the Forms section:
 
http://www.pmwiki.org/wiki/Cookbook/Comments-UseCases
 
 ... the problem is that after spending a couple of days trying to implement
 Case 3 concerning RSVPs, we've come to the conclusion that this page isn't 
 a
 recipe at all, but rather it's a this is how we users would like comments to
 work, but the page doesn't seem to state that.  :-(  [...]
[...]
 Alternatively or in complement, you can create a form like the one in Case 3 
 and process it/save it/mail it with PmForm.
 
  http://www.pmwiki.org/wiki/Cookbook/PmForm
 
 I haven't used or reviewed the other form-procesing recipes in the cookbook.

I have only used Zap and PmForm.  I have no doubt that the capability is in 
PmForm, but the documentation is thin (there are only simple examples for 
saving data).  I'm not sure how to insert data on the same page at a specific 
point in the page, as in the example RSVP form (Case 3) which inserts the name 
of the person submitting (form input text field) into the page at (above or 
below?) an anchor tag (e.g. [[#yes]], [[#no]], [[#maybe]]) while leaving former 
entries alone.  

How does one do that in PmForm?  I could use it myself on several websites.  
The other thing that would be useful is a headcount, so one can hide the list 
of names, but increment the headcount on the page (i.e. yes: 10 on the page). 
 Functionally: someone types in their name, chooses yes/maybe/no in a 
drop-down, and upon submit it adds their name to the correct list and 
increments the appropriate counter.

I wish I had the time to play with PmForm just to document it more thoroughly.


Crisses___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Comments-UseCases page

[Crisses]

Testing out an RSVP form in PmForm, and I came across documentation for an 
unimplemented feature that would make the whole thing work:

http://www.pmwiki.org/pmform/PmForm/Comments
the note:

Note: the below#anchor and above#anchor forms have not have been implemented 
yet in pmform.php -- as of 2.2.0-beta68.

However the Site/PmFormTemplates uses this feature in the comment form included 
with the package. (see http://www.pmwiki.org/pmform/Site/PmFormTemplates)  Was 
this implemented?

I'm trying this:

[@
[[#goingform]]
(:input pmform target=going :)
(:input default request=1:)
(:input default author {$Author} :)
Please RSVP for the event:
(:messages:)
Name: (:input text author:)\\
(:input radio anchor yes:) Yes
(:input radio anchor no:) No
(:input radio anchor maybe:) Maybe
(:input submit post Submit:)
(:input end:)
[[#goingformend]]

[[#goingpost]]
(:template defaults where=below#{$$anchor} :)
(:template require author errmsg=$[Missing name]:)
*{$$author}
[[#goingpostend]]
@]

And it gives an error for the where feature with the #anchor.  But for the 
RSVP list the #anchor is needed or I'll have to figure out something else.

Crisses


On May 25, 2014, at 2:37 AM, Petko Yotov wrote:

 Chris Knadle writes:
 I was on the hunt for some way of using PmWiki for doing RSVPs and found this
 page via a search and which is listed under cookbook in the Forms section:
 
http://www.pmwiki.org/wiki/Cookbook/Comments-UseCases
 
 ... the problem is that after spending a couple of days trying to implement
 Case 3 concerning RSVPs, we've come to the conclusion that this page isn't 
 a
 recipe at all, but rather it's a this is how we users would like comments to
 work, but the page doesn't seem to state that.  :-(  This also would explain
 why there's no particular plugin mentioned (there is at least CommentBox and
 CommentBoxPlus cookbook plugins that would seem to fit the description,
 leading to further confusion) and trying to figure out who authored the page
 doesn't seem easy either because it appears the History was deleted at some
 point.
 
 Yes, the pmwiki.org installation drops the history after 180 days (after the 
 latest 20 page revisions). This was set by Pm a long time ago. Dropping the 
 history, and even unverifying the user's identity reflects PmWiki's 
 pragmatism: the quality of the latest content is more important than the 
 process of building it. (As opposed to MediaWiki/Wikipedia where every single 
 edit is important and saved - another philosophical view.)
 
 
 So: is this page NOT a recipe?
 
 Yes, it is not a recipe (or No, it is not a recipe? :-).
 
 If that's the case, can someone please edit
 the page and add some text at the top of the page explaining what the page is
 intended for?
 
 I have added a block to the page. If someone knows anything else, please edit 
 the page.
 
 About RSVPs, a few years ago someone wrote to me that they use the Flipbox 
 recipe for RSVPs like Doodle. At that time I implemented the multiple-state 
 flipboxes.
 
  http://www.pmwiki.org/wiki/Cookbook/Flipbox
 
 Alternatively or in complement, you can create a form like the one in Case 3 
 and process it/save it/mail it with PmForm.
 
  http://www.pmwiki.org/wiki/Cookbook/PmForm
 
 I haven't used or reviewed the other form-procesing recipes in the cookbook.
 
 Petko
 
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Author name on RecentChanges pages

[Crisses]

Thank you again! :)  fgrep on pmwiki source code for Author got lots of 
responses.  Didn't know about $AuthorLink.  That should work.

On Feb 16, 2014, at 2:02 AM, Petko Yotov wrote:

 Crisses writes:
 « HTML content follows »
 
 New stupid question:
 
 
 Before calling UpdatePage, I've tried setting (global) $Author, 
 $_POST['author'] and $page['author'] to the author's name, none of which 
 have caused the Recent Changes to note the author's name...the page history 
 seems to be correct.
 
 What appears on RecentChanges, a question mark?
 
 You need to set $_POST['author'] before including scripts/author.php (it 
 normally is set before the progam starts...).
 
 Otherwise, set the global $AuthorLink variable to [[~$Author]] before 
 calling PostRecentChanges().
 
 You can read author.php to see how it's processed.
 
 Petko
 
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] XMLRPC Testers Please

[Crisses]

Thank you, Eric,

I saw that someone posted 2 Android posts on the wiki when I looked at the 
AllRecentChanges but the group name is '1' which means that the application 
passed information incorrectly.  It's supposed to pass the group name back when 
it posts, and I use the group name to form the PmWiki page.  If whomever did 
that tries again, try a title with the group name in it: i.e. Blog.TestAndroid 
instead of just TestAndroid. That may correct that issue.

Just fixed the plug-in so it should save the page author's name -- otherwise 
I'd have known who tried to post (oops!).

Chris K. also tried a couple clients on Linux today... He did manage to post 
using Blogilo -- but the newlines were stripped out on the way back to the wiki 
:(  Unfortunately that renders it mostly useless.  

I straightened out the instructions to make the settings as clear as possible 
(every client handles credentials differently -- very confusing!):  
http://www.pmwiki.org/wiki/Cookbook/XMLRPC-Talk  Only MetaWebLog API has been 
implemented, and you have to use the API link (there is no auto-discover, no 
idea how that works).

I'm only creating pass-through code for PmWiki to talk to a phpxmlrpc plug-in.  
I'll keep trying.  To help with testing clients without consoles, I've been 
trying to figure out how to get the original client XML requests to pass 
through to a log file...  With most apps I'm testing blind.  MarsEdit I've 
gotten quite far with because there's a console in the app and I can see 
exactly what's being passed back  forth -- between that and tons of debug 
messages to the php/apache logs, I'm making progress.  Some progress.

Unfortunately the phpxmlrpc mailing list is quiet and hasn't been particularly 
helpful regarding the newline problems I'm having.

Crisses

On Feb 15, 2014, at 6:31 PM, Eric Forgeot wrote:

 Good idea.
 
 On android unfortunately I couldn't get any app which worked with it.
 
 - Androdot (https://play.google.com/store/apps/details?id=com.androdot) said 
 the website didn't respond (but this app seems quite buggy)
 - Typo3 
 (https://play.google.com/store/apps/details?id=de.hsregensburg.activities) 
 said: unknown method fehlercode:1
 - Wordpress 
 (https://play.google.com/store/apps/details?id=org.wordpress.android) is a 
 very good app, but it can't connect. I'm not sure it's using xmlrpc either.
 - there is a xmlrpc client but it's not free and I'm not sure it's supposed 
 to be used for posting things : 
 https://play.google.com/store/apps/details?id=com.counterbolt.xmlrpcclient
 
 On Linux I tried blogilo, with MetaWebBlog or Wordpress API, but neither 
 worked. When trying autoconfigure it said:
 
 The program can not detect the API of your blog but found a XMLRPC interface 
 and will try to use it.
 The MovableType API is assumed from now on, please choose a different API if 
 you know that the server recognizes.
 
 Then it told me unknown xml tag
 
 Gnome-blog could connect and list the existing Groups (Blog, Pmwiki etc), but 
 I couldn't post.
 
 Drivel, another blog client for linux (gnome), didn't propose relevant 
 protocols (only movable type, blogger etc, and none worked)
 
 

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Author name on RecentChanges pages

[Crisses]

New stupid question:

Before calling UpdatePage, I've tried setting (global) $Author, 
$_POST['author'] and $page['author'] to the author's name, none of which have 
caused the Recent Changes to note the author's name...the page history seems to 
be correct.

Am I missing something?  How do I tell UpdatePage to set an author name for 
RecentChanges?  RecentChanges works correctly when authoring posts in the wiki 
edit form itself.

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] New Cookbook category for recipes that don't require server access

[Crisses]

There's already a Documentation category for recipes that simply document 
tips/tricks/uses for PmWiki, so why not!

I like Markup Only

Another possibility is Edit Access Only or Edit Permissions Only or No 
Admin Access -- these could be used in the description of the category in case 
someone is looking for this type of recipes, this way the category comes up in 
the search.

Some of the documentation pages would fit the bill to belong to the category 
too.

Crisses

On Feb 14, 2014, at 1:53 PM, StefCT wrote:

 Hi,
 
 I'd like to add a new category to the Cookbook encompassing all recipes
 that can be deployed without accessing the server (by relying solely on
 existing PmWiki markup). What does the community think about this?
 
 And how could such a category be named? NoServerInstall? That's the
 best idea I could come up with. All other options that came to my mind
 were either too ambiguous or too long. But maybe somebody with better
 proficiency in English has a better suggestion?
 
 Or does such a category already exist and has just escaped me?
 
 Best regards,
 
 StefCT
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] XMLRPC Testers Please

[Crisses]

Hi, all,

Still working on XMLRPC, but I have a test installation up and people are 
welcome to poke at it with software that supports MetaWebLog API.  I started a 
chart on the page with notes on each software I've tried  my current progress 
in the plug-in.

http://www.pmwiki.org/wiki/Cookbook/XMLRPC-Talk

What does it do?  It allows you to remote-administer one or more pmwiki 
installations through 3rd party software i.e. blog posting software such as 
MarsEdit, Ecto, Blogsy, or maybe browser extension software.  I've had some 
mixed results with different packages, and I'm going to run through them and 
re-test them again and update the -Talk page.  I'm only testing on iOS and Mac, 
it would be great to have someone test some packages on Android, Windows, 
Linux, etc.  Packages are often listed as blogging software.  See the -Talk 
page above for more info and current progress.

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Custom Action and Authentication

[Crisses]

On Feb 11, 2014, at 3:42 AM, Petko Yotov wrote:

 Petko Yotov writes:
 
 Crisses writes:
 « HTML content follows »
 Hi,
 
 I've spent a day trying to fix this, so I have to figure that the 
 documentation or myself (or both) aren't up to the task...
 
 I have an array of (xml scalar) variables being passed to PmWiki via 
 ?action=xmlrpc, including the author  password.  All the xmlrpc functions 
 are in their own classes, including extracting the password from the xml 
 data.  It works just fine, can dump the vars and all is (apparently?) in 
 order.
 
 I'm using basic PmWiki passwording.  I've set up the password to be passed 
 to $_POST['authpw'] and the username to go into $_POST['authid'] and 
 (global) $Author.
 
 
 If you use basic PmWiki passwording (shared password) you need to set 
 $_POST['authpw'] before calling RetrieveAuthPage().
 
 Or, you should be able to call SessionAuth($pagename, $pass); before calling 
 RetrieveAuthPage(), no need to set $_POST['authpw'].
 
 After you have authenticated, just get and return the PHPSESSID cookie when 
 you access the other pages, no need to repost user/pass every time.
 
 Petko



Apparently I'm still not getting it  Note: I'm just using basic passwords 
(for now) and not trying to make it compatible with authuser.php (yet).

I don't think the XMLRPC clients (Ecto, MarsEdit, etc.) have session cookies.  

$password and $username are set just fine as far as I can tell from the 
scalarval() (no whitespace chars added, etc...).  xes_error  xes_dump are 
debug functions which write to the error_log.  xes_dump does a print_r($var, 
true).  $page and $page['text'] comes out blank every time, unless I use 
ReadPage().  CondAuth would work to skip the rest of the loop, but the auth 
fails.  The remainder of the GetRecentPages function runs fine when I use 
ReadPage including client-side XML output, and with authentication the blank 
pages are sent to the XMLRPC client as if nothing else is wrong.


(parent function(s) called via $HandleActions['xmlrpc'] = 'HandleXMLRPC'; )

...

// Retrieves a certain number of PmWiki pages ordered by date
public static function GetRecentPages($params) {
xes_error(Calling GetRecentPages.);
global $XMLRPC_AuthPage;
$blogidp=$params-getParam(0); $groupname=$blogidp-scalarval();
$usernamep=$params-getParam(1); 
$username=$usernamep-scalarval();
$passwordp=$params-getParam(2); 
$password=$passwordp-scalarval();
$passp=$params-getParam(3); $number=$passp-scalarval();
ValidateUser($username,$password);

// Gather pages in an array for sorting by time
$grouppages = $fullpages = Array();
$pattern = /^$groupname\\./;
$grouppages = ListPages($pattern);
foreach($grouppages as $pagename) {
xes_dump($pagename, Next Name: );
// Skip pages we do not have access to
if (! CondAuth($pagename, 'edit')) xes_error(No Text 4 
u!);
$page = RetrieveAuthPage($pagename, 'edit', false, 0);
#$page = ReadPage($pagename);
xes_dump($page, Page: );
$fullpages[] = $page;
}
//Needs an empty error! No pages found

function ComparePageTime($a, $b) {
if ($a['time']  $b['time']) return -1;
if ($a['time']  $b['time']) return 1;
return 0;
}
usort($fullpages, ComparePageTime);

$arrayval = Array();
$pagenum = 0;
// Only return as many pages as are requested
foreach($fullpages as $page) {
if($pagenum++ = $number) break;

$arrayval[]= BloggerXMLRPC::PageAsXMLStruct($page);
}
$myVal=new xmlrpcval($arrayval, array);
return new xmlrpcresp($myVal);
}

...


separate helper function (I know it's not performing validation, I inherited 
the namespace from the former recipe author and haven't corrected it yet -- it 
used to support UserAuth and return false on failure):

function ValidateUser ($username, $password) {
global $Author;
xes_error(Calling ValidateUser);
$Author = $_POST['authid'] = $username;
$_POST['authpw'] = $password;
return true;
}


Crisses
--If PmWiki plug-ins are recipes, then I'm a chef! Or at least a line cook.  :)___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Custom Action and Authentication

[Crisses]

That's exactly the feedback I needed.  I'm testing in a pure new pmwiki 
install, no extra includes just the auth password set...and that fixes the 
issue.  Next is figuring out how to handle that as far as making it a real 
recipe.  So it wasn't that this recipe was calling anything -- some other 
recipe(s) probably were.  Thankfully they can be turned off for this recipe to 
run since it doesn't deal with browser output, just pure wiki 
markup/pages...have to figure out a graceful way to exclude recipe includes if 
(!$action == 'xmlrpc') include...   may work but that's a lot to ask.  I may 
have to eliminate the HandleActions and instruct people to call the recipe 
directly after setting the passwords in config.php.  It basically circumvents 
nearly (only nearly) every recipe or customization one might put into 
config.php since it doesn't deal with HTML wiki output at all.

At least I can get past the roadblock and go on from here.  Thank you again!

re: PS: I considered calling CondAuth() to skip the rest of the loop when not 
authorized, then using ReadPage() to populate $page since it would only read 
pages that already passed CondAuth().  It would eliminate the need to weed out 
blank unauthorized pages later.  I also used CondAuth() as a way to double 
check that authentication was the problem.  

On Feb 11, 2014, at 8:50 AM, Petko Yotov wrote:

 I don't have the potential to review and debug all this but you need to NOT 
 have a username $_POST['authid'] at all, not empty, just not set, if you only 
 use shared password protection.
 
 Is it possible that you have some function calls to CondAuth(), 
 RetrieveAuthPage(), PageVar(), FmtPageName() or other core function before 
 you have set $_POST['authpw']? Some of these functions, if they retrieve 
 content from the wiki.d files, will cache the authorization levels.
 
 Typically, any function call in config.php, or in a recipe included from 
 config.php, can cache the levels. The function you set with $HandleActions is 
 called much later, at the end of the processing. So you may want to assingn 
 the $_POST['authpw'] value before any function call and before any included 
 recipe.
 
 Petko
 
 P.S. There is no point in calling CondAuth() before RetrieveAuthPage(). 
 CondAuth() actually returns (boolean)RetrieveAuthPage() so you do the same 
 CPU-intensive operation twice.
 


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Skin Tutorial was Re: selling pmwiki to high school students

[Crisses]

Thank you!! :)  Sorry I've been a stranger for years -- been rather busy 
including 2 yrs homeschooling a teenager, writing books (with much thanks to 
WikiPublisher!!), etc.

Really, I will work on the tutorials -- still fussing with that XMLRPC (and 
getting places!).  

The only hard part will be documenting things I do in my sleep...Actually if 
anyone wants to make requests for what bothers them about creating Skins or 
basic CSS designs (I no longer even think of tables!), add something to the 
-Talk page:  

http://www.pmwiki.org/wiki/SkinTutorials/SkinTutorials-Talk

I'm putting my brainstorm there for the moment.

Crisses

On Feb 6, 2014, at 3:15 PM, Edwin Marte wrote:

 
 Crisses I know your work in pmwiki for years now. I have tweaked some skins 
 here and there but I don't have the skills to design and change as you do. I 
 think that if you can provide a recipe like the one you mention below it 
 would be wonderful for the community!
 
 You don't have to settle for what's available on PmWiki.org.  Maybe I could 
 write up a recipe/instructions/tips for skinning PmWiki.  I've done it so 
 many timesand I have some macros I use to do it even quicker  I'd be 
 willing to share how I do it.  Maybe I'll do it with a responsive design and 
 share a skin.  I already did 1 responsive design (Mobile Skin) -- so you 
 could cheat and take that very very bare-bones design and add a banner, play 
 with column widths  colors, and boom! you have a responsive design (that's 
 how I did Passionizing, above + I added a responsive menu plug-in, but it's 
 not a drop-down menu so I'm not thrilled with it).
 

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Custom Action and Authentication

[Crisses]

Hi,

I've spent a day trying to fix this, so I have to figure that the documentation 
or myself (or both) aren't up to the task...

I have an array of (xml scalar) variables being passed to PmWiki via 
?action=xmlrpc, including the author  password.  All the xmlrpc functions are 
in their own classes, including extracting the password from the xml data.  It 
works just fine, can dump the vars and all is (apparently?) in order.

I'm using basic PmWiki passwording.  I've set up the password to be passed to 
$_POST['authpw'] and the username to go into $_POST['authid'] and (global) 
$Author.

Later I call RetrieveAuthPage(), but the $page object response comes up blank.  
I checked my $pagename, etc.  I even tried CondAuth() (pages fail) and 
ReadPage() (pages work) so I am certain it's an authentication issue.  And I 
don't seem to have a crypt() issue on storing the password...unless I'm missing 
a step somewhere after $_POST['authpw'].

Is there a proper hook to use custom actions to pass along a user's credentials 
before calling RetrieveAuthPage()?  [I suppose theoretically I could have the 
password in the link (i.e. ?action=xmlrpcauthpw=X), and pass the $_GET to 
$_POST in config.php if needed before the custom actions are run.  But that's 
so messy and insecure.]

Thanks much!!!

Crisses


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] selling pmwiki to high school students

[Crisses]

I don't consider themes an excuse to use WordPress, although I agree about 
designers offering designs to wordpress.

When I need a design that doesn't look like PmWiki I often will grab designs 
from Open Source CMS or other websites and plug PmWiki into them.

Of course, I'm also a designer.  Lately I'm doing responsive designs.

My 2 latest responsive designs (load the page and play with your browser width 
to see the effect):
http://passionizing.com
http://myindependentliving.org

You don't have to settle for what's available on PmWiki.org.  Maybe I could 
write up a recipe/instructions/tips for skinning PmWiki.  I've done it so many 
timesand I have some macros I use to do it even quicker  I'd be willing 
to share how I do it.  Maybe I'll do it with a responsive design and share a 
skin.  I already did 1 responsive design (Mobile Skin) -- so you could cheat 
and take that very very bare-bones design and add a banner, play with column 
widths  colors, and boom! you have a responsive design (that's how I did 
Passionizing, above + I added a responsive menu plug-in, but it's not a 
drop-down menu so I'm not thrilled with it).

But right now my head is crammed into XMLRPC full-time. :)

Crisses

On Feb 5, 2014, at 7:52 PM, Chris Lott wrote:

 On Wed, Feb 5, 2014 at 10:05 AM, Crisses cris...@kinhost.org wrote:
 Any website you want to create that can be done with WordPress can be done
 with PmWiki.  And technically, vice versa.  But which is the easier path?
 
 Depends on the need. There are plenty of very capable themes that
 totally transform the look and feel of WP, which is often a need for
 me. Almost all of the relatively very few PmWiki themes still look
 like PmWiki with some light CSS hacking. Many more graphic designers
 are designing for WP. Yes, that can be done with PmWiki, but it would
 be a waste of time reinventing the wheel in some cases.
 
 It is also nice, sometimes, to have a db to access information from
 when that data is being used in different ways and not just from
 within the primary site.
 
 PmWiki is awesome and the multi-tool analogy is fine. In the end,
 there are times that the specific, full-size tool---expensive and
 awkward as it might be in some situations---is preferable to the
 multi-tool versions.
 
 I'm happy both PmWiki and WordPress exist.
 
 c
 --
 Chris Lott ch...@chrislott.org
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Getting Access to Wiki Markup

[Crisses]

Hi,

I want something similar to http://www.pmwiki.org/wiki/PmWiki/UpdatePage
but to document instead how PmWiki gets from reading a page 
(RetrieveAuthPage()) to what is placed in the browsers' (e_)textarea for 
editing a page ($EditText).
In other words I want the EditPage portion of the EditPage-UpdatePage 
transaction.

I'm working on XMLRPC, I've gotten the hang of what I'm doing, but I need to 
produce in the XML exactly the type of page content - markup  all - that we 
would edit natively in a browser window.

Is this documented?  Is there a specific function to add back in newlines and 
etc. before sending it to the browser?

Chasing down $EditText and other stuff in pmwiki.php  scripts/ got me lost and 
confused.

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] selling pmwiki to high school students

[Crisses]

To your point: I've been using PmWiki over 10 years and using it for many 
clients since I started my business...  I haven't had a request I couldn't 
handle in PmWiki.  Sometimes I had to write the plug-ins to do it, but PmWiki's 
strong point is a friendly development community, a single-point-of-contact for 
the main developer (used to be PM, now it's Petko) to ask the really hard 
questions, and its backward-compatibility.  With such a SMALL code-base, it's 
easier to look at the source code if you must, with things like SDVs it's easy 
to replace code and defaults instead of inserting your own custom code into the 
basic package.

I don't know the WordPress API, but if it's as bloated as the package is then 
it would be hard to use.  I don't think there's one person who wrote the 
majority of the code and understands it all.  My nightmare experience in 
customization was with OSCommerce and ZenCart: the plug-ins had you actually 
change the base package files you couldn't safely upgrade your software.  So I 
forgot to mention that a strength of PmWiki is upgradability.  Nearly 
everyone's recipe still works whether it was written 5 years ago or written 
last week.  That's a long time!  Right now, due to a change in PHP, we have the 
first time in a decade (I think) where we have to go through the entire recipe 
archive and identify recipes in need of updates.  That's a LNG time.

It's nice to know that something you contribute will last.  And when you 
upgrade your wiki software, your recipes are quite likely going to just 
continue working without the need to change anything.

PmWiki is more a multitool than a hammer, and given the basic PmWiki 
philosophy, sometimes it's better to hack the multitool to take care of the job 
in question because the results are (for the software world!) nearly permanent. 
 Since there is no spoon* perhaps the spoon might be a nail after all...  Any 
website you want to create that can be done with WordPress can be done with 
PmWiki.  And technically, vice versa.  But which is the easier path?  I'd say, 
with no data to back it up because after my experiences with themes for 
WordPress I have no desire to attempt to look at the API/code base, the easier 
path is hacking PmWiki than WordPress.

Crisses

*Matrix or quantum physics reference -- who cares.

On Feb 4, 2014, at 11:56 PM, tamouse pontiki wrote:

 Gosh, I'd have a hard time of this. I dislike wordpress so much, and
 love pmwiki so much. I'm sure I'd give them the wrong answers. :)

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] categories, how to translate category name for display

[Crisses]

I take my hint from Site/PageActions:

* %item rel=nofollow class=browseaccesskey='$[ak_view]'%  
[[{*$FullName} | $[View] ]]

thus 

[[!small]]
[[!Small| $[Small] ]]

I think.

Crisses

On Feb 5, 2014, at 4:58 AM, li...@basel-inside.ch wrote:

 Hello
 
 I like to have categories as large, medium, small
 and translate them to a target language as gross, mittel, klein
 
 is it somehow possible to translate
 [!small]
 [[!Small|$Small]]] - doesn't seem to work
 
 thanks in advance for the hints
 regards
 Patrick Ogay
 
 example:
 http://orientalcarpetstudio.com.jovinus-meta.net/Carpet/10027?Trail=Category.Medium
  (categories on the right not translated)
 
 
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] selling pmwiki to high school students

[Crisses]

I've worked with both, have clients who come to me with pre-existing WordPress 
sites, and I set up my own original work blog in a separate WordPress site 
(much to my current regret).

I just set up a blog in PmWiki which mimics a WordPress set-up.  
http://passionizing.com and I'm updating my XESBlog bundle to include the 
sidebar calendar and more tweaks.

PmWiki is 
1) easier to custom-theme -- I'm upgrading my sites and several client sites 
to responsive designs.  Like the wiki-blog linked above, 1 design that works on 
any device.  (Resize the browser window, it's a great trick to show the kids.)  
Creating a custom theme in Wordpress is SO much more of a headache.  
Customizing an existing theme in Wordpress (to change colors or banner images) 
usually has menu options, so it's not so bad  no HTML required.  This new blog 
site is based on the mobile skin I already made on PmWiki.org, but I don't 
bother detecting mobile.  It looks great on an iPhone or iPad.
2) easier to repeat page information from page-to-page (via templates, 
groupheader, groupfooter, etc.)
3) easier to make custom searches and customize the design  data included in 
the search output
4) faster if you want to throw a website up quickly and get going -- rather 
than a blog.
5) blog-optional, to make a wordpress site into a website rather than a blog is 
actually about the same level 
6) PmWiki gives you the ability to do in-page programming and to have fine 
control over nearly everything that you do.
7) able to have collaborative editing out-of-the-box with or without 
passwording to create an onlineopedia (i.e. think of all the XXXGame Wiki 
like the Plants vs. Zombies Wiki where people share tips  tricks  
screenshots -- PmWiki can do that, wordpress cannot)
8) Far less security problems than WordPress (may be through obscurity, may be 
due to superior security  an agile development team that fixes problems 
quickly)
9) Multiple layers of permissions and content control available
 much more...

Upsides to WordPress
1) WUSIWUG
2) Control-panel driven
3) It's a blog out of the box
4) Huge theme-making community - responsive designs are probably available 
there too
5) Loads of panel-installable plug-ins
6) Panel-installable upgrades (of both plug-ins and the entire package)
7) Often available to set up quickly for free
8) Friendly for non-techies

A few recipes on top of PmWiki make it MUCH more user friendly, like drag  
drop attachments, NewPageBoxPlus, etc.

I have a ton of YouTube video shorts on editing PmWiki on my YouTube 
channel  eclectictllc.  Documented here:  
http://eclectictech.net/Support/Support


In short, WordPress is an appliance website with some extra bells  whistles, 
PmWiki is a highly customizable power-house.  I've made business directories, 
encyclopedias, databases, etc. in PmWiki and would never dream of attempting to 
use WordPress for it.  PmWiki is a true CMS if you know how to use it.  
WordPress is a blog-as-cmsish. :)

Crisses
-- 
...truthfully, getting well seemed a lot more far-fetched than getting a Ph.D. 
at that moment.
  -- Cameron West, First Person Plural

On Feb 1, 2014, at 7:47 AM, Peter Bowers wrote:

 I am teaching a high school class in computers and our most recent project 
 was creating a site in WordPress and in PMWiki.  At the end my students were 
 not overly enamored with the setup and configuration of pmwiki and wanted to 
 know why they would ever use that over WordPress.
 
 I gave several thoughts but then I promised to write to the list to get 
 further input.
 
 If you were selling pmwiki to a group of high school students with limited 
 technical experience but good potential, what would you say are its top 
 advantages as compared with WP?
 
 -Peter
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] selling pmwiki to high school students

[Crisses]

...more

If the idea of their class in computers is to see if they would perhaps one day 
be programmers, sys admins, work in a techie business setting, etc. consider 
these scenarios where PmWiki fits:

Case Examples: 

A non-profit with several locations, and they want to have a passworded 
intranet section of their website with employee profiles with a photo of the 
employee, so that their employees can get to know one another across locations.

...They're also considering a separate section where the Board of Directors' 
reports can be stored under a different password.

A recruiting firm (I used Drupal I think...before I was doing development for 
PmWiki... but it's a good case for a CMS) wanted a document-management intranet 
for employees (intranet includes telecommuters, people on the road and 
traveling, etc.).  Again, passworded section that only employees can get into, 
and with different levels of access.  I can't tell you how much I hated Drupal. 
 PmWiki could do what it did, and more.  And easier.

A museum has a different home page picture that they only want posted near the 
holidays -- with an (:if date:) I can swap out photos only during certain 
months, put up a special holiday message, etc. and it will change itself every 
year.  

I have a site where I have a business membership directory. I can track any 
info like I would in a database: most importantly the day their membership 
expires.  The public pages list the people's contact information, but when I 
log in, I can see their expiration date, and I have it automagically hide 
people whose membership has expired.  If they re-up after it expires, just 
update the expiration date and POOF they're listed again.  With a little work, 
I could probably have the site email me near their expiry date so I remember to 
send them a re-up email.  Or have the site email them directly that their 
membership is expiring.  Note it would only email them if someone loads the 
website, but a cronjob would fix that issue if necessary.  

Anyway, all of this is through PmWiki's built-in permissions, Conditional 
Stamenents, PageTextVariables, and Pagelists.  No plug-ins required.


Features, continued:

Any website can have random information (like rotating quotes, rotating 
testimonials), hidden information on a page that only shows when logged in, or 
information that is seasonal or monthly in nature (my website used to change 
prices for a sale every month: in December I set up 12 different sales, and a 
message about the sale, and my prices throughout my website would update 
themselves each month of the year to reflect the sales...).  Do the work once, 
and let the website do the rest...

Page histories.  If you have to roll back to a previous version of a page in 
WordPress, you can't.  Maybe there's a plug-in for it, but it's built-in in 
PmWiki.  When I have a client who made a mistake and reverted the page, I go 
into the page history to see what they tried that broke the page. Awesome!

No database required.  You can probably get slashdotted and survive.

If you're viewing a page and you see a typo, just log in and fix it.  If you're 
already logged in, just hit edit and fix it.  On WordPress you have to open up 
the control panel and navigate to the page in question.  I've edited typos on 
my iPad  iPhone without needing special software or having to type in the 
login URL.

Tons of documentation that's included in the package.

A much smaller installation size than anything comparable even with all the 
documentation.  Size doesn't matter any more, but that slender size 
represents how much brainpower it requires to run PmWiki.  [That's why you can 
probably get /.'d and survive.] 1.8MB installed with the PmWiki.* files in 
wikilib.d.  Only 700KB if you remove the documentation (which is readily 
available on pmwiki.org).  WordPress 14.7MB installed, not counting running a 
database or anything else, no plug-ins, etc.  It's a hog.  WUSIWUG comes at a 
price, I guess.  This also translate into installation time, depending on your 
upload speeds

... I guess that will do for now :)

 On Feb 1, 2014, at 7:47 AM, Peter Bowers wrote:
 
 I am teaching a high school class in computers and our most recent project 
 was creating a site in WordPress and in PMWiki.  At the end my students were 
 not overly enamored with the setup and configuration of pmwiki and wanted to 
 know why they would ever use that over WordPress.
 
 I gave several thoughts but then I promised to write to the list to get 
 further input.
 
 If you were selling pmwiki to a group of high school students with limited 
 technical experience but good potential, what would you say are its top 
 advantages as compared with WP?
 
 -Peter
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users
 
 ___
 pmwiki-users mailing list
 

Re: [pmwiki-users] Category nesting question

[Crisses]

One thing being overlooked for nesting is a top-level link.

on Appetizers, link to [[!Category]]
on Breakfast, link to [[!Category]]

Now when you add Category.GroupHeader of:

Recipes:
(:pagelist link={$FullName} fmt=#titlespaced list=normal group=!Category:)

Subcategories:
(:pagelist link={$FullName} fmt=#category list=normal group=Category:)

 a Site/LocalTemplates including:

!!fmt=#category

Outputs nested categories.

[@
(:if false:)
[[#category]]
(:template defaults wrap=none:)
*[[{=$FullName}|{=$Titlespaced}]] (:pagelist link={=$FullName} fmt=#category 
list=normal order=title group=Category:)
[[#categoryend]]
(:ifend:)
@]

You will see the top-level categories on the Category.Category page, and all 
nested categories under any other category page.

I recently had a problem doing a recursive listing of nested categories (see my 
recent pmwiki-users email about wrap issues).
Here's the page where you can see the issue: 
http://holistichv.org/Category/Category

If you do the same thing WITHOUT the pagecount, you should be fine.  I removed 
the pagecount from the pagelist template for you.

Funnily, I did the right thing  submitted a PITS about it this morning 
(PITS:1336), but it's gone.  Perhaps it was rolled into another bug report, but 
I can't find it.  I'm starting to think that Recent Changes pages need to 
contain information on deleted pages.

Crisses


On Jan 17, 2014, at 10:26 AM, Peter Bowers wrote:

 On Fri, Jan 17, 2014 at 4:44 AM, Chris Lott ch...@chrislott.org wrote:
 What I want to add is have [[!Eggs]] as a nested category so,
 ultimately, the users can look at Eggs in Breakfasts or Eggs in
 Appetizers (and, ideally, all Eggs recipes). How do I go about setting
 this up?
 
 Unfortunately I believe that what you are wanting to do is not currently 
 possible for *truly* nested categories.  If you use the nested category as 
 Petko suggested there is no differentiation between the Eggs category for 
 Breakfasts or the Eggs category for Appetizers - when you go to view the 
 pages in Eggs you will see both of them.  Would it work to name them 
 [[!Appetizers-Eggs]] and [[!Breakfast-Eggs]] or does it get to prone to typos 
 then?
 
 Another alternative would be to make your Categories.Eggs page a 
 disambiguation page with a link to Categories.Appetizers-Eggs and another 
 link to Categories.Breakfast-Eggs and on Breakfast-Eggs your pagelist would 
 include *both* the !Breakfast *and* the !Eggs categories.  It's not quite so 
 seamless from a user perspective as they have an additional page in between 
 that they have to click through, but I think you arrive at your desired 
 funcationality in the end...  And, where appropriate, you could direct-link 
 to the final page (i.e., on the Category.Appetizers page you could exclude 
 the Eggs page explicitly from the pagelist and explicitly include the 
 Appetizers-Eggs page.  
 
 -Peter
 
 -Peter
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Cookbook XESBlog page deleted?

[Crisses]

I've been using XESBlog since I created it in 2008 without trouble including 
installing it on customer's websites.  But for some reason the cookbook page is 
gone (Cookbook/XESBlog).

The .zip file is still in the PmWiki.org attachments and the 
Cookbook/XESBlog-Use page is still up...

I don't know if it was deleted on purpose or not -- if it needs maintenance I 
can probably fix whatever needs to be fixed, but I'd rather not have to 
re-create everything from scratch.

Can the wiki page be restored?

Thank you,

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] inconsistent pagelist wrap behavior

[Crisses]

I'm using nested Category.Name syntax on a business directory, per the 
directions in PmWiki's Category documentation.

http://holistichv.org/Category/Category


!!fmt=#category

Outputs nested categories.

(:if false:)
[[#category]]
(:template defaults wrap=none:)
*[[{=$FullName}|{=$Titlespaced}]] (:pagelist link={=$FullName} fmt=#count 
group=Members:)(:pagelist link={=$FullName} fmt=#category list=normal 
order=title group=Category:)
[[#categoryend]]
(:ifend:)


First, the wrap=inline wasn't working for nested ULs, eventually I figured out 
how to get the ULs I wanted.  It's possible the documentation is wrong for 
wrap=inline.

Then I wanted to show a count of members for each category -- so I added in the 
count pagelist.  But sometimes the count stays on the correct line, sometimes 
it wraps down to the next line.  It's not one particular UL level with the 
problem -- it can have children or not -- so I don't understand what's 
happening.  In the HTML it's sometimes closing the parent UL -- sometimes it's 
staying in the LI like it's supposed to.  I tried wrap=none on the count, it 
puts them in a p tag, which also puts them on the next line (but under the 
current LI level at least).

Any ideas?  I'm on the latest stable PmWiki.



Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Anchors in PmForm templates

[Crisses]

When using a pagelist/pmform template, is there any way to insert an anchor 
link into them?

I have an email form, sometimes it's used on an event registration page so 
someone can RSVP for the event.  It can be at the bottom of the page -- when 
the page refreshes after sending, [error] messages are below the fold so people 
rsvp and the email isn't sent.

I added (:messages:) to the GroupHeader, and I'll CSS it larger, red and bold 
-- but I'd also like to be able to display an anchor link for the website 
visitor to jump down to the form rather than scroll down the page to make their 
corrections.

I can't add a simple anchor link [[#form]] to the template -- that doesn't 
work.  Is there another way to do it?

If there's no way to do it manually: can there be an automatic anchor added at 
the beginning of a pmform or pagelist?  It can be with the same name as the 
template being used...  I use (:pmform mailme:) so couldn't there be an 
automatic anchor [[#mailme]] at the start of the form?  Either that or fix it 
so that anchors within the template work without breaking the template?

Thank you for your time! :)

Crisses


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Anchors in PmForm templates

[Crisses]

Thanks, Randy -- that works with the pmform template, too

(:pmform mailme anchor=rsvp:)

and added 
[[#{$$anchor}]]
above (:messages:)

Crisses

On Dec 23, 2013, at 2:32 PM, Randy Brown wrote:

 
 When using a pagelist/pmform template, is there any way to insert an anchor 
 link into them?
 
 I can't add a simple anchor link [[#form]] to the template -- that doesn't 
 work.  Is there another way to do it?
 
 
 
 If you only have one pagelist result, you can try something like this:
 
 [[{$FullName}#jumptohere|Jump to anchor within pagelist result]]
 (:pagelist name={$FullName} fmt=#format anchor=jumptohere:)
 (:if false:)
 [[#format]]
 This is above the anchor
 
 [[#{$$anchor}]] 
 This is at the anchor
 
 This is below the anchor
 [[#formatend]]
 
 Randy

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] custom parameters in output HTML

[Crisses]

Thank you, that did the job!

Crisses
-- 
The criticism has been raised--from both inside and outside the mental health 
professions--that psychotherapy can be viewed as an attempt to get people 
adjusted to a sick society rather than to encourage them to work towards its 
improvement.  As a consequence, psychotherapy has often been considered the 
guardian of the status quo
Each time therapists decide that one behavior should be eliminated or 
substituted for another, however, they are making a value judgement
There are strong pressures on a therapist--from parents, schools, courts, and 
other social institutions--to help people adjust to the world as it is.
 -- Abnormal Psychology and Modern Life (11th ed). Carson, Butcher,  Mineka, 
p. 678-9.

On Dec 17, 2013, at 1:25 PM, Brian Tibbels wrote:

 I use something very similar for Boostrap 3. 
 
 $WikiStyleAttr['data-breakpoint'] = 'li|div|p';
 
 then you can use
 * %apply=list class=flexnav data-breakpoint=800% First Menu Item
 
 
 Rgds
 Brian
 
 
 
 
 On 17 December 2013 17:24, Crisses cris...@kinhost.org wrote:
 A wikistyle may not be the right way to do this:
 
 Here's what I need in the HTML output for a navigation menu:
 
 ul class=flexnav data-breakpoint=800 li.../li /ul
 
 
 Here's the markup I'm trying to use:
 
 *%apply=list class=flexnav db=800%First Menu Item
 *Second Menu Item
 **Nested Menu Item
 *Third Menu Item
 
 Here's the custom php I'm attempting to employ:
 $WikiStyleRepl['/\\bdb(=\d+)/'] = 'data-breakpoint$1';
 
 And the output I'm getting:
 ul class=flexnavli a class=wikilink href=...
 
 The whole db part disappears.
 
 ideas?
 
 Thanks!  Trying to make a responsive navigation plug-in...
 
 Crisses
 
 
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users
 
 

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] custom parameters in output HTML

[Crisses]

A wikistyle may not be the right way to do this:

Here's what I need in the HTML output for a navigation menu:

ul class=flexnav data-breakpoint=800 li.../li /ul


Here's the markup I'm trying to use:

*%apply=list class=flexnav db=800%First Menu Item
*Second Menu Item
**Nested Menu Item
*Third Menu Item

Here's the custom php I'm attempting to employ:
$WikiStyleRepl['/\\bdb(=\d+)/'] = 'data-breakpoint$1';

And the output I'm getting:
ul class=flexnavli a class=wikilink href=...

The whole db part disappears.

ideas?

Thanks!  Trying to make a responsive navigation plug-in...

Crisses


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Pagelist or Page Variable fail? bug or feature?

[Crisses]

Hi,

Got a potential bug? 

I had set:
$SearchPatterns['default'][] = '!\\.Group(Header|Footer)$!';

Because I didn't want GroupHeader or GroupFooters displayed in search results.

Then I put a template into GroupHeader, so it would be displayed on every page. 
 Normal text and PTVs work fine in the GroupHeader, but this failed:
(:pagelist name={*$FullName} fmt=#person:)

To be sure, I also attempted the stock pagelist template:
(:pagelist name={*$FullName} fmt=#title:)

Both died silently.

However this worked:
(:pagelist name=Group/SpecificPage fmt=#person:)

Disabling the $SearchPattern fixes this behavior.

I wouldn't think the $SearchPattern restriction would prevent this GroupHeader 
pagelist template from being pulled into the top of a viewed (non-GroupHeader) 
page.  Shouldn't {*$FullName} be evaluated before the block on a 
pagelist/search result of Group.GroupHeader?  

I can understand why the template wouldn't show up ON the GroupHeader page 
(that doesn't bother me).  But when I view Group/SpecificPage it should show 
the data in the pagelist template I've defined in GroupHeader.

Thanks! :)

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] PmForm documentation disappeared?

[Crisses]

I put up a walkthrough for PmForm on making a very basic website email form 
with captcha  honeypot, explaining all the lines  going over all the steps.

If anyone wants to add ordinal numbers to the steps feel free -- it was several 
hours of work, and I'm drained :) lol

http://www.pmwiki.org/pmform/PmForm/BasicEmailForm

Each section has narrative explaining the code, and then wraps up with just 
the code at the end of the section for copy-pasteaholics.

I'll gladly take questions, or requests for further clarification to the extent 
that I understand PmForm, since I've been using it since PM created it.

It's the form that I use for nearly all my client websites.  For example it's 
here:
http://nyses.org/Main/Contact-Us (New York Solar Energy Society -nonprofit-)

Crisses
http://eclectictech.net/wiki/Info/Contact (a modified form is here -my website-)

On Feb 2, 2011, at 4:45 AM, Oliver Betz wrote:

 Crisses wrote:
 
 The PmForm cookbook page still points to where PmForm's full documentation 
 used to live, but I'm getting a server error now.
 
 PmForm:Installation
 http://www.pmwiki.org/pmform/Installation
 PmForm:MailForm
 http://www.pmwiki.org/pmform/Installation
 
 while we're at it: PmForm deserves a better documentation. I use it in
 one project, but I found it really hard to get it working, and I'm
 still not sure whether I did it right.
 
 Oliver
 
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] PmForm documentation disappeared?

[Crisses]

The PmForm cookbook page still points to where PmForm's full documentation used 
to live, but I'm getting a server error now.

PmForm:Installation
http://www.pmwiki.org/pmform/Installation
PmForm:MailForm
http://www.pmwiki.org/pmform/Installation

referenced here:
http://www.pmwiki.org/wiki/Cookbook/PmForm

500 Internal Server Errors

Crisses

Now I've been crying lately, thinking about the world as it is 
Why must we go on hating, why can't we live in bliss 
Cause out on the edge of darkness, there rides a peace train 
Oh peace train take this country, come take me home again 
 -- Cat Stevens, Peace Train

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Hacked site - OLD code.

[Crisses]

pmwiki-2.2.0-beta65

Hacked to death.  Thankfully not on my server.  Obviously an XSS attack, got 
into the server, altered EVERY php file added base64 code to every page.

Trying to convey to the hosting service the severity of this moved all the 
folders for now so they can look at it.  Problem with working with grunts 
LOL  They changed the sever password, like that would help



Crisses
-- 
I have waited almost two years for a sign from God...
Sir, the truth is I talk to god all the time and, no offense, but he never 
mentioned you. 
--LadyHawke

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Accessibility Option

[Crisses]

I suggest using the PRINT feature.  Or copy the Print skin and modify it.  It's 
very close to what you're looking for.


Crisses

It is the psychology of our ancestors, our parents and grandparents, of our 
teachers and leaders, of almost all the people we know or know about.  
Coercion, to try to get our way, has been with us so long that it is considered 
common sense, and we use it without thinking about it.  We neither care where 
it came from nor question its validity.
  -- William Glasser, Choice Theory (p. 6)

On Jun 3, 2010, at 3:48 PM, Ivan Mann wrote:

 I have to add an accessibility button to quite a few of my pmwiki pages.  
 What that means is to display all of the content of the pages with plain, 
 large text on white background.
 
 Is there an automatic (that is, easy) way to do that or do I have to 
 duplicate the entire set of content, and then make duplicate updates of the 
 existing pages?
 
 -- 
 Ivan Mann 
 
 Any fool can criticize, condemn and complain and most fools do.
  Benjamin Franklin

 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Accessibility Option

[Crisses]

You can use the SkinChange recipe WITH the Print skin or a modified print skin.

If you need more help let me know.

And this is a great idea for one of my clients' websites.  :)  I'd love to see 
how you implement it, or bounce the idea backforth.

If you are handy with PHP you could probably modify any video recipe to include 
ALT text for the video and make a skinname.php file that swaps any videos for 
their ALT text -- it would take a little thought, but it's definitely feasible 
that instead of (:youtube VIDEOCODE:) you could do (:youtube VIDEOCODE Alt 
text:).


Things like that make a big difference

Crisses
(on board of directors of local cross-disability services provider/advocacy org 
now)

[That's o]ne reason I'm out about [my multiplicity].  I find most people 
react positively.  Those who do not, are probably ones I'd want to chase with a 
stick anyhow...
 -- Bob King

On Jun 3, 2010, at 3:59 PM, Eemeli Aro wrote:

 On 3 June 2010 22:48, Ivan Mann ivanm...@uab.edu wrote:
 I have to add an accessibility button to quite a few of my pmwiki pages.
  What that means is to display all of the content of the pages with plain,
 large text on white background.
 Is there an automatic (that is, easy) way to do that or do I have to
 duplicate the entire set of content, and then make duplicate updates of the
 existing pages?
 
 Use a different skin for the accessible view. With
 http://pmwiki.org/wiki/Cookbook/SkinChange the accessibility
 button/link can set the skin for that page (?skin=blah) or as a cookie
 (?setskin=blah) until it's reset.
 
 eemeli
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Blogging recipe for PmWiki

[Crisses]

Due to a hiccup on my mail server, I didn't send this through to the  
list

On Dec 17, 2007, at 6:22 PM, [EMAIL PROTECTED] wrote:

 I've pulled together recipes that support blogging [...]
 and created a recipe that contains several OTHER recipes
 by other authors, and packages them together with a few extras
 added in for good measure.

 Crisses, while your effort deserves a praise for sure, and while the
 blog itself celebrates its ten years [1], I admit that I would feel a
 bit scared to trust in a blog structure and mechanisms which are far
 from plain, not easy to upgrade, and not firmly tied to the pmwiki
 core.

How about you take a look at what I did and decide whether I did  
anything out of the ordinary.

I included  enabled other recipes (see below) in my xesblog.php, this  
way you only have to add one include_once statement to config.php, and  
only a small number of configuration values.

I added a few bits of code -- for allowing public comments to be  
approved by the admin.  It adds a (:markup:) for a form button to  
approve comments, and it adds a {$Value} to the comment pages saying  
whether they've been approved.  This value is used elsewhere in  
pagelist if statements so only approved comments are listed under  
blog entries.

I added a new pagestore xeslib.d so that pre-created wiki pages  
(such as a template for Blog.Blog that has the pagelist pre-configured  
in it, a template for the admin to approve comments, etc.) are  
available with the recipe.  This is optional: you can copy the pages  
to wiki.d or to wikilib.d instead, if you'd really want to.  These are  
normal wiki pages with pagelists, etc. and customizable using normal  
PmWiki markup.  It's just easier to work with pre-created pages than  
write out a recipe with instructions for every page you'd need to  
create.

I gave suggestions on things to add to the sidebar to show blog  
features to the world.  I would have put this in the new pagestore,  
but a sidebar is a very personal item, and I didn't want to get  
between a wikifanatic and their sidebar.

and lastly,

I put it all (recipes + pagestore + some blog|feed icons) into a  
single zipped plug-in so it's easier for people to download  install  
rather than picking through dozens of recipes and trying to figure out  
how to piece it together.


I am waiting on Patrick to review it for security (and perhaps sanity).

Included  pre-configured plug-in recipes:

XMLRPC
Pingback
TagPages
ListCategories
PmForm  captcha
EnhancedWebFeeds
GoogleBlogPing

None of the features these recipes supply will be included with the  
PmWiki core blog support, to my knowledge.  If you want a blog you  
can use Ecto with your blog (xmlrpc), support for pingbacks, the  
ability to easily tag pages (tagpages just adds typical PmWiki  
Categories to pages), Tag Clouds (ListCategories), comment forms with  
captcha, RSS feeds that contain full descriptions  tags/categories,  
and outbound ping when you post -- you'll need to either code all of  
these features yourself, or use recipes for them.  If you don't want  
any of these, the xesblog.php is commented, and any section can be  
commented out to eliminate the need for these recipes.

I've been using xmlrpc.php for years with Ecto to manage large  small  
wiki websites -- LOVE it.  I created the TagPages recipe it just adds  
categories ([[!Tag]]) to pages, alphabetizes and wikistyles them   
PmForm is by Patrick, EnhancedWebFeeds is a recipe created to take  
advantage of features in Patrick's built-in webfeeds that are not  
enabled by default.  I've been using PmForm's captcha ability and have  
had no problems with it.

The only IFFY recipes are pingback  googleblogping because I can't  
verify if they're working.  I can take or leave them.  I don't see  
these capabilities going into the core any time soon, and it would be  
nice to support pingback and pinging an external service if they work.


Other recipes I mentioned in the recipe page were theory-only recipes,  
and they lent ideas to the overall creation of this recipe.


The ONLY thing I believe is not what Patrick has been thinking: I have  
each blog comment on a separate page.  I thought about it long and  
hard, and thought that being able to individually approve each comment  
was -- at this time -- more important than worrying about getting my  
blog(s) dugg/slashdotted, and I wanted to keep the entries as close to  
core PmWiki as possible.  Thus each comment to a page, and only one  
variable value added in the page attributes -- i.e. it's not in the  
page text in-wiki, it's in the text file saved-to-disk and creates a  
$Variable rather than a $:Variable in-wiki  Other than this, I've  
worked closely with Patrick on a number of ideas  projects over the  
last year.  I don't believe I did anything outside of the norm in  
using PmWiki in the project, and I'm confident that what I've done is  
going to be good until a new major revision

Re: [pmwiki-users] Blogging recipe for PmWiki

[Crisses]

same hiccup


Thanks, Dave.  There's another email on the list that goes into more  
detail about what I did in the recipe.

I've installed it on 3 sites so far -- and found a couple bugs --  
fixed the package a couple times.  There's also other features I want  
to add, so people may want to wait to implement it in a production  
environment (I've given it to 2 clients in addition to my own site, so  
I guess I'm the guinea pig for testing it in production  
environments)..  On one I forgot to change permissions on the Comments  
group (But I was probably the first person to try putting a comment on  
her first post ;) so I caught it).  That's in the directions -- have  
to learn to follow my own directions.

I'd suggest trying it on a local or test wiki first.  Heck, you don't  
have to add the blog stuff to the sidebar, or you can wrap the entire  
blog sidebar in (:if auth admin::) so only you can see the blog  
features.  The only pages it actually does anything outside of  
pmordinary to is the Comments group.  On Blog pages it adds  
(:timestamp:20071218TXX:) when you save (Publish) the page.

It turns on PmWiki's Draft's feature too.  For your whole site.   
That's easy to remedy and make happen only for the Blog group, though  
if you don't want it.  That feature allows you to save any page as a  
draft before making it public.  Not a bad thing for your entire site  
if you think about it.

On one of my user's sites I added:  (:if [ auth admin  exists {* 
$FullName}-Draft ] :)[- | [[{*$FullName}-Draft | View Draft ]] to the  
Site.PageActions

This adds a draft page to the page action links across the top of the  
site when it exists -- I have my page actions only show up for the  
admin -- most folk would just use:

(:if exists {*$FullName}-Draft:)[- | [[{*$FullName}-Draft | View  
Draft ]](:ifend:)

Thanks again,

Crisses

On Dec 18, 2007, at 12:25 AM, DaveG wrote:

 I like the way you've tied separate cookbooks together to present a  
 pretty rounded blogging implementation. I haven't used it yet, so  
 the pain may be yet to come, but it looks promising. Thanks.

 ~ ~ Dave

 Crisses wrote:
 I've pulled together recipes that support blogging and made some  
 executive decisions on what blogging means (to me, a WordPress  
 user), what it should be, and how it should work, and created a  
 recipe that contains several OTHER recipes by other authors, and  
 packages them together with a few extras added in for good measure.
 Please see http://www.pmwiki.org/wiki/Cookbook/XESBlog for  
 features, installation instructions, etc.  Note that Pingbacks  
 require a few PEAR modules, so you could comment out the pingback  
 lines until someone comes up with a better pingback recipe.
 See also http://www.pmwiki.org/wiki/Cookbook/XESBlog-Use for  
 instructions on creating blog posts with the package.  I made it  
 simple, so my clients can use it.
 Please make suggestions if you see missing features, I plan on  
 adding more as I go along and as I or clients need them.
 Blog is live at my website http://crisses.org/Blog/Blog
 Have fun!!  For those of us with holidays past  present, I hope  
 you're having a wonderful time!
 Crisses
 
 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] vCalendar

[Crisses]

(same hiccup -- due to a translation from hyphen to plus in email  
addresses on my incoming mail, my reply-all went to pmwiki 
[EMAIL PROTECTED] never made it to the list.  Damn postfix+cyrus.)

On Dec 17, 2007, at 11:15 PM, Josh Miller wrote:


 Has anyone had any experience using PmWiki to create vCalendar files  
 so
 a website user can click a link to add an event to their Outlook or  
 PIM?

 If you can't do it in PmWiki does anyone have any knowledge or
 experience with other PHP scripts or applications that do this?

 I found the specs for vCalendar files at:
 http://www.phpbuilder.com/columns/chow20021007.php3

I actually discussed doing things the other way around with Patrick  
not tooo long ago: using the vCalendar format to pull data into  
PmWiki (PmCal /or WikiCalendar).  (and similar vCard format for a  
business directory)

In short, yes of course this can be done.  The question would be 1)  
how to go about it in general 2) how much of the POSSIBLE vCalendar  
data should it support? 3) should it work from a data perspective --  
such as PageTextVariables? or a page attribute perspective?  Or should  
the recipe attempt to read data off the page in some other way? 4)  
should it integrate with an existing calendar recipe or be something  
that stands alone?

In the short term you may want to create calendar events in your own  
application (iCal, Outlook, etc.), export a vCalendar event file, and  
Attach:file.ext the vCalendar file to the wiki Calendar page  
(regardless of which recipe for calendars/events you use, this will  
work! :) ).  It might require adding a new file extension/mime type to  
your config.php -- but that's all -- and it would work as any  
attachment would.  This is the you don't need to know php version.

I also wonder if there's a DTD that translates vCalendar into a usable  
XHTML display format, in which case maybe it could be in a popup  
window or javascript frame?

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Blogging recipe for PmWiki

[Crisses]

I've pulled together recipes that support blogging and made some  
executive decisions on what blogging means (to me, a WordPress user),  
what it should be, and how it should work, and created a recipe that  
contains several OTHER recipes by other authors, and packages them  
together with a few extras added in for good measure.


Please see http://www.pmwiki.org/wiki/Cookbook/XESBlog for features,  
installation instructions, etc.  Note that Pingbacks require a few  
PEAR modules, so you could comment out the pingback lines until  
someone comes up with a better pingback recipe.


See also http://www.pmwiki.org/wiki/Cookbook/XESBlog-Use for  
instructions on creating blog posts with the package.  I made it  
simple, so my clients can use it.


Please make suggestions if you see missing features, I plan on adding  
more as I go along and as I or clients need them.


Blog is live at my website http://crisses.org/Blog/Blog

Have fun!!  For those of us with holidays past  present, I hope  
you're having a wonderful time!



Crisses___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] NotifyList not working

[Crisses]

On Jul 4, 2007, at 2:13 AM, John Morris wrote:

 I am running PmWiki 2.2.0 beta37
 I am trying to get NotifyList to run on two different farm sites

 The following is the typical config.php lines

 # enable notifications
 $EnableNotify = 1;
 $NotifySquelch = 8640;# 86400-wait at least one day between
 notifications
 $NotifyDelay = 30;# wait five minutes after initial post
 $NotifyFrom = 'OregonCoastWoodturners.com';

I would assume that if the from is an invalid email address, your  
spam filter or an ISP would reject the email.

Try [EMAIL PROTECTED]

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] neverending registration question

[Crisses]

On Jun 7, 2007, at 8:57 PM, Sandy wrote:

 Marguerite Floyd wrote:
 WHERE can I find the recipe or option that displays a registration
 form?  You've been great about showing me how to set passwords and
 display login boxes, but WHERE is the page I can link to that  
 requires
 the user to put in their name???  It's not much use to display a box
 asking for a password when there's no display anywhere asking for a
 user name to begin with.

 When you register with sites there's a page where you have to put in
 your name, userid, chosen password, etc.  Where in pmwiki.org can I
 find this page OR if there is no page like that, where's a recipe or
 code to connect up a designed page with the pmwiki system?

 Thanks!

 The Crisses have just written a how-to for the basic AuthUser,  
 where the
 database is maintained by the wiki in Site.AuthUser .
 http://www.pmwiki.org/wiki/Cookbook/QuickStartForAuthUser
 Yes, the procedure seems rather round-about, having to set temporary
 access to set the permanent access, but that's the way it works at the
 moment.

Following up, due to someone mentioning my name :)

A wiki was originally an open-edit system before it became abused.   
Over time, more security became required (whether detecting spam in  
posts, or requiring user authorization/authentication).  As a hold- 
over from the true spirit of the wiki the out-of-the-box pmwiki  
package comes open-edit with the recommendation to turn on the spam  
detection software (Blocklist) and change the admin password.

The built-in AuthUser does not allow users to self-register, recover  
passwords, or do email authentication.  Ben Wilson  I have worked on  
AuthUserDBase which combines those features with using a MySQL  
database to manage user authentication. It works with the built in  
AuthUser system, but gives users a registration form, sends them an  
email to verify their account, allows them to update their email or  
passwords, and allows the request to change a lost password.  This is  
much more content-management-system-like than wiki-like.

Last I used it, it worked, but that's a while ago (January), and the  
recipe may require updating.  I will probably be picking it up again  
soon and making sure it works -- perhaps when 2.2.0 is finalized,  
since that's a sensible time to check a recipe.  Note that using the  
recipe requires first using http://www.pmwiki.org/wiki/Cookbook/ 
DatabaseStandard (prerequisite) then http://www.pmwiki.org/wiki/ 
Cookbook/AuthUserDbase
There ARE other options.  I haven't used any of them, so I don't know  
what to recommend.  I've either left wikis open-edit (I have at least  
2 of those), used one admin password for the whole site because only  
one person is using them (most are like this), used AuthUser for  
sites with a limited number of users, or AuthUserDBase for large  
multi-user self-registration websites (similepedia.com).  You can try  
it out at http://similepedia.com/index.php/Main/AccountInfo --  
registration is free and easy :)  You can change your information,  
request a password change, etc.  If you want to thank the site owner,  
open up Moby Dick and add the first simile you come across to his  
database.  He'll be thrilled to get a contribution :)

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] using PTVs as shortcuts for conditionals

[Crisses]

On May 29, 2007, at 5:41 PM, Ben Stallings wrote:

 Ben Stallings wrote:
 (:flag: yes:)

 so that rather than testing conditions 1 through 4 over and over  
 again I
 could just test for

 (:if equal {$:flag} yes:)

 ... but it doesn't work.

 Found the problem, I think... the tests in question are in a
 GroupHeader, and page text variables defined in a GroupHeader do not
 appear to be available unless you specify the full name of the page  
 each
 time, in this case {Events/GroupHeader$:flag}.  Is this a feature or a
 bug?  --Ben

Feature -- {$:flag} is set to create its definition on the INCLUDING  
page, only for the auto-included features such as GroupHeader/ 
GroupFooter.  This is so we don't always have to do {*$:flag} in what  
are automatically included pages.  Thus {$Name} will always be  
PageName not GroupHeader.

I'm not sure what you're doing, so I can't recommend a solution

Crisses



___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] PTVs in a URL

[Crisses]

On May 29, 2007, at 5:48 PM, Jon Haupt wrote:

 On 5/29/07, Jon Haupt [EMAIL PROTECTED] wrote:
 Would it be possible to use a page text variable in a URL?  In
 particular, I would like to construct an RSS feed link that returns
 only pages that satisfy a PTV.  Like this:

 http://whatever.com/pmwiki/Main/HomePage?action=rss; 
 $:YourVariable=1count=5

 This doesn't seem to work.  Am I missing something, or is it just not
 configured to work this way yet/ever?

 Jon Haupt

 Also, this doesn't work either:
 http://whatever.com/pmwiki/Main/HomePage?action=rss%24% 
 3AYourVariable=1count=5

 Jon

What I do is pull up the search/pagelist feature on the site, and  
play with it until I have a URL that gives me the results I wanted.   
I think you could then change action=rss instead of action=search to  
make it an RSS feed list.

So for your answer, study search/pagelist documentation and that  
should help.  I think you may be missing brackets, etc.  but I would  
let pmwiki do the grunt work :)

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] registration form

[Crisses]

On May 28, 2007, at 10:24 AM, Patrick R. Michaud wrote:

 On Mon, May 28, 2007 at 10:18:07AM -0400, Crisses wrote:
 So I would recommend PmWiki/AuthUser and I wrote up a quickstart for
 AuthUser at http://pmwiki.org/wiki/Cookbook/QuickStartForAuthUser
 which helps you lock down your entire website from editing, and fills
 in the missing how-to where the PmWiki/AuthUser page describes the
 theory rather than the use itself.

 FWIW, I would _much_ prefer that the PmWiki.AuthUser be more of a
 how-to document than a theory document.  Please feel free to
 improve it.

Then let's get feedback on what I did.  Mine is specifically a how-to- 
lock-the-site-down, which is different than a how-to on general  
use...having the generic documentation is very useful as well, so  
maybe there should be a bunch of HowTos in the documentation attached  
to the theory/documentation of a feature.

For example:
lockdown for a one-password private-edit-only site (this can be  
config.php alone)
lockdown the admin for an open-edit site (this can be config.php alone)
lockdown for a closed-edit site (this is what I think I did in my  
Cookbook/QuickStartForAuthUser)
etc.

With PmForm, hopefully we'll be able to handle what AuthUserDBase  
does without the need for a database -- that's to say that people can  
register to the site, choose their password, get an email  
verification, can change their password/email on the website, etc.   
Some websites only require that users register, not that they be  
specifically known to the admins or go through an approval process.

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Pagelist for Page Text Variables

[Crisses]

On May 4, 2007, at 12:19 PM, Patrick R. Michaud wrote:

 On Fri, May 04, 2007 at 11:19:49AM -0400, Ben Wilson wrote:
 I wonder how to display a list of pages where a page text variable
 contains a value:

 (PAGE)
 Things: this, that, other
 (/PAGE)

 (:pagelist $:Things=this:)

 At the moment, the best one can do is

 (:pagelist $:Things=*this* :)

 Pm

One day we'll probably need to create arrayswhich could be as  
little as trim(items in that PTV appearing between commas)


Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] OT: Telemarketers without a Clue

[Crisses]

On May 1, 2007, at 12:30 PM, Sandy wrote:


 Damn. I wish he'd stayed on longer. I wanted to learn more about the
 competition.

Doesn't sound like competition to me :)

Criss(es) Ittermann
Owner  Head (read: only) Designer  Web Administrator
Eclectic Tech, LLC

;)



___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] OT: Telemarketers without a Clue

[Crisses]

On May 2, 2007, at 1:20 PM, [EMAIL PROTECTED] wrote:

 Em Quarta 02 Maio 2007 07:35, Crisses escreveu:

 This is completly OT, but I have to say this.

 Criss, I saw your presentation on PmWiki at your website and I  
 really liked
 the french accent. Maybe you could do a series with different  
 accents, that
 would be a lot of fun, and I believe, good for business .


 I'm not joking or kidding, I really liked it.

 CarlosAB

Thanks Carlos.

He's referring to http://www.eclectictech.net/wiki/Listen/ 
LiberateYourWebsite1 (YouTube: Flash required)

I've already considered that.  I could do a few types of Brooklyn  
accent (Canarsie (think Edith Bunker) or JAP (Jewish American  
Princess) and Mobster come to mind), the Surfer Girl accent, and the  
American Southern Belle

It would certainly be more fun to create than dry boring  
presentations ;)

I'll give it some thought.  I need inspiration for the actual content  
rather than the accents ;)

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Recipe stability (was: Why all this zapping?)

[Crisses]

On May 2, 2007, at 9:50 AM, Sandy wrote:

 Endorsements is a good word. One of the reasons I joined this list was
 to get a feel for the contributors, but that's a luxury many new users
 don't have. They'd still have to get a feel for the endorsers, but  
 more
 names means more chance of recognizing one.

 Let's make one thing clear:

 A proper evaluation of a recipe involving security or private data can
 take several hours of a senior programmer's time, and setting up
 examples and explaining them takes even more time, time that could be
 spent paying the rent. It's frustrating to be told little more  
 than, It
 won't work, but, no matter how friendly and helpful the community,
 there will always be recipes that don't get evaluated, simply  
 because no
 expert has that much time to invest in a recipe they don't expect  
 to use.

You said it better than I did.  Thank you.

Although I tried to say something like this, I also tried to add in  
that not every great developer is a great hacker -- it takes a  
different method of thinking.  On that note, we could hire a group of  
people who do this in their spare time from more shady walks of life,  
but the donations need to be pouring in for that, and from what I  
hear there's not much financial backing for PmWiki.

So, it would be great in theory.  In practice, I think it's one of  
those well-meant suggestions that just won't get the time and energy  
support it needs to work, and to be kept up-to-date.  For one thing,  
no matter how important it is, it lacks in the fun and  
recognition departments that are the motivations for much of the  
developer community behind these projects.  If the security team  
got big headlines, kudos, pizza, and ticker-tape parades, it might work.

Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] [humor] Re: ZAP and fun with forms

[Crisses]

On Apr 21, 2007, at 12:53 AM, Dr Fred C wrote:


Pmwiki has PITS, which covers features, bugs, cookbooks, and more.
Perhaps Zap should have ZITS... :)   , with the goal of promoting more
blemish free development towards usable utilitarian ACME like  
goals.  :-o


Wouldn't that be Acne-like goals? :)

Crisses___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] ZAP and fun with forms

[Crisses]

On Apr 20, 2007, at 9:24 AM, Patrick R. Michaud wrote:


I'm wondering if Pm, or any current ZAP users have input on the
direction ZAP should pursue?


Since ZAP's goals are somewhat different from mine, I don't have
any real recommendations.  None of the code that I've been  
implementing

should have any direct negative impact on ZAP.


Sometimes (not all the time) the only reason I'm using ZAP is to save  
data.  I will be happy when it is core.


For some things, ZAP is quite interesting.  I could use to explore  
more features, and will probably need to do so.


What I think happens is that ZAP moves away from saving data on  
pages, but uses the savedata only when needed (when saving to  
multiple pages), and keeps the current ZAP authentication methods for  
those special directives (since they're not moving into the core).


Crisses___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Ideas for PIM, GTD (Getting Things Done)

[Crisses]

On Mar 6, 2007, at 5:16 PM, Sandy wrote:


Given the popularity, I Googled PmWiki and GTD.
http://www.gtd-php.com/Profiles/Crisses . (I recognize the wiki  
engine!)





GTD-PHP is the other open-source project I'm on

 :)

I was considering whether to merge the projects with one as a plug-in  
for the other, or to borrow the PmWiki markup for the text entries on  
GTD-PHP, but that would be over the longer term.


Their use of PmWiki for documentation was one reason I joined the  
project.  Obviously, they must be very sensible people  ;)


I've considered PmWiki for GTD implementation, but it would really  
have to be similar to GTD-PHP for me to adopt it -- I'll take a look  
at it soon...


Crisses

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[pmwiki-users] Bugfix to AuthUserDbase 2.x

[Crisses]

I just had someone report a bug to AuthUserDbase that doesn't allow  
users to recover their login after losing their password.  Fixed   
uploaded AuthUserDbase v2.0.1.


It's recommended that people upgrade if they're using 2.0.0


Crisses
--
You know, I better find the person(s) I'm going to settle down with  
for the rest of my life very soon; it's taking too long just to  
explain the absolute essentials that people need to know just to date  
me.  Pretty soon people are going to have to pass 3 preliminary  
interviews including their ability to multitask, their willingness to  
read my website and their ability to spend hours and hours listening  
to crap about me, after which they'll be required to RTFM and pass an  
independently proctored entrance exam.


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users