Re: [pmwiki-users] pmwiki on github

[Patrick R. Michaud]

I've been mulling the idea of switching PmWiki source to GitHub, but
haven't had the time to really work on it.  (Doing so involves more than simply
porting the sources over, but also redesigning our release toolchain.)

I may have time this summer to look into that effort.  In the meantime,
Subversion continues to meet our needs adequately so we're still there.

Pm

On Sat, May 15, 2021 at 05:31:48PM +0200, Petko Yotov wrote:
> On 15/05/2021 17:16, j...@dodin.org wrote:
> > However, I can add any application, given I can provide an url like
> > this:
> > 
> > http://:some.git.forge.tld:USER/REPO
> 
> For code versioning, we use Apache Subversion, not git.
> 
> Check if they can pull PmWiki from our subversion repository. You'll find
> the address at PmWiki/Subversion.
> 
> > I'm not fluent about github, but somehow I will have to learn :-(
> > 
> > I found this:
> > 
> > https://github.com/walkingice/pmwiki
> > 
> > is this a usable pmwiki instance? is there a better one?
> 
> It says on that page it is from 11 years ago. It may be usable if your PHP
> version is similarly old, and if you run it in read-only mode, as in,
> filesystem read-only. (There have been a number of vulnerabilities found and
> closed since then.)
> 
> Petko
> 
> -- 
> If you upgrade :  http://www.pmwiki.org/Upgrades
> 
> ___
> 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] page blank

[Patrick R. Michaud]

What version of PmWiki are you running?  Perhaps an upgrade will fix it.

What version of PHP do you have now?

See also http://www.pmwiki.org/wiki/PmWiki/Troubleshooting , especially 
http://www.pmwiki.org/PmWiki/Troubleshooting#blank_sections .  It may have some 
useful information there.

Pm

> Hi all
> 
> My wiki in aprendendofisica.pro.br is with all pages blank. all pages stay
> in wiki.d but nothing is showed.
> 
> PHP was upgraded in server!
> 
> Any direction?
> 
> Thanks
> 
> Sérgio Lima
> 
> ___
> 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] SSL Migration & Coexistance etc.

[Patrick R. Michaud]

On Sun, Jun 04, 2017 at 04:35:58PM +0200, Walter Keller wrote:
> $PubDirUrl = 'http://www.mydomain.com/path/to/pub';
>===> $PubDirUrl = '//www.mydomain.com/path/to/pub';
> By the definition of URIs, the browser use http: or https: as in the
> current request and everything works like a charme.
> 
> (1) I propose to change sample-config.php accordingly - or can anybody
> see a disadvantage here?

1a.  Historically, some browsers and web consumers don't properly handle the 
'//...' link format.  Yes, technically such browsers are out of specification, 
but "your browser is out of spec" isn't exactly the message many sites want to 
be transmitting to their visitors.  And desktop browsers aren't the only 
consumers of web content -- we also have reader apps on smart phones, search 
engine spiders, site analysis tools, etc.

PmWiki strives to follow a "strict in what it produces, liberal in what it 
accepts" philosophy.  The "strict" part of that implies that any urls we 
produce really ought to be as complete as possible.

1b.  There are a number of sites recommending against relative URLs:
https://jeremywagner.me/blog/stop-using-the-protocol-relative-url
https://www.paulirish.com/2010/the-protocol-relative-url/

http://www.dirigodev.com/blog/seo-web-best-practices/relative-vs-absolute-urls-seo/
https://moz.com/blog/relative-vs-absolute-urls-whiteboard-friday

1c.  The sample-config.php file serves several purposes; one of them is to help 
get things up and running quickly, and another is to educate.  A lot of 
newcomers aren't going to be familiar with the nuances of relative-scheme URLs, 
and are likelier to be confused upon seeing a "url" that doesn't include a 
scheme.  They might not even recognize it as a url.  In the interest of keeping 
sample-config.php as accessible to newcomers as possible, I'd prefer it to 
continue to use the full url.

So, while I completely recognize the value of relative-scheme urls, I think its 
usage belongs in cookbook or discussion and not something that is considered a 
best default practice.  I totally accept that others' may have different views 
on this.

> (3) while integrating the newest sample-config.php, I had to change
>  include_once("scripts/xlpage-utf-8.php");
> ==>  include_once("$FarmD/scripts/xlpage-utf-8.php");
>I guess this is necessary for every wikifarm and should
>be changed in sample-config.php

Again, sample-config.php's intended audience has traditionally been 
newcomers... and I really didn't want to burden a newcomer with "What's this 
$FarmD variable used for?!" when they're unlikely to be using a farm anyway for 
their initial setup.  If this change is made, it'd be the _only_ reference to 
$FarmD (or farming) inside of sample-config.php.  I think I'd rather keep the 
simplicity for now... someone who is building a WikiFarm will be able to figure 
out the need for $FarmD pretty quickly I think.  (Perhaps your experience here 
was otherwise.)

Thanks for the excellent suggestions and analysis!

Pm

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

Re: [pmwiki-users] https with PmWiki

[Patrick R. Michaud]

PmWiki *already* responds properly to https: requests -- it detects when a 
request comes in via HTTPS and converts its outgoing links accordingly.  This 
doesn't need a new variable.

If you want to force all pmwiki-links to use https, then update $ScriptUrl 
accordingly:

   $ScriptUrl = 'https://www.mydomain.com/path/to/pmwiki.php';

Chances are that a site is already setting $ScriptUrl in the local/config.php 
anyway -- it's one of the first things mentioned in docs/sample-config.php, and 
in the initial setup task documents.

I'd be fine with updating docs/sample-config.php to include something like:

   # If you prefer HTTPS over HTTP linkages:
   # $UrlScheme = 'https';
   # $ScriptUrl = 'https://www.mydomain.com/path/to/pmwiki.php';
   # $PubDirUrl = 'https://www.mydomain.com/path/to/pub';

And yes, it makes sense to have this information in the standard PmWiki 
documentation as well.  I suggest it can go into 
http://www.pmwiki.org/wiki/PmWiki/InitialSetupTasks , e.g. in the part that 
mentions setting up $ScriptUrl and $PubDirUrl .  Or it can go into 
http://www.pmwiki.org/wiki/PmWiki/Security .  Or both.

If you want to have PmWiki automatically redirect incoming HTTP requests to be 
a HTTPS request... that sounds recipe-ish to me.  And it's much more efficient 
for it to be handled at the webserver level anyway (e.g., vi .htaccess, 
Redirect, etc.)

Pm

On Tue, May 30, 2017 at 05:19:54PM -0400, Peter Kay wrote:
> Perhaps
> 
> $forcehttps=1;
> or
> $requirehttps=1;
> 
> On Tue, May 30, 2017 at 6:11 AM, Simon  wrote:
> > Good idea,
> > having now addressed the mobile friendly issue (i.e. getting google to give
> > your website credence) I agree that pmwiki.org.should move to https for
> > better google ranking and importantly
> > I'd like to see a PmWiki (rather than cookbook) documentation page on this
> > subject, and also an OOTB option (e.g. a config.php setting
> > [$enablehttps=1;]) for installing PmWiki with HTTPS enabled
> >
> > thanks
> > Simon
> >
> > 
> > http://kiwiwiki.nz
> >
> > On 30 May 2017 at 01:03, Thomas Lundgren  wrote:
> >>
> >> It´s seems that the era of http soon will end and https will (continue) to
> >> live long and prosper...
> >>
> >> When looking for how to make my PmWiki-installations more prosper and
> >> serve pages with ssl/https i found this page;
> >>
> >> http://www.pmwiki.org/wiki/Cookbook/SwitchToSSLMode
> >>
> >> The tips and instructions on that page are rather old. Are they still
> >> valid and "best practice" or are there any new tips and information that I
> >> can use?
> >>
> >> My installations contains a standard PmWiki (with some cookbooks...),
> >> Apache running on a FreeBSD-server that I have total control over.
> >>
> >> Thank you!
> >>
> >> Best regards,
> >> / Thomas.
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> 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 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] On the order of Markup

[Patrick R. Michaud]

On Thu, Mar 23, 2017 at 11:21:06AM -0400, Peter Kay wrote:
> textvar:   ><
> nl0  ><
> Sidebar  ><
> input+sp ><
> nl1  >nl0 B>><>
> [...]
> I am wondering:
> 
> Is there any particular benefit to this non-intuitive approach to
> ordering markup?  A tree structure strikes me as the more intuitive
> way to order things, with each node having "before" and "after"
> branches.  Then MarkupToHTML can traverse the tree and "nl1" will
> happen immediately after "nl0".

Technically speaking, PmWiki *is* using a tree structure for ordering --
it's just not a binary tree.  The <'s and >'s are specifying ordering, 
and it's always possible to insert nodes before or after an existing one.

The problem with a strictly binary tree structure (as described with
"each node having 'before' and 'after' branches") is that it's not
precisely clear what to do when you need to insert something "before" a node
that already has a "before" branch.  

For example, if we have a node 'B' that already has 'A' before and 
'C' after, and we have a rule that needs to go before 'B', it's not
entirely correct to simply assume that it should go after 'A'... 
especially if "A" was supplied by a recipe that also assumes it
will be happening immediately before "B".  And PmWiki can't know
the necessary ordering in advance, since these are coming from
recipes, and I didn't want the order in which recipes are included
to be the driving factor of markup rule order.

So, the approach PmWiki takes is to enable recipes to specify
whatever level of detail is necessary for ordering.  If you specify 
"http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] quoted text markup

[Patrick R. Michaud]

I think I'd prefer this as a recipe (or an addition to an existing recipe) 
rather than core for now.  

I'm concerned a change to core might match code display segments where a single 
"" represents an empty string.

I also don't know how widely this feature would be used; I suspect most people 
will still end up writing "This is a quote" rather than ""This is a quote"".

I'm open to be convinced otherwise, however.

Pm


On Tue, Sep 20, 2016 at 12:55:12PM +0100, Hans wrote:
> Hi, I was wondering what your thoughts may be on a new markup
> for quoted text.
> 
> HTML offers the use of quoted text
> which browsers display as text surrounded by a left and a right double
> quote.
> 
> I  was thinking a markup of ""quoted text"" may be useful for that,
> easy to write and to remember, inline text surrounded by two double
> quotes. It certainly beats the use of “quoted text”
> 
> ## ""quote""
> Markup("\"\"","inline","/\"\"(.*?)\"\"/",'$1');
>   
> Any thoughts pro or against? Could this be added to the core?
> 
> 
> Best regards,
>  Hans  
> mailto:desi...@softflow.uk
> www.softflow.co.uk
> 
> 
> ___
> 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] PS Embeded Web Address Characters -

[Patrick R. Michaud]

To me, this looks like a bug (or missing feature) in the IncludeSite recipe.

Pm

On Sat, Sep 10, 2016 at 04:31:45PM -0700, Kirk Siqveland wrote:
> Addendum:
> 
> The Code:
> This works fine
> (:includeSite http://en.wikipedia.org/wiki/Nikola_Tesla?printable=yes:)
> 
> but this does not
> (:includeSite https://en.wikipedia.org/wiki/Nikola_Tesla?printable=yes:)
> 
> Nor does this
> (:includeSite
> http://en.wikipedia.org/wiki/Stephen_Gray_(scientist)?printable=yes:)
> 
> On 9/10/2016 4:07 PM, Kirk Siqveland wrote:
> >Hi All,
> >
> >I have been building a site in which I am sometimes embedding other pages,
> >particularly Wikipedia.
> >Sometimes those URL's include parenthesis  e.g.:
> >https://en.wikipedia.org/wiki/Stephen_Gray_(scientist)
> >
> >
> >The code to do this works nicely on other pages, but not in this case.  Is
> >there some way to correct for links that include Parens...?
> >And while we are at it, how about allowing https as well as http?
> >
> >Thanks,
> >
> >Kirk
> >   Siqveland
> >
> >Two Main sites manged with PMwiki:
> >http://www.technites.wiki/pmwiki.php
> >(I'm working on this one, but have not "launched" it yet so please do not
> >link or discuss it publicly)
> >
> >and
> >
> >http://www.steam-age.net/
> >- in my spare time, I have been tweaking the skin for this and will add it
> >to the collection for everyone else to use pretty soon...
> >
> >___
> >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 mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Upload protection not working

[Patrick R. Michaud]

I'm a bit stumped.

Grasping at some straws:

1.  Change the name of "directors.jpg" to something else and see if
that fixes anything.  (Perhaps the url result itself has been cached 
somewhere?  I've had this happen to me and then spent hours/days trying 
to figure it out, when it turned out my ISP was caching things and
ignoring cache-control headers.)

2.  farmconfig.php ?

3.  Try a different group and page and see if the problem persists ?

4.  Try a fresh pmwiki.php install, with only the upload-related variables set?

Pm


On Mon, Jun 06, 2016 at 06:23:36PM -0500, c...@endlessnow.com wrote:
>If I remove the download parm I get the login page.  I don't have any
>other php involved.
>Sent on the new Sprint Network
>- Reply message -
>From: "Patrick R. Michaud" 
>To: 
>Cc: 
>Subject: [pmwiki-users] Upload protection not working
>Date: Mon, Jun 6, 2016 6:14 PM
> 
> Out of curiosity, what happens if you attempt to access the page
> via incognito mode or equivalent?  I'm wondering if somehow you're
> obtaining authorization through another path... e.g., perhaps an
> admin authorization that has been cached somewhere.
> 
> Also, what happens if you remove the "?action=download" portion?
> Do you get something denying immediate access to the Test/Directors
> page (e.g., an authentication prompt), or do you see the page itself?
> If the latter, then authorization isn't being blocked for some reason
> unrelated to uploads/downloads.
> 
> Lastly, is there anything the Test.php (group config) that might be
> throwing off the authorization stuff?
> 
> Pm
> 
> 
> 
> On Mon, Jun 06, 2016 at 05:46:30PM -0500, c...@endlessnow.com wrote:
> > So I stripped out AuthUser as well and set a simple password on page and I
> > can still get to the attachment using:
> >
> > [1]https://www.example.com/Test/Directors?action=download&upname=directors.jpg
> >
> > My config.php attached.
> >
> >
> > > I've stripped my config.php down to just my AuthUser ldap stuff.. with per
> > > page uploads defined and I can get to the attachment even though I don't
> > > have read permissions for the page.
> > >
> > >
> > > I know it's asking a lot, but is it possible to do a test with AuthUser
> > > involved?  I'm using ldap but I know that's probably harder to do.
> > >
> > > Let me know if you want my config.php (devoid of comments), etc.
> > >
> > >
> > >> It works as expected on pmwiki.org:
> > >>
> > >>
> > >> [2]http://www.pmwiki.org/wiki/TestProtected/TestProtected?action=download&u
> pname=pmwiki-32.gif
> > >>
> > >> If you have per-group uploads and want to protect a file, there is no
> > >> interest to protect a single page - a visitor can download the file from
> > >> another, unprotected page. In this case PmWiki will require "read"
> > >> permissions for the whole group, which you set in
> > >> GroupAttributes?action=attr.
> > >>
> > >> If you have per-page uploads, PmWiki requires "read" permissions for the
> > >> page.
> > >>
> > >> "upload" permissions are only required for people to upload files, not
> > >> to download them. To download them they need "read" permissions.
> > >>
> > >> Petko
> > >>
> > >> ---
> > >> Change log :  [3]http://www.pmwiki.org/wiki/PmWiki/ChangeLog
> > >> Release notes  :  [4]http://www.pmwiki.org/wiki/PmWiki/ReleaseNotes
> > >> If you upgrade :  [5]http://www.pmwiki.org/wiki/PmWiki/Upgrades
> > >>
> > >>
> > >> On 2016-06-06 21:44, c...@endlessnow.com wrote:
> > >>> Consider the following url.  I have direct downloads disable and
> > >>> htaccess
> > >>> is blocking the uploads area.  So, attachments to get translated like
> > >>> so:
> > >>>
> > >>> [6]https://www.example.com/Test/Directors?action=download&upname=directors
> .jpg
> > >>>
> > >>> However, I have protected read, edit, attr and upload for the page
> > >>> Test/Directors.. and I can still get to the content.
> > >>>
> > >>> Do I have to protect the group instead?  Perhaps I need to go to per
> > >>> page
> > >>> uploads? Would that fix things?
> > >>
> > >> ___

Re: [pmwiki-users] Upload protection not working

[Patrick R. Michaud]

Out of curiosity, what happens if you attempt to access the page
via incognito mode or equivalent?  I'm wondering if somehow you're
obtaining authorization through another path... e.g., perhaps an 
admin authorization that has been cached somewhere.

Also, what happens if you remove the "?action=download" portion?
Do you get something denying immediate access to the Test/Directors
page (e.g., an authentication prompt), or do you see the page itself?
If the latter, then authorization isn't being blocked for some reason
unrelated to uploads/downloads.

Lastly, is there anything the Test.php (group config) that might be
throwing off the authorization stuff?

Pm



On Mon, Jun 06, 2016 at 05:46:30PM -0500, c...@endlessnow.com wrote:
> So I stripped out AuthUser as well and set a simple password on page and I
> can still get to the attachment using:
> 
> https://www.example.com/Test/Directors?action=download&upname=directors.jpg
> 
> My config.php attached.
> 
> 
> > I've stripped my config.php down to just my AuthUser ldap stuff.. with per
> > page uploads defined and I can get to the attachment even though I don't
> > have read permissions for the page.
> >
> >
> > I know it's asking a lot, but is it possible to do a test with AuthUser
> > involved?  I'm using ldap but I know that's probably harder to do.
> >
> > Let me know if you want my config.php (devoid of comments), etc.
> >
> >
> >> It works as expected on pmwiki.org:
> >>
> >>
> >> http://www.pmwiki.org/wiki/TestProtected/TestProtected?action=download&upname=pmwiki-32.gif
> >>
> >> If you have per-group uploads and want to protect a file, there is no
> >> interest to protect a single page - a visitor can download the file from
> >> another, unprotected page. In this case PmWiki will require "read"
> >> permissions for the whole group, which you set in
> >> GroupAttributes?action=attr.
> >>
> >> If you have per-page uploads, PmWiki requires "read" permissions for the
> >> page.
> >>
> >> "upload" permissions are only required for people to upload files, not
> >> to download them. To download them they need "read" permissions.
> >>
> >> Petko
> >>
> >> ---
> >> Change log :  http://www.pmwiki.org/wiki/PmWiki/ChangeLog
> >> Release notes  :  http://www.pmwiki.org/wiki/PmWiki/ReleaseNotes
> >> If you upgrade :  http://www.pmwiki.org/wiki/PmWiki/Upgrades
> >>
> >>
> >> On 2016-06-06 21:44, c...@endlessnow.com wrote:
> >>> Consider the following url.  I have direct downloads disable and
> >>> htaccess
> >>> is blocking the uploads area.  So, attachments to get translated like
> >>> so:
> >>>
> >>> https://www.example.com/Test/Directors?action=download&upname=directors.jpg
> >>>
> >>> However, I have protected read, edit, attr and upload for the page
> >>> Test/Directors.. and I can still get to the content.
> >>>
> >>> Do I have to protect the group instead?  Perhaps I need to go to per
> >>> page
> >>> uploads? Would that fix things?
> >>
> >> ___
> >> 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
> >

> $WikiTitle = 'Agora';
> $ScriptUrl = 'https://'.$_SERVER['HTTP_HOST'];
> $PubDirUrl = 'https://'.$_SERVER['HTTP_HOST'].'/pmwiki/pub';
> $EnablePathInfo = 1;
> $PageLogoUrl = "$PubDirUrl/skins/pmwiki/skopos-small.png";
> $DefaultPasswords['admin'] = array(pmcrypt('secret'), '@admins');
> $HandleAuth['diff'] = 'edit';
> $DefaultPasswords['edit'] = 'id:*';
> $Author = $AuthId;
> include_once("scripts/xlpage-utf-8.php");
> $EnableGUIButtons = 1;
> include_once("scripts/creole.php");
> $EnableUpload = 1;
> $DefaultPasswords['upload'] = 'id:*';
> $EnableDirectDownload=0; 
> $EnableUploadGroupAuth=1;
> $UploadPrefixFmt = '/$Group/$Name';
> $EnablePageListProtect = 1;
> if ($action == 'refcount') include_once("scripts/refcount.php");
> if ($action == 'rss')  include_once("scripts/feeds.php");  # RSS 2.0
> if ($action == 'atom') include_once("scripts/feeds.php");  # Atom 1.0
> if ($action == 'dc')   include_once("scripts/feeds.php");  # Dublin Core
> if ($action == 'rdf')  include_once("scripts/feeds.php");  # RSS 1.0
> $AutoCreate['/^Category\\./'] = array('ctime' => $Now);
> Markup("'~", "inline", "/'~(.*?)~'/", "$1");# '~italic~'
> Markup("'*", "inline", "/'\\*(.*?)\\*'/", "$1");# '*bold*'

> ___
> 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] Issue with blocklist regex (for /\bcialis\b/), blocking word spécialisé

[Patrick R. Michaud]

On Tue, May 03, 2016 at 01:16:37AM +0200, ABClf wrote:
> Hello,
> 
> Not a big issue, but a strange one : my blocklist has an entry copied
> from PmWiki's :
> 
> block:/\bcialis\b/
> 
> This wrongly blocks the word "spécialisé" on my website whereas
> everything is fine in PmWiki, where "spécialisé" is allowed, as
> expected.
> (Can check the issue in www.languefrancaise/Test group).

I suspect the problem is somehow due to UTF-8 encoding.  The regular
expression engine may not be recognizing "é" as a valid word
character, so "cialis" appears to be surrounded by non-word characters
and thus matches the \b (word boundary) assertions.

I don't have an immediate answer for how to fix this one.

Pm

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

Re: [pmwiki-users] Pagelist conditional: One of two PTV not empty?

[Patrick R. Michaud]

On Sun, Feb 28, 2016 at 12:35:32PM -0600, Chuck G wrote:
> Petko Yotov <5...@5ko.fr> Wrote in message:
> > On 2016-02-27 12:55, Oliver Betz wrote:
> >> how can I get a pagelist where at least one of the PTV "foo" or "bar"
> >> are not empty?
> > 
> > If the PTV are short one-line strings, you can probably use a 
> > conditional in the pagelist template:
> > 
> > (:template each:)
> > (:if expr ! equal "{=$:PTV1}" "" && ! equal "{=$:PTV2}" "" :)
> > * {=$Fullname} has either PTV1 or PTV2 not empty.
> > (:ifend:)
> 
> I think you need OR (||), not AND (&&).

Or even avoid the junction altogether:

(:if ! equal "{=$:PTV1}{=$:PTV2}" "" :)
* {=$Fullname} has either PTV1 or PTV2 not empty.
(:ifend:)

Pm

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

Re: [pmwiki-users] Too many pmwiki.php processes

[Patrick R. Michaud]

If you haven't done so already, be sure to add 
include_once('scripts/robots.php') to your configuration file.  It does a lot 
of things to try to control robots flooding your website.  As you might guess, 
the pmwiki.org site has had to deal with robot floods as well (often thousands 
of requests per day), especially from poorly-behaved crawlers that don't obey 
the current conventions or that don't throttle themselves appropriately.

For example, here is pmwiki.org's robot-related settings in local/config.php:

  $RobotActions['diag'] = 1;
  $RobotPattern = '(?i:bot|crawler|spider)|Slurp|Teoma|ia_archiver|HTTrack|XML 
Sitemaps Generator|Yandex';
  $EnableRobotCloakActions = 1;
  
  ##  send an error to robots if the site is currently overloaded
  include_once('scripts/robots.php');
  if ($IsRobotAgent) {
$avg = file_get_contents('/proc/loadavg');
if ($avg > 5) {
  header("HTTP/1.1 500 Server Busy");
  print("Server too busy");
  exit();
}
  }

The first part is the pattern that gets used to try to identify robot crawlers 
-- any User Agent that matches this pattern is classified as a robot.  If the 
robot is requestion an action that doesn't make sense for a robot -- such as a 
request to edit a page or perform a search -- then PmWiki cuts the connection 
as quickly as it can to reduce the load on the server.

Setting $EnableRobotCloakActions to true means that PmWiki will try to strip 
out any ?action= patterns in the pages that it generates to robots.  That way 
robots are less likely to follow up with requests for ?action= links that are 
likely to be useless to the robot anyway.

The $IsRobotAgent variable is set to true if PmWiki believes it's being 
currently accessed by a robot.  On pmwiki.org, if we're being accessed by a 
robot we first check the current system load (in /proc/loadavg) and immediately 
return a "500 Server Busy" response to the robot if the system load is above 5. 
 This basically tells the robot "busy now...try again later".

Next, make sure your skin is setting appropriate rel="nofollow,noindex" 
attributes to links and in the  section of the output document.  Lots of 
rogue robots don't honor these links, but at least you'll catch the ones that 
do.

And lastly, I've found that Yahoo! Slurp has been one of the worst offenders of 
them all in terms of not playing nice with spidering, indexing pages, and 
honoring directives such as robots.txt.  I ultimately decided to block them at 
the .htaccess level altogether.

Hope this helps.  There probably needs to be a better documentation or cookbook 
page about this on PmWiki.org somewhere, if anyone is willing to draft one.

Pm



On Wed, Feb 24, 2016 at 07:23:53AM -0600, Rick Cook wrote:
> They were complaining about too many processes and claiming it was putting 
> too much load on their server.
> 
> The PmWiki sites involved are very simple with no dynamic content.
> 
> Most of the "visitors" are robots of various varieties. The most access_log 
> entries for the year so far across my whole account (~10 PmWiki sites and 2 
> WordPress sites) was about 9200 on one day. Typically, it was more like 2500 
> a day. Since this all started, I have put a more restrictive robots.txt file 
> in all of the URL roots and added 192.168 to all of the appropriate .htaccess 
> files (somehow, the non-routeable address 192.168.151.0 was one of the more 
> frequent IP addresses in my access_log files). I think it is running more 
> like 1000 per day now.
> 
> They suggested several IP addresses to block. One was the dynamic IP assigned 
> to my home connection and another was their site monitoring service. Most of 
> the other addresses were attached to well known sites like Google.
> 
> 
> Rick Cook
> 
> > On Feb 24, 2016, at 05:59, ABClf  wrote:
> > 
> > Why are they complaining : because "too many" (quantitative) or
> > because "too heavy" (your sites cannibalize the server) ?
> > 
> > Maybe you use too heavy pagelists ? What I mean is X processes doesn't
> > tell us how much cpu eager they are (printing out a simple page vs
> > building a complex page from multiparameter pagelist). How many users
> > visiting your sites in the busy hours ?
> > 
> > In that case, if possible, you might be happy with fastcache recipe.
> > That's a must have for me as I use pagelists and ptv a lot. It works
> > nicely (40 visitors on the busy hours).
> > I never delete all cached pages ; I run a cron which delete 300 oldest
> > cached pages every day.
> > 
> > I have been in trouble with my host recently, when my pageindex was
> > lost for unknown reason : hard to rebuild one, process was taking all
> > cpu for minutes. Thus they blocked my site for a few hours. (Shared
> > host, "premium option", 2 cores, 2 go ram, 20 go ssd...).
> > 
> > My host didn't give me useful informations I can read to try to
> > understand what was going wrong ; just told me : run htop to see the
> > processes and cpu/memory usage.
> > 
> > Gilles.
> > 
> > 2016

Re: [pmwiki-users] Insert meta tag in

[Patrick R. Michaud]

On Wed, Feb 10, 2016 at 07:34:35PM +0100, Thomas Lundgren wrote:
> I´ve made a cookbook from where I will share the page to Facebook. To be
> more sure that Facebook grabs the page correct Facebook "require" some meta
> tags in the -part of the html-page.
> 
> How do I - from a cookbook insert meta tags into the -part? Do I in
> some way have to alter the skin? How?

See the $HTMLHeaderFmt variable.  
http://www.pmwiki.org/wiki/PmWiki/LayoutVariables#HTMLHeaderFmt

This allows a recipe to insert custom tags in the ... section of 
the output.

Pm

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

Re: [pmwiki-users] Disappearing backslashes?

[Patrick R. Michaud]

I just tried this in the WikiSandbox on pmwiki.org and the following
appears to work fine:

[@
openssl pkcs12 -export -in certificate.crt -inkey private.key \
 -certfile int.pem -out certificate.pkcs12
@]

I'm guessing there may be a recipe or local customization on your site
that is causing the backslashes to disappear.

Pm

On Tue, Jan 26, 2016 at 04:17:51PM +, Steve Glover wrote:
> Hi,
> 
> A colleague is trying to include an example command line in a page, thus:
> 
> [@
>  openssl pkcs12 -export -in certificate.crt -inkey private.key -certfile
> int.pem -out certificate.pkcs12
> @]
> 
> Unfortunately, the command is too long to display without running off the
> right-hand side of the allowable text area.
> 
> The traditional way to break such a line, and indicate to the reader that
> the linebreak is not meant to be there is to finish the first line with a
> backslash, thus:
> 
> [@
> openssl pkcs12 -export -in certificate.crt -inkey private.key \
>  -certfile int.pem -out certificate.pkcs12
> @]
> 
> However, if you try this, not only does the backslash not render, but
> returning to the edit window reveals it has actually disappeared from the
> page text.
> 
> Doubling the backslash works, sort of, but the next time the page is saved,
> it disappears again, leaving a single backslash in the text, which then
> disappears on the next edit
> 
> I suggested using \, but the [@ ... @] stops that from rendering.
> 
> I did manage to find a previous example in the mailing list
> 
> http://pmichaud.com/pipermail/pmwiki-users/2007-April/041255.html
> 
> but the fixes there don't work. I'm guessing that part of PmWiki or PHP has
> changed since then.
> 
> Any ideas, please?
> 
> Thanks
> 
> Steve
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users

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

Re: [pmwiki-users] Allow only one IP range at specific page.

[Patrick R. Michaud]

The Blocklist is probably not the answer you're looking for -- it's intended to 
prevent sites from _writing_ to pages, not to prevent them from being viewed.

I think you're probably looking for http://www.pmwiki.org/wiki/Cookbook/AuthDNS 
.


It's also possible to do per-page customizations -- see 
http://www.pmwiki.org/wiki/PmWiki/GroupCustomizations .  For example, if you 
want something to be done only on page ABC.XYZ, you can create a file 
local/ABC.XYZ.php that has things to be done only on that page.  However, 
per-page customization isn't a good approach for securing access to pages, 
since an author can always do (:include ABC.XYZ:) from another page and access 
the contents that way.

I think your best bet is the AuthDNS recipe mentioned above.  You would define 
a IP address (or range) as belonging to a given authentication group, and then 
you can use the standard PmWiki password-protection tools on a page to restrict 
access to that authgroup.

Hope this helps,

Pm


On Tue, Nov 17, 2015 at 03:04:48PM +, Brian Tibbels wrote:
> There is no example of $BlocklistPages but I'm sure it holds the key.
> http://www.pmwiki.org/wiki/PmWiki/Blocklist#BlocklistPages
> 
> 
> *Brian Tibbels*
> *IT support for small business and the individual*
> http://clickmarlow.co.uk/
> *m*: 07804 109906* | t*: 01628 477640
> 
> 
> On 17 November 2015 at 14:59, James Almeida  wrote:
> 
> > Thank you for the answer Gilles,
> >
> > But from what I saw it still seem wiki wide, and not page wide.
> > Maybe I will have to sync the PmWiki with the LDAP server and require
> > login to view.
> > I am just reading the docs to find out how to use the LDAP groups in the
> > PmWiki.
> >
> >
> > On Tue, Nov 17, 2015 at 2:26 PM, ABClf  wrote:
> >
> >> Try the whitelist solution on this page
> >> http://www.pmwiki.org/wiki/PmWiki/Security
> >>
> >> Gilles.
> >> Le 17 nov. 2015 18:01, "James Almeida"  a écrit :
> >>
> >>> Hello PmWiki users,
> >>>
> >>> I need to only one ip range in an specific page of a wiki. Is that
> >>> possible?
> >>>
> >>> Its a research group wiki. I need to do that to allow viewers within the
> >>> university to access the list of available projects, but not anyone 
> >>> outside
> >>> the university, due to IP concerns.
> >>> I read about the Blocklist implemented in the PmWiki, but it seems to be
> >>> wiki-wide, and not for specific page.
> >>>
> >>> Thank you for your attention!
> >>> --
> >>> _
> >>>  Dr. James Moraes de Almeida
> >>>  Postdoctoral researcher at Theory and Simulation of Materials (THEOS).
> >>>  École Polytechnique Fédérale de Lausanne (EPFL).
> >>>  Direct: +41 21 693 1126
> >>> *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> >>> *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> >>> *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> >>>
> >>> ___
> >>> pmwiki-users mailing list
> >>> pmwiki-users@pmichaud.com
> >>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
> >>>
> >>>
> >
> >
> > --
> > _
> >  Dr. James Moraes de Almeida
> >  Postdoctoral researcher at Theory and Simulation of Materials (THEOS).
> >  École Polytechnique Fédérale de Lausanne (EPFL).
> >  Direct: +41 21 693 1126
> > *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> > *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> > *¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯**¯*
> >
> > ___
> > 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 mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] after update - unable to edit

[Patrick R. Michaud]

When you went to the pmwiki.php page, did PmWiki give you the default
home page or did it give you instructions for creating wiki.d ?

Normally PmWiki will create wiki.d for you, or it will tell you what
needs to be changed in order to create it.

You might also need to temporarily rename local/config.php to something
else in case there are any recipes that are affecting normal startup.

Pm


On Tue, Oct 20, 2015 at 09:30:03PM +0200, Wolf Drechsel wrote:
> Hello, thanks for the quick reply.
> 
> I renamed the wiki.d dir into wiki.d-backup - then went to a browser 
> and called my site http://mydomain.com/pmwiki/pmwiki.php (guess, this 
> was meant by "run PmWiki").
> 
> But no wiki.d directory is created after that. Permissions of the 
> pmwiki dir is 755.
> 
> What shall I do?
> 
> Wolf
> 
> 
> 
> > Another (possibly simpler) approach to try is to rename "wiki.d" to 
> > "wiki.d-backup", run PmWiki to let it create a new "wiki.d" 
> > directory,
> > then copy the files from wiki.d-backup into wiki.d .  (I suggest 
> > doing
> > a copy instead of a move so you still have the originals lying 
> > around.)
> > 
> > In most PHP environments, it's the permissions of the wiki.d 
> > directory 
> > itself that matters for updating, and not the permissions of the 
> > files
> > within the wiki.d directory.
> > 
> > Pm
> > 
> > ___
> > 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 mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] after update - unable to edit

[Patrick R. Michaud]

On Tue, Oct 20, 2015 at 11:21:08AM +0200, Petko Yotov wrote:
> Another way to check the permissions is to let PmWiki create a directory and
> a file. Rename "wiki.d" on the server to another name, say "renamed-wiki.d",
> then PmWiki will create a new 'wiki.d' and will add files in it. Visit the
> wiki in your browser and make a few edits, like HomePage and WikiSandbox.
> Then you'll see the newly created files in the new wiki.d directory and you
> can compare their permissions with the ones of renamed-wiki.d. If this is a
> permissions issue, the permissions will be different, so match them, remove
> the new "wiki.d" and rename back "renamed-wiki.d" to "wiki.d". To see/change
> permissions with an FTP browser, right-click on a file or files and select
> Permissions or Properties.

Another (possibly simpler) approach to try is to rename "wiki.d" to 
"wiki.d-backup", run PmWiki to let it create a new "wiki.d" directory,
then copy the files from wiki.d-backup into wiki.d .  (I suggest doing
a copy instead of a move so you still have the originals lying around.)

In most PHP environments, it's the permissions of the wiki.d directory 
itself that matters for updating, and not the permissions of the files
within the wiki.d directory.

Pm

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

Re: [pmwiki-users] Trouble with .pageindex when too much _new_ data to index (+ sqlite)

[Patrick R. Michaud]

On Wed, Jan 28, 2015 at 08:11:28PM -0600, Patrick R. Michaud wrote:
> Lastly, you may be able to force PageIndexUpdates without doing a search at 
> all.
> Create a local/Site.Site.php script with the following:
> [...]

Actually, after reviewing the code, the Site.Site.php script I suggested
probably won't work, it'll just re-index the same pages over and over again.

So, let me revise my previous email, and suggest each of the following things 
to try:

#1:  Try doing link= requests to rebuild the .pageindex.  Try the following 
searches:

Word/ link=Word.RecentChanges
Quote/ link=Quote.RecentChanges

#2:  Try rebuilding the .pageindex using search requests of only one group at a 
time:

Word/ text
Quote/ text

#3:  Try increasing the amount of time PmWiki has to perform searches -- in 
local/config.php, add

set_time_limit(90);   # wait 90 seconds to time out

Let me know which (if any) of the above work.  Then I should be able to make 
other suggestions to improve the (re)building of your .pageindex whenever you 
need it done.

Pm

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

Re: [pmwiki-users] Trouble with .pageindex when too much _new_ data to index (+ sqlite)

[Patrick R. Michaud]

On Thu, Jan 29, 2015 at 12:45:44AM +0100, ABClf wrote:
> As of now, I say : after I import a big amount of new data (in sqlite
> recipe), pmwiki fails to start indexing and something runs out of memory
> before it starts indexing. 

You say it runs out of memory, but the error messages you're posting say that 
it's running out of time.  They aren't exactly the same, so which is it?


Thereafter it's dead. Please note PmWiki is
> still working fine for printing out pages, for linking, etc., no matter the
> quantity of pages.
> Fails happened several times to me this evening and the only working way
> was to limit the amount of new imported data. (do not import 60 mo of new
> data, but import 6 mo and do it 10 times).

When you say "import 60 mo of new data", is that a single page with 60 mo,
or is it a large number of pages that collectively contain 60 mo?

> What if PmWiki has suddenly 10k new pages to index ? It may take time to
> list all of these new pages, and to get ready to index them in the next
> step. In my simulation case, new pages are very short in size, yet they are
> quite a lot (9 quotes = 9 pages ;)). How would I debug a bottleneck
> if ever in the very early task of indexation ?

If PmWiki has 10K pages to index, it indexes as many as it can in $PageIndexTime
seconds (for short pages this should at least one or two thousand pages), and 
then
the next time it runs it will fewer pages to index.

> Tested just now :
> I alter .pageindex, .flock and .lastmod 's names in wiki.d, so it's like
> there is nothing else the 100 mo sqlite database, and I run a search in the
> browser.
> PmWiki has to index a sql database made of 10 new pages ;) I see my
> hard drive led running fast, I feel temperature going higher, (really, some
> processing is happening), and finally error message is printed out on
> browser screen : Fatal error: Maximum execution time of 30 seconds exceeded
> in D:\xampp3\htdocs\abclf\scripts\xlpage-utf-8.php on line 75

This isn't an out of memory message, it's an "out of time" message.  What is
likely happening is that there's a very large page that PmWiki is unable to
index before PHP's 30 second timeout takes place.  Is there a very large page
in your database?

If that's not the case, try increasing the execution time limit to 60 seconds.
Add the following to a config.php:

set_time_limit(60);

> Checking in wiki.d : a new 0 byte .flock file is has been created. No new
> .pageindex

Is there a ".pageindex,new" file created?  If not, then PmWiki must be 
terminating
long before page indexing is starting -- perhaps when doing the search itself.
One of the first things that the indexing function does is to create the 
".pageindex,new" file.  So if that file isn't being created, then the problem 
is occuring *before* indexing ever gets started, not during.

> I rerun a search. Hard drive rerun, and message error : Fatal error:
> Maximum execution time of 30 seconds exceeded in
> D:\xampp3\htdocs\abclf\pmwiki.php on line 2015
> [...]
> Last rerun, and last error message is : Fatal error: Maximum execution time
> of 30 seconds exceeded in D:\xampp3\htdocs\abclf\cookbook\sqlite.php on
> line 403

These are functions called when reading pages, so again, it could be that PmWiki
is timing out when doing the initial search itself, as opposed to when it's 
building the index (which comes afterwards).

What search are you doing?

Instead of doing a text search, which will take PmWiki a very long time
to complete if there's no index already built (and is probably why things are
timing out), try doing a link= search instead and see if that starts building
the index.  For example, do the following searches:

   link=Word.RecentChanges
   link=Quote.RecentChanges

PmWiki attempts to build an index whenever it encounters reverse-link requests,
but it won't try to do the full text search (which is probably slowing things
down).

Lastly, you may be able to force PageIndexUpdates without doing a search at all.
Create a local/Site.Site.php script with the following:

   http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Trouble with .pageindex when too much _new_ data to index (+ sqlite)

[Patrick R. Michaud]

On Wed, Jan 28, 2015 at 10:10:06PM +0100, ABClf wrote:
> Main issue encountered is how .pageindex is handling its indexation task.
> It sounds like it definitely stops working when the amount of _new_ data is
> too big. [...]

I don't think this is quite how it works.  If you're examining the code to
see how things work, it would help a lot if you could refer to functions by
name.

Here are a couple of possibly helpful items, though.  The amount of time
PmWiki spends building .pageindex is controlled by the $PageIndexTime variable,
which defaults to 10 seconds.  This variable controls how long PmWiki spends
indexing pages after serving a page in response to a search; increasing the
value of this variable should allow more pages to be indexed during each
request.

As far as I remember, PmWiki doesn't check to see if the amount of new 
data is acceptable to index.  PmWiki simply has a list of pages that it
knows aren't in the index, indexes as many as it can in $PageIndexTime 
seconds, and leaves the rest for a later request to index.  

If there's a single page that is too large for PmWiki to index because of 
PHP memory limits, I'm not sure there's a whole lot we can do about that 
short of increasing the memory limits.

I think it would not be difficult to create a custom action that does
nothing but pageindexing for a very large page or set of pages... but I
really need to know more precise details about what you're trying to do
before I can help further, such as specific page names and exactly what
they contain.

Pm

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

Re: [pmwiki-users] preg_replace (RFC)

[Patrick R. Michaud]

On Fri, Dec 05, 2014 at 10:26:33PM +0100, Peter Bowers wrote:
> On Thu, Dec 4, 2014 at 9:55 AM, Hans Bracker  wrote:
> 
> > Could  PmWiki  be more specific to identify in which function call and
> > script offending regular expressions reside?
> >
> 
> It occurs to me that the stopwatch() function could be modified to respond
> to a variable $EnableDebugStackTrace and then spread throughout the code a
> little more widely (always at the begin and exit point of key functions)
> and it could be constantly updating a stacktrace which could then be
> printed off in an error handler...

Veto.  For this to be useful, the recipe authors would have to be the ones
calling StopWatch() at appropriate entry/exit points.  I neither want to 
increase the burden on recipe authors nor rely on them to get this
exactly right.  I think it would be worse to provide misleading info
than none at all.

Pm


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

Re: [pmwiki-users] preg_replace (RFC)

[Patrick R. Michaud]

On Fri, Dec 05, 2014 at 10:22:50PM +0100, Peter Bowers wrote:
> On Thu, Dec 4, 2014 at 9:55 AM, Hans Bracker  wrote:
> What if pmwiki was distributed with 2 copies of pmwiki.php -- one the
> standard production version and the other pmwiki-debug.php.  In the case of
> a need for troubleshooting an admin would swap out the pmwiki.php with the
> pmwiki-debug.php (simply renaming appropriately) and then re-load the
> page.  The pmwiki-debug.php version could do various things to help debug:

>From a maintainer's point of view, this is a real pain, because you have
to do extra work to keep the two copies in sync.  The standard way to do
this in programming is using a flag variable.

> creating an array indexed by regex/replace strings and holding a
> "Scriptname.php: lineno" string.  Then when Petko's error is triggered it
> could include the script name and line #

I still think it's better to report things when the markup rule
is registered (i.e., inside the call to Markup()), rather than when 
the rule is executed.  And the existence of debug_backtrace ought to
mean that PmWiki doesn't need to do any special tracing of its own.

Pm


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

Re: [pmwiki-users] preg_replace (RFC)

[Patrick R. Michaud]

On Fri, Dec 05, 2014 at 10:15:01AM -0500, DaveG wrote:
> On 12/4/2014 3:55 AM, Hans Bracker wrote:
> >Could  PmWiki  be more specific to identify in which function call and
> >script offending regular expressions reside? I don't see how.
>
> Agree with this sentiment, and option 3. If we could somehow guide
> admins in tracking down exactly where errors are occurring, beyond
> the pmwiki.php end point I think that would help a great deal.
> Perhaps an option to provide more of a stack trace -- although like
> Hans, not sure how that could be done.

I wasn't sure how this could be done either, but searching the PHP
function library helped.  There's a debug_backtrace() function available
since PHP 5.1 that can provide the current backtrace.  So, the 
Markup() function could check the $pat argument to see if there's a 
"/e" modifier, and produce a warning/backtrace if so.

Ideally this behavior would only be triggered by an administrator and
not be enabled by default; e.g. if ?action=diag or ?action=ruleset or 
something like that.

For example, perhaps something like the following in PmWiki's Markup()
function (this is completely untested!):

function Markup($id, $when, $pat=NULL, $rep=NULL) {
  global $MarkupTable, $EnableMarkupDiag;
  if ($EnableMarkupDiag && preg_match('!/[^/]*e[^/]*$!', $pat)) {
var_dump(debug_backtrace());
  }
  # ...

So, when a recipe calls Markup() with a pattern containing an 'e'
modifier after the last slash, it produces a backtrace showing the
file and line that called Markup().  I'm sure the output can be 
vastly improved beyond doing a simple var_dump, but I'll leave 
that to others to work out.  :)

Pm

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

[pmwiki-users] Mailing lists working again

[Patrick R. Michaud]

Hello, all-

For those who attempted to send messages to the pmwiki-users or
pmwiki-devel mailing lists this past weekend, this note is to let you
know that the lists are working again.

The webhosting software I use did an automated update on Thursday this
past week, causing nearly all of the mailing lists on the server to
stop working.  After a weekend of troubleshooting with tech support 
(and escalating the issue up to one of their providers), we finally
have the mailing lists working again.

My apologies for any inconvenience.

Pm

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

Re: [pmwiki-users] $MetaRobots?

[Patrick R. Michaud]

You should be seeing a change to the "" tag...
Are you seeing a  tag at all in the HTML source?

Pm

On Fri, Apr 04, 2014 at 08:10:24PM -0700, Matthew Wayne Selznick wrote:
> I've added $MetaRobots = 'noindex, nofollow'; to my config.php file,
> but I'm not seeing any change in the source of my wiki pages.  Am I
> missing something?
> 
> (Sure wish the mailing list archives were searchable..!)
> 
> Thanks again,
> 
> -- 
> Matthew Wayne Selznick
> Author, Creator and Creative Services Provider
> http://www.mattselznick.com
> Get a Free Sampler of My Short Stories, Novels, and Non-Fiction:
> http://www.mattselznick.com/join-community-newsletter/
> 
> ___
> 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] PmWiki.org attachments cleanup

[Patrick R. Michaud]

Do a search instead for "/pmwiki/uploads/Cookbook" -- you'll find 
several pages that reference attachments directly by their URL.

Pm

On Wed, Mar 26, 2014 at 04:53:41PM +1300, Simon wrote:
> A quick search of "attach:http" shows there are no Attach statements that
> use a fully qualified URL on PmWiki
> 
> 
> On 26 March 2014 12:51, Patrick R. Michaud  wrote:
> 
> >
> >
>  Also, there might be some attachment files referenced by [[http://... ]]
> > links instead of Attach: .
> >
> >

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

Re: [pmwiki-users] PmWiki.org attachments cleanup

[Patrick R. Michaud]

On Wed, Mar 26, 2014 at 12:17:42AM +0100, Petko Yotov wrote:
> I'd like to know Pm's opinion on migrating uploads from group based
> to page based, ie $UploadPrefixFmt = '/$Group/$Name';

I don't see any real advantage of page-based uploads for the Cookbook.
We'd still have to check all of the pages to find orphaned attachments;
and on top of that the attachments would then be spread across multiple
directories to be checked.  It might help as far as figuring out which
page an attachment was originally intended to be associated with...
but I'm not sure that's a big enough advantage to warrant a switch.

Note that even with a per-page file organization it's still 
possible/likely that some attachments will be referenced from
multiple Cookbook pages.  So, for any given attachment we still
should check every Cookbook page for an active link to it.

Also, there might be some attachment files referenced by [[http://... ]]
links instead of Attach: .

I'd suggest developing a mechanism (recipe, likely) that scans
a set of pages to generate attachment links, then generate a table
cross referencing attachments with the pages that link to them.
Then we can figure out which files are candidates for deletion.

Another possibility is to use a spider to crawl the 
pmwiki.org/wiki/Cookbook/ space and then extract the list
of links to the uploads/Cookbook/ directory.

Pm

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

Re: [pmwiki-users] Redirecting to a change group

[Patrick R. Michaud]

On Thu, Mar 20, 2014 at 08:24:32PM +1300, Simon wrote:
> I had the idea of adding the following to Site.PageNotFound
> 
> (:if equal "{$RequestedGroup}" "MyGroup":)
> (:redirect NewGroup.{$RequestedPage}:)
> (:ifend:)

Why not just do a (:redirect:) inside of MyGroup.GroupHeader ?

   (:redirect NewGroup.{$Name} :)

Pm

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

Re: [pmwiki-users] Moving pmwiki to a new server

[Patrick R. Michaud]

On Tue, Mar 18, 2014 at 09:50:48PM +0100, Petko Yotov wrote:
> [lots of useful tips here]
> 
> [...] Other reason for
> the skin not displaying properly may be directory permissions on the
> server: both the server process and the PHP interpreter need read
> access to the files in the pmwiki/pub directory tree.

FWIW, this is my top guess as to the likely cause -- that rsync
preserved file ownership/permissions in the transfer and the new 
server is expecting something different.

Pm


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

Re: [pmwiki-users] sync local wiki with server

[Patrick R. Michaud]

FWIW, this topic also came up in November of last year -- there might
be some useful ideas and suggestions in this thread:

http://comments.gmane.org/gmane.comp.web.wiki.pmwiki.user/61472

It might also be worth a Cookbook page (there's one already but
it's a couple of years out of date).

Pm

On Sun, Mar 16, 2014 at 11:37:58AM +1300, Simon wrote:
> I do this on Windows using a shareware program
> AllWaySync,
> that has worked very well for me.
> In my case I use it to sync (uploads and wiki.d) from my server to my local
> machine on a scheduled basis,
> and use FileZilla to manually send releases from my local to the server
> after I have tested them.
> 
> One of the nice things is that AllWaySync is, like FileZilla, that you can
> use a 
> regex
> to
> skip all the ThumbList 
>  thumbnails.
> 
> 
> 
> On 16 March 2014 06:15, Patrick Frank  wrote:
> 
> > Hello,
> >
> > the pmwiki is really what suits me the best of all the wikis out there.
> > And I am wondering right now if I could work out the following problem:
> >
> > pmwiki is installed locally in a virtual machine and it is installed on my
> > server. i would like to make modifications to the local wiki and sync these
> > with the server so that my master is local.
> >
> > How could i go about this?
> >
> >
> > Patrick
> >
> >
> > ___
> > pmwiki-users mailing list
> > pmwiki-users@pmichaud.com
> > http://www.pmichaud.com/mailman/listinfo/pmwiki-users
> >
> >
> 
> 
> -- 
> 
> http://kiwiwiki.co.nz

> ___
> 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] PHP 5.5 compatibility

[Patrick R. Michaud]

On Fri, Feb 21, 2014 at 05:31:31PM +0100, Petko Yotov wrote:
> Hans Bracker writes:
> >I am updating some recipes and cookbook pages:
> >do you want the category link [[!PHP55]] on all cookbook pages where
> >the script is PHP5.5 compatible? 

> There are two different notions - compatibility and requirement.
> 
> A recipe "compatibile" with PHP 5.5 will work on PHP 5.5 but
> probably also on earlier versions - we simply inform the readers
> that this recipe works with this very particular PHP version which
> introduced a major change. We add the category [[!PHP55]] to those
> pages.

I wonder if it's better to have a "Compatible-with:" (or similarly
named) PageTextVariable here instead of categories.  

Somehow having "PHP55" as a category link feels wrong to me... if
PHP makes a 5.7 with lots of changes, do we start creating new 
categories for every version of PHP?

Pm

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

Re: [pmwiki-users] PHP 5.5 compatibility

[Patrick R. Michaud]

Marking PHP compatibility on recipes sounds like a really good idea
if we're not doing it already.  Perhaps a PageTextVariables would be
easier/more flexible than category links, though.

Pm

On Fri, Feb 21, 2014 at 01:37:37PM +, Hans Bracker wrote:
> 
> I am updating some recipes and cookbook pages:
> do you want the category link [[!PHP55]] on all cookbook pages where
> the script is PHP5.5 compatible? There are some recipes which do not
> use markup definitions or preg_replace calls with /e modifier.
> Shall those be marked with the PHP55 category link as well?
> 
> Sorry if this has been discussed previously, i have not followed
> discussions for a while!
> 
> Best,
>  Hans  
> 
> 
> 
> ___
> 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] How to fix broken RSS feed and AllRecentChanges?

[Patrick R. Michaud]

It's possible that the two problems are related... the AllRecentChanges
page may have gotten too large for PmWiki to update properly, and the
RSS feed likes to use (All)RecentChanges to generate its content.

I suggest shortening (or removing/renaming) the AllRecentChanges
page and see if it starts working again, then see if the RSS feed
comes back.

Pm



On Tue, Feb 18, 2014 at 12:40:46PM +, Charles Weir wrote:
> Hi,
> 
> We've got a PmWiki running with internal company information.  It's done us 
> fine for many years.  And the people who set it up have now left. :-(  I'm a 
> newbie to the working of the wiki, though I know well how to create content.
> 
> Alas the RSS all-changes feed stopped working a couple of years back, and the 
> AllRecentChanges page has just stopped working.
> 
> What could be causing this, and how to I go about diagnosing it and fixing it?
> 
> The wiki installation is running version pmwiki-2.2.0-beta54, version number 
> 2001954.
> 
> Best regards,
> 
> Charles Weir
> CEO and Technical Director
> Tel:+44 (0)1768 214400
> Mobile:   +44 (0)7876 027350
> Email: char...@penrillian.com
> Web:   www.penrillian.com
> Number: 4001413
> VAT:   759 3237 03
> Address: Clint Mill, Cornmarket, Penrith, Cumbria, CA11 7HW
> (registered address) This email, including any attachments, is subject to 
> copyright and the information it contains is confidential.  Use, other than 
> by the addressees, of this email or any information within is unlawful and 
> unauthorised.
> 
> [Twitter-icon2]   [linkedin-iconCA8242R6] 
> 
> 
> Interested in Mobile Money? Visit our dedicated Mobile Money 
> website to find out more.
> 




> ___
> 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] Proposed change to pmwiki.php: Markup_e

[Patrick R. Michaud]

On Tue, Feb 11, 2014 at 10:00:14AM -0500, michael paulukonis wrote:
> How can one contribute to the code? I'm not finding it quickly on the wiki
> [...]
> The SVN page only discusses how to pull  the code, not to offer changes:
> http://www.pmwiki.org/wiki/PmWiki/Subversion

For a while I've been toying with the idea of moving PmWiki's 
source to GitHub.  It's not as simple as just converting the 
subversion repository to git, though -- we have a lot of
packaging and build tools that rely on Subversion, and those
would also need converting.  

Any opinions from the crowd on moving to git/GitHub?

(There's also a tags problem in PmWiki's subversion history
left over from the days of using CVS, and last time I did a test
git conversion all of that had to be manually managed and 
was Not Fun.)

Pm

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

Re: [pmwiki-users] Proposed change to pmwiki.php: Markup_e

[Patrick R. Michaud]

On Fri, Feb 07, 2014 at 08:36:09AM -0700, Simon wrote:
> Because it could lead to confusion, where 'r' (or 'R') and 'return' may be
> perceived as offering differing functionality.

I respectfully disagree.  Unix command-line utilities have
provided abbreviated and long options for decades and they don't 
cause significant confusion.

Pm

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

Re: [pmwiki-users] Proposed change to pmwiki.php: Markup_e

[Patrick R. Michaud]

If it's something that someone will have to write often, it should
have a short name.  (This is why "SDV" has a short name. :)  
Otherwise, a longer or more descriptive name should be used.

For this case, if the choice is between 'return' and 'r' I would
tend to prefer 'return', but I'd probably need to look at a few
code examples.

Also, this is a computer and the function isn't called frequently, 
so why not accept both 'return' and 'r' as valid options?  :-)

Pm


On Fri, Feb 07, 2014 at 08:46:21AM -0500, michael paulukonis wrote:
> What is the reason for using abbreviations and supershort pieces instead of
> the full semantic name?
> 
> Staring at "SDV" for the first time (or the first time in a long time) it's
> rather opaque.
> 
> As John said, 'return' is a lot more semantic than 'r'
> 
> -Michael Paulukonis
> http://www.xradiograph.com
>  Interference Patterns (a
> blog)
> @XraysMonaLisa 
> http://michaelpaulukonis.com
> 
> 
> Sent from somewhere in the Cloud
> (hearthrug, by the fender)
> 
> 
> On Thu, Feb 6, 2014 at 9:28 PM, John Rankin wrote:
> 
> >
> > > I think we can add this. Why the key is named markup_c? This template can
> > > be
> > > used on many places which call PCCF(), is there a better key name?
> >
> > 'return' would be a clearer (and shorter) key name
> >
> > If a very short key name is acceptable, how about 'r'? Then we could write
> >
> >   Markup_e( ... , 'r');
> >
> > Thanks!
> > >
> > > John Rankin writes:
> > >> I'd like to suggest a small change to the pmwiki core:
> > >>
> > >> $CallbackFnTemplates = array(
> > >>   ...,
> > >>   'markup_c' => 'return %s;',
> > >>   ...,
> > >> );
> > >>
> > >> ...
> > >>
> > >> function Markup_e($id, $when, $pat, $rep, $tmpl='markup_e') {
> > >>   if (!is_callable($rep)) $rep = PCCF($rep, $tmpl);
> > >>   Markup($id, $when, $pat, $rep);
> > >> }
> > >>
> > >>
> >
> > --
> > John Rankin
> >
> >
> > ___
> > 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 mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] regex in (:if how to use correctly

[Patrick R. Michaud]

On Thu, Jan 23, 2014 at 08:45:42PM +0100, li...@basel-inside.ch wrote:
> Good evening
> 
> I like to only include some pages in a pagelist, I have seen the
> possiblity of regexp as
> (:if match -Talk$:)  [PmWiki/ConditionalMarkup-Talk]
> 
> I'm not very familar with regexp and (:if constructions
> I made one test with (:if match [0-9]* :-) in the hope to selekt
> everything which beginns with numeric, but it seems to be
> uncorrect...

Everything that begins with numeric:

(:if match ^\d :)
  or
(:if match ^[0-9] :)

> Actually I like to select
> =>1   (5 Numbers Product-Nr and n letters for variations/tests)

Everything that starts with five digits:

(:if match ^\d{5} :)
  or
(:if match ^[0-9]{5} :)

Pm

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

Re: [pmwiki-users] maybe stupid question

[Patrick R. Michaud]

On Fri, Jan 10, 2014 at 11:06:27AM +0100, Peter Gragert wrote:
> How do I suppress for all pages pmwiki.php in the address field:
> E.g.  http://www.petergragert.info/pmwiki/pmwiki.php/Blender/Blender 

http://www.pmwiki.org/wiki/Cookbook/CleanUrls

Pm

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

Re: [pmwiki-users] widi.d file = 0 byte

[Patrick R. Michaud]

On Sun, Nov 17, 2013 at 10:32:50PM +0100, marc-alexis morelle wrote:
> I looked far on Online web, and this solution is "illimitée". Is
> that means in reasonably limits ? :-)

I think that "illimite"  may be referring to the number of files
allowed (unlimited).   But again, I'm just guessing.

> I cleaned all directories (old logs and the like) but there was no big file.
> So, for testing, just now, I delete 4 video files (1Go)... don't work.

What does "don't work" mean in this case...  after removing the
video files you tried updating a page and still ended up making
a zero-length file?

Pm

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

Re: [pmwiki-users] widi.d file = 0 byte

[Patrick R. Michaud]

On Sun, Nov 17, 2013 at 08:31:32PM +0100, marc-alexis morelle wrote:
> Le 17/11/2013 16:56, Patrick R. Michaud a écrit :
> >I might suggest checking to see if there's a quota
> >limit in effect on the server.
> 
> There is a quota, but it seems we are far from :
> 
> Online admin console says : "Quota web 21541 Mo / illimité"
> and FTP connexion says :
> Response: 230-25912 files used (25%) - authorized: 10 files
> Response: 230 22058139 Kbytes used (21%) - authorized: 104857600 Kb

It looks to me as though you may be hitting the quota limit.  
Your admin console says the web quota is "21541 Mo" 
(I assume that's megabytes somehow), and FTP is saying that
22058 megabytes are being used.

I don't know where FTP might be getting it's "authorized"
numbers from, but I normally wouldn't expect FTP to be aware of
operating system quota limits.

Again, these are just guesses, but it really looks like a quota
issue to me.  If you can, you might look around the account a bit
and see if there are any very large temporary or log files that
could be deleted.  I suspect that if you free up some space, your
zero-length file issues in PmWiki will go away.

Pm

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

Re: [pmwiki-users] widi.d file = 0 byte

[Patrick R. Michaud]

I might suggest checking to see if there's a quota
limit in effect on the server.  A quota limits the
amount of space a user can use on a filesystem... with
a quota in effect the operating system can refuse to
write a file even if there's plenty of disk space available.

Petko's description of PmWiki's method for saving files
is spot-on accurate... in normal operation PmWiki ensures
that it has successfully saved an updated version of a page
before deleting the old.  If you're ending up with empty
files in wiki.d, it's most likely because something in the
operating system or filesystem isn't setup properly or is
causing it to not actually save files to disk.

Pm


On Sun, Nov 17, 2013 at 12:48:39PM +0100, marc-alexis morelle wrote:
> Le 16/11/2013 22:30, Petko Yotov a écrit :
> >  session_save_path("sessions");
> >This will only help if the sessions problem does not come from "your"
> >filesystem.
> 
> This test do not work : the captcha is not displayed.
> Does that means there is a filesystem problem on Online servers ?
> Is "your filesystem" the Online filesystem, or mine, my pmwiki install ?
> 
> Thank you !
> 
> marc
> -- 
> http://www.malexism.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

Re: [pmwiki-users] Markup

[Patrick R. Michaud]

You probably also need the 'm' modifier at the end of the pattern.  Otherwise
the ^ will only match at the very start of the string, and not at the start
of every line.

Even better might be to remove the ^'s altogether, unless you really want
to make sure the markup directives will only be processed when at the beginning
of a line.

Pm

On Wed, Nov 13, 2013 at 11:50:08PM +, Brian Tibbels wrote:
> Many thanks Patrick - that sorts out when it should be done but I still
> don't get the desired result. I amended the markup to escape all the quotes
> and PSS the return strings, so it now stands at :
> 
> Markup( "panel",
> "fulltext",
> "/^\\(:panel-default:\\)(.*?)^\\(:panelbody:\\)(.*?)^\\(:panelend:\\)/sie",
> "Keep('
>   
> '.PSS('$1').'
>   
>   '.PSS('$2').'
> ')"
> );
> 
> 
> Rgds Brian
> 
> 
> 
> *Brian Tibbels*
> *IT support for small business and the individual*
> http://clickmarlow.co.uk/
> *m*: 07804 109906* | t*: 01628 477640
> 
> 
> 
> On 13 November 2013 22:17, Patrick R. Michaud  wrote:
> 
> > By the time PmWiki reaches the "block" phase of Markup rules, the
> > text has already been broken into individual lines.  If you want to
> > match a pattern against multiple lines of input, it needs to be
> > in the "fulltext" phase, or at least " >
> > Pm
> >
> > On Wed, Nov 13, 2013 at 09:39:48PM +, Brian Tibbels wrote:
> > > I am trying to create a set of markups which will include Bootstrap
> > > components - I thought I would start with an easy one and fell at the
> > first
> > > hurdle :(. I have looked at all the sample markups and some were obvious
> > > and others were rather hard to follow as regular expressions are not my
> > > strong point. Could someone please tell me what is wrong with this
> > though...
> > >
> > > Markup( "panel",
> > > "block",
> > >
> > "/^\\(:panel-default:\\)(.*?)^\\(:panelbody:\\)(.*?)^\\(:panelend:\\)/sie",
> > > "
> > >   
> > > $1
> > >   
> > >   
> > > $2
> > >   
> > > "
> > > );
> > >
> > >
> > > I was hoping to transform this sort of thing.
> > >
> > > (:panel-default:)
> > > My Title
> > > (:panelbody:)
> > > Body text
> > > (:panelend:)
> > >
> > > also if this could be transformed even better
> > >
> > > (:panel-default:)
> > > My Table
> > > (:panelbody:)
> > > || class=table
> > > || Col-1 || Col-2 || Col-3 ||
> > > (:panelend:)
> > >
> > >
> > > 
> > > Best wishes
> > > Brian
> >
> > > ___
> > > 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] Markup

[Patrick R. Michaud]

By the time PmWiki reaches the "block" phase of Markup rules, the
text has already been broken into individual lines.  If you want to
match a pattern against multiple lines of input, it needs to be
in the "fulltext" phase, or at least " I am trying to create a set of markups which will include Bootstrap
> components - I thought I would start with an easy one and fell at the first
> hurdle :(. I have looked at all the sample markups and some were obvious
> and others were rather hard to follow as regular expressions are not my
> strong point. Could someone please tell me what is wrong with this though...
> 
> Markup( "panel",
> "block",
> "/^\\(:panel-default:\\)(.*?)^\\(:panelbody:\\)(.*?)^\\(:panelend:\\)/sie",
> "
>   
> $1
>   
>   
> $2
>   
> "
> );
> 
> 
> I was hoping to transform this sort of thing.
> 
> (:panel-default:)
> My Title
> (:panelbody:)
> Body text
> (:panelend:)
> 
> also if this could be transformed even better
> 
> (:panel-default:)
> My Table
> (:panelbody:)
> || class=table
> || Col-1 || Col-2 || Col-3 ||
> (:panelend:)
> 
> 
> 
> Best wishes
> Brian

> ___
> 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] The Philosophy of PmWiki: adding to the core

[Patrick R. Michaud]

On Sat, Nov 09, 2013 at 12:14:38AM +0100, Eric Forgeot wrote:
> On 03/11/2013 22:54, Tamara Temple wrote:
> On the other hand, there is something I like very much on dokuwiki,
> and find annoying on pmwiki: it's the way data are stored. I regret
> all history and metadata are kept in the same files in pmwiki, I
> also guess it might impact a bit the performance if it loads the
> whole data when reading the content of the files, but I may be wrong
> on this point.

Data and history data in PmWiki's files are always stored 
most-recent-first, so PmWiki almost never has to read the entire
data file except when editing a page or displaying history.
When simply reading or scanning a page, PmWiki will stop reading
the file as soon as the first history entry is found.

Storing data and metadata in a single file was a very conscious 
design choice in PmWiki -- I wanted pages to be well encapsulated
and didn't want to ever have to worry about them getting out-of-sync.
Keeping them separate is also a perfectly valid design choice; for
my needs it just made much more sense to keep it all together.

> I also regret line breaks and such are mangled in pmwiki, which
> means you can't easily edit your data from outside a web browser,

I agree a fair bit on this point -- there are many times that I
wish for a plainer-text version of the files.  That's actually
quite pluggable, however; we could certainly have a module that
stores the files in a more plaintext form.  But there's also a
very strong issue of security at play -- part of the advantage
of PmWiki's encoding is that it also limits a variety of attack
vectors.

> Dokuwiki also support out of the box cached data. I haven't tried to
> achieve the same on pmwiki, but it looks complicated to set up (for
> example with http://www.pmwiki.org/wiki/Cookbook/FastCache).

PmWiki does as much caching as it can by default.  With caching
there's a really difficult balance to be struck between dynamic
page content and ability to cache... and again we've tended to
favor dynamic content over caching.

Be sure to set or look at the $PageCacheDir and $EnableIMSCaching
variables if you aren't doing so already.  (PmWiki's built-in
page caching features seem to be underdocumented at the moment,
hopefully someone can help improve that!)

Pm

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

Re: [pmwiki-users] Getting pages created by other software to appear in category lists

[Patrick R. Michaud]

On Mon, Oct 28, 2013 at 10:25:58PM -0300, Peter Payzant wrote:
> ... and looking at the old and new versions of that file, by the
> way; the old one is ten times the size of the new one. Presumably
> there is an accepted practice for garbage collection on this file -
> maybe just deleting it from time to time!

There's generally no "garbage" in the .pageindex file... it gets cleared
automatically from time to time.  It gets (re)built over multi page
queries, so the fact that the old one was 10x bigger is simply a
reflection of having been more fully built than the new one you
created.

Pm

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

Re: [pmwiki-users] Getting pages created by other software to appear in category lists

[Patrick R. Michaud]

On Mon, Oct 28, 2013 at 06:06:29PM -0300, Peter Payzant wrote:
> I'm creating one page with a daily Perl program, and in general
> everything works as expected. However, I can't get this page to show
> up in a category list.
> [...]
> However, this page does not appear on the page
> Category.BoardDocuments. Dozens of other pages created the normal
> way, by editing in PmWiki, do appear in the category list.
> 
> What am I doing wrong?

The indexes aren't being notified that there's a new page that might
need scanning.

Simply have your Perl script also touch/update the .lastmod file in
wiki.d/, and the categories should start seeing your automatically
generated page(s).

In Perl the following will work to update the timestamp of .lastmod:

open(my $fh, ">", "wiki.d/.lastmod");
close($fh);

Hope this helps.

Pm

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

Re: [pmwiki-users] Nofollow in external URLS

[Patrick R. Michaud]

On Mon, Oct 21, 2013 at 08:09:54PM -0400, John Rigdon wrote:
> This is an important issue for me.  [...]
> I find there are a half dozen or so references to 'nofollow' in
> pmwiki.php.  From what I understand of the dialogue, adding the line to
> config.php should override these so the indexing will occur.
> 
> Is this correct?

Well, let's make sure we're in agreement as to what rel=nofollow
actually does.  In PmWiki, rel=nofollow ends up on *external* links --
i.e., the links that lead *away* from your PmWiki site.

rel=nofollow links in your PmWiki pages have no impact on whether 
your pages are indexed or not, and they have very little impact 
on the ranking your site's pages receive.  The ranking your site 
receives will depend more on the content of the pages, and the links 
that are coming *in* to your site from other locations.

(...which may somewhat answer why your traffic has fallen.  When
converting the site over to PmWiki, were a lot of incoming link 
targets broken in the process?)

Even if a link has rel=nofollow on it, search engines will often
follow the link anyway.  What rel=nofollow really means is "this is
a link to this other place, but don't consider the link as an
endorsement of its value".  In other words, search engines will 
still tend to follow the link, but they don't give the link 
much weight when calculating the value of the target page.

Hope this helps,

Pm

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

Re: [pmwiki-users] Nofollow in external URLS

[Patrick R. Michaud]

Because comment spam, wiki spam, and blog spam have been such large
problems in the past, I prefer PmWiki's current default of rel=nofollow.
This makes more sense given that PmWiki defaults to an open editing
model (i.e., a wiki) when it is first installed.

The config already makes it possible to disable/enable rel=nofollow as
desired by setting $UrlLinkFmt:

# remove rel=nofollow
$UrlLinkFmt =
  "\$LinkText";

Pm

On Mon, Oct 21, 2013 at 10:22:51AM +0200, Eric Forgeot wrote:
> I guess most people are using PmWiki as a CMS and not as an open wiki so it
> could make sense to disable this no follow option (and make it possible to
> enable it again in the config)
> Le 21 oct. 2013 10:15, "Simon"  a écrit :
> 
> > I understand that the attribute rel=nofollow was added as an antispam
> > measure some time ago,
> > but I wonder if in fact it penalises PmWiki websites but not having their
> > content counted and weighted by search engines?
> >
> > I'm thinking it would be better not to have the default being nofollow.
> >
> > 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 mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Wiki maintenance

[Patrick R. Michaud]

First, I'll note that I don't see anything wrong with putting site
(pmwiki.org) maintenance details into the PmWiki/ group.  It won't 
automatically become part of the distribution.

On the other hand, there is the Site/ wikigroup which is explicitly 
intended for site-specific documents, so perhaps Site/Maintenance or 
Site/SiteMaintenance is where documents and notes about maintaining
the pmwiki.org site could go.  

The main reason I'd give for not choosing to put it in is that it
doesn't seem to be an obvious place that people think of for it.
OTOH, perhaps we should start encouraging this as a pattern, perhaps
even going so far as to create a template/dummy page to be included
in the distributions.

For a category tag, I suggest [[!SiteMaintenance]].

Pm

On Thu, Aug 29, 2013 at 11:07:16PM -0400, michael paulukonis wrote:
> >If I understand correctly, the [[!Maintenance]] category was used in the
> past for pages needing some fixing.
> 
> Simon said pretty much the same thing, which surprised me, since it _looks_
> like it's _about_ maintenance, as opposed to _needs_ maintenance.
> 
> "WikiMaintenance" was suggested, but that sounds a bit like smurf-naming
> (wiki-edit a wiki-page to make wiki-changes when you are doing
> wiki-maintenance in a wiki-group).
> 
> 
> I was asking because there isn't a page in the wiki with this information
> -- how to maintain the wiki, the difference between despam and desandbox,
> etc.
> It should not go into Core distribution, as it pertains to the maintenace
> of the PmWiki website itself.
> 
> Since there seems to be only a small handful of pages with the
> [[!Maintenace]] tag on them, and there is a page Cookbook.Maintenance --
> which is, unsurprising, not named so in order to draw attention and have
> itself fixed, as much as it is _about_ maintaining the cookbook -- I will
> probably double-check any existing tag of [[!Maintenance]] to see if it
> should be changed to [[!NeedsMaintenance]] or [[!NeedsAttention]] or
> [[!UpdateMe]] (they aren't the same -- one is definitely needs change, one
> is asking for another set of eyes), as will as creating a page about
> Maintaining the wiki.
> 
> -Michael Paulukonis
> http://www.xradiograph.com
> Interference Patterns (a
> blog)
> @XraysMonaLisa 
> http://michaelpaulukonis.com
> 
> 
> Sent from somewhere in the Cloud
> (hearthrug, by the fender)
> 
> 
> On Thu, Aug 29, 2013 at 4:10 PM, Petko Yotov <5...@5ko.fr> wrote:
> 
> > michael paulukonis writes:
> >
> >> Where would a page on wiki-maintenance at PmWiki.org go?
> >>
> >> The pages under PmWiki/ get bundled for distribution, correct?
> >>
> >
> > On pmwiki.org, pages that are into the distribution have a small gray
> > star before the "View Edit History..." actions.
> >
> >
> >  In which case, site-specific notes should be frowned upon.
> >>
> >> Thus, a note regarding "don't put stuff into the PmWiki/ group" wouldn't
> >> go into the PmWiki group... so where?
> >>
> >
> > Notes related to the pages should go to their *-Talk pages. For example,
> > questions not yet answered, things you are not sure, ideas for improvements
> > (but you can be bold and improve the pages without long discussions).
> >
> > If you need me to look into a page, place a category link [[!UpdateMe]]
> > near the place where I should look (a short message about what I should do
> > can help me if it is not clear enough).
> >
> > If I understand correctly, the [[!Maintenance]] category was used in the
> > past for pages needing some fixing.
> >
> > I am not sure if pages in the core distribution should have any categories
> > in them.
> >
> > 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


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

Re: [pmwiki-users] very weird - spam filter?

[Patrick R. Michaud]

On Mon, Jun 17, 2013 at 03:43:39AM -0400, adam overton wrote:
> i've never witnessed this before in all my time with pmwiki
> but while logged in either as a regular user or as admin
> when i try to type and save the word "slot machines", "slotmachines" 
> (but not the singular "slotmachine), i get an error page that says:
> 
> Sorry, the page "403.shtml" doesn't exist. 
> Please check the spelling of the pagename you're looking for, 
> and try searching again.

Sounds like mod_security has been enabled on the sites.
See the section of http://www.pmwiki.org/wiki/PmWiki/Troubleshooting
that answers the question "Some of my posts are coming back with
'403 Forbidden' errors..."

Pm

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

Re: [pmwiki-users] use pagelist results in function

[Patrick R. Michaud]

I think you're looking for the MakePageList() function (in pagelist.php), 
which will generate a list of pages according to the arguments
you supply.

You should be able to call it from a function to generate
a list of pages you're looking for.

Note that it should also be possible to use a pagelist 
template to do what you're wanting to do (although it
might not be as efficient as a custom function).

Pm

On Sun, May 26, 2013 at 04:36:34PM -0700, Mark Lee wrote:
> I guess I can make a copy of the pagelist script and add any feature I
> want. I think I will explore that next.
> 
> 
> On Sun, May 26, 2013 at 7:38 AM, Mark Lee  wrote:
> 
> > How can I use the results of (:pagelist ...:) in a function? I a PTV in
> > some pages in a group that holds a number. such as (:size x=10:). I want to
> > generate a line of html for each page found if the value is in a range. I
> > can display the values in a table using pagelist, but I have other ideas
> > than just making a table.
> > -Mark
> >

> ___
> 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] Relaxing htaccess in cookbook dir

[Patrick R. Michaud]

On Mon, Apr 08, 2013 at 12:38:35PM +0530, V.Krishn wrote:
> 
> The default pmwiki/cookbook/.htaccess has following:
> 
> Order Deny,Allow
> Deny from all
> 
> Will this be useful/better if it were:
> 
> Options All -Indexes
> 
> RewriteEngine On
> RewriteRule !\.(js|ico|gif|jpg|jpeg|png|svg|svgz|swf|flv|css)$ index.html [L]
> # index.html or a 404
> 

No.  The theory is that external users should never be able to access
the files in cookbook/ directly.  Publicly accessible files belong in
a pub/ directory.

> ---
> Following this
> http://pmichaud.com/pipermail/pmwiki-users/2005-March/011805.html
> 
> Is there a way to know from cookbook via variable or method if they're farm-
> based or field-based ?

Cookbook recipes have evolved quite a bit since 2005... I suspect
one of our recipe authors has a good answer to this question.

Pm

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

Re: [pmwiki-users] PmWiki 2.2.49 released

[Patrick R. Michaud]

On Mon, Apr 01, 2013 at 10:10:03AM +0200, Oliver Betz wrote:
> another possibility is to disallow file names with more than one dot.
> Even more restrictive but it would repair the whitelist approach.

That would eliminate things like  "myphoto-0.1.jpg", 
"somefile-1.2.0.beta.txt", and "pmwiki-2.2.49.zip".  :-)

Pm

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

Re: [pmwiki-users] http://www.pmwiki.org/wiki server disallows download of .php recipe files

[Patrick R. Michaud]

On Mon, Mar 25, 2013 at 02:18:18PM +0100, Lukasz Stafiniak wrote:
> I cannot download the .php files in:
> http://www.pmwiki.org/pmwiki/uploads/Cookbook/
> It appears Apache is configured to run them.

Yes, a .htaccess file that controlled access to the php files 
went missing somehow; it's now been restored and the .php files
can be downloaded again.

Thanks!

Pm

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

Re: [pmwiki-users] On a page name, is there a way to take dots after the first dot and translate them automatically

[Patrick R. Michaud]

On Mon, Mar 04, 2013 at 07:31:58AM -0800, c...@endlessnow.com wrote:
> What I'd like to be able to do is to allow a construct like:
> 
> [[Product.Release 1.0]]
> 
> The first dot obviously is the Group separator... but I'd love for the
> next one to be "ok" and have it so that internally we map any subsequent
> set of "dots" to "dashes" (for example).  

At first glance I'd say it ought to be possible by either manipulating
$MakePageNamePatterns or setting $MakePageNameFunction to a custom
conversion function.  Of these two, easier would be to add an entry to
$MakePageNamePatterns to convert any second and subsequent dots to
hyphens.   If that doesn't work out, then you'll probably need
to create a custom $MakePageNameFunction (and copy a lot of the
code from MakePageName() ).

My first stab at a $MakePageNamePattern entry would be something like:

'/(\..*)(\..*)$/e' => "'$1' . strtr('$2', '.', '-')"

Hope this helps.

Pm

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

Re: [pmwiki-users] SwitchToSSLMode

[Patrick R. Michaud]

Depending on what sort of authentication system you're using, it'd
be something like:

include_once("scripts/authuser.php");
if (@$AuthId) {
$ScriptUrl = 'https://www.example.com/pmwiki/pmwiki.php';
$PubDirUrl = 'https://www.example.com/pmwiki/pub';
# ... other switch-to-ssl stuff here
}

Essentially, load the authentication system and let it do its
thing, then check $AuthId to determine if the visitor has
logged in yet.  If they have, then switch everything over to SSL.

Pm


On Sun, Feb 24, 2013 at 10:39:41PM -0800, Maria McKinley wrote:
> Does anyone know if there is a way to detect from config.php if a user is
> logged in or not? Most of the recipes in SwitchToSSLMode assume you just want
> the login itself to use ssl, or at most just certain actions to use ssl. But 
> it
> seems that the way my wiki is set up, switching back and forth between ssl and
> not causes the site to forget that someone is logged in. So, I'd like ssl
> always on if you are logged in; so the logic in config.php would be that if 
> the
> action is login or if the user is already logged in, then pages are sent via
> ssl, otherwise http.
> 
> thanks,
> maria

> ___
> 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] 4+ links on page preventing saving

[Patrick R. Michaud]

On Sat, Feb 16, 2013 at 10:46:36AM -0800, Kyle Newton wrote:
> Hmm... the response seems to suggest "forbidden access" which is
> strange because editing and saving the page with 3 or fewer links (or none)
> works.
> 
> ?invalid page namep=403.Shtml, pagename=403.shtml

This is almost certainly mod_security getting in the way.

Mod_security is looking at the contents of your post, detecting
that there are 4+ http:// strings in the post contents, and
redirecting the page to /403.shtml .  This new url is then being
forwarded somehow to PmWiki, which considers "403.shtml" to be
an invalid pagename.

You probably need to search namecheap's web hosting forums or
contact their technical support to find out how to disable or
adjust the mod_security settings on your hosting account.

(I just searched namecheap's hosting forums for "mod_security"
and the general response seems to be to contact their technical
support.)

Pm

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

Re: [pmwiki-users] Localisation

[Patrick R. Michaud]

On Wed, Jan 16, 2013 at 04:40:31PM +1300, Simon wrote:
> I have the markup
> 
> [[BestPractices/Te Reo ]]Māori
> 
> but the linked text only shows
> Te Reo M
> (should show Te Reo Māori)
> 
> How can we update the set of characters that PmWiki uses 
> to 'extend' the link.
> Perhaps this is a PITS issue, as I imagine that there are a number of
> characters with diacritics that should be included

PmWiki is able to handle diacritics if they're entered directly
and not using &#... notation.  See 

   http://www.pmwiki.org/wiki/Test/Localization 

for a working example.

I don't think PmWiki should have to be aware of all letterforms
based on their &#... notation.  Enter the diacritic directly and
things should work fine (or at least as well as the underlying
PHP libraries will allow).

Pm

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

Re: [pmwiki-users] in advanced tables

[Patrick R. Michaud]

On Mon, Jan 07, 2013 at 12:19:02PM +0100, Petko Yotov wrote:
> Oliver Betz writes:
> >thanks, I will try that (but not try to understand).
> 
> It inserts a line break in the source if you havent't inserted it yourself.
> 
> >Do you think that everything should be wrapped in  even if there is
> >only one line of text in the source?

In general, I'm against wrapping everything in .  For one, in
HTML 4 (and I think HTML 5 also) the  elements don't allow 
nested block elements.  

See examples:
http://article.gmane.org/gmane.comp.web.wiki.pmwiki.user/1959
http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/1798

Much of what I know about  may be out of date here, though;
I just know that HTML's definition for  has always been
problematic.

Pm

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

Re: [pmwiki-users] Uploaded files world readable!?

[Patrick R. Michaud]

On Mon, Dec 31, 2012 at 01:48:14AM +0100, Petko Yotov wrote:
> The second argument 0444 causes world read permissions always, not
> sometimes. No matter if the file owner and the directory owner are
> the same or in the same group or not.

Ah, I didn't remember that.

According to the SVN log, this is one of the oldest changes made to
PmWiki (Nov 2004).  The original problem appeared to be with PHP's
move_uploaded_file() function, which would always leave files with
0600 permissions, which meant the account owner could not view or
otherwise manipulate the files.

Of course, this was with whatever version of PHP was available at the
time, it's entirely likely that PHP's upload ownership/permissions
model has changed since then.

> Patrick, do you think this second argument should be made modifiable
> by a wiki admin? And should it be 0444 by default or O?

I'm okay with it being an admin-modifiable value.  It should continue
to default to 0444, at least until we can figure out exactly why it
was forced to 0444 in 2004 and can be certain that changing it to
zero won't cause lots of problems for people on older PHPs or in
various ISP setups.

Pm

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

Re: [pmwiki-users] Uploaded files world readable!?

[Patrick R. Michaud]

On Wed, Dec 26, 2012 at 08:21:56PM +0100, Oliver Betz wrote:
> Hello all,
> 
> upload.php uses "fixperms($filepath,0444);", therefore uploaded files
> get world read access, correct?
> Why is this needed?

Short answer: Fixperms only adds the minimum permissions necessary 
to ensure that the account owner has sufficient permission to access 
the file.

Longer answer:  Some PHP installations run programs under a 
special "nobody" or "apache" account, which means that any files
uploaded to the server are owned by that account and not the
account that installed PmWiki.  If permissions aren't fixed,
this means that the person who installed PmWiki is sometimes
unable to view or even remove uploaded files from their own
account.

The fixperms() function detects when this occurs and makes sure
that the account that installed PmWiki always retains appropriate
permissions to any files that are uploaded.  Sometimes the only
way to do this is by adding world read permissions.

If PHP is already running under the account of the PmWiki owner,
or if the default file permissions of uploaded files are such
that the owner will still be able to access the file, then fixperms()
doesn't do anything to the file.

> BTW: There is no "fixperms" for "Mini" thumbnails.

There probably should be, although PHP installations running under
"nobody" accounts are becoming far less common (and this is a
very good thing IMO).

Pm


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

Re: [pmwiki-users] Invalid Page name when editing Site.SideBar

[Patrick R. Michaud]

If the problem is indeed mod_security rejecting posts with %'s, then 
upgrading PmWiki won't help at all; it's completely outside of 
PmWiki's control.

See the question on mod_security in 
http://www.pmwiki.org/wiki/PmWiki/Troubleshooting for a few
more details.

Pm

On Sat, Oct 27, 2012 at 10:06:40PM -0400, Sandy wrote:
> I do have customized .htaccess files. Again, they used to work and I
> know so little about them that I wouldn't knowingly change them. I
> remember changing them to get clean URLs -- not related to the
> current problem. Who knows what the host might have changed.
> 
> See my other message: it's down to style names surrounded by % %.
> 
> Thanks again,
> 
> Sandy
> 
> On 10/26/2012 3:37 PM, Petko Yotov wrote:
> >This is not an easy one. As you have enabled diagnostics, I looked and I
> >don't see anything obvious that should go wrong.
> >
> >The message you see only appears if the requested page name, after
> >normalization, doesn't match the regular expression for $GroupPattern
> >and $NamePattern. But yours appear the default ones, you haven't changed
> >them so it should work. It doesn't.
> >
> >Can you edit and save another Group.SideBar page?
> >
> >Do you have a custom edit form? Some skins come with an edit form
> >different from the default one.
> >
> >If editing works but previewing and saving doesn't, then PmWiki has
> >trouble with the $_POST variables. Do you have in your config.php some
> >lines or including a recipe containing or manipulating the $_POST array?
> >
> >A similar problem might also come from some incorrect setting of the
> >Rewrite rules of Apache.
> >
> >Petko
> >
> >Sandy writes:
> >>Clarifying:
> >>
> >>Editing works fine.
> >>
> >>Saving or previewing doesn't work.
> >>
> >>On 10/25/2012 9:18 PM, Sandy wrote:
> >>>When I try to edit Site.SideBar, it tells me:
> >>>
> >>>
> >>>
> >>>PmWiki can't process your request
> >>>?invalid page name
> >>>We are sorry for any inconvenience.
> >>>Return to http://www.sandy.onebit.ca
> >>>
> >>>
> >>>I'm running pmwiki-2.2.42 .
> >>>
> >>>I haven't touched the SideBar in years. I edited several other pages
> >>>tonight with no problem.
> 
> 
> 
> ___
> 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] Invalid Page name when editing Site.SideBar

[Patrick R. Michaud]

On Sat, Oct 27, 2012 at 10:32:40PM +0200, Peter Bowers wrote:
> On Sat, Oct 27, 2012 at 10:03 PM, Sandy  wrote:
> > I added a debug line suggested by another user to show some page variables.
> > That might help someone who knows the guts. I can add another line if that
> > would help. (I don't write PHP, but can recognize a bit from other
> > languages.)
> 
> FYI the debug statement revealed that the "page" being aborted within
> ResolvePageName is "406.SHtml".

I think 406 is the status code used by mod_security when rejecting
pages.  That would imply to me that the page/POST content contains 
something that mod_security doesn't like, causing it to return a 406
HTTP status.  

So, I think something in the webserver configuration is translating that
to be a request for a custom 406.shtml page, then passing _that_ off
to PmWiki (which then complains about it being an invalid pagename).

Try posting the contents of the page to a different (temporary) page
(which should also fail in the same way).  Then you can start removing
content until you find out what mod_security is carping about.

Pm

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

Re: [pmwiki-users] pmwiki skin

[Patrick R. Michaud]

On Tue, Aug 28, 2012 at 01:11:06PM +0200, sh...@joshleepictures.com wrote:
> [...] In my email user refers to the admin, as in original/primary 
> user of the PmWiki software, whereas CarlosAB usage of ‘user’ seems 
> to refer to the actual editor.

This is part of my continuing crusade against ever using the term
"user" when trying to describe something -- it's too ambiguous.
I almost never write "user"; I write "site admin", "recipe author",
"page author", "reader", "viewer", etc. -- it makes things a _lot_
clearer.

I do this in contexts outside of PmWiki as well; almost always choosing
words such as "application programmer", "library programmer", "compiler 
writer", "system administrator", "database administrator", etc.

Or if it really needs to be generic, use names such as Alice, Bob, Carol,
etc. and then describe the role each plays.  But almost any description
can be improved _greatly_ by simply replacing the word "user" with
a much more descriptive name.

(Long ago I would regularly do searches for "user" or " user " in the
PmWiki documentation and replace whatever I could find with something
better.)

Pm


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

Re: [pmwiki-users] Would the sqlite recipe gain anything in storing pages in separate tables based on group?

[Patrick R. Michaud]

On Thu, Aug 23, 2012 at 12:35:24PM +0200, Peter Bowers wrote:
> [...]  Splitting the page-table into multiple
> tables would be non-standard, inefficient, and unnecessarily
> complicated with 0 (probably negative) performance improvement.
> [...]

FWIW, I agree with Peter here.  If the queries are constructed
well (i.e., to use sqlite's filters to reduce the number of page 
entries returned to PmWiki), then a single table will be far more 
efficient and easier to work with than multiple tables.

Pm

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

Re: [pmwiki-users] errors with Pm,apache,Html5mobileBP

[Patrick R. Michaud]

On Sun, Aug 05, 2012 at 03:32:36PM -0300, jack marting wrote:
> I am getting the following error code with
> Pm,php5,apache,html5mobileboilerplate-
> *Warning*: session_write_close()
> [function.session-write-close]:
> write failed: No space left on device (28) in *
> /home/a32071/public_html/pmwiki.php* on line *2063*
> [...]

"No space left on device" means "disk full".  In this
case, I'm guessing whatever drive is holding the /tmp
directory has run out of space, and thus PmWiki is
unable to write session files.

> According to the Cpanel, I have plenty of space.

Note that the amount of space available in your /home directory
(which is what Cpanel is likely reporting) may be very different 
from the amount of space left in /tmp, which is where the
session files are being written.

Pm

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

Re: [pmwiki-users] Pagelists not catching all pages

[Patrick R. Michaud]

[Resending message -- a mail problem on my end caused the message to
not be sent to pmwiki-users.]

I wonder if some of your pagelists are bumping up against the
PHP memory_limit setting.

If you have $EnableDiag set to 1, you can do ?action=phpinfo and
find out what the current setting of "memory_limit" is.  Often
it's something like "8M" or "16M" on older PHPs and in certain
environments.

If it's anything less than "128M", then you could try doubling
it and see if that resolves the issue you're having.  For example,
if ?action=phpinfo reports "16M", you could add the following
near the top of your local/config.php:

   ini_set("memory_limit", "32M");

Let me know if this helps.  If not, is the site at a public URL
that I (or others) could look at?

Pm

On Wed, May 30, 2012 at 10:39:34PM +0100, Elysian Fields wrote:
> I've tried increasing maxincludes and deleting the .pageindex file,
> but they haven't helped. Is there anything else I can try?
> 
> Regards,
> Emma
> 
> On 5/30/2012 2:52 PM, Elysian Fields wrote:
> >Hello there!
> >
> >I run a game wiki that hosts all of our game's setting and lore
> >pages. There are a *lot* of pages, so pagelist functionality is
> >vital for navigation, but suddenly links to pages we know exist
> >are missing. Some pages are listed just fine with the exact same
> >tags and groups involved, while others have disappeared from
> >certain pagelists and not others. We've tried a several ways of
> >doing things differently to get around the problem, but
> >cross-referencing has become a major issue and it's only getting
> >worse.
> >
> >I've tried swapping out our config file for the default to see if
> >one of the recipes we use was borking things up, but it didn't
> >make a difference. From what we can tell, group= name= and fmt=
> >are causing the problems (fmt=#titlespaced works fine without the
> >others but fmt=#titlesummary doesn't). For instance, our
> >categories list, using (:pagelist group=Category:), is losing more
> >than half of the categories we've created.
> >
> >I'm just really poking around in the dark here and trying not to
> >make things worse, but the loss of pagelist functionality is a
> >major issue for site navigation. I'd really rather not have to
> >manually link everything because we add new stuff frequently and
> >the updating alone would be a nightmare.
> >
> >Thanks in advance for your help,
> >Emma
> 

> ___
> 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] Fwd: using rsync for wiki sync

[Patrick R. Michaud]

On Tue, Mar 27, 2012 at 01:47:49AM -0500, tamouse mailing lists wrote:
> On Mon, Mar 26, 2012 at 11:05 AM, Patrick R. Michaud  
> wrote:
> > Encryptions in SiteAdmin.AuthUser should also translate across
> > installations, as long as both installations support the same
> > types of encryption.  In other words, there's nothing site-specific
> > about the encryption -- it simply uses PHP's crypt() function.
> 
> Well, this is interesting. I have two identical installations on my
> box, one for staging, one for production, synchronized via git. If I
> set the password in staging, push to a .git repository, then update
> the production wiki by pulling from the same repository, the passwords
> do not work. The same thing happens going the other way. These are
> side-by-side in the same directory under the farm:
> 
>/var/www/farm/var/
>tamwiki/
>tamwikistage/
> 
> so, what am i doing wrong?

I don't know -- perhaps something else is going on here.  

  (1) What are the versions of PHP on each box?
  (2) What are the first few characters of encrypted passwords on
  each box?  Common ones would be things like "$1$..." or 
  "$2$...", but other options are possible too.

Pm


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

Re: [pmwiki-users] Tracking number of page views statistics

[Patrick R. Michaud]

On Mon, Mar 26, 2012 at 04:37:54PM -0700, wri...@creativevirtuosity.com wrote:
> I would like to track the number of times some of the pages in my Wiki
> are viewed.  Is there a recipe that will allow me to do this?  I can't
> find any specifically targeted to display reader stats in the cookbook. 

For the pmwiki.org site I use Google Analytics (free) to keep 
track of page view statistics -- Google Analytics makes it easy 
to see page visits, organize by groups, where visitors are coming
from, etc.  See http://www.pmwiki.org/wiki/Cookbook/GoogleAnalytics .

(That recipe may need a little updating if Google has changed
their tracking code, but the basic idea is there.)

Hope this helps!

Pm


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

Re: [pmwiki-users] Fwd: using rsync for wiki sync

[Patrick R. Michaud]

On Mon, Mar 26, 2012 at 10:14:07AM -0500, tamouse mailing lists wrote:
> > rsync should work out okay, yes.
>
> I'd like to voice one caveat:
>
> If you are using authuser.php script and protecting your pages, be
> aware the encryptions in SiteAdmin.AuthUser do no translate across
> installations (at least they haven't in my experience).

Encryptions in SiteAdmin.AuthUser should also translate across
installations, as long as both installations support the same
types of encryption.  In other words, there's nothing site-specific
about the encryption -- it simply uses PHP's crypt() function.

Pm

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

Re: [pmwiki-users] Pondering adding comment ability to wiki pages, and thoughts on spam prevention

[Patrick R. Michaud]

On Wed, Mar 21, 2012 at 06:01:48PM +1300, John Rankin wrote:
> 
> Have you investigated the option of a "honey trap"? That is, a field
> within a  with a class for display:none, so a human doesn't see it.
> The theory being that if the field is filled in, it must be a spambot, so
> reject the comment. 

pmwiki.org has used a couple of honeypots for a while, and it works
fairly well.  On the Site.EditForm, we have

(:input hidden code1 6472:)
%comment%Enter code: (:input text code2:)

Then in local.php, something like:

if ($action == 'edit' && preg_grep('/^post/', array_keys(@$_POST)) {
if (@$_REQUEST['code1']!='6472' || @$_REQUEST['code2'] > '') {
$EnablePost = 0;
$IsBlocked = 1;
}
}

The 'code1' hidden input control verifies that hidden input controls 
are being filled in and not modified by the submitter.  The 'code2' 
input control is the honeypot; although it's in the HTML output it 
doesn't display in the browser (because of %comment%).  If code2 comes 
back filled in with a value, it's probably a robot of some sort.

> It would be interesting to know how well this works in
> practice, because it is simple to implement (a field, a css class and an
> if statement) and adds no burden to human commenters. No password or
> captcha is required.

When I added this to pmwiki.org (several years ago), I did some logging 
to see how effective it was -- it did manage to trap quite a lot of
spam submissions.  However, it's not a total solution, as evidenced by 
the fact that spam still manages to get past it onto pmwiki.org.

Pm

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

Re: [pmwiki-users] Site.SiteFooter, 1px Solid Border-Top

[Patrick R. Michaud]

On Fri, Mar 16, 2012 at 12:42:09AM -0500, Patrick R. Michaud wrote:
> >>border-top="1px solid #336633<<
> >><<
> [...]
> %define=hr border-top="1px solid #336633%

Hmm.  My closing quotes got eaten somehow.  :-(

Those should be
  >>border-top="1px solid #336633"<<
and
  %define=hr border-top="1px solid #336633"%

(assuming that whatever ate them before doesn't eat them again.  :-).

Pm



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

Re: [pmwiki-users] Site.SiteFooter, 1px Solid Border-Top

[Patrick R. Michaud]

On Thu, Mar 15, 2012 at 07:29:47PM -0600, Jasyn Jones wrote:
> Beautiful. Worked perfectly. Thank you, Kathryn.
> 
> I've not been able to find this anywhere in the documentation, but based on 
> your reply:
> 
> >>name<<
> ...content...
> >><<
> 
> Makes a div with the class='name' tag?
> 
> That is very helpful.

Technically, it generates a div with the "name" WikiStyle, which
defaults to "class='name'" if not otherwise defined.  See
http://www.pmwiki.org/wiki/PmWiki/WikiStyles.

Knowing this, one can also avoid the .css entry entirely with:

>>border-top="1px solid #336633<<
>><<

This creates a  with style='border-top: 1px solid #336633'>.

You can also do:

%define=hr border-top="1px solid #336633%

and then later

>>hr<<
>><<

whenever you want to have a horizontal rule.

Pm

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

Re: [pmwiki-users] Find out users authorization in PHP when loading page

[Patrick R. Michaud]

On Tue, Feb 21, 2012 at 12:04:48AM +0100, Thomas Lundgren wrote:
> Help! :)
> 
> I´m trying to find a way to (in PHP) check if the user that makes
> PmWiki load a page are authorized to edit that particular page.

The CondAuth() function does what you want:

if (CondAuth($pagename, 'edit')) { ... }

You can provide either authorization levels ('read', 'edit', 
'attr', 'admin') or action names ('browse', 'upload', 'source')
as the second argument to CondAuth().

Hope this helps,

Pm

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

Re: [pmwiki-users] Session conflicts - how to handle this

[Patrick R. Michaud]

On Mon, Feb 06, 2012 at 05:28:59PM +0200, Rogutės Sparnuotos wrote:
> Jan Erik Moström (2012-02-06 15:57):
> > I've got a question for how to handle a session info conflict. I use
> > PmWiki for courses I teach, I usually just put up a quick
> > wiki-installation and author my course pages. These pages are run with
> > the web server as the owner of the session.
> > 
> > On the same server I also have my private wiki which is run as me as
> > the owner of the session.
> > 
> > The problem is that if I log in to a course site, do some editing and
> > then go my own site I get a session  error:
> > [...]
> > How do I handle this situation?
> 
> This looks like a strange error to stumble upon, so my suggestion is
> probably out of band, but try setting a different session name in your
> config.php (so that your browser cookies have different names for
> different sites), for example:
> 
>   # at the beginning of local/config.php of your private wiki:
>   session_name('pmwiki-private');
> 
>   # at the beginning of local/config.php of your public wiki:
>   session_name('pmwiki-teaching');

Likely correct.  Having multiple pmwiki installations on a single
server makes it act just like a wiki-farm; and the sessions are
getting conflated.

See http://www.pmwiki.org/wiki/PmWiki/Passwords#farm  ("How come
when I switch to another wiki within a farm, I keep my same
authorization?").

Hope this helps!

Pm

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

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

[Patrick R. Michaud]

On Mon, Feb 06, 2012 at 11:12:55AM -0500, Crisses wrote:
> 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:)

Out of curiosity, does this work?

(:pagelist name=Group.SpecificPage fmt=#person:)

I agree that what you're seeing is quite odd; at first glance it
seems to me like it ought to be working as you expect.

Pm

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

Re: [pmwiki-users] speeding up pages and pagelists

[Patrick R. Michaud]

On Thu, Jan 05, 2012 at 11:51:24AM -0600, Frank Graffagnino wrote:
> 4. Is there anything I can do to get rid of all those PageStore::ls calls?
> [...]
> 17: 00.08 FPLTemplate: FPLTemplateSliceList
> 18: 00.08 FPLTemplate: FPLTemplateFormat
> 19: 00.10 MarkupToHTML begin
> 20: 00.15 PageStore::ls begin wiki.d/{$FullName}
> 21: 00.18 PageStore::ls merge wiki.d/{$FullName}
> 22: 00.18 PageStore::ls end wiki.d/{$FullName}
> 23: 00.18 PageStore::ls begin $FarmD/wikilib.d/{$FullName}
> 24: 00.18 PageStore::ls merge $FarmD/wikilib.d/{$FullName}
> 25: 00.18 PageStore::ls end $FarmD/wikilib.d/{$FullName}
> 26: 00.18 PageStore::ls begin wiki.d/{$FullName}
> 27: 00.20 PageStore::ls merge wiki.d/{$FullName}
> 28: 00.20 PageStore::ls end wiki.d/{$FullName}
> 29: 00.20 PageStore::ls begin $FarmD/wikilib.d/{$FullName}
> 30: 00.20 PageStore::ls merge $FarmD/wikilib.d/{$FullName}
> 31: 00.20 PageStore::ls end $FarmD/wikilib.d/{$FullName}
> <... repeats a ton of times. Edited for brevity ... >
> 509: 03.82 MarkupToHTML end

How many times does it repeat?  In looking at the above, it appears
to me that the total time needed to perform a single PageStore::ls
sequence is only 0.05 seconds (0.20 - 0.15).  It would be good to
know the timestamp for the *last* PageStore::ls that occurs, as that 
gives an upper bound on the amount of time that would be saved by
eliminating PageStore::ls calls.

Pm

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

Re: [pmwiki-users] speeding up pages and pagelists

[Patrick R. Michaud]

On Thu, Jan 05, 2012 at 11:51:24AM -0600, Frank Graffagnino wrote:
>  Our pmwiki site has pages that sometimes take between 2 - 8 seconds to
> load.  [...]
> enable the following in my local config:
> 
> 1. With pagelist caching enabled, why is there an PageStore::ls for every
> single result?  Should that be in the cache?

PageStore::ls() returns a list of pages matching a pattern passed as an
argument.  PmWiki can't reliably cache the list of pages between page 
requests because external things are allowed to modify the files in
the pagestore directories, and the only way to find out that files have 
been added and deleted is by scanning the directories.

Within a single page request it might be possible for PmWiki to scan the
pagestore directories once and keep a list of everything it finds, but
for sites with lots of pages that could quickly eat up a fair bit of 
memory (and there's a bit of trickiness in that the pattern argument
may be different from one call to the next).  We could add it as an
option, I suppose.

> 2. Is the spike in CPU usage for each pageview normal?  Could something
> like PHP accelerator help?

It depends on the complexity of the pagelist request -- if there's a lot
of sorting or pattern matching going on, it could spike the CPU, yes.

> 3. I have EnableHtmlCache on, but it doesn't appear to do anything.  Is
> this because the pages require login?

Most likely, yes.  HTML caching is of little value when the contents
of a page can be affected by the identity and authorizations of the 
requesting party.

> 4. Is there anything I can do to get rid of all those PageStore::ls calls?

See above -- or perhaps Petko and/or I could work on a caching option here.

> 5. Is there anything I'm doing in my template that is ineffecient?

My guess is that it's the (:if:) markups that are eating up a lot of
CPU time.  Try switching

(:if equal {<$Group}:)-->   (:template first {=$Group}:)
(:if equal {>$Group}:)-->   (:template last {=$Group}:)

See "Page list template special markup" at 
http://www.pmwiki.org/wiki/PmWiki/PageListTemplates .

Using (:template ...:) instead of (:if:) *greatly* reduces the amount
of work the engine has to do to produce the pagelist.

Also, try really hard to move the logic of

   (:if [ exists {=$FullName} && auth read {=$FullName} ]:)

out of the template body and into the pagelist directive itself somehow.  
It's much more efficient to have pagelists exclude pages from formatting 
at the outset than it is to have an (:if:) directive remove the markup 
after it's already been processed.  As a first cut, you can try adding

(:template defaults if="exists {=$FullName} && auth read {=$FullName}" :)

to the pagelist template and change the "(:if ... :)" directive to
"(:template each:)".  Or, you can put the if= directly into the pagelist
directive (see http://www.pmwiki.org/wiki/PmWiki/PageLists#pagelistif).

Try some of these suggestions and see if things improve sufficiently.
If they don't, let's analyze what you have left after making some of the
above changes and see where further refinements can be made.

In the final analysis, pagelists still remain fairly expensive.
We've looked at many ways to try to make things faster in specific cases,
but the overall consensus has typically been that we didn't want to
sacrifice too much flexibility in the process.

Pm

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

Re: [pmwiki-users] adding auth levels

[Patrick R. Michaud]

On Tue, Dec 27, 2011 at 07:26:46PM +, Hans wrote:
> Saturday, December 24, 2011, 12:19:05 AM, Hans wrote:
> 
> > is this about right, or did I miss something?
> > Please check
> > http://www.pmwiki.org/wiki/Cookbook/AddingAuthLevels
> 
> I would appreciate some feedback on this new cookbook page.
> Is it necessary to bind a new auth level into the password cascade?

AFAIR, it's not necessary to bind it into the password cascade.
My memory on PmWiki authorization is a bit fuzzy, but what you have
in the recipe sounds about right.

However, I would recommend using some word other than "post" for 
the new authorization level, however, since "?action=post" is what
gets used to update the contents of a page during an edit (i.e.,
using the word "post" for two different things can add to confusion).
Suggestions might be "foxpost" or "postcomment" or "comment" or
something like that.

Pm

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

Re: [pmwiki-users] using rsync for wiki sync

[Patrick R. Michaud]

On Tue, Dec 27, 2011 at 02:06:43PM +0100, jdd wrote:
> Hello :-)
> 
> I'm in the way of migrating one pmwiki instence from a server to an
> other one.
> 
> I will update the software (pmwiki) manually
> 
> May I use rsync to update the data (in wiki.d?)

rsync should work out okay, yes.

Pm

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

Re: [pmwiki-users] Patrick: Is the PmWiki header picture GPL'd?

[Patrick R. Michaud]

On Sun, Dec 04, 2011 at 01:53:29AM +0100, Petko Yotov wrote:
> Hello Patrick,
> 
> The PmWiki logo on Wikipedia was nominated for deletion. Wikipedia more and 
> more tends to accept images under a Free license such as CC-BY-SA, GNU FDL or 
> GNU GPL. 
> 
> Can we assume that this file pmwiki-32.gif, which is included in the core 
> PmWiki distribution, is also covered by the GNU GPL?
>   http://www.pmwiki.org/pmwiki/pub/skins/pmwiki/pmwiki-32.gif

Yes.

> Moreover, this SVG file is probably a derivative version of the pmwiki-32.gif:
> 
>   http://www.pmwiki.org/pmwiki/pub/skins/boira/images/pmwiki.svg
> 
> The file is part of the Boira skin [1], created by Carles Escrig i Royo and 
> released under the CC-BY-SA license. As a copyright holder of the original 
> picture, can you grant a permission for this derivative work to be released 
> under the Creative Commons Attribution-Share Alike 3.0 License ?
> 
>   http://creativecommons.org/licenses/by-sa/3.0/

Granted.

Pm

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

Re: [pmwiki-users] URL/host based configuration

[Patrick R. Michaud]

On Thu, Dec 01, 2011 at 07:00:16AM +1300, Simon wrote:
> Thanks, firstly I am currently using IIS.
> Secondly I can use index.php, but what difference would it make, PmWiki will
> still interpret the URL in the same way.

If you have the index.php files for each domain in separate
subdirectories, PmWiki will treat each subdirectory as its
own farm instance with its own local/ configuration directory.

If you really want to be switching things based on URL/hostname,
try looking at the value of $_SERVER['HTTP_HOST'].  It should
contain the hostname used to access PmWiki.

> I think that there needs to be an internal change to PmWiki somewhere.

I doubt it -- there are many ways to address this issue without
having to modify PmWiki.

Pm


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

Re: [pmwiki-users] PmWiki default upload file formats

[Patrick R. Michaud]

On Mon, Oct 31, 2011 at 04:44:03PM +0100, Eric Forgeot wrote:
> I'd suggest updating this list: PmWiki should be open source friendly,
> and therefore more open format should be added by default:

I have no problem with the notion of updating the list.

ogg, ogv, mp4  +1

> In addition to psd, xcf (gimp native format) could be added.
> In addition to ai, svg could be added.

+1

> I don't think bmp or wav should be kept, it's quite bad practice to use
> them on the web. 

Uploads to PmWiki aren't used strictly for display on the web; many
places (e.g. educational institutions) use PmWiki as a library/
archive of shared files.  Thus .bmp and .wav should be kept, if only
because they're a very common file format (even if they aren't
a common *web* format).

> If it's for storage, flac (audio loseless compression
> format) could be used instead of wav.  [...]

I don't believe PmWiki should require transcoding to be used as
a storage system.

> There are also more OpenDocument formats:
> http://en.wikipedia.org/wiki/OpenDocument
> At least .odg should be added.
> 
> .epub might be added as well.

.odg and .epub +1

Before adding any of the above to the defaults, let's be 
careful/certain that they don't add increased security risks.

Pm

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

Re: [pmwiki-users] it's time to change pmwiki default skin!

[Patrick R. Michaud]

On Sun, Sep 11, 2011 at 08:35:59PM +0100, Forgeot Eric wrote:
> Hello,
> 
> why not proposing a new default pmwiki skin?
> 
> - for the default installation
> - and for the http://www.pmwiki.org website?
> 
> The current one is not attractive at all (blue, underlined links), it 
> looks like it was designed in 1992, and therefore, it give the 
> impression PmWiki is backward technology, and not powerful at all.

Just a reminder that part of the reason behind the simplicity of
PmWiki's default skin is to make it easier for people (who may not
have a lot of HTML/CSS knowledge) to see how/where to customize it.

This isn't to say that I'm voting in favor of the current skin,
just that "how it looks" isn't the _only_ criterion.

I'd be fine with a high-quality and slightly complex skin if
we also have a good "how to customize your own skin" tutorial
to go along with it.

Pm

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

Re: [pmwiki-users] uploads failing

[Patrick R. Michaud]

On Thu, Jul 07, 2011 at 12:20:56PM -0700, adam overton wrote:
> the host admin is asking whether there's a way to get a more 
> verbose message than the one that shows up on the upload page 
> that says "myFile.jpg: no file uploaded" - they think the actual 
> error is being masked.

The error that PmWiki generates comes from PHP's file upload
errors -- i.e., it's from  $_FILES['uploadfile']['error'].
In this case, PHP is giving an error code of "4", which
corresponds to "No file was uploaded."  PHP doesn't provide
any more information than that about why the file wasn't uploaded,
so PmWiki can't give further information either.

See http://us2.php.net/manual/en/features.file-upload.errors.php.

(Any "masking of the actual error" is therefore being done by PHP,
not by PmWiki.)

> is there a way to see what else is happening (or not happening) 
> during this upload?

Have you (or they) checked the webserver logs?  More detailed
error messages often show up there.

Also, have you tried uploading really small files, to make sure
you're not hitting an upload limit somewhere?

Is there a way we could see the config for the site?

Pm

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

Re: [pmwiki-users] Lack of ability to use % in CSS directives a real pain

[Patrick R. Michaud]

On Sat, Jun 11, 2011 at 08:50:38PM -0500, Tamara Temple wrote:
> In http://www.pmwiki.org/wiki/PmWiki/WikiStyles , one of the Known
> Issues is:
> 
> "Percents in style definitions (like: %block width=50% %) require
> the use of "pct" instead of "%"."
> 
> This is a REAL pain, because "pct" is not valid (nor necessarily
> recognized) CSS unit. Thus my desire to have 3 divs side-by-side
> each taking up 1/3 of the space is not possible without rewiring the
> skin template, thus making it not portable to other skins. Is there
> ANY chance this can be fixed?

IIRC, PmWiki converts the "pct" into a "%" so that it becomes valid CSS.
Is that not good enough?

The reason PmWiki can't use a percent sign directly is because that's
what marks the end of the wikistyle.  :-|  Maybe we could come up with
an alternate wikistyle delimiter that wouldn't have difficulty with the
percents.

Pm

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

Re: [pmwiki-users] Broken (:nl:) ?

[Patrick R. Michaud]

On Sat, Jun 04, 2011 at 07:42:11PM +0200, Oliver Betz wrote:
> In contrast, http://www.pmwiki.org/wiki/PmWiki/MarkupMasterIndex
> contains a description similar to Christian Ridderström's explanation
> from the thread mentioned above:
> 
> | [[#nl]][@(:nl:)@] - Insert a newline into the ''markup'' if one is
> | not already present before or after the directive. This is
> | primarily for use together with directives  such as
> | [[([==]:include ...:) -> #include]] and is  rarely used.
> 
> If my understanding is right, shouldn't (:nl:) be removed from
> Site/EditQuickReference? I think such a special markup shouldn't be
> mentioned there, and it shouldn't be mentioned beneath \\ and [[<<]].

Correct, (:nl:) probably doesn't belong in the EditQuickReference.

Pm

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

Re: [pmwiki-users] passwd after migration

[Patrick R. Michaud]

On Sat, Jun 04, 2011 at 08:57:17AM +0200, jdd-gmane wrote:
> each time I try to edit a page, I'm asked to give the passwd. It's
> offered by firefox, so it's just a little bit surprising. I'm asked
> before editing and after editing (when saving). looks like the fact
> I logged is not saved. some permission problem?

More likely the PHP session configuration isn't correct, and so
the session cookie/data isn't being stored after login.
Is your new server running on Windows, Linux, or ...?

Pm

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

Re: [pmwiki-users] About "fmt=count" : does count the non existant page

[Patrick R. Michaud]

On Fri, Jun 03, 2011 at 03:38:55PM +0200, ABClf wrote:
> I remark that "fmt=count" counts the non created pages ; I'm not sure
> it is always the best behaviour.
> When writing (:pagelist trail=BibliographieDesDictionnaires
> fmt=count:) i'm expecting to get the number of existing pages.
> 
> What do you think about ? what about a new fmt :
> fmt=count -> count all, no change ;
> fmt=countexisting -> count only existing pages.

Try the following:

(:pagelist "if=exists {=$Name}" fmt=count ... :)

That should limit the count to only the existing pages.

Pm

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

Re: [pmwiki-users] External editors, anyone?

[Patrick R. Michaud]

On Wed, Jun 01, 2011 at 07:59:02PM -0500, Tamara Temple wrote:
> I'm curious, has anyone done anything with using an external editor
> for editing wiki pages? I can envision a way to hook up emacs
> possibly to do it with some scripting on both the local and remote
> side, but was just curious if someone had done it before?

Perhaps...

http://www.pmwiki.org/wiki/EmacsModes/EmacsPmWikiMode

Pm

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

Re: [pmwiki-users] Why do we need lots of "vspace"?

[Patrick R. Michaud]

On Mon, May 30, 2011 at 05:41:02PM +0200, Oliver Betz wrote:
> is there a brief explanation why PmWiki controls vertical spacing with
> lots of class='vspace'?

PmWiki wants to be able to translate vertical space in the input
markup to vertical space in the output.  Trying to mimic that
via straight CSS is incredibly difficult.

Pm

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

Re: [pmwiki-users] Syncing / migrating a wiki configuration

[Patrick R. Michaud]

On Fri, May 27, 2011 at 10:44:37AM +0300, Oguz Altun wrote:
> The two sites are running on linux machines, and my only access is
> through ftp. So, no rsync or unison to me. Furthermore, my desktop
> machine is a windows. So when I transfer to my desktop, e.g. by
> wget, permissions are lost. Big down for me.

As long as the directories (i.e., wiki.d/) have the correct 
permissions, the permissions of the individual files aren't 
generally important.  PmWiki will fix them as it encounters
them.

Pm

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

Re: [pmwiki-users] XHTML strict compatible replacement for [[<<]]

[Patrick R. Michaud]

On Thu, May 26, 2011 at 11:28:44AM +0200, Oliver Betz wrote:
> What's the preferred way to create such a clear:something element (a
> "p" would be useful) with PmWiki markup?
> 
> For example, lfloat styled images with some related text beside them:
> 
> %lfloat% Attach:image1.jpg %%
> some text \\
> more text
> (:comment how to clear the lfloat here, i.e. clear:left styled ?:)
> %lfloat% Attach:image2.jpg %%
> This image shall be positioned below the first image

Perhaps override [[<<]] to have this instead:

Markup('[[<<]]', 'inline',
'/\\[\\[<<\\]\\]/',
"");

To really make it a paragraph, perhaps:

$WikiStyleCSS[] = 'clear';

and then

%lfloat% Attach:image1.jpg
some text \\
more text

%p clear=left%
%lfloat% Attach:image2.jpg
This image shall be positioned below the first image

Pm

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

Re: [pmwiki-users] XHTML strict compatible replacement for [[<<]]

[Patrick R. Michaud]

On Wed, May 25, 2011 at 09:02:38PM +0200, Oliver Betz wrote:
> PmWikimarkup [[<<]] produces  in HTML, which is not
> allowed in XHTML 1.0 Strict.
> 
> Can the output generated by [[<<]] generally be changed to get similar
> results with XHTML 1.0 Strict compatibility?
> 
> If not, what is clean markup to clear a lfloat style

IIRC, there's not an exact XHTML 1.0 Strict equivalent to 
.  You can get close by creating an element
that has CSS with 'clear: both', but it doesn't always work 
exactly the same.

Pm

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

Re: [pmwiki-users] Large ammount of articles... about 50k

[Patrick R. Michaud]

On Tue, May 24, 2011 at 07:32:42PM +0200, ABClf wrote:
> If not for the performance, maybe is SQLite storage format more
> convenient for back-up ?

It could be more convenient for some people, yes.  I tend to
use rsync and/or tar for backups, which is extremely convenient 
for me, and makes it easy to restore individual pages if/when 
I need them.

For example, to back up my site to another machine ("orange"),
I simply do:

rsync -auv pmwiki orange:backups/pmwiki

Rsync is smart enough to transfer only the files that have
changed since the previous backup.

Pm

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

Re: [pmwiki-users] Funding?

[Patrick R. Michaud]

On Sun, May 22, 2011 at 12:35:48PM +0200, Oliver Betz wrote:
> What about commercial "clients" - they usually need an invoice for tax
> deduction.

I have access to a corporate entity that can provide 
commercial-level support and invoices for clients that 
need them.

Pm

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

Re: [pmwiki-users] Large ammount of articles... about 50k

[Patrick R. Michaud]

On Mon, May 23, 2011 at 08:07:29PM +, Jaime Sempere wrote:
> Hi Patrick, 
> 
> thanks a lot for your personal help. What do you think about 
> the other suggested solution proposed, using SQLite recipe? 
> What approach would you use?

I've never used the SQLite recipe, so I can't really comment
on it.  Personally, I'd use the file-based approach until it
starts to look like it might not work out (for me it's easier
to manipulate files than database records, which is why PmWiki
is based on the filesystem:-).  When it looks like the file-based 
approach is starting to bog down, then I'd see about using
SQLite or some other database-backed approach.  (But as I mentioned,
on one of my systems we had over 250K pages and never really hit
a point of PmWiki not being able to handle it.)

Pm

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

Re: [pmwiki-users] Large ammount of articles... about 50k

[Patrick R. Michaud]

On Mon, May 23, 2011 at 06:20:03PM +, Jaime Sempere wrote:
> I have been using PMwiki for a wiki and really like its 
> simplicity. I was thinking to use for a large amount of 
> articles (as indicated on the subject of this mail, 
> about 50.000 articles, and later I hope to increase 
> the articles until 250.000 or even more). 

I've had at least one site that had over 250,000 pages
and supported hundreds of authors, with several dozen
editing at the same time.  As long as you aren't wanting
PmWiki to do lots of searches or pagelists of those 
250K pages, PmWiki can handle it.

(If you do need searching capabilities at that scale,
I recommend an external search engine such as htDig
or even Google.  At the site I just mentioned, we let
Google index the site and provide all of our search
results.)

The trick is indeed to make sure the pages don't
end up in the same filesystem directory.  If you have groups,
it's natural to subdivide by group name; if not, then
you can use almost any other criteria you wish that can
be reliably determined from the pagename.  Here's an
example customization that subdivides based on the 
first letter of each article's name:

$FmtPV['$Name1'] = 'substr($name, 0, 1)';
$WikiDir = new PageStore('wiki.d/{$Name1}/{$FullName}');

The first line creates a $Name1 page variable that returns
the first letter of a page's name.  The second line sets
the default page storage ($WikiDir) to be wiki.d with
the articles subdivided into subdirectories based on the
first letter of each name.  Thus an article of Main.HomePage
would end up in wiki.d/H/Main.HomePage .

If subdividing by first letter isn't enough, it's easy
to switch to the first two, first three, etc., letters.

Pm


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

Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?

[Patrick R. Michaud]

On Sun, May 22, 2011 at 09:23:12PM +0200, Oliver Betz wrote:
> Peter Bowers wrote:
> 
> [...]
> 
> >Thus if I need $group or $name early on in my config.php I can either
> 
> just to avoid misunderstandings: This is verbatim $group and $name
> from the HTTP request and might be different from the final value used
> to find the requested page.

...which is exactly why PmWiki doesn't try to impose its own notion
of "group" and/or "page" until after the customization files have 
had a chance to manipulate it a bit.  :-)

ResolvePageName() is Pmwiki's official function that means "determine
the group and page from the available information using PmWiki's 
standard page resolution algorithms".  Calculating pagenames from
specialized requests requires custom solutions (and pmwiki.org
does a fair bit of this in its configuration, e.g. to enable XLPage()
in various groups).

What PmWiki _does_ do is guarantee that at the start of customization,
$pagename is set to

   1. Any value of ?n= if it's set, or
   2. Any value of ?pagename= if it's set, or
   3. The "path info" information from REQUEST_URI (whatever follows
  SCRIPT_NAME), or
   4. Blank otherwise

If it would help to have PmWiki save this value in another variable
as well ($requestedname) for use by customizations and recipes, we
can do that.

Pm

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

Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?

[Patrick R. Michaud]

On Sun, May 22, 2011 at 09:07:43PM +0200, Peter Bowers wrote:
> On Sun, May 22, 2011 at 8:19 PM, Patrick R. Michaud  
> wrote:
> > The correct solution for getting/setting the group and
> > pagename in config.php is already given at
> > http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-group-page
> >
> >    ## Get the group and page name
> >    $pagename = ResolvePageName($pagename);
> >    $page = PageVar($pagename, '$FullName');
> >    $group = PageVar($pagename, '$Group');
> >    $name = PageVar($pagename, '$Name');
> 
> Am I mistaken in thinking that we've periodically run into
> difficulties with this solution related to caching?
> 
> ResolvePageName calls MakePageName which calls FmtPagename which calls
> PageVar which (a) calls PCache() (first problem) and (b) also calls
> PageTextVar which calls RetrieveAuthPage which normally calls
> PmWikiAuth (second problem).

ResolvePageName (and its calls to MakePageName) doesn't normally 
expect to be using variables that would cause any caching issues.
In fact, it doesn't expect to be doing any page reads at all --
it expects to be able to resolve a pagename using just the information
in a url.  I'm having trouble imagining a situation where converting
a url to a pagename requires the use of PageTextVars, or the actual
reading and caching of a page file.

That said, just because I can't imagine it right now doesn't mean
it won't happen for some configurations.  I don't think it would be
a problem at all to have ResolvePageName also clear the caches after
it's done its work, or to disable the caches altogether until
some "we've reached a stable configuration point" is reached (e.g.,
at the beginning of stdconfig.php).

> PITS/01177 is related.

This answer would seem to also address #01177.

Pm

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