Re: [pmwiki-users] File names with spaces in variables

[Dominique Faure]

In fact, a name-spaced image attachment doesn't render as such when
the name comes from a variable because those are evaluated in the
context of the current page which is the only one available in PmWiki.
So, when the Attach:... markup is handled, the variable content has
already been processed into the page content and the inserted spaces
are seen as an "end of markup" separation.

When dealing with the following page content:

  ptv: aaa bbb.txt
  ...
  Attach:{$:ptv}

The markup rules apply one after the other on it, transforming the page to:

  ptv: aaa bbb.txt
  ...
  Attach:aaa bbb.txt

Which results to:

  ptv: aaa bbb.txt
  ...
   bbb.txt

The solution here would be to provide a protected/encapsulated
variable content such as:

  Attach:[=aaa bbb.txt=]

But since the regular PmWiki's content protection markup is acting
before the variable evaluation while rendering the page, the
encapsulation should occur earlier, therefore:

  ptv: [=aaa bbb.txt=]
  ...
  Attach:{$:ptv}

Should do the trick.

On Tue, Apr 5, 2022 at 6:26 AM Simon  wrote:
>
> Thanks for the examples
>
> Attach:{$:gifPTVspaced}
>
>
> is the problem.
>
>
> But longer story:
>
> the problem arose because the Site.ImageTemplate page I created stopped 
> working (I haven't got to the bottom of that yet).
>
>
> It turns out I was debugging the default-default image page template 
> generated by thumblist2-actions.php (after searching for the strong "Back to 
> Gallery")
>
>
> there is a line in there -
>
> %p center% {*$PrevLink} [[{*$FullName}?action=browse | $[Back to gallery] ]] 
> {*$NextLink}
>
> Attach:{*$UpDirUpFile}
>
>
> but my ImageTemplate also has the same problem
>
>
> ngā mihi
>
>
> Simon
>
>
>
> On Mon, 4 Apr 2022 at 22:46, Dominique Faure  
> wrote:
>>
>> Cf. https://www.pmwiki.org/wiki/Test/AttachWithSpaces
>>
>> What is the exact challenge?
>>
>> On Mon, Apr 4, 2022 at 11:26 AM Simon  wrote:
>> >
>> > We now have the cool markup Attach:[=some file name with spaces=]
>> > but I have a challenge when the file name is already in a variable, e,g,
>> >
>> > [[Attach:{*$UpDirUpFile} | download]]
>> >
>> > Does anyone have any suggestions for how I can solve this?
>> >
>> > ngā mihi
>> >
>> > 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

Re: [pmwiki-users] File names with spaces in variables

[Dominique Faure]

Cf. https://www.pmwiki.org/wiki/Test/AttachWithSpaces

What is the exact challenge?

On Mon, Apr 4, 2022 at 11:26 AM Simon  wrote:
>
> We now have the cool markup Attach:[=some file name with spaces=]
> but I have a challenge when the file name is already in a variable, e,g,
>
> [[Attach:{*$UpDirUpFile} | download]]
>
> Does anyone have any suggestions for how I can solve this?
>
> ngā mihi
>
> 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] Corner case issues in pmwiki-2.8.2 under PHP 8.1

[Dominique Faure]

Hi,
On a PmWiki instance set up according to one of the Clean URL
(https://www.pmwiki.org/wiki/Cookbook/CleanUrls) solution AND browsing
to the home page (i.e. no pagename given to an invocation of
pmwiki.php?n=... by the webserver), the following message appeared
with PHP 8.1:

Deprecated: preg_match(): Passing null to parameter #2 ($subject) of
type string is deprecated in /home/debian/websites/XXX/pmwiki.php on
line 333

Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of
type array|string is deprecated in
/home/debian/websites/XXX/pmwiki.php on line 335

Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of
type array|string is deprecated in
/home/debian/websites/XXX/scripts/xlpage-utf-8.php on line 44

Regards,
Dominique

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

Re: [pmwiki-users] New warnings with php 8.1.2

[Dominique Faure]

Hi,

Toying with the prerelease on an updated php8.1-fpm (8.1.2), I got
another set of deprecation warnings:

Deprecated: strncmp(): Passing null to parameter #1 ($string1) of type
string is deprecated in /home/debian/websites/X/pmwiki.php on line
1595
Deprecated: strncmp(): Passing null to parameter #1 ($string1) of type
string is deprecated in /home/debian/websites/X/pmwiki.php on line
1599

Which can be easily removed by inserting at 1595 the following line:

$fmt = strval($fmt);

But I'm not sure this would be optimal.

Regards,
Dominique

On Wed, Jan 26, 2022 at 5:29 PM Petko Yotov <5...@5ko.fr> wrote:
>
> Absolutely, there will be a version 2.3.2 with corrections.
>
> Thanks for your report. I have PHP 8.1.2 on Ubuntu but for some reason
> it didn't show this warning even with error_reporting(E_ALL),
> display_errors and track_errors enabled.
>
> Anyway, I know what causes this, and I have fixed if for PmWiki 2.3.2,
> due in a few days.
>
> This precise warning is indeed caused by a change in PHP where
> previously it treated undefined variables or null as an empty string,
> now it complains that these are undefined. The "@" before the variable
> that previously suppressed the warnings is no longer enough.
>
> The fix I use is to wrap the possibly undefined variable with strval(),
> it makes it behave like it did before.
>
> You can get the pre-release, or even only the files that changed since
> 2.3.1, from the top of the page Changelog:
>
>https://www.pmwiki.org/wiki/PmWiki/ChangeLog
>
> Please test it and let me know if you encounter other problems.
>
> Petko
>
> --
> PmWeekly Blog  :  http://www.pmwiki.org/News
> If you upgrade :  http://www.pmwiki.org/Upgrades
>
>
> On 26/01/2022 16:43, Hans-Jürgen Godau wrote:
> > Today I got a number of deprecated error messages in my pmwiki after
> > setting up php to version 8.1.2 on arch linux. There seem to be new
> > warnings in case of unset parameters to preg_repalce, strlen or
> > strncmp.
> > That happens for examplin pmwiki.php:
> >
> > Passing null to parameter #3 ($subject) of type array|string is
> > deprecated in pmwiki.php on line 75
> >
> > and also in some skin/cookbook scripts.
> >
> > Will there be a Version 2.3.2 with corrections?
>
> ___
> 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-devel] Block Markup

[Dominique Faure]

Hi,

> I would like to do Block Markup
>
> (:markupstart parameter1:)
>
> lorem-ipsum lorem-ipsum lorem-ipsum lorem-ipsum lorem-ipsum lorem-ipsum
> lorem-ipsum
>
> (:markupend:)

Fell free to have a look at SourceBlock or CodeMirror which both
provides this kind of markup for source code highlighting.

Regards,
Dominique

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

Re: [pmwiki-users] Conditional expressions

[Dominique Faure]

Hi,

Several years ago, aside boolean expressions, numerical tests were presents
In the ConditionalExtensions recipe. When Patrick asked me to relicence the
recipe to let him include the boolean evaluation into PmWiki's core, I
tailored it down, keeping the numerical tests.

Even if the recipe might deserves some cleanup/performance enhancements, it
should still work as expected.

Regards,
Dominique


On Tue, Sep 7, 2021 at 10:59 AM Simon  wrote:

> Just on the offchance I can't see it in
> https://www.pmwiki.org/wiki/PmWiki/ConditionalMarkup
>
> there is an "equal" operator, is there a greaterthan or lessthan operator
> in the core release?
>
> I get that you can do it yourself -
> https://www.pmwiki.org/wiki/Cookbook/ConditionalMarkupSamples or
> https://www.pmwiki.org/wiki/Cookbook/ConditionalExtensions
> butt better would be to have consistent markup common to all PmWikis in
> the core
>
> ngā mihi
>
> 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

Re: [pmwiki-users] Problem with conditional markup equal ?

[Dominique Faure]

Hi,

You could also have a try with the MarkupExprPlus recipe :

First, you'll need to set the $EnableExprVarManip flag set in your
configuration in order to enable variable evaluation in expressions.

Then, instead of relying on two distinct expressions as you have in
the "equal" condition, you could use the {(test equal ...)} enclosing
expression which should evaluate as expected in one shot.

Regards,
Dominique

On Tue, Mar 30, 2021 at 12:48 PM Benjamin Grassineau
 wrote:
>
> Hello list !
>
> I have a problem. I would like to test if two variables are equal to
> each other. One of them is stored in a page text variable, the other is
> "present" in the name of the page. It could be, more specifically, an
> existent or non-existent page (I desactivate the message of non-existent
> page, so, the "variable" is located in the adress bar).
>
>
> In the group header, I test this, for example :
>
> - The name of the page where I will execute the test :
> Utilisateurs/InitGYheJLMrKtest
>
> - The value of the page text variable called $:ptv : GYheJLMrK. It is
> located in Utilisateurs.test
>
> - the conditional test : (:if equal "{(substr '{*$Name}' 4 9)}"
> "{Utilisateurs.{(substr '{*$Name}' 13)}$:ptv} ] ":) Great ! (:if:)
>
>
> Problem : the conditional markup "equal" doesn't work ! I don't have
> "Great". It is strange because both expressions work, independently of
> the test. I have the good result which is displayed in both case
> (GYheJLMrK in this example).
>
> Apparently, the problem come from the second term {(substr '{*$Name}'
> 13)} (I eliminated the other candidates).
>
> Does anyone have an idea of the origin of the problem: just the
> syntax, sequence of execution, php version ...? I block !
>
> Thanks for your help.
>
> Benjamin
>
>
> ___
> 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] Save and Edit with Preview

[Dominique Faure]

Hi,

Maybe you need to organize the edit form in the same mood as what you
have on discogs.com: While editing record releases on discogs, the
input form shows only a "preview/submit" button. Once triggered the
editing form is reloaded with a preview AND the real submit button
display.

On Wed, Jun 10, 2020 at 11:20 AM Petko Yotov <5...@5ko.fr> wrote:
>
> On 10/06/2020 10:54, Simon wrote:
> > Are the possible values for  $_REQUEST documented?
>
> No, but for the edit form these are the name="..." attributes in that
> HTML form fields.
>
> If something not documented by Pm or by me, it should *not* be
> considered written in stone.
>
> And if it is, it should be considered written in wiki. ;-)
>
> Also, PHP has been known to introduce deprecations and incompatibilities
> with what previously used to work. Also, the $_REQUEST variable may hold
> a different value from one server configuration to another
>
> See:
>https://www.php.net/manual/en/ini.core.php#ini.request-order
>https://www.php.net/manual/en/reserved.variables.request.php
>
> > I want to only preview if I click Save and Edit, I don't want a preview
> > when I click Edit
> >
> > I'm assuming I need to do something like
> > if ($_REQUEST['saveandedit']) {
> >  $_REQUEST['preview'] = 1; # preview page on Save and Edit
> > }
>
> Almost. It should be more like this:
>
>if(@$_POST['postedit']>'') {
>  $_REQUEST['preview'] = 1;
>}
>
> Petko
>
> > On Tue, 9 Jun 2020 at 08:02, Petko Yotov <5...@5ko.fr> wrote:
> >
> >> This in config.php:
> >>
> >>$_REQUEST['preview'] = 1;
> >>
> >> Note that it always says "Page is unsaved" even when you have pressed
> >> "save and edit". That phrase is in Site.EditForm inside a (:if
> >> e_preview:) conditional, which only checks if a preview is requested,
> >> not if the page was saved.
> >>
> >> Petko
> >>
> >> On 08/06/2020 21:46, Simon wrote:
> >> > Once upon a time I saw some advice on how, when I click save and edit,
> >> > I
> >> > also get a preview without specifically having to click preview as
> >> > well.
> >> >
> >> > I can't re-locate it, so I'm hoping someone can tell me how to get a
> >> > preview  when I click save and edit
>
> ___
> 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] Using attached file names in a pagelist or similar

[Dominique Faure]

Considering this one and the previous topic on the list, I fear that
we urgently need something to loop around a data source (attachment
list, numerical values...) and apply some kind of page templates on
each step :)

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

Re: [pmwiki-users] RFC: ToggleNext or Details+Summary

[Dominique Faure]

> It is also possible to keep both ToggleNext and a cross-browser working
>  but this may sound like a feature creep. Also, I feel that the
> (:details:) markup in a wiki page, while more characters to type than %p
> toggle%, leaves the page source text more readable.

You're perfectly right, but preferring to rely on standardized browser
features and behaviors I thought that we could get the best of the two
world having the one written in term of the other.

Dominique

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

[pmwiki-users] RFC: ToggleNext or Details+Summary

[Dominique Faure]

Hi,

Before all, I want to thank Petko sparing no effort to provide us with
an ever more efficient wiki including interesting features with each
release.

The last release (v2.2.125) was embedding the ToggleNext[1] recipe and
I wanted to share some thoughts on this particular feature:

The ToggleNext recipe is mostly a upgraded rewrite of what was offered
by the previously released as beta Untoggle[2] recipe, ie. a clever
use of css and javascript to offer visual toggling of sibling document
divs.

For several years, the W3C was defining the ...
html block element[3] which should enable the same features in recent
browsers natively[4], and it has already been handled (at least
partially) in our favorite wiki engine[5].

My concern here is two-fold:

In order to keep being future-proof as usual with PmWiki, the
ToggleNext recipe should be relying on the  and 
elements for the html rendering, even if this implies providing some
kind of element+behavior simulation for older browser (aka a
polyfill), such as those easily available on github[6][7].

For now we are in lack of a proper wiki markup definition to handle
the  and  elements as a sole structural block
possibly nestable (btw, there're similar potential issues with the
 and  couple and one of the  +  form).

Perhaps, we need a slightly more elaborate (:div:) handling which
would allow to specify if a (:summaryNN:) block markup could render as
the summary element of the following first encountered (:detailsNN:)
block such as:

(:summary:)
Nested content
(:details:)
The de-facto container
(:detailsend:)

giving:


  
  Nested content
  
The de-facto container


Regards,
Dominique

References:
[1] https://www.pmwiki.org/wiki/Cookbook/ToggleNext
[2] https://www.pmwiki.org/wiki/Cookbook/UnToggle
[3] 
https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element
[4] https://caniuse.com/#feat=details
[5] https://www.pmwiki.org/wiki/PmWiki/BlockMarkup#semantic
[6] https://gist.github.com/remy/370590
[7] 
https://github.com/javan/details-element-polyfill/blob/master/dist/details-element-polyfill.js

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

Re: [pmwiki-users] Cookbook MarkupExprPlus

[Dominique Faure]

Hello Hans,

The recipe has been fixed (and uploaded) and the PHP 7.2 compatibility
should be complete now.
No features were harmed in the making the fix :)

Regards,
Dominique


On Tue, Nov 12, 2019 at 2:18 PM Hans  wrote:

> Hello Dominique,
> when using any of the arithmetic Markup Expressions from
> MarkupExprPlus https://www.pmwiki.org/wiki/Cookbook/MarkupExprPlus
> it is throwing error on PHP 7.2:
> "Deprecated: Function create_function() is deprecated in ...pmwiki.php on
> line 499"
>
> I can see from the code in markupexprplus.php that the arithmetic MEs
> using PPRE() calls, which leads to PCCF() calls, which leads to the
> error. Is this fixable?
> The recipe is flagged to be PHP 7.2 compatible, but apparently it is
> not.
>
> For my very simple purposes I could substitute the arithmetic MEs
> with some very simple code:
> $MarkupExpr['add'] = '$args[0] + $args[1]';
> $MarkupExpr['sub'] = '$args[0] - $args[1]';
> $MarkupExpr['mul'] = '$args[0] * $args[1]';
> $MarkupExpr['div'] = '$args[0] / $args[1]';
>
> but the MarkupExprPlus MEs allowed for more complex expressions.
>
>
> Best regards,
>  Hans
>
>
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Any way to get page counts with breaks based on a PTV?

[Dominique Faure]

Hi,

You may have a try with the variables handling provided by the
MarkupExprPlus recipe.

Regards

On Mon, Nov 11, 2019 at 9:15 PM Christopher Cox  wrote:

> Consider the following template and assume a SysUser group with pages of
> users having the PTVs: department, name and active.
>
> [[#test1]]
> (:template defaults order=$:department:)
> (:template first {=$:department}:)
>
> Users in {=$:department}
> (:template each:)
> (:if equal {=$:active} true:)
> * [[{=$FullName}|{=$:name}]]
> (:ifend:)
> (:template last {=$:department}:)
> {=$:department} contains  pages.
> [[#test1end]]
>
>
> My question is if there's any way to get establish a counter that is
> zeroed for each new department and can be referenced in the "last" where
> I have the .
>
> I know there are counters for pages and groups.  Here, it's the same
> group, and I want a counter that I can set somehow based on the PTV
> change.  Possible?
>
> Ultimately, I'm hoping to use such things to generate pie charts (in
> case you wondering).
>
> Department  Count
> --  -
> IT  3
> Accounting  5
> etc..
>
> Yes, I know I can do this with lots of individual pagelists, just trying
> to see if there was a more efficient way.
>
>
> ___
> 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] "/e" in Cookbook / ExternalLinks2

[Dominique Faure]

Hi,

This could be nice if we could have these auto-generated from the PmWiki
Core itself, taking account of the $ScriptUrl definition, no?

Regards,
Dominique


On Wed, Sep 18, 2019 at 9:01 PM Petko Yotov <5...@5ko.fr> wrote:

> I think I've fixed the recipe, if you test it please report if it works.
>
> As of 2019, for my websites, instead of this recipe, I'd certainly *not*
> enable the %newwin%/target="_blank" link feature (people know how to
> middle-click or long-tap to open a new window), and if I needed the
> external link styling I'd place into pub/css/local.css these styles:
>
>a.urllink:not([href*="://www.example.com"]) {
>  color: #2f6fab;
>}
>
>a.urllink:not([href*="://www.example.com"]):after {
>  content: '\2197'; /* NE arrow */
>}
>
> "a.urllink" is the default CSS class for external links, unless a recipe
> or a skin modified it. www.example.com is your domain name.
>
> Petko
>
> On 17/09/2019 17:02, Donald Z. Osborn wrote:
> > Noted the /e parameter - perhaps the very same one that causes issues
> > with
> > PHP7.2 - in:
> > https://www.pmwiki.org/wiki/Cookbook/ExternalLinks2
> >
> > Should/can this be fixed, or is there a recommended alternative?
>
> ___
> 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] New features to be enabled in the PmWiki core

[Dominique Faure]

Hi,

As far as the purpose is to ease the wiki maintenance, here's the list of
recipes (not counting my own ones) I'm used to install almost
unconditionally and that I'd love to get in the core:

https://www.pmwiki.org/wiki/Cookbook/LocalCSS
https://www.pmwiki.org/wiki/Cookbook/Toggle
https://www.pmwiki.org/wiki/Cookbook/MovePage
https://www.pmwiki.org/wiki/Cookbook/ExpireDiff
https://www.pmwiki.org/wiki/Cookbook/NewPageBoxPlus
https://www.pmwiki.org/wiki/Cookbook/CaseCorrection
https://www.pmwiki.org/wiki/Cookbook/CleanUp

Regards


On Thu, Aug 29, 2019 at 10:00 PM Petko Yotov <5...@5ko.fr> wrote:

> Hello,
>
> This is to let you know that I've added to the PmWiki core in Subversion
> a number of features from my own recipes/addons that are somewhat
> popular and that I see myself installing on every new wiki I create.
>
> Because many of you already use these or similar addons, the newly added
> features will be disabled but it will be very easy to enable them from
> config.php.
>
> Here is the list:
>
> Editing a wiki:
> * PreviewChanges - this has been enabled on PmWiki.org for years, shows
> a highlighted diff in Preview mode (already added in 2.2.118).
> * NotSavedWarning - signal to editors when they are moving away from the
> edit form and risk losing their changes (the Author/Summary prompts from
> the recipe are not included in the core, because now it is easy to add
> "required" attributes to the edit form fields).
> * A sub-feature from NotSavedWarning scrolling to the same position when
> pressing either Preview or Save (enabled by default).
> * EditHelp - predictive insertion of markup like list bullets (I use
> this a lot, especially on a mobile device).
>
> Reading a wiki:
> * DeObMail - obfuscating e-mail links for spam bots.
> * PmTOC - a really basic "table of contents +/- numbered headers",
> currently a simpler subset of the AutoTOC recipe will be included in the
> core, see:
>https://www.pmwiki.org/wiki/PmWiki/TableOfContents
>
> Again, these will be disabled in the default installation, but could be
> enabled as easily as adding $EnableNotSavedWarning = 1; if you decide to
> use any of them.
>
>
> Other features planned for inclusion:
> * PmEmbed, a subset of the Ape recipe (minus the OpenStreetMap part
> which is too complex to include in the core at this point). The main
> embedding function is light and simple and can be easily extended. As
> more people need to include videos or other media from external
> platforms, this recipe can do the job in a simple way.
>
>
> Other recipes (actually their feature set) under consideration:
>
> * DragDropMultiUpload - upload files by dropping them into the edit
> form.
> * LocalTimes - RecentChanges enhancements.
> * LocalCSS - CSS in a wiki page.
> * A small subset of the features of Attachtable - I use a very old fork
> with just rename/delete/restore.
> * PageListMultiTargets - this allows a pagelist "link=" argument to
> accept more than one link. We should decide if "link=Page1,Page2" should
> include pages that link to *any* of the pages or to *both* pages.
> Currently it includes any of the pages, and you need to use
> "link=+Page1,+Page2" to require both pages.
>
> * Add a set of CSS rules for editors to be able to more easily create
> nicer-looking tables -- to the default skins -- obviously other skins
> can redefine the styles of the same classname(s), like they currently do
> for the "frame" class.
>
> You can follow the progress of this project at:
>
>https://www.pmwiki.org/wiki/PmWiki/ChangeLog
>https://www.pmwiki.org/wiki/Site/AllRecentChangesShort
>
> Tell me what you think. What recipes/addons do you install on your wikis
> (especially if you have installed multiple wikis)?
>
> I am interested in features you and your editors actually use, not
> "might be nice", and that do help editors create better content with
> less effort.
>
> See how the above recipes once configured are mostly automatic, and
> don't add new markups that people are required to learn. And they
> considerably enhance the editing experience or the webmaster's work.
>
> Please comment.
>
> Petko
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

Hi,

> Please wait a day or two a fixed release.

Sorry for the extra delay for it, but the last version just released
is now better handling the source code syntax highlighting, providing
the full file content when the generated dependencies data couldn't be
written to the cookbook folder.

Extra pending fixes have been also integrated for source line
highlighting and embedding into (:markup:) sections.

The unix copy/paste issue you got is really something that I can't
manage and should be reported directly to the CodeMirror author.

Regards

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

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

> Ok, I got the link now after specifiying a mime type.
>
> Ufortunately it didn't work after clicking the link:
>
> PmWiki can't process your request
>
> # Unable to generate CodeMirror mode dependencies file
> (/www/vhost/xyz.xyz.chalmers.se/htdocs/Farm-2.2.97/cookbook/cm-modes-dependencies.php).
> # Configuration data given below:
>
> $CodeMirrorModesReferenceUrl = '$FarmPubDirUrl/codemirror-5.48.0';
> SDVA($CodeMirrorModeSpecs, array (
>'text/apl' => 'apl',
>'application/pgp' => 'asciiarmor',
>'application/pgp-encrypted' => 'asciiarmor',
>'application/pgp-keys' => 'asciiarmor',
>'application/pgp-signature' => 'asciiarmor',
>
> [cut long list]

This message indicates that the recipe didn't get enough permissions
to write it's dependencies file into the cookbook directory, and in
this case you should have been able to copy-paste most of the ouput to
manually create the file yourself, but apparently, I missed something
here.

Please wait a day or two a fixed release.

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

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

I just got 1 hour free to make some tests updating SourceBlock to PHP7
with Github's GeSHI release v1.0.9 and found that the highlighter
wasn't fully compliant:

Deprecated: Function create_function() is deprecated in
C:\inetpub\wwwroot\pmwiki-2.2.116\cookbook\geshi\geshi.php on line
4698

Ironically, a fix has already been committed but not released
(https://github.com/GeSHi/geshi-1.0/commit/ed9f49a7c7a195f6ed2bc864f5ce03b990b5867d)

Anyway, I updated the recipe itself.

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

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

Le 15 juil. 2019 4:15 PM, "Peter Kay"  a écrit :

Can CodeMirror adjust its markup?  Look for (:source...:) instead of
(:code...:)?  That might be an option as well, and might be worth checking.


IMHO, this should be written as an extra script (as already done with the
code highlighter for the main recipe), providing both the markup and the
parameters translation (language identifier...).
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

> On https://www.pmwiki.org/wiki/Cookbook/SourceBlock-Talk author which
> I believe is on this list says he is waiting for geshi to be updated for
php
> 7.2...

You're right, I was the one who wrote this recipe. For the record, I wasn't
aware that GeSHI had been forked on github when I answered on the Talk
page. I was also stopping to work on it for technical reasons: Using a PHP
tools like GeSHI to render the source code may be an heavy task for the
server side while modern browsers have all the features available to do
this fluently and more.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

> Also could not get syntax highlighting to work, there seems
> to be some sort of setup procedure required, but I can't find any docs that
> clearly explains it.

Once the recipe own files and the CodeMirror distribution have been
put in the proper places, the setup merely consists in trying to
render a piece of code resulting as a single link to follow to perform
the recipe setup.

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

Re: [pmwiki-users] Syntax highlighting recipes

[Dominique Faure]

Hi,

Feel free to have a try with the CodeMirror recipe (
https://pmwiki.org/wiki/Cookbook/CodeMirror).

When I managed to make work CodeMirror in rendering-only mode for all the
extra languages, I found it a nice alternative to SourceBlock and its
un-maintained GeSHI.
It shouldn't be too difficult to write a compatibility recipe able to
translate SourceBlock (:source... :) blocks into CodeMirror (:code...:)
ones.

Regard,
Dfaure

On Mon, Jul 15, 2019 at 10:54 AM Johan Bengtsson  wrote:

> My employer uses several pmwikis, we are currently using pmwiki-2.2.97 and
> php 5.5.18.
>
> On one of the biggest wikis we are using the  SourceBlock recipe (
> https://www.pmwiki.org/wiki/Cookbook/SourceBlock).  But it has the
> preg_replace problem. I don't know if it's possible to fix that and make it
> php 7.2 compliant?  It is dependant on geshi which is abandoned??
>
> I have looked at a number of other recipes but most of them seems to have
> problems one way or the other...
>
>  https://www.pmwiki.org/wiki/Cookbook/Beautifier # old,
> preg_replace prob...
>
> https://www.pmwiki.org/wiki/Cookbook/PmPygment  # can't make it work on
> our wiki...
>
> https://www.pmwiki.org/wiki/Cookbook/Precode  # no php 7.2?, don't like
> the syntax,  but seems to work.
>
> https://www.pmwiki.org/wiki/Cookbook/SourceBlock  #  what we use now,
> preg_replace prob, geshi probs??
>
> https://www.pmwiki.org/wiki/Cookbook/Syntaxlove # buggy...at least for
> us...
>
> https://www.pmwiki.org/wiki/Cookbook/ZCode  # only for external files but
> not for code in the wiki???
>
> The ideal solution would perhaps be something with a similar syntax to
> SourceBlock but using highlight.js...?
>
> -Johan Bengtsson
>
> ___
> 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] WYSIWYG on PmWiki

[Dominique Faure]

A wiki engine work is mainly a one-way rendering from the wiki text into
html during page building.

Dealing with a WYSIWYG editor would consists in handling the exact
opposite, ie. getting back some html from a browser's content-editable
block (the WYSIWYG equivalent of a textarea editing) and translate it into
wiki markup.

If this can be done more or less easily for basic styling, the task is
rather difficult for complex markup such as tables or div sections and
almost impossible for pagelist directives or form elements and all kind of
custom stuff defined by various cookbook recipes.

Therefore, I'm afraid that in this case, the "Worse" is the best.

Dominique

On Tue, Jun 18, 2019 at 6:24 AM Svetlana Tkachenko 
wrote:

> Peter Kay  wrote:
> >
> > > It would be nice to know how Google Docs overcomes this problem
> >
> > Probably through the liberal application of money, which can hire people
> to work.
> >
> > Pmwiki's markup is translated to HTML server-side by a php-based engine.
> In order to have a WYSIWYG editor, you would need a way to translate
> client-side, probably javascript?
>
> Does it have to be javascript? Perhaps an api which can translate from
> html to markup and back on the server side?
>
> With another wiki the translation from html to markdown is enormously
> difficult. Is this the case here?
>
> They resolve this by adding additional attributes (like  data-foo="bar">) to the html markup. Is this the best approach?
>
> -- Sveta
>
> ___
> 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] Screen-reader friendly PmForm captchas

[Dominique Faure]

The Cookbook/Captcha recipe should be able to provide some help here, no?

Regards,
Dominique


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

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

Re: [pmwiki-users] how to "edit here" ?

[Dominique Faure]

Hi,

May be you have a try on one of the following cookbook recipes:

* CodeMirror (https://www.pmwiki.org/wiki/Cookbook/CodeMirror)
* EditPosFix (https://www.pmwiki.org/wiki/Cookbook/EditPosFix)
* RememberEditPosition
(https://www.pmwiki.org/wiki/Cookbook/RememberEditPosition)

Which are both able to keep cursor position between page editions

Regards,
Domibique

On Mon, Nov 12, 2018 at 10:40 AM Piotr A. Dybczyński
 wrote:
>
> Peter,
>
> thanks for your suggestion but this is not what I need.
>
> I am looking for a way to start editing a page by clicking a piece of it with 
> the
> cursor in a specified place. But I want a whole page to be available for 
> editing.
>
> Something similar to the effect of "save and continue editing" with a cursor
> still in the just edited place.
>
> Cheers,
> Piotr
> --
> /**
>   dr Piotr A. Dybczyński
>  homepage: http://www.dybczynski.pl/Piotr  e-mail: pi...@dybczynski.pl
> PAD***/
>
>
> __ Information from ESET Mail Security, version of virus signature 
> database 17890 (20180815) __
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
>
> ___
> 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] GDPR

[Dominique Faure]

(I forgot to answer to the end of the point)

> Anyone else have particular GDPR-related needs? Can anyone think of other 
> places user information is potentially collected (even IP address, etc.) and 
> cookies set?

An easy one: The web server itself (through its own cookie handling
configuration and its access/error log files).
But, according to your specific hosting architecture (eg. shared
web-only solutions), you could not always deal with these as you like!

Anyway, IMHO, and according to
https://www.demandlab.com/insights/blog/dont-get-caught-with-your-hand-in-the-gdpr-cookie-jar/
This should easily be solved with a wiki page of explanations on local
cookie usage and some clever use of the HttpVariables cookbook recipe
in order to track an set a persistent cookie flag controlling their
display.

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

Re: [pmwiki-users] GDPR

[Dominique Faure]

Hi,

As far as you don't rely on some cookbook recipe specific cookie
usage, and you don't extend abusively the php session lifetime, I
think that according to
https://webmasters.stackexchange.com/questions/114973/are-session-cookies-exempt-from-consent-under-gdpr
There's should be no problem with that in PmWiki. No?

-D-

On Wed, Sep 5, 2018 at 1:54 PM Criss Ittermann  wrote:
>
> Hi, All,
>
> California has adopted GDPR standards, making this no longer just an issue 
> for people only dealing with the EU. And more municipalities will do this as 
> time goes on.  Because everyone wants a piece of Facebook & Google's hugely 
> profitable pie.  And the fines are steep enough to put any of us out of 
> business or out of a house.
>
> I believe PmWiki sets cookies for visitors, not just people who log in to the 
> site to author.  I'm not sure how to circumvent the cookie setting, and make 
> it contingent on consent.  "Using this site means you're OK with cookies" is 
> not sufficient. Someone VISITING your site is not consent to put cookies on 
> their machine, and sites doing that will probably eventually get sued.  
> Active consent is required.
>
> So here's what I need help with:
>
> A way to disable cookie setting until the website user clicks OK that the 
> site will set cookies, and a persistent-until-clicked-OK banner to that 
> effect with the button.  If they don't click OK, no cookies are set.  Former 
> cookies (before a date set by the person setting it up) should be UN-set I 
> would think, if they have previously used the site.
>
> And then we also need to TRACK their consent.  A SiteAdmin/GDPRCookieTracking 
> page that logs the IP, timestamp, and author name if they have one that they 
> consented might suffice. Yes it might get long.  But better a long log than 
> no log at all.
>
> This is EASIER if visitors don't have cookies set, then the login form &/or 
> edit form need a GDPR checkbox that is UNchecked by default — it can 
> disappear after the first time a cookie is set for that machine/author name, 
> and we don't have to worry about all site visitors needing to click OK.
>
>
> I can put up documentation on adding a GDPR compliance box to email 
> submission forms on the PmForm site since I've worked on that before and 
> doing so is fairly straightforward (for me anyway).  I will probably have to 
> do the same for comments on some of my recipes. Yay.  So logging in to 
> author, leaving comments (which contain potential personal identifying info 
> like name, email, IP, and the comment content itself), and sending emails via 
> PmWiki.
>
> Anyone else have particular GDPR-related needs? Can anyone think of other 
> places user information is potentially collected (even IP address, etc.) and 
> cookies set?
>
> Crisses
> 
> "The shipping labels of one U.S. electronics company may best capture just 
> how global the marketplace has become: 'Made in one or more of the following 
> countries: Korea, Hong Kong, Malaysia, Singapore, Taiwan, Mauritius, 
> Thailand, Indonesia, the Philippines.  The exact country of origin is 
> unknown.'"
>  -- p. 47, Organizational Behavior 9th Edition, Luthans, 2002.
>
>
> ___
> 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] Talk Pages

[Dominique Faure]

Hi,

IMHO, these practises are good candidates as Cookbook recipes. Nobody say
that recipes should always provide a bunch of php/js/ scripts.

Regards

On Sun, Feb 18, 2018 at 6:12 AM, Christopher Cox 
wrote:

> On 02/17/2018 08:47 PM, Chuck Dee wrote:
>
>> Perhaps there needs to be another category of modifications other than
>> recipes
>> that covers this level of complexity.  I've seen other modifications that
>> require modification to code in several locations that I haven't thought
>> were
>> recipes, but that's what they're called.
>>
>
> The point is this is "easy" and requires no code modifications.  Just some
> markup on a page to implement.
>
>
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>



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

Re: [pmwiki-users] Talk Pages

[Dominique Faure]

Hi,

In PmWiki, Talk pages are strictly regular pages.

Its up to you to setup some kind of binding (usually a link) between a
specific page and another talk-related one.

Group headers/footers (http://www.pmwiki.org/wiki/PmWiki/GroupHeaders) are
convenient places where to insert such links.


On Thu, Feb 15, 2018 at 5:30 PM, Jim Syler  wrote:

> Okay, I’m sorry for cluttering up the list, but I’m at my wit’s end. How
> do you enable Talk pages? This seems like a basic function of a wiki, and I
> see that PmWiki supports them, but there are no Talk pages associated with
> the pages on my site, I don’t see how to install Talk pages, and searching
> for “Talk Pages” on PmWiki just gets me a long list of actual Talk pages on
> PmWiki, not anything about how to activate them. I feel like I’m missing
> something simple and obvious. Help?
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>



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

Re: [pmwiki-users] Markup expression for substring delimited by string

[Dominique Faure]

> I am looking for a markup expression which will return a substring
starting from the left up until, say, the first punctuation mark.
>

Hi,
This is rather easily done using MarkupExprPlus reg_replace feature:

(:text: Lorem ipsum dolor sit amet, ad has esse duis lucilius, platonem
reprimique eam at, et etiam augue interpretaris eos. Est odio nemore in,
dolor meliore an his. Quod praesent delicatissimi ut qui. Iusto
reprehendunt pro ea. Ad vel volutpat constituam.:)
* text: {$:text}
* processed: {(reg_replace '/^([^.,]+)[.,].*/' '$1' '{$:text}')}

=>

* text: Lorem ipsum dolor sit amet, ad has esse duis lucilius, platonem
reprimique eam at, et etiam augue interpretaris eos. Est odio nemore in,
dolor meliore an his. Quod praesent delicatissimi ut qui. Iusto
reprehendunt pro ea. Ad vel volutpat constituam.
* processed: Lorem ipsum dolor sit amet

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

Re: [pmwiki-users] Direct me to a Cookbook that uses markup that takes an uploaded attachment as a parm

[Dominique Faure]

Hi,

Feel free to have a look on the way I'm used to handle attachments with the
help of http://www.pmwiki.org/wiki/Cookbook/LinkedResourceExtras.



On Fri, Mar 31, 2017 at 5:29 PM,  wrote:

> I wanting to do something in a recipe in php that takes in an argument of
> Attachment or Group/Attachment or Group/Page/Attachment
>
> In particular needs to support the latter (down to uploads per page).  I
> just want to make sure I code it "right".
>
> Thanks for any hints.
>
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>


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

[pmwiki-users] CodeMirror recipe update

[Dominique Faure]

Hi,

Just a few words to announce a CodeMirror recipe update.

Most of the editor built-in features advertised at the author's website, as
far as relevant in a PmWiki page editing context, are now available as
configuration presets.

Two new presets would enable the editor vertical resizing by dragging the
enlarged bottom border with the mouse, and also keep visible the last
cursor position in browser local storage for each edited/previewed wiki
page.

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

Re: [pmwiki-users] quoted text markup

[Dominique Faure]

IMHO and after a look at
http://www.pmwiki.org/wiki/PmWiki/MarkupMasterIndex, I would suggest
to keep on using the prefix/suffix pattern that emerges in the
"Character format" section, and chosse one of:

'"quoted text"'
{"quoted text"}
["quoted text"']

Regards,
Dominique


On Tue, Sep 20, 2016 at 9:07 PM, Hans  wrote:
>> I think I'd prefer this as a recipe (or an addition to an existing
>> recipe) rather than core for now.
>
> of course that is always an option.
>
>> I'm concerned a change to core might match code display segments
>> where a single "" represents an empty string.
>
> would code segments not be written inside [@   @] markup, i.e.
> as escaped code?
>
> My markup suggestion could be tightened a bit disallowing spaces after
> "" start and before "" end. That would make it less likely to catch
> single instances of  ""
>
> something like this:
>
> Markup("\"\"","inline","/\"\"(\\S.*?\\S)\"\"/",'$1');
>
>> 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"".
>
> Yes, but some people would like to see smart quoting. And using 
> tags would make that possible.
>
> I guess there are two common types of using double quotes:
> A) as a way to "quote", in which case  tags would be good,
> B) as a way to emphasise a word, in which case  tags would be
> good, and PmWiki allows this using two single quotes.
>
>
> Hans
>
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users



-- 
Dominique

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

Re: [pmwiki-users] Search problem

[Dominique Faure]

On Thu, Sep 8, 2016 at 10:22 AM, Ulf Bro  wrote:
> More information about this error may be available in the server error log.


Technical error reports are always useful to track this kind of behavior... :)

-- 
Dominique

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

Re: [pmwiki-users] UserAdmin

[Dominique Faure]

This should mean that:

* The php 5 flavor is selected by the file extension and you should
use the .php one to get the v5.6.8 running (Free is known to do weird
things with php),
* The config file error line 36, lets think to some erroneous object
related declaration that was not supported anymore in recent php
versions,
* The useradmin-core ones shows that the UserAdmin recipe hasn't been
made "php 5.5" compatible, ie. it's still using deprecated regular
expression syntax.

IMHO, you should try to stay with php 5.1+ until the recipe hasn't been updated.


On Thu, Aug 18, 2016 at 3:27 PM,   wrote:
> Yes, I cloned index.php5 to index.php
>
> And now
>
> http://testpmjv.free.fr/index.php?n=Main.HomePage?action=phpinfo
>
> returns
>
> Warning: Creating default object from empty value in 
> /var/www/sda/1/8/testpmjv/local/config.php on line 36
> PHP Version 5.6.8
>
> Whereas
> http://testpmjv.free.fr/index.php5?n=Main.HomePage?action=phpinfo
> returns PHP Version 5.1.3RC4-dev
>
> And If I test the action=user with index.php
> http://testpmjv.free.fr/index.php?n=Main.HomePage?action=user
>
> many lines with errors occurs before the page of my site
>
> like
>  Deprecated: preg_replace(): The /e modifier is deprecated, use 
> preg_replace_callback instead in 
> /var/www/sda/1/8/testpmjv/cookbook/useradmin-core.php on line 1014
>
> Deprecated: preg_replace(): The /e modifier is deprecated, use 
> preg_replace_callback instead in 
> /var/www/sda/1/8/testpmjv/cookbook/useradmin-core.php on line 1177
>
> Warning: Cannot modify header information - headers already sent by (output 
> started at /var/www/sda/1/8/testpmjv/cookbook/useradmin-core.php:1014) in 
> /var/www/sda/1/8/testpmjv/pmwiki.php on line 1240
>
> A new idea?
>



-- 
Dominique

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

Re: [pmwiki-users] UserAdmin

[Dominique Faure]

The major difference between your two urls seems to be the .php/.php5 extension.
Did you tried changing the index.php5 to index.php ?


-- 
Dominique

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

Re: [pmwiki-users] UserAdmin

[Dominique Faure]

Hi,

> So Is there a way to force the PHP's version of all the page?

According to http://les.pages.perso.chez.free.fr/migrations/php5v6.io
You should alter your .htaccess with something like:


php56 1


-- 
Dominique

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

Re: [pmwiki-users] problem with https and includeurl

[Dominique Faure]

(reposting to the list as I wrongly replied to the sender)

Hi,

Taking profit of the MakeLink PmWiki's internal function, the markup was
tailored to let you use all the intermap features to handle your links.
More precisely, you should specify local resources with the "Path:" prefix.

I modified the sample given on the cookbook page accordingly.

Regards,
Dominique


On Tue, Aug 16, 2016 at 4:07 PM, Byron Lunz  wrote:

> Thank you Petko! Your "possible fix" seems to work (although $url was on
> lines 75 & 83 for me). This is just another reason to love pmwiki - it's
> actually SUPPORTED! Thanks again.
>
> So who is responsible for fixing/updating the current includeurl.php file
> on the site?
>
> Byron
>
>
> On Mon, Aug 15, 2016 at 10:41 PM, Petko Yotov <5...@5ko.fr> wrote:
>
>> Indeed, I confirm that the documented way to include URLs on the same
>> server doesn't work:
>>
>>   (:includeurl /samplesite/path/page.html :)
>>
>> The reason is that the target URL is processed by the MakeLink function
>> in order to test if the external link is approved.
>>
>> But if it is not an external link (http, https, ftp...) this function
>> assumes it is an internal page link, and having more than one among "/" and
>> "." would be an invalid page name, so it returns an empty string.
>>
>> With the current includeurl.php, the loading of local resources is
>> broken. You can use the full URLs.
>>
>> A possible fix would be to replace "$url" with "$tgt" on lines 80 and 88.
>>
>> 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-08-16 03:51, Byron Lunz wrote:
>>
>>> I upgraded to the latest version 2.2.89 but still see the same problem.
>>> Using the latest includeurl.php file from pmwiki.org, I can include only
>>> links which begin with http or https - not links to local files such as
>>> (:includeurl /update/file.php :)
>>>
>>> Should links to files work (they used to), or do I need to edit all my
>>> links to full URLs??
>>>
>>>
>>> On Sun, Aug 14, 2016 at 5:54 PM, Byron Lunz  wrote:
>>>
>>> Well, I spoke too soon. The new includeurl.php did indeed allow the
 included https links to work, but various others which were only
 pointing
 to files (e.g. "includeurl /update/some.php") stopped working.

 On Sun, Aug 14, 2016 at 6:34 AM, Byron Lunz 
 wrote:

 Hi, Petko,
>
> Thank you! Installing the latest version of includeurl.php did the
> trick!
>
> Byron
>
>
>
>
> On Sat, Aug 13, 2016 at 10:35 PM, Petko Yotov <5...@5ko.fr> wrote:
>
> Normally browsers will refuse to load resources from the "http" scheme
>> if the requesting page is on a "https" connection.
>>
>> The current version of includeurl.php works fine with a "https" URL.
>> On
>> your page it does not appear to be the case: even if you have in the
>> source
>> "https", somehow it becomes "http" in the output.
>>
>> Does it work for you with the latest version from here:
>>
>>   http://www.pmwiki.org/wiki/Cookbook/IncludeUrl
>>
>> Petko
>>
>> On 2016-08-14 00:22, Byron Lunz wrote:
>>
>> My web site is implemented via pmwiki. We just installed a LetsEncrypt
>>> cert
>>> to convert all accesses to https. Now, the forms which would
>>> previously
>>> displayed using the includeurl directive no longer appear.
>>>
>>> Chrome's developer console says:
>>> [image: Inline image 1]
>>> ... even after I have edited the includeurl from http to https. I've
>>> also
>>> added a line of markup to config.php from the includeurl man page
>>> which
>>> is
>>> supposed to allow https but so far no joy.
>>>
>>> Page in question is https://www.cctomany.com/Info/ContactUs
>>>
>>>
>> ___
>> 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
>
>


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

Re: [pmwiki-users] Recipe to generate calendar invites

[Dominique Faure]

​Hi,
​
> I'm looking for a recipe that would generate a google/outlook(ics) inite
that people can use to add an event to their own personal calendar?
​
I was about to write such a thing many years ago but didn't had enough
spare time (nor interest) to handle it.
Now, as thanks to you, CodeMirror is in a reasonably stable state, I should
be able to get few hours to code something for this.
Stay tuned :)

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

Re: [pmwiki-users] Don't allow saving guest post for 0 modification

[Dominique Faure]

Incidentally the test should be reverted:

...
if ($new['text'] == $page['text']) {
...


On Wed, Dec 16, 2015 at 11:59 PM, Dominique Faure <dominique.fa...@gmail.com
> wrote:

> Hi,
>
> A solution could be to handle this in the same way it is already done with
> author requirement: Looking at scripts/author.php, you'll could easily see
> that the form post is interrupted by setting the $EnablePost variable to 0;
>
> Have a try with the following code:
>
> array_unshift($EditFunctions, "DeltaPageContent");
> function DeltaPagecontent($pagename,&$page,&$new) {
>   global $EnablePost, $ModifiedPageContentRequiredFmt;
>   if (!$EnablePost) return;
>
>   if ($new['text'] != $page['text']) {
> SDV($ModifiedPageContentRequiredFmt, "$[The
> page hasn't been modified.]");
> $MessagesFmt[] = $ModifiedPageContentRequiredFmt;
> $EnablePost = 0;
>   }
> }
>
> Regards,
> Dominique
>
>
> On Wed, Dec 16, 2015 at 2:57 PM, ABClf <languefranca...@gmail.com> wrote:
>
>> Hello,
>>
>> I'm facing a bit of spam on my wiki.
>> For my defense, I use blocklist and Petko's Spamfilters cookbook.
>>
>> Problem is I have spammer posting unmodified pages (original text
>> remains unaltered, yet spammer does appear in the page's history as a
>> contributor and therefore the page is said to have been newly
>> revised).
>>
>> What would be the right config lines to block such a possibility ?
>> I would like to implement that rule : for other than admin, if page is
>> not modified then dont allow saving it.
>>
>> Might the deltapagesize function (I'm using
>> http://www.pmwiki.org/wiki/Cookbook/DeltaBytesRecentChanges) be
>> completed, so that 0 modification means saving is unallowed ? Or is it
>> doable to use Spamfilters Post Size option ?
>>
>> Thank you.
>>
>> ___
>> pmwiki-users mailing list
>> pmwiki-users@pmichaud.com
>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>>
>
>
>
> --
> Dominique
>



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

Re: [pmwiki-users] Don't allow saving guest post for 0 modification

[Dominique Faure]

Hi,

A solution could be to handle this in the same way it is already done with
author requirement: Looking at scripts/author.php, you'll could easily see
that the form post is interrupted by setting the $EnablePost variable to 0;

Have a try with the following code:

array_unshift($EditFunctions, "DeltaPageContent");
function DeltaPagecontent($pagename,&$page,&$new) {
  global $EnablePost, $ModifiedPageContentRequiredFmt;
  if (!$EnablePost) return;

  if ($new['text'] != $page['text']) {
SDV($ModifiedPageContentRequiredFmt, "$[The
page hasn't been modified.]");
$MessagesFmt[] = $ModifiedPageContentRequiredFmt;
$EnablePost = 0;
  }
}

Regards,
Dominique


On Wed, Dec 16, 2015 at 2:57 PM, ABClf  wrote:

> Hello,
>
> I'm facing a bit of spam on my wiki.
> For my defense, I use blocklist and Petko's Spamfilters cookbook.
>
> Problem is I have spammer posting unmodified pages (original text
> remains unaltered, yet spammer does appear in the page's history as a
> contributor and therefore the page is said to have been newly
> revised).
>
> What would be the right config lines to block such a possibility ?
> I would like to implement that rule : for other than admin, if page is
> not modified then dont allow saving it.
>
> Might the deltapagesize function (I'm using
> http://www.pmwiki.org/wiki/Cookbook/DeltaBytesRecentChanges) be
> completed, so that 0 modification means saving is unallowed ? Or is it
> doable to use Spamfilters Post Size option ?
>
> Thank you.
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>



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

Re: [pmwiki-users-fr] Group name title

[Dominique Faure]

Bonjour,

Il n'y a pas de solution prédéfinie dans PmWiki pour ça, mais la
recette http://www.pmwiki.org/wiki/Cookbook/GroupTitle peut apporter
une réponse.

2015-09-28 6:37 GMT+02:00 Pierre-Marie CARETTE :
> Comment donner un (title Nomdugroupe:) à un groupe ? Où l’inscrire ? Merci
> Pierre-Marie CARETTE
> pierremariecare...@gmail.com
>
>
>
>
>
> ___
> pmwiki-users-fr mailing list
> pmwiki-users-fr@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users-fr
>



-- 
Dominique

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

Re: [pmwiki-users-fr] transition pour php 5.5

[Dominique Faure]

Rectification: J'ai pu localiser l'erreur, corriger le skin et le
mettre à jour sur pmwiki.org

2015-07-17 15:57 GMT+02:00 Dominique Faure dominique.fa...@gmail.com:
 Bonjour,

 2015-07-17 13:59 GMT+02:00 Bien Entendu in...@bienentendu.fr:
 y a t’il moyen de corriger facilement ces 3 .php ?

 J'ai testé brièvement le skin recurve sous php 5.4 sans soucis
 particuliers. Pourriez-vous détailler les comportements douteux et/ou
 fournir des messages d'erreurs?

 --
 Dominique



-- 
Dominique

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

Re: [pmwiki-users-fr] transition pour php 5.5

[Dominique Faure]

Bonjour,

2015-07-17 13:59 GMT+02:00 Bien Entendu in...@bienentendu.fr:
 y a t’il moyen de corriger facilement ces 3 .php ?

J'ai testé brièvement le skin recurve sous php 5.4 sans soucis
particuliers. Pourriez-vous détailler les comportements douteux et/ou
fournir des messages d'erreurs?

-- 
Dominique

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

Re: [pmwiki-users] Same name but different pages if case sensitive

[Dominique Faure]

Hi,

 Is there a solution via configuration ?

You  should perhaps have a look at this recipes:

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


-- 
Dominique

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

Re: [pmwiki-users] if exists conditional markup problem

[Dominique Faure]

Hi,

This comes simply because the space between ftime and %Y%m is seen
as a separator when evaluation the condition.
You should try enclosing your expression with quotes:

(:if exists ’Profile-Data.{Members/Hosts$:{(ftime %Y%m)}}’ :)

-D-


On Wed, Apr 1, 2015 at 1:07 PM, Criss Ittermann cris...@kinhost.org wrote:
 I'm trying to figure out why this is returning false (To be announced.):

 (:if exists Profile-Data.{Members/Hosts$:{(ftime %Y%m)}} :)
 ...
 (:else:)
 To be announced.
 (:ifend:)


 When the following returns a fully functioning link to the correct page,
 which exists:

 [[Profile-Data.{Members/Hosts$:{(ftime %Y%m)}}]]


 What am I doing wrong?

 Crisses



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




-- 
Dominique

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

Re: [pmwiki-users] Users, groups, permissions, security, tools... Help?

[Dominique Faure]

Hi,

By itself, the PmWiki User oriented security system
(http://www.pmwiki.org/wiki/PmWiki/AuthUser) is able to handle
credentials coming from external sources, and noticeably coming from
.htpasswd/.htgroup files, ie. the regular credential storage files
used by apache web servers. Being able to use them is a way to have
synced authentications between some wiki content and other protected
web locations, but nothing prevent you to use it only for wiki
purposes.

You should then perhaps have a look at this recipe:
http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm, which provides
convenient tools to handle these files contents, both at user and
administrative levels.

FTR, having a look at the mailing-list archives, you'd easily see that
the zap recipe has born as a derivative work from this recipe (and
some others) and has been more or less rapidly abandoned by its
original author who preferred to leave the community, borrowing most
of PmWiki concepts and re-implement them in his own engine (so you
shouldn't expect many help from him).

-- 
Dominique

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

Re: [pmwiki-users] guibuttons in skin.php

[Dominique Faure]

Hi,

 I moved $EnableGuiButtons = 1; to precede the skin setup, but that had no
 effect.

When dealing with skins, you have to remember that the skins code
itself (ie. the {$Skin}.php or skin.php file) is included from within
a function call, therefore most of PmWiki's global variables aren't
available without a preceding global declaration.

you should add:

global $EnableGuiButtons;

in your code before trying to modify the variable.

-- 
Dominique

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

[pmwiki-users] Major rewrite: CodeMirror

[Dominique Faure]

Hi,

I finally managed to get a large enough free-time span to build and
deliver a quite stable new version of the CodeMirror recipe
(http://www.pmwiki.org/wiki/Cookbook/CodeMirror).

For the record, this recipe provides the CodeMirror JavaScript text
editor component to PmWiki, enabling both:

* An enhanced page editing experience with pmwiki syntax highlighting,
line numbers and line wrapping,

* A generic syntax highlighting renderer for your source code excerpts.

As pointed out as caveats/known limitation on the recipe page, the
PmWiki language is a very convenient markup set for the user,
therefore writing a syntaxic highlighter for it is rather hard. The
one provided is far from perfect, but should be able to render most of
the language features.

The syntax colors/styles proposed really need to be improved.
Fell free to provide better style definitions.


Regards,
-- 
Dominique

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

Re: [pmwiki-users] MarkupExpressionPlus recipe

[Dominique Faure]

Hi,

I was (rather slowly, I must apologize) more or less in the process of
reworking the recipe for PHP 5.5, and therefore was also wondering how
far the features you precisely commented out really need to be updated
or simply dropped.
For the record, I mainly designed these excluded parts as
proof-of-concepts without any real life usage at this time.

Regards,
Dominique


On Wed, Dec 3, 2014 at 8:59 PM, Hans Bracker des...@softflow.co.uk wrote:
 PHP 5.5 compatible version
 http://www.pmwiki.org/wiki/Cookbook/MarkupExprPlus
 Download markupexprplus2.php
  http://www.pmwiki.org/pmwiki/uploads/Cookbook/markupexprplus2.php
 untill original script gets updated.

 I commented out a huge section of the original script, and dropped/lost
 the modified behaviour previously enabled with $EnableExprMultiline
 and $EnableExprVarManip flags. All the other extra markup expressions
 are run through PmWiki's MarkupExpression() function, not the
 MarkupExpressionPlus() function of the original script. Only the
 wikiword markup expression needed a revised definition. This seems to
 work. This script needs PmWiki version 2.2.56 or younger. I hope the
 original script will get fully revised and updated, or the most
 important parts get added to the PmWiki core (markupexpr.php). Then
 this script can be removed.

 cheers,
  Hans
 mailto:des...@softflow.co.uk
 www.softflow.co.uk


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



-- 
Dominique

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

Re: [pmwiki-users] MarkupExpressionPlus recipe

[Dominique Faure]

In fact, most of the MarkupExpressionPlus() is borrowed from the
equivalent core code.

The real added value of the function is limited to the code addition
at the beginning of the function which is responsible for triggering
the evaluation of the various {$variable} markup rules before handling
the expressions themselves. This was needed to ensure getting the
current variable value and not the one that have been evaluated by the
core before the rendering of the page.

As I'm quite sure that like you, most of the recipe's users don't use
the -inactive by default- variable manipulation features, I'll
rerelease the recipe soon as a pure PHP 5.5 script without the
offending features, keeping the original version available for
reference/older configs, leaving open for more spare time the porting
of feature in a dedicated script file.

Dominique


On Thu, Dec 4, 2014 at 2:10 PM, Hans Bracker des...@softflow.co.uk wrote:
 Hello Dominique,

 Thursday, December 4, 2014, 11:37:34 AM, you wrote:

 I was (rather slowly, I must apologize) more or less in the process of
 reworking the recipe for PHP 5.5, and therefore was also wondering how
 far the features you precisely commented out really need to be updated
 or simply dropped.
 For the record, I mainly designed these excluded parts as
 proof-of-concepts without any real life usage at this time.

 thanks  for  looking into this! Personally I never used those advanced
 features, so I do not mind for them being dropped.
 When  I  was  revising  your  script  I  did  not  understand  how the
 MarkupExpressionPlus() function worked, and was just happy that I could
 get most of the expressions to work without using it.
 So  please,  if  you  got  time,  do have a look at it and decide what
 should  be  in markupexpressionplus.php, perhaps a leaner script would
 be just as well.

 If Petko thinks that some of the expressions could get migrated to the
 markupexpressions.php  script, so they are part of the core, then this
 could be a good time to do so.


 Best regards,
  Hans
 mailto:des...@softflow.co.uk
 www.softflow.co.uk


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

Re: [pmwiki-users-fr] Installation pmwiki chez free.fr

[Dominique Faure]

2014-11-14 11:15 GMT+01:00 Didier Bretin did...@bretin.net:
 Bonjour

 J'ai installé pmwiki sur mon compte sur free.fr mais je n'arrive pas à créer
 de nouvelles pages. Or j'ai vu pleins de compte free.fr avec un pmwiki qui
 semble bien marcher.

 Aurais-je oublier qqchose ?

La configuration des serveurs de Free.fr est assez exotique:
* PHP 5.1 en mode fast/CGI sur une version d'Apache customisée,
* Un certain nombre de fonctions php désactivées, dont étrangement rmdir(),
* La nécessité de déclarer un dossier 'sessions' à la racine et qu'il
faudra protéger avec un .htaccess (une copie de celui du dossier local
fera parfaitement l'affaire).

Quelques détails ici: http://www.pmwiki.org/wiki/PmWikiFr/WebHosts

Dans les quelques essais que j'ai pu faire (version = 2.2.48), j'ai
forcé l'utilisation de php5 depuis le .htaccess principal qui se
résume à:
===8- - - - -
IfDefine Free
PHP 1
/IfDefine
===8- - - - -

et j'ai placé pmwiki dans un sous-dossier 'wiki', dans lequel je me
suis contenté d'ajouter le fichier 'index.php' suivant:
===8- - - - -
?php
include_once('pmwiki.php');
===8- - - - -

$EnablePathInfo est fonctionnel en l'état et offre par défaut des urls
de la forme http://.../wiki/PmWiki/Group/Page

-- 
Dominique

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

Re: [pmwiki-users] Recipe update needed?

[Dominique Faure]

On Wed, Jul 2, 2014 at 1:55 PM, Crisses cris...@kinhost.org wrote:
 Hi, Dfaure,

 I am wondering whether you are still using your PmWiki recipe for
 http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm because I'm very interested
 in using it.

 However it's not working right now with the latest PmWiki.

Hi,

Feel free to try the latest version I just fixed and uploaded (nothing
fancier than trying to be php 5.5 compliant).

-- 
Dominique

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

Re: [pmwiki-users] rotated pictures displaying original

[Dominique Faure]

 It displays rotated on my computer, but when I upload it to pmwiki and
 display it using Attach:foo.jpg markup (I also tried with Galleria) it
 displays the original rotation as if I had never rotated it.

The problem rather comes from the way the browser takes account of the
image rotation information usually stored in jpeg image metadata, as
explained here [1].

[1] 
http://sethfowler.org/blog/2013/09/13/new-in-firefox-26-css-image-orientation/

Regards

-- 
Dominique

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

Re: [pmwiki-users] pmwiki-users Digest, Vol 89, Issue 6

[Dominique Faure]

On Wed, Nov 7, 2012 at 8:11 PM, Petko Yotov 5...@5ko.fr wrote:
 John writes:
...

Hi,

And anyway, while sending messages to the mailing list, could you
please conform to usual elementary etiquette[1].
More precisely, don't quote digest mails as they would appear as bags
of unrelated stuff with your topics, making it heavily unreadable.

[1] http://www.gweep.ca/~edmonds/usenet/ml-etiquette.html

--
Dominique

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

Re: [pmwiki-users] Truncate PageTitle

[Dominique Faure]

On Mon, Aug 20, 2012 at 1:30 PM, Brian Tibbels
brian.tibb...@clickmarlow.co.uk wrote:


 I need to truncate a page title for side bar presentation
 (:title Language - Full Page Title:)

Using MarkupExprPlus as suggested by Peter, the following expression will do it:

{(reg_replace '/^.*\s+-\s*/' '' '{$Title}')}

-- 
Dominique

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

[pmwiki-users] Pagelist templates defaults specifications not taken in account

[Dominique Faure]

Hi,

As stated in http://www.pmwiki.org/wiki/PITS/01282, some pagelist
options seemed to be badly handled while given as template default.

Though I suspect that the fix would require a rather hard and large
modification in the page list processing, this could be nice to allow
the feature as suggested in the linked test page.

-- 
Dominique

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

Re: [pmwiki-users] text and image as link content in same [[ ]]

[Dominique Faure]

On Sun, Mar 11, 2012 at 13:44,  a.sonderh...@gassi-tv.de wrote:
 Hi

 I am trying to put some text and an image in the same link markup:
 [[ linktarget | some text goes here http://host/image.ext ]]

 This is necessary in order to trigger the hover state of the text when the 
 mouse cursor moves over the image. This also why I cannot use separate link 
 markups, e. g. text in another link wikimarkup than the image.

 Can this be achieved using readily available pmwiki markup or do I have do 
 define a custom markup for that in config.php?

Hi,
Feel free to have a try on the DomTT recipe, which implement the kind
of features you're looking for.

-- 
Dominique

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

Re: [pmwiki-users] RFC: Link titles

[Dominique Faure]

Short version: do it :)

The (not so) longer rationale is that things having common usages and
behaviors should be expressed the same way, enforcing the analogy
between them.

All internal/external/intermap/image links are primarily *links* which
should only differ by the target specification (as the html anchor
does).

Anyway, the previous behaviour could always be provided as a recipe.

BTW, Would it make sense to allow empty titles such as
[[Link|text]] (whatever the target could be)?
Couldn't this be, by default, a mean to express the target url?

-- 
Dominique

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

Re: [pmwiki-users] RFC: Link titles

[Dominique Faure]

On Sun, Oct 30, 2011 at 20:50, Petko Yotov 5...@5ko.fr wrote:
 For me these two should have identical output:

  [[Link|text]] and [[Link|text]]

There's but a subtle difference: in the 1st case, the author
explicitly want a title whereas not in the 2nd.

Since the empty title is quite useless, why not using it to reveal
more information on the target?

For example:
* [[TargetedPage|+]]
* [[http://targeted_url/;|external target]]

could be equivalent as:
* [[TargetedPage{$Group}.TargetedPage|+]]
* [[http://targeted_url/http://targeted_url/;|external target]]

At least, the title default value should be able to be computed from a recipe.
-- 
Dominique

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

Re: [pmwiki-users] vspace revisited

[Dominique Faure]

On Wed, Jul 27, 2011 at 13:11, Oliver Betz list...@gmx.net wrote:
 This doesn't work because if I suppress the PmWiki vspace handling,
 the css has to take care about the margins.

 I consider vspace handling being part of a skin.

 (misaligned results with monobook skin)

For the record, the monobook skin was designed from the original
MediaWiki skin few years ago, and are not synched anymore.

The misalignment may also be due to the skin own styling.

-- 
Dominique

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

Re: [pmwiki-users] I want a pagelist template like the oneline sample, but NO spaces between entries...help

[Dominique Faure]

 Like the subject says.  I desire something like the #oneline fmt example in
 the pagelist samples, but I do NOT want intervening spaces in the result.
  Even if I specify a backslash, I end up with a space between the items.
  Possible to eliminate without writing some custom markup expression?

Hi,
According to this test:

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

it seems to work as expected, and even more since Camel case
concatenated strings are recognized as potential links.

-- 
Dominique

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

Re: [pmwiki-users] Remember Password Feature in Firefox

[Dominique Faure]

On Tue, Mar 8, 2011 at 15:38, Sebastian Schneider s...@unibw.de wrote:
 Hello,

 I know this might be a firefox-issue, but I thought I'd still give this list
 a try, since the problem only occurs to me with pmwiki pages.

 I'm using the remember my password-feature from firefox and I have a
 pmwiki-page. Now I have two different pages, let's say Main.Page1 and
 Main.Page2.

 I set the passwords for viewing, editing, attribute changing and uploading
 for the first page to page1 and for the second page to page2.

 Now, the first time I try to open Main.Page1 it asks for a password. I enter
 page1 and allow firefox to store the password. Now, when I go to got to
 Main.Page2, firefox fills in the password field with the stored password
 page1, which obviously doesn't open the site.

 If I enter the correct password page2, firefox asks me if I want to change
 the previously stored password.

 How come, that firefox doesn't recognize, that Main.Page1 and Main.Page2 are
 different pages, and store the passwords for each Page individually?

 Could this have to do with the Adress-Rewrite-Rules, that make Links to
 Pages appear as: http://www.example.com/Main/Page1?

 Thanks for your tipps,

 Sebastian


Hi,

A solution could be to have password remembering disabled for all the wiki.
According to this page:

http://www.dailygyan.com/2008/08/force-firefox-to-remember-password-of.html

this could be made using an edited Site.AuthForm page containing the
following directive.

(:input password name=authpw autocomplete=off:)

I didn't test this.
-- 
Dominique

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

Re: [pmwiki-users] pmwiki.org server migration

[Dominique Faure]

Hi,

On Sat, Nov 20, 2010 at 10:23, Oliver Betz list...@gmx.net wrote:
 Patrick R. wrote:

 [...]

I'm also considering migrating PmWiki's subversion repository
to GitHub -- any comments?  (If you don't understand what

 Aren't the git people condemning Windows users? I remember
 MSysGitHerald9 and other opportunities.

There seems to be some solutions:

* http://code.google.com/p/msysgit/
* http://code.google.com/p/tortoisegit/

Hope this help
-- 
Dominique

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

Re: [pmwiki-users] PTV including directive : (:text: this is my long text, with pictures. (:thumlist:):)

[Dominique Faure]

On Sun, Aug 15, 2010 at 16:20, Patrick R. Michaud pmich...@pobox.com wrote:
 On Sun, Aug 15, 2010 at 03:44:38PM +1200, Simon wrote:
 A while ago we had a similar discussion about markup for nesting , with
 variations on themes such as 

 I feel that counting the number of colons may have similar drawbacks, I 
 wonder
 if we can find a scheme similar to (:if1 and (:div1 that might work, and have
 the advantage of being similar,
 eg (:1:Name:Value:)

 This doesn't help with being able to embed a directive containing ':)' into 
 the
 Value portion of the directive.

[thinking out loud] BTW, a bit OT but...
...it could be worth handling an extra ptv=name parameter to divs,
letting them act as multi line variables, no?

  (:div ptv=myvar ... :)
  ...
  (:divend:)


-- 
Dominique

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

Re: [pmwiki-users] AsciiMath: Why all the whitespace?

[Dominique Faure]

On Fri, Jun 25, 2010 at 01:38, David Spitzley dspit...@wash.k12.mi.us wrote:

 I'm working with AsciiMath, and its equation rendering is a miracle to 
 behold.  However, the iframes that it generates have about a half-dozen lines 
 worth of empty space underneath the equations, and I can't for the life of me 
 figure out how to change it.  You can see it at 
 http://www.davidaspitzley.org/PotatoPatch/index.php?n=Research.LocalEconomyModel
  .  This occurs in both Firefox 3.6.4 and IE 8.  I've checked the CSS and 
 block boundaries of the iframe contents with Firefox's Web Developer Toolbar, 
 and there doesn't seem to be anything in the empty area of the iframe, not 
 even html tag, and I also can't find any height styling on the iframe element 
 which would cause overuse of space.  Any suggestions as to how to rein in the 
 ballooning iframes?



I had the same kind of consideration while developping the recipe.
That's why I made it handle a kind of style definition at markup
start:

{$ %height=3.5em% ... $}

Anyway, you could always override the default css definitions in the
configuration file:

$HTMLStylesFmt['formula'] = 
div.eqn { margin: 0 2em; }
div.eqn table { width: 100%; }
div.eqn iframe {
 width: 100%;
 height: 80px;
};

--
Dominique

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

Re: [pmwiki-users] New recipe: AbcTunebook

[Dominique Faure]

On Mon, May 17, 2010 at 14:24, V.Krishn vkri...@insteps.net wrote:
 On Monday 17 May 2010 5:24:39 pm V.Krishn wrote:
 On Monday 17 May 2010 2:42:36 am Hans wrote:
  Announcing a new recipe: AbcTunebook
  http://www.pmwiki.org/wiki/Cookbook/AbcTunebook

 Hi,
 Looks nice.

 Just to mention, I think the script uses canvas tag, of html5.

Hi,
You we're perhaps referring to:

http://0xfe.blogspot.com/2010/05/music-notation-with-html5-canvas.html

-- 
Dominique

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

Re: [pmwiki-users] What attachment operations do you want or need?

[Dominique Faure]

On Tue, May 4, 2010 at 15:19, Eemeli Aro eem...@gmail.com wrote:
 Greetings.

 I'm working on a bundle of recipes for better PmWiki attachment
 handling http://www.pmwiki.org/wiki/Cookbook/Attache.
[...]
 But there's more to come, and I'd like to hear what you want or need
 to do with PmWiki attachments that isn't possible yet, or is too
 difficult with current recipes.

Hi,

FWIW, I would really like to have a unified way to handle attachments
in recipes, in order to improve user experience keeping a well known
behavior while handling objects of the same kind, and as an
interesting side effect, simplify recipe development.

I tried several years ago to provide some kind of answer with the
http://www.pmwiki.org/wiki/Cookbook/LinkedResourceExtras stuff (which
clearly needs to be enhanced). But nothing really went further...

...until now, where your requests could be the time to improve things there.
-- 
Dominique

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

Re: [pmwiki-users] Google: noindex, nofollow error 403

[Dominique Faure]

On Mon, Apr 19, 2010 at 23:47,  pmw...@911networks.com wrote:
 On Mon, 19 Apr 2010 15:53:47 -0500
 Patrick R. Michaud pmich...@pobox.com wrote:

Or, it appears you can disable the GetCode link globally with

   $EnableSourceBlockGetCode = 0;

 $EnableSourceBlockGetCode = 0;

 Actually this didn't work. I placed it after the
 include_once('cookbook/sourceblock.php)


Hi,

This seems strange, since the $EnableSourceBlockGetCode is only taken
in account during the markup processing. Anyway, giving the parameters
values before the include_once directive would ensure you to have the
recipe working as designed.

For the record, this parameter is only defining the default behavior,
which may be overloaded using the '+getcode' or '-getcode' markup
argument.

You may also modify the link specification itself with:

$SourceBlockLinkUrl = a href='\$LinkUrl' type='text/plain'
rel='nofollow'\$LinkText/a;

Regards,
Dominique

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

Re: [pmwiki-users] (:directive:) in (:mytext: this is a hidden PTV:)

[Dominique Faure]

On Tue, Apr 20, 2010 at 11:19, Hans desi...@softflow.co.uk wrote:
 Tuesday, April 20, 2010, 1:26:45 AM, ABClf wrote:

 I was in trouble for using (:thumblist:) in a large hidden PTV
 (:myptv: long text :).
 Here it is my problematic source:

 (:text: some long text, where I want images (:thumblist:) some more text:)

 doesn't work when showing {$:text} ; I guess it is because of the
 thumblist's « :) »

 you could define a markup expression for thumblist
 and use that inside the PTV:

 in config:

 $MarkupExpr['thumb'] = $MarkupExpr['thumblist']
        = 'MXThumbList($pagename, $args, $argp)';
 function MXThumbList($pagename, $args, $argp) {
  $suffix = (isset($args[0])) ? '' : 'list';
  unset($argp[''],$argp['#']);
  foreach($argp as $k = $v)
    $opt .=  .$k.=.$v;
  foreach($args as $v)
    $opt .=  .$v;
  return FmtThumbList($pagename, $opt, $suffix, '');
 }

 PTV example in the page:
  (:text: some long text, where I want images {(thumblist)} some more text:)
 or
  (:text: some text {(thumb myimage.jpg)} some more text:)

 thumblist parameters should work too.


  ~Hans


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


Then why not, the generic:

$MarkupExpr['directive'] = '(: . trim(preg_replace($rpat, $rrep,
$params)) . :)';

with the wiki page syntax:

(:text: some long text, where I want images {(directive thumblist)}
some more text:)

-- 
Dominique

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

Re: [pmwiki-users] (:directive:) in (:mytext: this is a hidden PTV:)

[Dominique Faure]

On Tue, Apr 20, 2010 at 11:42, Dominique Faure
dominique.fa...@gmail.com wrote:
 On Tue, Apr 20, 2010 at 11:19, Hans desi...@softflow.co.uk wrote:
 Tuesday, April 20, 2010, 1:26:45 AM, ABClf wrote:

 I was in trouble for using (:thumblist:) in a large hidden PTV
 (:myptv: long text :).
 Here it is my problematic source:

 (:text: some long text, where I want images (:thumblist:) some more text:)

 doesn't work when showing {$:text} ; I guess it is because of the
 thumblist's « :) »

 you could define a markup expression for thumblist
 and use that inside the PTV:

 in config:

 $MarkupExpr['thumb'] = $MarkupExpr['thumblist']
        = 'MXThumbList($pagename, $args, $argp)';
 function MXThumbList($pagename, $args, $argp) {
  $suffix = (isset($args[0])) ? '' : 'list';
  unset($argp[''],$argp['#']);
  foreach($argp as $k = $v)
    $opt .=  .$k.=.$v;
  foreach($args as $v)
    $opt .=  .$v;
  return FmtThumbList($pagename, $opt, $suffix, '');
 }

 PTV example in the page:
  (:text: some long text, where I want images {(thumblist)} some more text:)
 or
  (:text: some text {(thumb myimage.jpg)} some more text:)

 thumblist parameters should work too.


  ~Hans


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


 Then why not, the generic:

 $MarkupExpr['directive'] = '(: . trim(preg_replace($rpat, $rrep,
 $params)) . :)';

 with the wiki page syntax:

 (:text: some long text, where I want images {(directive thumblist)}
 some more text:)


oops, the generic version should be more elaborated:

$MarkupExpr['directive'] = 'preg_replace(/\\n$/, ,
   MarkupToHTML($pagename,
:block(: .
trim(preg_replace($rpat, $rrep, $params)) . :),
array(escape = 0)))',

should do the trick
-- 
Dominique

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

Re: [pmwiki-users] (:directive:) in (:mytext: this is a hidden PTV:)

[Dominique Faure]

On Tue, Apr 20, 2010 at 12:26, Hans desi...@softflow.co.uk wrote:
 Tuesday, April 20, 2010, 11:07:32 AM, Dominique Faure wrote:

 oops, the generic version should be more elaborated:

 $MarkupExpr['directive'] = 'preg_replace(/\\n$/, ,
                                MarkupToHTML($pagename,
                                             :block(: .
 trim(preg_replace($rpat, $rrep, $params)) . :),
                                             array(escape = 0)))',

 should do the trick

 this did not work, even with ';' at end instead of ','
 but your previous suggeastion works with thumb and thumblist.

Here's my full bench:

=8- - - - - (Test.MarkupExpr wiki page) - - - - -
:PTV1: ptv1 (:mymarkup  :) ptv1
:PTV2: ptv2 {(directive mymarkup  )} ptv2
(:PTV3: ptv3 {(directive mymarkup  )} ptv3 :)

* {$:PTV1}
* {$:PTV2}
* {$:PTV3}

=8- - - - - (Test.MarkupExpr.php) - - - - -
Markup('mymarkup', 'directives', /\\(:mymarkup\\s+(.*?):\\)/sei,
  MyMarkup(\$pagename, PSS('$1')));

function MyMarkup($pagename, $args) {
  return This is my markup...\$args\;
}

if(true) {
  $MarkupExpr['directive'] =
'(: . trim(preg_replace($rpat, $rrep, $params)) . :)';
} else {
  $MarkupExpr['directive'] =
'preg_replace(/\\n$/, , MarkupToHTML($pagename,
  :block(: . trim(preg_replace($rpat, $rrep, $params)) . :),
  array(escape = 0)))';
}
- - - - - - - - - - - - - - -

While having the 1st solution active, the page is rendered as below,
where you may see an evaluation artefact (ptv3 :)) while rendering
PTV2 definition:

=8- - - - -
PTV1
  ptv1 This is my markup...  ptv1
PTV2
  ptv2 This is my markup...  ptv2 ptv3 :)

* ptv1 This is my markup...  ptv1
* ptv2 This is my markup...  ptv2
* ptv3 This is my markup...  ptv3

=8- - - - -

Reversing the test to activate the other definition, let the markup
render without the offending ptv3 :)

 Is
 $MarkupExpr['directive'] = '(: . trim(preg_replace($rpat, $rrep, $params)) 
 . :)';
 restricted to directives without line breaks?

The MarkupExpr markup definition, ie. the {(...)} general processing
isn't designed to handle multiple lines.

-- 
Dominique

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

Re: [pmwiki-users] RFC: Indexing categories and links (suspended)

[Dominique Faure]

On Sun, Mar 7, 2010 at 20:42, Oliver Betz list...@gmx.net wrote:
 Dominique Faure wrote:

 [...tags vs. links...]

IMHO (and on a rather technical point of view), we already have almost
all the bells and wistles we could need to handle such kind of data
(page text variable, page attributes,...). The problerm here is more a
need to know how to use the available features in a no non-sense
way...
...and document it!

 as far as I know, the issue is speed: Backlinks are searched much
 faster than page text variables.

Speed isn't the most important point there: backlinks are searched
faster than page text variables because they're specifically handled
through the .pageindex file. If a consesus is found on a way to
express category ownership without using category links, I'm sure the
feature would be managed using the same speed considerations.

-- 
Dominique

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

Re: [pmwiki-users] RFC: Indexing categories and links (suspended)

[Dominique Faure]

On Sun, Mar 7, 2010 at 17:47, DaveG pmw...@solidgone.com wrote:


 On 3/7/2010 8:23 AM, Hans wrote:
 Sunday, March 7, 2010, 8:44:24 AM, Simon wrote:

 The markup [[!SomeCategory]] is a tag, it categorises a page. It is a 
 definition or declaration.
 The  markup [[Category/SomeCategory] is a reference to page (that
 lists pages on which a particular tag occurs)

 To me [[!SomeCategory]] is foremost a link,
 a special type of link, but still a link.
 If tags were implemented in Pmwiki there would be some kind of tag
 markup, which will not necessarily display as a link.
 Tags would be more like the title directive, and stored as separate
 page attributes.
 I believe the way many people use [[!...]] is as a basic tagging
 mechanism already.

+1 to this.

Couldn't we consider that [[!...]] could be *both* a tag and a link?
Therefore we only need a way to express what could be a silent tag,
ie. not rendering as a link. someting like {{!...}} could be
aproppriate.

 If PmWiki wants a tag system, then that should be discussed,
 but such discussion is beyond what is proposed on that PITS page
 about distinguishing [[!Page]] and [[Category.Page]] in backlinks.

 For me a tagging system would not only use markup which could be
 invisible, but also could use multiple tag groups, and has a
 mechanism in the standard edit form to add and change tags.
 The latter might brake PmWiki's simplicity rule.
 Adding additional functionality to the category system to extend it's
 use as a tagging system has merit, but as you say beyond where this
 discussion is.

IMHO (and on a rather technical point of view), we already have almost
all the bells and wistles we could need to handle such kind of data
(page text variable, page attributes,...). The problerm here is more a
need to know how to use the available features in a no non-sense
way...
...and document it!

-- 
Dominique

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

Re: [pmwiki-users] PmWiki 2.2.10 released

[Dominique Faure]

On Tue, Jan 19, 2010 at 18:45, Petko Yotov 5...@5ko.fr wrote:
 On Monday 18 January 2010 21:59:07, Dominique Faure wrote :
 On Mon, Jan 18, 2010 at 09:34, Oliver Betz list...@gmx.net wrote:
  Petko Yotov wrote:
 * If set to 1, the first title directive will be used, and if a page
  defines a title, directives from included pages cannot override it.
 
  Sadly a title in EditQuickReference still clobbers the title of the
  edited page (well, we don't really _need_ to set a title in
  EditQuickReference).

 I didn't had a look at the code, but it would be great to have some
 kind of markup directive which could temporary prevent title
 propagation (by setting $EnablePageTitlePriority to 1).

 It will not be easy. When the markup is being processed, all markup rules are
 already defined. Then the two modes of the title are processed differently.

 The old one is processed with other directives, after all included sections
 have been brought into the page -- this is how it worked, we don't want to
 change it for people who need it.

 The new one is processed before the inclusion of other sections, so that the
 real page have the priority for setting the title. If the page doesn't set a
 title, the first included section containing (:title:) will set it.

 It is possible to change the markup rules, or to set a switch for a function
 to accept or not a subsequent (:title:) directive, but it is not possible to
 change the when part (directives or include) for an existing markup, so
 this will be a mess.

 When we edit a page, PmWiki knows it is on PageName, but the markup it renders
 comes from Site.EditForm.
 * If there is no (:title:) directives in EditForm or in the inclided pages
  like EditQuickReference, the page will show the title from the
  $page['title'] attribute like it should.
 * If there is a (:title:) directive in EditForm or in the pages it includes,
  this overrides the $page['title'] attribute and appears as title.

 So, we could possibly fix this by ignoring the (:title:) directives when
 Site.EditForm is rendered for editing, but I'm not sure if this wouldn't
 interfere with the Save and Edit function and even with the normal Save
 for the correct setting of the $page['title'] attribute.

[thinking loudly]

Why not having a (:localtitle ...:) directive which defines the page
title only while the page is directly displayed?

IMHO, after a (quick) look at the code, I would have considered the
following alternative implementation:
* The (:title ...:) directive is only pushing the different title
definitions onto a stack.
* Then, a post processing rule is choosing the top or bottom
definition from the stack according to the current configuration and
set it as the effective page title.
BTW, this kind of implementation would enable writing optional extras
stack manipulation via markup definition.

-- 
Dominique

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

Re: [pmwiki-users] PmWiki 2.2.10 released

[Dominique Faure]

On Mon, Jan 18, 2010 at 09:34, Oliver Betz list...@gmx.net wrote:
 Petko Yotov wrote:

 [...]

This release adds a new variable $EnablePageTitlePriority which defines how to
treat multiple (:title..:) directives.

* PmWiki default is 0. For years, the last title directive has been used
  (it could come from an included page or a GroupFooter).

 or a group header, I guess.

* If set to 1, the first title directive will be used, and if a page defines
  a title, directives from included pages cannot override it.

 Great.

 Sadly a title in EditQuickReference still clobbers the title of the
 edited page (well, we don't really _need_ to set a title in
 EditQuickReference).

Hi,

I didn't had a look at the code, but it would be great to have some
kind of markup directive which could temporary prevent title
propagation (by setting $EnablePageTitlePriority to 1).

The EditQuickReference page, and btw most of those from Site(Admin)?
group, would be excellent candidates. no?

--
Dominique

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

Re: [pmwiki-users] test email adress

[Dominique Faure]

On Mon, Oct 26, 2009 at 08:55, PKHG p.k.h.grag...@misc.utwente.nl wrote:

 Thanks Dave,
 Indeed, you allow much more complicated e-mail addresses, e.g. special
 characters.

 Is there 'somewhere' an official definition, what e-mail addresses may look
 like?

You may safely refer to RFC-822 for this:

http://www.ietf.org/rfc/rfc0822.txt?number=822

and here for a perl validation regexp:

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

--
Dominique

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en début de message est-il si effroyable?

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

Re: [pmwiki-users] Improving PITS

[Dominique Faure]

On Thu, Jul 9, 2009 at 10:39, Petko Yotov 5...@5ko.fr wrote:

 On Thursday 09 July 2009 08:29:27 Oliver Betz wrote:
  Petko Yotov wrote:
   * Inactive discussions (no edits for 180+ days) are automatically
labeled and moved to a sub-page, instead of cluttering the main page.
  
   IMO there should be also a view of this list sorted by expiration
   date, else it will be very hard to catch entries slipped to
   inactive by accident.
  
  If one edits (and saves) the inactive entry, the entry becomes active
   and returns automatically to the main list.
 
  I know, but I wanted to address another problem: There are long
  pending issues where everything is said, therefore there is no need
  to edit this entry again and again. It would go inactive
  undeservedly.

 This is fair. Entries with status Confirmed, ToDo or In Progress are no longer
 automatically expired.

  Therefore one has to look at the inactive entries from time to time
  to catch these. For this task, it would be useful to have the youngest
  entries listed first.

 I just added a drop-down menu to reorder the lists by a number of properties.
 (Other users also suggested sortable lists, thanks!)

 A note, however: the drop-down menu reorders all lists in the page.


Hi,

BTW, couldn't the Cookbook.PITS recipe be updated with this brand new
fancy configuration/script? I' love it.

--
Dominique

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

Re: [pmwiki-users] Breeak picture captions?

[Dominique Faure]

On Tue, May 19, 2009 at 19:52, Oliver Betz list...@gmx.net wrote:
 Update:

 Attach:foo.jpg | caption1 Attach:bar.jpg | caption2

the second picture with it's caption is used as caption of the first
picture.

How can I avoid this, IOW put two or more pictures with captions side
by side?

 The fine manual says in PmWiki/Images that I have to use lframes, but
 this doesn't work well if the gallery has to wrap.

 As a workaround, I dropped the captions and use links now.

 Nevertheless I'm still interested in a solution to place pictures with
 captions side by side, with wrapping.

 Oliver


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


Please have a look at http://www.pmwiki.org/wiki/Test/Image to see if
it solves your issue

-- 
Dominique

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en début de message est-il si effroyable?

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

Re: [pmwiki-users] User management (Cookbook: htpasswdform)

[Dominique Faure]

On Sat, May 9, 2009 at 19:48, Tyrus Elias ty...@livelifetoday.info wrote:
 In continued effort to manage users, I have moved on to try using a
 cookbook. I have tried include_once($FarmD/cookbook/htpasswdform.php);


Did you literaly use
include_once($FarmD/cookbook/htpasswdform.php); in your
configuration file, ie. including the surrounding quotes?
If so, they should be removed. The configuration line should be read:

  include_once($FarmD/cookbook/htpasswdform.php);

Hope this help,
Dominique

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

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

Re: [pmwiki-users] Translation downloads updated

[Dominique Faure]

On Fri, Feb 6, 2009 at 06:34, Petko Yotov 5...@5ko.fr wrote:
 On Friday 06 February 2009 02:49:00 Patrick R. Michaud wrote:
 On Wed, Feb 04, 2009 at 07:30:56PM +0100, Petko Yotov wrote:
  [1] I can use some help. If people from the community have the time and
  are willing to help out, we could review all PmWiki/* pages and fix them
  with an edit summary like Ok for a release. This will be much faster.
  (Other ideas are welcome too.)

 I've been thinking of adding a special password-protected action
 for pmwiki.org where trusted editors are able to push the page
 directly into wikilib.d, and a way of quickly finding the pages needing
 review.

 I like this, just it would be safer to *copy* the current version to wikilib.d
 and not to *move* it. This way we keep the page history and can revert to a
 previous version, just in case.


Just a little question: isn't all this already the job of the
Draft/Publish edition?
(with a slightly modified processing action)

Dominique

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

Re: [pmwiki-users] Formatting numbers

[Dominique Faure]

On Sun, Jan 18, 2009 at 04:27, Marcus pr...@wordit.com wrote:
 Is there a way to format numbers?
 If I have a form variable 1.5, is there a way to add a zero *only*
 if the variable has one digit after the decimal point?

 1.5 becomes 1.50
 1.54 stays as 1.54


Hi,

The http://www.pmwiki.org/wiki/Cookbook/MarkupExprPlus recipe offers
the 'sprintf' function which could be used as:

{(sprintf %1.2f 1.5)}

Regards,
Dominique

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

Re: [pmwiki-users] htpasswdform

[Dominique Faure]

On Tue, Nov 18, 2008 at 14:41, noskule [EMAIL PROTECTED] wrote:
 hi list
 I installed htpasswdforms, this works great, but I cant figure what I have to
 do to automatically generate a Profiles.Username page.

 My configuration looks like this:
 $EnableHtpasswordProfileLinks = 1;
 $HtpasswordAutoLogin = 1;
 $HtpasswordNewPageRedirect = $AuthorGroup...$Author;
 $HtpasswordDefaultGroup = 'readers';

 anyone an idea how to achieve this?


There's no autocreation of Profiles.Username pages in the
HtpasswordForm recipe (for now).
The $EnableHtpasswordProfileLinks flag is only providing a way to
display the usernames as profile page links in the administration
form, therefore relying on the link to nonexistent page default core
feature.

-- 
Dominique

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

Re: [pmwiki-users] htpasswdform

[Dominique Faure]

On Tue, Nov 18, 2008 at 18:42, noskule [EMAIL PROTECTED] wrote:
 Am Dienstag 18 November 2008 16:55:25 schrieb Dominique Faure:
 On Tue, Nov 18, 2008 at 14:41, noskule [EMAIL PROTECTED] wrote:
  hi list
  I installed htpasswdforms, this works great, but I cant figure what I
  have to do to automatically generate a Profiles.Username page.
 
  My configuration looks like this:
  $EnableHtpasswordProfileLinks = 1;
  $HtpasswordAutoLogin = 1;
  $HtpasswordNewPageRedirect = $AuthorGroup...$Author;
  $HtpasswordDefaultGroup = 'readers';
 
  anyone an idea how to achieve this?

 There's no autocreation of Profiles.Username pages in the
 HtpasswordForm recipe (for now).
 The $EnableHtpasswordProfileLinks flag is only providing a way to
 display the usernames as profile page links in the administration
 form, therefore relying on the link to nonexistent page default core
 feature.

 could you add this feature as an option ? or give me a brief idea how to
 realize that. I would like to avoid change the code of htpasswordform?


I'll look at this as soon as I can.

-- 
Dominique

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

Re: [pmwiki-users] httpvariables / markupexprplus

[Dominique Faure]

On Thu, Oct 23, 2008 at 20:45, noskule [EMAIL PROTECTED] wrote:
 hi list
 I expirienced a problem using httpvariables and markupexprplus.

 If I include httpvariables bevor markupexpr plus, setting pv's via {(set
 xx12)} is not working, if I include it after it works.

 dont work:
$EnableExprVarManip = 1;
include_once($FarmD/cookbook/markupexprplus.php);
include_once($FarmD/cookbook/httpvariables.php);

 work:
include_once($FarmD/cookbook/httpvariables.php);
$EnableExprVarManip = 1;
include_once($FarmD/cookbook/markupexprplus.php);

The HttpVariables recipe must appear first in order to be found and
handled by MarkupExprPlus.

 When I try do do the following condition:

(:if equal {$?count} :)no count, setting to {(set count 20)}
(:else:){(setq count {$?count} )}(:ifend:)

 setting $count to 20 do not work if the condition is true, see:

http://test.netstreams.org/pmwiki/index.php?n=Main.WikiSandbox

This is but the expected behaviour...
...and here's why:

The page markup is processed by successive translation passes, each of
them being dedicated to a particular markup form handling. As the
Variable/MarkupExprPlus page markup is processed *before* the
conditional markup itself, the translation saw only two successive
assignment to the same variable:

Initial:
  (:if equal {$?count} :)no count, setting to {(set count 20)}
  (:else:){(setq count {$?count} )}(:ifend:)

MarkupExprPlus translation pass with ignored text enclosed in brackets:
  [(:if equal ] {$?count} [ :)no count, setting to ] {(set count 20)}
  [(:else:)] {(setq count {$?count} )} [(:ifend:)]

Resulting in:
  {$?count} = nothing
  {(set count 20)} = {$count} set to 20
  {(setq count {$?count} )} = {(setq count )}
= {$count} set to nothing

This explains why I added the 'test' and the 'if' function, in order
to handle conditions during variable evaluations.
In your case, you should use

  {(set count (if (test equal {$?count} ) 20 {$?count} ))}

to get the expected result.

-- 
Dominique

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

Re: [pmwiki-users] Displaying a markup variable via a skin template

[Dominique Faure]

On Mon, Sep 29, 2008 at 23:28, marc [EMAIL PROTECTED] wrote:
 Hi,

 I want to display a variable from the markup on each displayed page via
 the skin template.

 I thought I would be able to use a PTV directly. Thus, in markup:

  (:something: marctest:)

 and in the template file, something like this:

  {$:something}

 But this just displays {$:something} on the page.

 I get close with

  !--markup:{$:something}--

 but this puts a p/p around the result and breaks the div it's in.

 I don't have to use a PTV, I just want to use something in markup so
 that users can change it.

 (I currently have:

  !--function:header_text--

 in the template and:

  function header_text($pagename) {echo 'something';}

 in the page's .php file, but the users can edit the text in this
 method.)

 Any ideas? Thanks.


Hi,

You may perhaps have a look at the Monobook/grease Skins where I
implemented such kind of workarounds in order to handle markup
definition rendering within specific template areas.

Excerpt from grease/grease.tmpl:
  ...
  h1 class='titlepage'!--function:RenderPart title--/h1
  ...

Excerpt from grease/grease.php:
  ...
  function RenderPart($pagename, $part, $strip = '') {
global $SkinPartFmt, $PCache;
$n = skin_$part;
if(!isset($PCache[$pagename][$n])) {
  $t = MarkupToHTML($pagename, :block{$SkinPartFmt[$part]},
array('escape' = 0));
  $PCache[$pagename][$n] = $strip ? preg_replace($strip, '', $t) : $t;
}
print $PCache[$pagename][$n];
  }
  ...

Roughly, the function takes a markup source fragment from the
$SkinPartFmt definition array, renders it as an unenclosed block of
text (no p markers), then does some optional housekeeping on the
resulting html and stores it in the page cache for future reuse to
prevent extraneous generations before outputing the result.

-- 
Dominique

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

Re: [pmwiki-users] define $FmtPV via foreach

[Dominique Faure]

On Thu, Oct 2, 2008 at 21:32, noskule [EMAIL PROTECTED] wrote:
 hi list
 I try to define page variables out of an array:

 $skinsection_ptv_arr = array(
 SectionA = 1,
 SectionB = 0,
 ...
 );

 foreach ( $skinsection_ptv_arr as $ptvname = $val ) {
  $FmtPV['${$ptvname}]' = '$val';
  }

 I cant figure out the right syntax for the variable name in $FmtPV,
 anyone a suggestion


Perhaps:

  foreach ($skinsection_ptv_arr as $ptvname = $val ) {
$FmtPV['$' . $ptvname] = '$val';
  }

-- 
Dominique

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

Re: [pmwiki-users] SourceBlock: unable to turn off Get Code

[Dominique Faure]

On Tue, Sep 16, 2008 at 20:31, Jean-Marc Meessen
[EMAIL PROTECTED] wrote:
 Hello,

 I am using this cookbook (v2008-06-12) with success on a 2.1.26 PMWIKI. The
 only thing that  I can't get to work is the feature to turn off Get Code
 option.

 I am stuck and don't know where to for a hint.

 I tried the following tags:
 (:source -getcode lang=bash tabwidth=4 highlight='2':) [@
 fgsdfgsfg dfgsdfg
 @]
 or
  (:source -getcode lang=bash footer=:)
 bvcbcvbc dssdfsfgsfg
 (:sourcend:)

 Up to now I resisted patching the cookbook PHP. Any hint or debuging
 strategy would be welcome.


Oops! This is a bug... I just uploaded an updated version.

Thanks for the report.
---
Dominique

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

Re: [pmwiki-users] proposed markup for rowspan in simple tables

[Dominique Faure]

On Mon, Aug 25, 2008 at 14:48, Patrick R. Michaud [EMAIL PROTECTED] wrote:
 On Mon, Aug 25, 2008 at 10:44:46AM +0200, Christian Ridderström wrote:
 What about this:

[...]

 (:simpletable separator=; alignment=llc :)
 Column A ; Column B  ; Column C
 asfasdf  ; asdfasdf  ; asdfas
 afasdff  ;
 (:simpletableend:)

 I like this approach a lot -- I'll have to think about it.
 It might even be do-able within the existing table markup, as
 something like:

 || separator=; alignment=llc
 || Column A ; Column B ; Column C
 || apple; banana   ; cherry
 || ask  ;

 Or, perhaps combine separators and alignments in a single format string,
 allowing the separator to change:

 || format=l ; l - c
 || Column A ; Column B - Column C
 || apple; banana   - cherry
 || ask  ;  -


A great idea, I like it also but IMHO, the handling of table headers
should not be forgotten (they're not always aligned like the values).


-- 
Dominique

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

Re: [pmwiki-users] Proposal to change (...) in links to {...}

[Dominique Faure]

On Mon, Aug 25, 2008 at 19:40, Patrick R. Michaud [EMAIL PROTECTED] wrote:
 In this proposal we would not immediately eliminate the
 use of parens to suppress link text -- it would be left
 as an option for now and removed in some future major
 release of PmWiki.

 Any comments on this proposal?


Anyway, a companion migration script/action/whatever... would surely
be well appreciated (at least by myself).
And btw, wouldn't it be also the time to make a decision on
http://www.pmwiki.org/wiki/PITS/00657 ?

-- 
Dominique

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

Re: [pmwiki-users] Beautiful urls: how to put pmwiki.php out?

[Dominique Faure]

On Mon, Aug 18, 2008 at 14:28, Francesco Sblendorio
[EMAIL PROTECTED] wrote:
 Hi.

 I'd like to know how to turn an url such as (it does exist):

 http://fsblendorio.netsons.org/wiki/pmwiki.php/Teatro/Motel

 into something like that:

 http://fsblendorio.netsons.org/wiki/Teatro/Motel


This recurring topic is explained at:

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

-- 
Dominique

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

Re: [pmwiki-users] automatic page titles (aless)

[Dominique Faure]

On Sat, Aug 2, 2008 at 09:33, aless [EMAIL PROTECTED] wrote:

   [...] I found also the AlternateNamingScheme recipe in the Cookbook
  (http://www.pmwiki.org/wiki/Cookbook/AlternateNamingScheme), and
  following the instructions I came up with this array that should transform
 
  l'albero di natale = L_albero_di_natale:
 
  $MakePageNamePatterns = array(
   /'/ = '',   # strip single-quotes
   /[^$PageNameChars]+/ = ' ', # convert non-alnums to spaces
   /(^\\w)/e = strtoupper('$1'), # initial caps
 
   /\\s+/ = '_'# Convert spaces to
  underscores
  );
 
  It should be possible to handle the apostrophe too. One option
  would be to use the ~ character in the pagename and url as a
  surrogate for the ' and then convert ~ to ' on output, in much
  the same way as the above code converts '_' to ' '. This is done in
  the custom $AsSpacedFunction.

 Hello John,

 actually, page names with underscores instead of apostrophes are still
 quite readable, I wanted to try your solution too, but I really don't
 know where to start, could you give me some more hints? I tried to put
 this in my config.php, but it still converts single quotes to spaces and
 then to underscores:

 $PageNameChars = '-~[:alnum:]';

 $MakePageNamePatterns = array(
 /'/ = '~',   # strip single-quotes
 /[^-[:alnum:]]+/ = ' ', # convert non-alnums to spaces
 /(^\\w)/e = strtoupper('$1'), # initial caps
 /\\s+/ = '_');  # Convert spaces to underscores

 I think I'm missing something, don't I?

You just forget to exclude the '~' from the char to convert to space:

$MakePageNamePatterns = array(
/'/ = '~',  # strip single-quotes
/[^-~[:alnum:]]+/ = ' ',# convert non-alnums to spaces
/(^\\w)/e = strtoupper('$1'), # initial caps
/\\s+/ = '_');  # Convert spaces to underscores

or better:

$PageNameChars = '-~[:alnum:]';

$MakePageNamePatterns = array(
/'/ = '~',  # strip single-quotes
/[^$PageNameChars]+/ = ' ', # convert non-alnums to spaces
/(^\\w)/e = strtoupper('$1'), # initial caps
/\\s+/ = '_');  # Convert spaces to underscores


--
Dominique

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

Re: [pmwiki-users] Pu

[Dominique Faure]

On Tue, Jul 29, 2008 at 05:17, DaveG [EMAIL PROTECTED] wrote:

 2] Quotes within the $2 text now appear in the final output as \ rather
 than simply . I've tried moving the $2 around to no avail. Any suggestions
 there?

 Using PSS as described here removed the backslashes before the quotes. I now
 have this (with a few tweaks):

 Markup('^Country:', 'fulltext',
   '/^Country\\s+([a-zA-Z][a-zA-Z]):(.*?)gt;gt;lt;lt;/isme',
   Keep('div class=\'country\'
 style=\'background-image:url(\'.\$GLOBALS['PubDirUrl'].'/skins/dropdown/flags/'.
 strtolower($1). '.png\)\''. PSS('$2'). '/div')
 );


 1] What does the first ':block' do? Didn't appear to do anything.
 Still interested in the intent of this.

 Thanks for pointing me in the right direction.

  ~ ~ Dave


It was to ensure that the output is treated as a sole block, and not
being encapsulated into a paragraph.

-- 
Dominique

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

Re: [pmwiki-users] list of ptv-values from pagelist

[Dominique Faure]

On Mon, Jul 28, 2008 at 23:49, noskule [EMAIL PROTECTED] wrote:
 hi list
 anyone an idea how I get a list of ptv values of certain pages.  Example:

 Page1:
 (:test: A:)

 Page2:
 (:test: B:)

 Page3:
 (:test: C:)


 I need:

 A,B,C


 thanks for any hints
 n os

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


Perhaps some samples from the Test group like
http://www.pmwiki.org/wiki/Test/PTV  may be useful...

-- 
Dominique

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

Re: [pmwiki-users] Pu

[Dominique Faure]

On Tue, Jul 29, 2008 at 00:49, DaveG [EMAIL PROTECTED] wrote:

 I'm trying to define a markup, part of which will be used to determine
 the path for an image styled background. However, this markup:
 Markup('^Country:', 'fulltext',
'/^Country\s+([a-zA-Z][a-zA-Z]):(.*?)gt;gt;lt;lt;/ism',
'div class=country style=background-image: url(\''.
 $GLOBALS['PubDirUrl']. '/dropdown/flags/$1.png\');$2/div'
 );


 results in this HTML:
 div class='vspace'/divdiv class=country style=background-image:
 url('img src='http://mr2wiki.com/pmwiki/pub/dropdown/flags/JP.png'
 alt='' title='' /'); some text/div

 Notice the img src= in the middle of the background-image url.

 I suspect PmWiki is seeing the http://png and considers that to be
 an image.  Is there a way to prevent this?

  ~ ~ Dave

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


You should perhaps use Keep(...) to prevent any further Markup processing:

Markup('^Country:', 'fulltext',
   '/^Country\\s+([a-zA-Z][a-zA-Z]):(.*?)lt;lt;gt;gt;/isme',
   ':block'.Keep('div class=\'country\'
style=\'background-image:
url(\'.\$GLOBALS['PubDirUrl'].'/dropdown/flags/$1.png\)\'').'$2'.Keep('/div'));

-- 
Dominique

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

Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

[Dominique Faure]

On Thu, Jul 10, 2008 at 13:20, Vince Administration
[EMAIL PROTECTED] wrote:
 EEmeli,
 Thanks. I have plenty of work to do on the site, so it is no problem to wait
 a week or two.
 And  Hans,
 Thanks,  I see by studying the function I can create a version which will
 collect the data that I  want.
 But I will go slowly because of eemeli's reply. This sounds like what I
 would want to develop in the future as well as now.
   Vince

 On Jul 10, 2008, at 4:27 AM, Eemeli Aro wrote:

 I'm working just now on something that might fill your needs. It's not
 quite ready yet, but I should be able to get it out by the end of next
 week (no promises, mind). It's a module on top of authuser that can
 read and write usernames, password hashes and additional data in
 SiteAdmin.AuthUser. When done, it'll let me have new users sign up,
 verify their email addresses and create accounts for them, use email
 to reset passwords, let users modify additional details, remove users,
 as well as generate lists of users with specified details.

 I've actually got most of this already working on my own sites, but I
 need to polish up the whole lot and finish implementing it as a
 PageStore extension before I'm ready to publish.

 In other words, I ought to have a better answer for you next week.

 eemeli

 2008/7/10 Vince Administration [EMAIL PROTECTED]:

 Hans, Dominique,
 Thanks for pointing me to the htpasswdform recipe. It comes very
 close to what I want.  The only thing that I really can't quite
 figure out how to
 do is to modify the login form, since it is created by a PHP
 program.   I don't want to give exact details of what I want the form
 to collect because
 then you might do it for me, and it is probably not of wide interest.
 But is there a reasonable way to use a custom form for new users?
 I guess by reasonable I mean without writing the php code.  I see
 that there are a lot of SDV's, so that it might be possible to
 customize.

 Thanks for your help.
   Vince

 On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:

 On Wed, Jul 9, 2008 at 20:56, Hans [EMAIL PROTECTED] wrote:

 Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:

  The idea is to have read access to anyone,  but
 posting only for authenticated users.  For a start I would like the
 users to authenticate themselves by filling in a form.

 Not sure how this can be done. The standard way for granting users
 some authorisation in PmWiki would be to install PmWiki.AuthUser
 and add user id's to SiteAdmin.AuthUser.

 Fox or FoxForum has no separate user management. It is perceivable
 that Fox could be used to add userid/password pairs to
 SiteAdmin.AuthUser. But that alone will not grant any access rights.
 The userid needs to be added to a @group as well. Fox could do that
 too I guess. And then that user group, say call it @forummembers, can
 be used as id for an edit password for the Forum wiki group,
 and you set for that Forum group  $FoxAuth = 'edit';

 Of course the initial NewForumMember form needs to be able/allowed to
 post (add) to SiteAdmin.AuthUser.

 This may work (not tried any of this), but as soon as we let users
 add themselves plus password to SiteAdmin.AuthUser we have the
 problem
 to check first if the userid does already exist. And most likely
 users would like to be able to change their password. I don't see any
 simple solution there.

 Oh, I just remember: there is this recipe to check out:
 http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
 It has (amongst many others) this config option:

 $HtpasswordNewUsers
   When set to 1, a new user form is provided to unauthenticated
 users,
   allowing them to register themselves (defaults to 0).

 This may well be the ticket! and forget all I wrote above about
 adding users with Fox!


  ~Hans


 I couldn't provide more details :)

 --
 Dominique



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





Sorry for the late feedback, but I couldn't find enough time to
correct a minor bug in this code and give you an answer.

The two configuration variables that Hans described previously should
contains regular PmWiki form markup with some $Variables tags
automatically filled/replaced by the recipe.

You just have to make sure that these tags are defined in your own
configuration.

-- 
Dominique

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

Re: [pmwiki-users] Semi-automatic user accounts for fox forum

[Dominique Faure]

On Wed, Jul 9, 2008 at 20:56, Hans [EMAIL PROTECTED] wrote:

 Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:

   The idea is to have read access to anyone,  but
  posting only for authenticated users.  For a start I would like the
  users to authenticate themselves by filling in a form.

 Not sure how this can be done. The standard way for granting users
 some authorisation in PmWiki would be to install PmWiki.AuthUser
 and add user id's to SiteAdmin.AuthUser.

 Fox or FoxForum has no separate user management. It is perceivable
 that Fox could be used to add userid/password pairs to
 SiteAdmin.AuthUser. But that alone will not grant any access rights.
 The userid needs to be added to a @group as well. Fox could do that
 too I guess. And then that user group, say call it @forummembers, can
 be used as id for an edit password for the Forum wiki group,
 and you set for that Forum group  $FoxAuth = 'edit';

 Of course the initial NewForumMember form needs to be able/allowed to
 post (add) to SiteAdmin.AuthUser.

 This may work (not tried any of this), but as soon as we let users
 add themselves plus password to SiteAdmin.AuthUser we have the problem
 to check first if the userid does already exist. And most likely
 users would like to be able to change their password. I don't see any
 simple solution there.

 Oh, I just remember: there is this recipe to check out:
 http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
 It has (amongst many others) this config option:

 $HtpasswordNewUsers
When set to 1, a new user form is provided to unauthenticated users,
allowing them to register themselves (defaults to 0).

 This may well be the ticket! and forget all I wrote above about
 adding users with Fox!


  ~Hans


I couldn't provide more details :)

--
Dominique

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

Re: [pmwiki-users] print icon

[Dominique Faure]

On Wed, Jun 25, 2008 at 22:55, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 ...action=print...

 this gives the print preview, but don't
 lauch the print window?

 Right.
 It calls the print skin, if there is one, while triggering a printer
 is quite a different task.

 Actually, there are links that trigger the very printing process, like
 the one you find at the bottom of this page
 http://www.simplehelp.net/other/how-to-remove-red-eye-from-your-digital-photos-using-gimp/print/
 but I wouldn't know how to enable such a behaviour.


This is done with the help of a bit of javascript. The bottom link is:

Click a href=#Print onclick=window.print(); return false;
 title=Click here to print.here/a

For PmWiki, such a link could only be integrated directly into the
skin template or with a dedicated markup extension defined by an
external recipe.

Regards,
Dominique

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

Re: [pmwiki-users] custom markup: passing arguments to function

[Dominique Faure]

On Mon, Jun 16, 2008 at 15:30, Anno [EMAIL PROTECTED] wrote:
 Hans wrote:
 Monday, June 16, 2008, 12:53:57 PM, Anno wrote:

 Markup('jslide', 'end_',
 '/\\(:jslide\\s(.*)\\s(.*)\\s(.*):\\)/e',
 jslide('$1','$2','$3'));

 try this:

 Markup('jslide', 'end_',
  '/\\(:jslide\\s+(.*?)\\s+(.*?)\\s+(.*?)\\s*:\\)/e',
  jslide(PSS('$1'),PSS('$2'),PSS('$3')));



   ~Hans

 No, nothing. Does it work at your site?

 Anno


IMHO, this is due to the fact that the '.' regexp placehoder is also
capturing '\s'.
You sould perhaps use the ParseArgs function to handle your markup parameters:

Markup('jslide', 'end_',
  '/\\(:jslide\\s+(.*?)\\s*:\\)/e',
  jslide_markup(PSS('$1')));

function jslide_markup($args) {


-- 
Rodney Dangerfield  - I haven't spoken to my wife in years. I didn't
want to interrupt her.

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

Re: [pmwiki-users] custom markup: passing arguments to function

[Dominique Faure]

On Mon, Jun 16, 2008 at 16:04, Dominique Faure
[EMAIL PROTECTED] wrote:
 On Mon, Jun 16, 2008 at 15:30, Anno [EMAIL PROTECTED] wrote:
 Hans wrote:
 Monday, June 16, 2008, 12:53:57 PM, Anno wrote:

 Markup('jslide', 'end_',
 '/\\(:jslide\\s(.*)\\s(.*)\\s(.*):\\)/e',
 jslide('$1','$2','$3'));

 try this:

 Markup('jslide', 'end_',
  '/\\(:jslide\\s+(.*?)\\s+(.*?)\\s+(.*?)\\s*:\\)/e',
  jslide(PSS('$1'),PSS('$2'),PSS('$3')));



   ~Hans

 No, nothing. Does it work at your site?

 Anno


 IMHO, this is due to the fact that the '.' regexp placehoder is also
 capturing '\s'.
 You sould perhaps use the ParseArgs function to handle your markup parameters:

 Markup('jslide', 'end_',
  '/\\(:jslide\\s+(.*?)\\s*:\\)/e',
  jslide_markup(PSS('$1')));

 function jslide_markup($args) {


[Oops, keyboard wipe-out]

function jslide_markup($args) {
  $opt = ParseArgs($args);
  return jslide($opt[''][1], $opt[''][2], $opt[''][3]);
}

See http://www.pmwiki.org/wiki/Cookbook/ParseArgs for further references.

Dominique

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