Re: [pmwiki-users] Deprecated error after upgrade to version 2.3.11
Thanks for your message.
This has already been fixed in Subversion 2 weeks ago, directly inside
stripmagic(). Next PmWiki version will be released in a few days.
Petko
--
If you upgrade : https://www.pmwiki.org/Upgrades
На 15/09/2022 17:25, Hans-Jürgen Godau написа:
After upgrqading pmwiki to vs. 2.3.11 i got the error
Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of
type array|string is deprecated in
/home2/godau/public_html/valentin/wiki/pmwiki.php on line 75
My installed php Version is 8.2. I changed line 75 from
$ChangeSummary = substr(preg_replace('/[\\x00-\\x1f]|=\\]/', '',
stripmagic(@$_REQUEST['csum'])), 0, 100);
to
$ChangeSummary = stripmagic(@$_REQUEST['csum']);
if (!is_null($ChangeSummary) && strlen($ChangeSummary) > 0) {
$ChangeSummary = substr(preg_replace('/[\\x00-\\x1f]|=\\]/', '',
$ChangeSummary), 0, 100);
}
and pmwiki ran without the deprecated warning.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.3.11 released
Hello. PmWiki version 2.3.11 was published today, and is available at:
https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.11.tgz
https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.11.zip
svn://www.pmwiki.org/pmwiki/tags/latest
This version fixes the function stripmagic(), when used with arrays
(a recent update for PHP 8 broke it).
New PageVariables derived from a Group's homepage are now
available: {$GroupHomePage}, {$GroupHomePageName},
{$GroupHomePageTitle}, {$GroupHomePageTitlespaced}.
A new helper function should simplify recipes with custom markup
directives of the format:
(:mydirective arg=val param="other value":)
with an optional closing tag (:mydirectiveend:)
See the documentation at:
https://www.pmwiki.org/wiki/Cookbook/MarkupDirectiveFunctions
The core documentation was updated.
Thanks,
Petko
--
If you upgrade : https://www.pmwiki.org/Upgrades
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Syntax highlighting in the core documentation?
Hello, There is an effort in progress to beautify / syntax highlight the PHP snippets in the documentation. The benefit is obvious -- it is very nice, it allows to easily notice the different parts of the configuration. There are unfortunately 2 relatively important downsides. 1. The Highlight.js library only expects plain text in the code blocks, and if there is any HTML, it strips it keeping the plain text, and it outputs many rather ominous warnings in the JavaScript console of the browser saying: One of your code blocks includes unescaped HTML. This is a potentially serious security risk. One of your code blocks includes unescaped HTML. This is a potentially serious security risk. One of your code blocks includes unescaped HTML. This is a potentially serious security risk. This is for every processed/highlighted block, sometimes 20 times in a page. These warnings are unacceptable to me, I don't want a wiki admin to install PmWiki and Highlight.js and to have these warnings appear out of the box from the core documentation. How can unescaped HTML happen? It can if the code is surrounded with @@...@@ instead of [@...@], then there may be some HTML inside, like bold, or a PmWiki variable like $EnableDiag or $DefaultPasswords. This leads to: 2. In highlighted blocks stripped of inner HTML, PmWiki variables from the documentation like $DefaultPasswords or $EnableUpload no longer link to the PmWiki/Variables documentation sections where these variables are explained. What do you think is more useful to wiki admins installing and configuring PmWiki? * Is it the nice colors for the PHP code? * Is is the automatic links to the PmWiki Variables documentation? I suspect in a short PHP snippet the documentation links are more useful to admins than the colors (and BTW the links are colored blue so they already stand out). I see 2 options: 1. If the syntax highlighting is more important, we can strip all HTML in the blocks before highlighting them, just to keep the warnings from appearing: the Highlight library will strip it anyway, while complaining. 2. We can omit PHP blocks containing HTML, especially links to core variables, from being highlighted. However, this might surprise some editors with their own code.We can configure a "title" attribute for the block that explains the reason? What do you think? Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Concealing text on a page
Welcome to PmWiki! There are 2 ways to have hidden sections, one is easy and convenient but not very secure, the other is secure but somewhat less convenient. The easy way is to use conditionals. In a page, you can have hidden sections like this: (:if auth admin:) This only shows to admins. (:ifend:) The problem with this is, occasionally people might be able to see the hidden parts if the actions "diff" and "source" are not sufficiently protected, or if they have edit access to any page on the wiki like WikiSandbox. See: https://www.pmwiki.org/wiki/PmWiki/ConditionalMarkup The more secure way is to place the secret content in a separate page, protect that page against reading, and include the page (or sections of it) into the public page. In a public page, you can have: (:include PrivatePage#section1:) or: (:include PrivateGroup.AnyPage#section1:) For people with read access to the remote page, this "include" directive will be expanded to the text of the other page or section. For people without read access to the remote page, the directive will be empty/blank. How to include pages or sections, see: https://www.pmwiki.org/wiki/PmWiki/IncludeOtherPages How to password-protect pages, see: https://www.pmwiki.org/wiki/PmWiki/Passwords In any case, you should test your pages with and without admin access to make sure it works as you intended. Petko -- If you upgrade : https://www.pmwiki.org/Upgrades On 09/06/2022 17:34, Ben Quant wrote: I'm new to pmwiki and using wikis in general. I've set up a pmwiki for a roleplaying group I run to log the details of their adventures and the world we are creating. What I'd like to be able to do is set it up so if I log in with my admin username I can see everything, but if the others log in with a different username, some portions of the text on a page are hidden from them. Is this possible, and if so, how do I go about it? Many thanks, Ben ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] New recipe: Checklists
Hello, I published a new recipe "Checklists" Ephemeral to-do lists: https://www.pmwiki.org/wiki/Cookbook/Checklists It is an attempt to improve on the Cookbook:Flipbox functionality, styles and user experience, for ephemeral lists only (task states not saved in the page). I prototyped this as a module for a different project and the reception was better than what I expected. Also, I found myself using it for various situations and reminders, so I decided to detach it into a stand-alone PmWiki recipe. Questions, comments will be welcome. Petko -- If you upgrade : https://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Conditional markup and category
Something like this: https://www.pmwiki.org/wiki/Cookbook/InCategory Petko -- PmWeekly Blog : https://www.pmwiki.org/News If you upgrade : https://www.pmwiki.org/Upgrades On 06/06/2022 10:29, Simon wrote: I want to use conditional markup to determine if a page has been tagged with a specific category. E.g. (:if incategory WikiPage ThisCategory:) - true if WikiPage contains "[[!ThisCategory]]" Any idea if I can achieve this? thanks Simon ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.3.5 released
Hello. PmWiki version 2.3.5 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.5.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.5.zip svn://www.pmwiki.org/pmwiki/tags/latest This version fixes a bug with (:pagelist list=grouphomes:) reported earlier today. A new helper function DisableSkinParts() allows for simpler disabling of headers, footers and sidebars from recipes. When a file is uploaded, new variables with the file path and URL are now available to recipes. The version also contains fixes for PHP 8 and documentation updates. Thanks, Petko -- PmWeekly Blog : https://www.pmwiki.org/News If you upgrade : https://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.3.4 released
Hello. PmWiki version 2.3.4 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.4.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.4.zip svn://www.pmwiki.org/pmwiki/tags/latest This version includes more fixes for PHP 8 and documentation updates. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.3.3 released
Hello. PmWiki version 2.3.3 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.3.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.3.zip svn://www.pmwiki.org/pmwiki/tags/latest This version includes fixes for PHP 8 and documentation updates. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] New recipe: LazyLoading
Hello, This new recipe instructs browsers to fetch pictures only when they are about to appear on the screen: https://www.pmwiki.org/wiki/Cookbook/LazyLoading It may be useful if you have long (tall) pages with pictures or thumbnails below the fold, especially for visitors on mobile devices. Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Undefined array key "title" in .../grouptitle.php - in PHP8
Thanks for notifying me, recipe updated, you can get it from the
cookbook.
Here we can suppress the "undefined/null variable" notice with @:
if (@$page['title']) {...
Petko
On 19/02/2022 11:27, Jean-Patrick Charrey wrote:
Hi
I have been testing the latest Pmwiki 2.3.2 on PHP8.0 I have the
following warning message:
Warning: Undefined array key "title" in .../cookbook/grouptitle.php on
line 39
I have been to reproduce this bug on a plain setup, no other
cookbooks, default PMwiki skin.
I don't have this message in PHP7.4
Line 39 in grouptitle.php has the following code
_if ($page['title']) { return $page['title'];
I guessing a sintax update is needed, but not sure which one. I
realize this Cookbook is perhaps not the most used, but I would
appreciate some help to fix this issue.
Jean-Patrick
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Corner case issues in pmwiki-2.8.2 under PHP 8.1
Thanks for the report, I have updated the scripts for the next version. You can get an archive with the modified files since the release from the page Change log: https://www.pmwiki.org/wiki/PmWiki/ChangeLog Please report if you find other omissions. Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades On 12/02/2022 12:01, Dominique Faure wrote: 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] Fwd: Undefined array key "squelch" in .../notify.php - in PHP8
Thanks for the report, I have updated the notify.php script for the next version. You can get an archive with the modified files since the release from the page Change log: https://www.pmwiki.org/wiki/PmWiki/ChangeLog Please report if you find other omissions. Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades On 12/02/2022 11:39, Jean-Patrick Charrey wrote: Hi I have been testing the latest Pmwiki 2.3.2 on PHP8.0 I have the following warning message: _Warning__: Undefined array key "squelch" in __.../scripts/notify.php__ on line __137_ All cookbooks are removed from config.php and I only have $EnableNotify = 1; I don't have this message in PHP7.4 Line 137 in notify.php has the following code if ($opt['squelch']) I wonder if some sintax update is needed there? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.3.2 released
Hello. PmWiki version 2.3.2 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.2.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.2.zip svn://www.pmwiki.org/pmwiki/tags/latest This version includes bug fixes and updates for PHP 8.1. The core variable $EnableIncludedPages introduced in 2.3.0 was renamed to $EnableListIncludedPages to avoid ambiguity. With LocalTimes, it is now possible to configure the number of days the "plus" button will pull from the page history, and the function will better recognize some older RecentUploads formats. PmSyntax was updated so that "\\" line breaks in tables and headings are treated like in the core, staying in the same context; and the different PmSyntax blocks will now be processed in parallel. The code configuring and loading pub/pmwiki-utils.js was moved to a new file scripts/utils.php, and a new variable $EnablePmUtils was added to allow administrators to easily disable these functions. The script pmwiki-utils.js will now be included in the page header rather than the footer, which may reduce the number of page redraws. The individual functions will now be processed in parallel. The documentation was updated. Thanks, Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades ___ 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
Thanks, added for 2.3.2. Petko On 07/02/2022 15:12, Dominique Faure wrote: 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 ___ 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
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
Re: [pmwiki-users] Include-problem
On 15/01/2022 20:05, Thomas Lundgren wrote:
I´m using the (:include Group/Page:) (with no other parameters)
directive quite a lot on a couple of my PmWiki-sites. All but one
works well!
On the site that does not work I´m, in a group (named Admin) and a
page (named Allt), using include for a couple of pages.
At the top of the page PmWiki prints out; "Admin.GroupHeader self=0
basepage={*Admin.Allt}". After that all content from the pages are
includes but no images are included.
Why does PmWiki prints out "Admin.GroupHeader self=0
basepage={*Admin.Allt}" and how do I get the images to be included (as
in my other sites).
If you have attached files or images with the Attach:file.ext markup,
and you're including this text in another wikigroup, the same link may
not work in the other group unless there is a similarly named file
attached to the other group.
Normally, if you want to include text with attachments, into another
group (or page, depending on your $UploadPrefixFmt setting), the Attach:
links may work if you use the full format as in
Attach:Group.Page/file.ext
or
Attach:{$FullName}/file.ext
This should work even when included in another wikigroup.
Also, uploads need to be enabled in the other wikigroup, and with the
same $UploadPrefixFmt setting.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Include-problem
This looks like pages may have reached the limit number of inclusions,
sometimes nested inclusions, or inclusions from pagelists.
See the $MaxIncludes variable:
https://www.pmwiki.org/wiki/PmWiki/LayoutVariables#MaxIncludes
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
On 15/01/2022 20:05, Thomas Lundgren wrote:
Please help! :)
I´m using the (:include Group/Page:) (with no other parameters)
directive quite a lot on a couple of my PmWiki-sites. All but one
works well!
On the site that does not work I´m, in a group (named Admin) and a
page (named Allt), using include for a couple of pages.
At the top of the page PmWiki prints out; "Admin.GroupHeader self=0
basepage={*Admin.Allt}". After that all content from the pages are
includes but no images are included.
Why does PmWiki prints out "Admin.GroupHeader self=0
basepage={*Admin.Allt}" and how do I get the images to be included (as
in my other sites).
With best regards,
Thomas Lundgren
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 20 years, version 2.3.1 released
Hello,
PmWiki version 2.3.1 was published today, and is available at:
* https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.1.tgz
* https://www.pmwiki.org/pub/pmwiki/pmwiki-2.3.1.zip
* svn://www.pmwiki.org/pmwiki/tags/latest
January 2022 is the 20th year anniversary of the release of PmWiki
version 0.1, and 13 years since I (Petko) became core developer. This
merited additional work and effort with hopefully interesting and useful
new production.
PHP 5.3 - 8.1 compatibility
* PmWiki 2.3.1 includes updates for PHP 8.0 and 8.1.
* Consequently, it requires PHP version 5.3 (released 2009) or more
recent.
PmSyntax. A new function PmSyntax was added to the core, and enabled on
pmwiki.org.
* It highlights PmWiki syntax in the documentation, and possibly in
the basic edit form.
* It only highlights PmWiki markup, and is independent from
Highlight.js. See Cookbook:PmSyntax [1] and $EnablePmSyntax [2].
* It should highlight most core language features and those of many
recipes, see this mashup of various markups [3].
* Developers can add custom rules in the $CustomSyntax [4] array, see
Cookbook:CustomSyntax [5].
* The (:markup:) directive can now have class=norender to only show
the source code without processing it. This may be useful, together with
PmSyntax, in 2 cases: writing/discussing markup code without actually
running it, or working on PageList Templates where you want to see and
edit them highlighted.
Improvements to the edit form
* PmSyntax (above) can be enabled to highlight the PmWiki markup the
edit form, and should work in recent standards-compliant browsers.
* The variable $EnableNotSavedWarning [6] is now enabled by default.
Add to config.php $EnableNotSavedWarning [6] = 0; to disable it.
* A new variable $EnableIncludedPages [7] allows listing of other
pages included from the currently edited page, with links to see or edit
them. When the variable is enabled, the list of pages appears in the
edit form, after the text area, in a collapsed element. The
list includes pages from which text, text variables, or templates are
included from the edited page. This is enabled on pmwiki.org if you wish
to preview it.
* The $EnableEditAutoText [8] function will now feel more like other
text editors by removing the automatically inserted bullet when Enter is
pressed twice.
Dates and times, monitoring, review
* The {(ftime)} Markup expression now accepts a new format '%o' for
the ordinal suffix of the date.
* The Notify [9] feature now accepts a tz= timezone specifier for
individual subscribers. See Notify#tz [10].
* A function based on Cookbook:LocalTimes [11] was added to the core.
See the recipe page [11] for the differences. You can continue using the
recipe, or disable it and enable the core function.
* New core variables $EnableLocalTimes [12], $CurrentLocalTime [13].
* New markup @2022-01-09T08:35:00Z output as a element,
formatted via $TimeFmt [14]; localized if $EnableLocalTimes [12].
* Added a variable $EnableRecentUploads [15] which makes it easy to
enable the Recent Uploads feature on AllRecentChanges. This is a basic
format that may be good enough for many wikis. For more options, see
Cookbook:RecentUploadsLog [16].
* The default $RecentChangesFmt [17] now use the variable
$CurrentLocalTime [13] instead of $CurrentTime [18]. In the wiki source
text it saves the timestamps in a portable time format in GMT, which is
then shown formatted per $TimeFmt [14] (wiki timezone). It looks just
like $CurrentTime [18] did previously, but can be converted to the
visitor's time zone if LocalTimes is enabled. If you have custom
$RecentChangesFmt [17] entries that use $CurrentTime [18], nothing will
change for you, but you may want to update these with $CurrentLocalTime
[13] if you want to benefit from localization.
* The "page history" page now has CSS classes for the delay between
edits: diffday, diffweek, diffmonth, diffyear. These allow styling of
vertical spacing between individual edits in page histories. See
Cookbook:DiffDelay [19] for an example.
* The page history can now have a "hidden" edit type, in addition to
"minor". This is intended to be used by recipes in order to hide, rather
than delete, some edits from the page history. A couple of new recipes
using this feature will be added in the next few days.
PageLists, categories, backlinks
* PageLists [20] now accept a new argument category=Name which lists
only pages declared in the category with the markup [[!Name]], and does
not include pages simply linking to [[Category/Name]] (unless they also
contain [[!Name]]).
* The differentiation between links to !Name and Category.Name
requires the pages containing category links to be re-indexed; see
Cookbook:ReindexCategories [21] which can automate this.
* Also in PageLists, the arguments link= and category= now accept
multiple and negative specifiers, and
Re: [pmwiki-users] Should $EnableNotSavedWarning be enabled by default?
Thanks all, I have enabled it by default for 2.3.0, and documented in sample-config.php for easy noticing. Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 08/01/2022 20:02, Jake D. Parsons wrote: To prevent accidental loss I use a text editor and then copy and paste, Preview, edit, proofread again, and Publish. Seems the only sane way to not lose work, be productive, and keep away from browser quirks with Text Boxes. As a touch typist though, I make bad mistakes at times and the warning has saved me a few times. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Should $EnableNotSavedWarning be enabled by default?
On 04/01/2022 21:38, Simon wrote: I couldn't agree more. As there is no easy undo if you close without saving, and the consequences are severe - the loss of potentially a lot of work. Also I think modern expectation (cf online editing such as google docs) is that you can't/shouldn't be able to accidentally lose input. Agreed. I was worried what if I write and write, then preview, and decide not to save my edits. But as PmWiki stores all page history, in case of a mistake I can restore an older version. There is a recipe AutoSave: https://www.pmwiki.org/wiki/Cookbook/AutoSave However, it is somewhat complex, I don't use it, and I am not comfortable with adding the full recipe to the core. For example, it requires for Drafts to be enabled. Also, if someone else is editing the same page, it may fail to resolve the differences. We also have SessionPageStore: https://www.pmwiki.org/wiki/Cookbook/SessionPageStore Something like this could be adapted to only temporarily store unsaved texts. It is specific to the user, another user would have a separate storage. But the future is probably the modern browsers' LocalStorage interface, where we could store the page text until it is submitted and saved. Which would also allow offline editing (but not previewing and saving while offline). Petko On Wed, 5 Jan 2022 at 00:23, Petko Yotov <5...@5ko.fr> wrote: Currently by default PmWiki doesn't warn when people edit a page, and try to move away from the edit form without saving. We have $EnableNotSavedWarning but it needs to be enabled in config.php by the administrator. I added it to sample-config.php, but I wonder if instead we should simply enable it by default. I believe the setting dramatically improves the user experience and saves a lot of frustration, especially with inexperienced editors and administrators (who have yet to read the documentation and enable the setting). The setting, enabled, might possibly interfere with some custom edit forms, although I am not aware of such a case, or with some of the existing recipes that do exactly this. If we enable it by default, anyone who doesn't need this feature can disable it with $EnableNotSavedWarning = 0; Even if there might be existing administrators who may be annoyed to add this line when they upgrade, I feel the benefit from having the feature enabled outweighs the downside. Thoughts? Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Should $EnableNotSavedWarning be enabled by default?
On 05/01/2022 01:46, ABClf wrote: No matter what choice will be done for sample-config, it's convenient to have this line written in starting config (commented or no), so that administrators know that such option does exist. Agreed. As for me I have no preference here. I did not use that option ; testing now. I always want this message, except when I'm testing/debugging PmWiki code and recipes and I reload a page multiple times. In such a case it only bothers me, but I have disabled it on my dev/test installation. If the message written in the pop-up can be modified, I would prefer "Quit this page" instead of "Quit website". There is no such string, this is a browser-specific thing. Our message is: $[Content was modified, but not saved!] It is translatable in XLPage, but it is most likely ignored by the browsers. It appears some websites were abusing this function in order to keep people from leaving their website. So now browsers mostly ignore what we set as a message, and they mostly display a generic message, in the language of the operating system. Nevertheless, for us this is acceptable, we only need a generic warning. Petko Le mar. 4 janv. 2022 à 21:40, Simon a écrit : I couldn't agree more. As there is no easy undo if you close without saving, and the consequences are severe - the loss of potentially a lot of work. Also I think modern expectation (cf online editing such as google docs) is that you can't/shouldn't be able to accidentally lose input. great idea Simon On Wed, 5 Jan 2022 at 00:23, Petko Yotov <5...@5ko.fr> wrote: Currently by default PmWiki doesn't warn when people edit a page, and try to move away from the edit form without saving. We have $EnableNotSavedWarning but it needs to be enabled in config.php by the administrator. I added it to sample-config.php, but I wonder if instead we should simply enable it by default. I believe the setting dramatically improves the user experience and saves a lot of frustration, especially with inexperienced editors and administrators (who have yet to read the documentation and enable the setting). The setting, enabled, might possibly interfere with some custom edit forms, although I am not aware of such a case, or with some of the existing recipes that do exactly this. If we enable it by default, anyone who doesn't need this feature can disable it with $EnableNotSavedWarning = 0; Even if there might be existing administrators who may be annoyed to add this line when they upgrade, I feel the benefit from having the feature enabled outweighs the downside. Thoughts? Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Should $EnableNotSavedWarning be enabled by default?
Currently by default PmWiki doesn't warn when people edit a page, and try to move away from the edit form without saving. We have $EnableNotSavedWarning but it needs to be enabled in config.php by the administrator. I added it to sample-config.php, but I wonder if instead we should simply enable it by default. I believe the setting dramatically improves the user experience and saves a lot of frustration, especially with inexperienced editors and administrators (who have yet to read the documentation and enable the setting). The setting, enabled, might possibly interfere with some custom edit forms, although I am not aware of such a case, or with some of the existing recipes that do exactly this. If we enable it by default, anyone who doesn't need this feature can disable it with $EnableNotSavedWarning = 0; Even if there might be existing administrators who may be annoyed to add this line when they upgrade, I feel the benefit from having the feature enabled outweighs the downside. Thoughts? Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Minor issue(s) in sample-config.php
Hi Robert, On 01/01/2022 22:27, Robert Riebisch wrote: docs/sample-config.php says: ## By default, pages in the Category group are manually created. ## Uncomment the following line to have blank category pages This doesn't seem to be true in that way, that my fresh PmWiki installation already creates Category.* pages, whenever I insert, e.g., [[!FooBar]] into a page, although the $AutoCreate line is commented out in my local/config.php, that I copied from docs/sample-config.php. Does it actually create the page files in wiki.d? Normally in a fresh installation the category link has a specific HTML snippet, and the link looks like links to existing pages, even if the category page doesn't exist (e.g. not a link to Category?action=edit). Also, when you follow a link to a category page that doesn't exist or open its URL, PmWiki doesn't show the "Site.PageNotFound" page, but shows the empty page with the HTTP response code 200 (OK). This is by design. By default the Category.GroupFooter contains a pagelist with backlinks, so even a non-existing category page will function properly. I would also prefer if you turn any remaining "## Text" lines into "## Text" (two spaces) to make docs/sample-config.php look more nice. Done. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Intermap with accented link
Accented characters in Site.InterMap may or may not work. It may depend on your server locale and PHP version. Normally only "word"-characters can be used, but in different languages different characters can appear in words. The following, added to config.php, appears to work regardless of the server locale, from a UTF-8 enabled wiki, to a UTF-8 enabled target: $LinkFunctions['Littré:'] = 'LinkIMap'; $IMap['Littré:'] = 'https://www.littre.org/definition/$1'; In your case, both your wiki and the target website are UTF-8 enabled. Also, config.php must be saved in the UTF-8 encoding (it probably is; this is selected in the "File-Save As" dialogue box, or on some text editors from "File-Save With Encoding", or "Tools-Encoding", or "Tools-Charset"). Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 30/12/2021 12:58, ABClf wrote: Hello, I would like to know if intermap links do work if accented characters is used for the command word. In my case, it doesn't, but my config might be involved (can not test on pmwiki as my link has to be approved first) : intermap tested : littré: https://www.littre.org/definition/ command tested : littré:péquin Thank you. Gilles. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] RFC: Community poll for PageList link/category arguments
On 27/12/2021 07:57, Petko Yotov wrote: When you're searching for links to multiple pages or to wildcards, the new core algorithm is different from the one in the recipe, with fewer loops, and I believe (hope) it will be faster than the current recipe. On PmWiki.org we only have about 10K pages, and here is our benchmark: https://www.pmwiki.org/wiki/Test/CorePLMT2 Single page: link=PmWiki.BasicEditing 17: 00.22 00.21 PageListTermsTargets begin count=10109 20: 00.25 00.24 PageListTermsTargets end count=70 That's 0.03 seconds. Wildcard, multiple pages: link=PmWiki.BasicEditin?,NoSuchGroup654.NoSuchPage987 52: 00.32 00.30 PageListTermsTargets begin count=10109 55: 00.39 00.37 PageListTermsTargets end count=72 That's 0.07 seconds, only 0.04s or 1/25th of a second slower than the first one. I think it might be good enough for many people. Note that the second search is case-insensitive, it returns 2 additional pages which link to Pmwiki.BasicEditing (lowercase "w" in "Pmwiki") which doesn't exist. Not sure if I should do something about this case, or not. Petko On 27/12/2021 07:57, Petko Yotov wrote: Thank you Gilles, these are great questions. My replies below. On 27/12/2021 01:28, ABClf wrote: I understand current installations won't be broken, yet I have a question about performance, concerning multiple link in pagelist : when benchmarking the same pagelist, targeting a one single link, native link=mylink against cookbooked links=mylink, it looks to me that native is faster ; am I right ? https://www.languefrancaise.net/Test/PageListMultiple (around 3) https://www.languefrancaise.net/Test/PageListNormal (around 1,70) If so, would it be possible to get the best of each : native for one target search, and complex for complex queries ? First, this is a fabulous installation with 64817 pages! It will be great indeed to benchmark the new feature. Second, we need to look at the numbers between the start and end of the functions, so the difference between the core and the recipe are even greater: 422: 00,69 PageListTermsTargets begin count=64817 425: 01,09 PageListTermsTargets end count=164 1.09-0.69=0.4 seconds for the core processing 422: 00,76 PageListMultiTargets begin count=64817 425: 03,17 PageListMultiTargets end count=164 3.17-0.76=2.41 seconds for the recipe, that's about 6 times more CPU-intensive. Indeed, in 2.3.0, when you have link=SinglePage, then the original scanning method is used, so the times should be very close to the current ones. When you're searching for links to multiple pages or to wildcards, the new core algorithm is different from the one in the recipe, with fewer loops, and I believe (hope) it will be faster than the current recipe. Again, your installation will be a great place to verify this. Question 2, for this paragraph : link=PageA,PageB should list pages linking to "AT LEAST ONE" among PageA and PageB. link=+PageA,+PageB should list pages linking to "BOTH" PageA and PageB. I would like to know if case bellow is involved in the choice. In my case, I have a group made of pages named 1900, 1901, 1902, etc., for aggregating words by years. Then, for the query links=Year.199* expected output would be to list pages having a link to any year page from 1990 to 1999 (and not list pages having a link to all pages included in the range). link=Year.199* or link=+Year.199* lists pages linking to any page with the pattern, not to all pages, whether the target page exists or not. The wildcard characters are about characters, not about existing pages: ? = exactly one character, any character * = between zero and any number of any character(s) The poll is more about a case like link=GroupA.*,GroupB.* then we need to decide how we want it to behave. Should it require at least one link to GroupA OR to GroupB like in the recipe? Should it require at least one link to GroupA AND at least one link to GroupB? Or should this case be written as link=+GroupA.*,+GroupB.* ? Petko Le sam. 25 déc. 2021 à 09:13, Petko Yotov <5...@5ko.fr> a écrit : Hello, I hope you are all safe, and happy holidays if you're celebrating! I've been working on some new features for version 2.3.0 and I'd like your input. If you have a few minutes, please look at this page: https://www.pmwiki.org/wiki/PITS/01475 ...and consider which ones of the proposed implementations may suit your wiki and your editors best, and add your name. I'd like to see some comments/votes and to release 2.3.0 by January 8. 2022, which will include implementing and documenting the new features. If you have questions or suggestions, you can add them to the page, or reply to the mailing list. Thank you in advance. Petko ___ pmwiki-devel mailing list pmwiki-de...@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Re: [pmwiki-users] RFC: Community poll for PageList link/category arguments
Thank you Gilles, these are great questions. My replies below. On 27/12/2021 01:28, ABClf wrote: I understand current installations won't be broken, yet I have a question about performance, concerning multiple link in pagelist : when benchmarking the same pagelist, targeting a one single link, native link=mylink against cookbooked links=mylink, it looks to me that native is faster ; am I right ? https://www.languefrancaise.net/Test/PageListMultiple (around 3) https://www.languefrancaise.net/Test/PageListNormal (around 1,70) If so, would it be possible to get the best of each : native for one target search, and complex for complex queries ? First, this is a fabulous installation with 64817 pages! It will be great indeed to benchmark the new feature. Second, we need to look at the numbers between the start and end of the functions, so the difference between the core and the recipe are even greater: 422: 00,69 PageListTermsTargets begin count=64817 425: 01,09 PageListTermsTargets end count=164 1.09-0.69=0.4 seconds for the core processing 422: 00,76 PageListMultiTargets begin count=64817 425: 03,17 PageListMultiTargets end count=164 3.17-0.76=2.41 seconds for the recipe, that's about 6 times more CPU-intensive. Indeed, in 2.3.0, when you have link=SinglePage, then the original scanning method is used, so the times should be very close to the current ones. When you're searching for links to multiple pages or to wildcards, the new core algorithm is different from the one in the recipe, with fewer loops, and I believe (hope) it will be faster than the current recipe. Again, your installation will be a great place to verify this. Question 2, for this paragraph : link=PageA,PageB should list pages linking to "AT LEAST ONE" among PageA and PageB. link=+PageA,+PageB should list pages linking to "BOTH" PageA and PageB. I would like to know if case bellow is involved in the choice. In my case, I have a group made of pages named 1900, 1901, 1902, etc., for aggregating words by years. Then, for the query links=Year.199* expected output would be to list pages having a link to any year page from 1990 to 1999 (and not list pages having a link to all pages included in the range). link=Year.199* or link=+Year.199* lists pages linking to any page with the pattern, not to all pages, whether the target page exists or not. The wildcard characters are about characters, not about existing pages: ? = exactly one character, any character * = between zero and any number of any character(s) The poll is more about a case like link=GroupA.*,GroupB.* then we need to decide how we want it to behave. Should it require at least one link to GroupA OR to GroupB like in the recipe? Should it require at least one link to GroupA AND at least one link to GroupB? Or should this case be written as link=+GroupA.*,+GroupB.* ? Petko Le sam. 25 déc. 2021 à 09:13, Petko Yotov <5...@5ko.fr> a écrit : Hello, I hope you are all safe, and happy holidays if you're celebrating! I've been working on some new features for version 2.3.0 and I'd like your input. If you have a few minutes, please look at this page: https://www.pmwiki.org/wiki/PITS/01475 ...and consider which ones of the proposed implementations may suit your wiki and your editors best, and add your name. I'd like to see some comments/votes and to release 2.3.0 by January 8. 2022, which will include implementing and documenting the new features. If you have questions or suggestions, you can add them to the page, or reply to the mailing list. Thank you in advance. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] RFC: Community poll for PageList link/category arguments
Hello, I hope you are all safe, and happy holidays if you're celebrating! I've been working on some new features for version 2.3.0 and I'd like your input. If you have a few minutes, please look at this page: https://www.pmwiki.org/wiki/PITS/01475 ...and consider which ones of the proposed implementations may suit your wiki and your editors best, and add your name. I'd like to see some comments/votes and to release 2.3.0 by January 8. 2022, which will include implementing and documenting the new features. If you have questions or suggestions, you can add them to the page, or reply to the mailing list. Thank you in advance. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.145 released
Hello. PmWiki version 2.2.145 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.145.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.145.zip svn://www.pmwiki.org/pmwiki/tags/latest This version includes a minor change in search patterns: searches and pagelists with a wrong or undefined $SearchPatterns (list=abc argument) will now use $SearchPatterns["default"] rather than an empty array (effectively all pages). This was likely the intended behavior, a way for admins to restrict search locations. It also includes updates for PHP 8, a fix of an emoji for non-UTF8 wikis, and the latest pages of the documentation. Thanks, Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Error 406
This error code is never issued by the PmWiki core, so I suspect a server (mis-)configuration. This request is blocked, never reaching PmWiki. The first thing I'd check is that the server accepts pathname information, like you use pmwiki.php/Main/HomePage instead of pmwiki.php?n=Main.HomePage. If it is disabled, on the Apache server it can be enabled with this line in .htaccess: AcceptPathInfo On However, since you say it only happens when you post an edit form, and only on some pages, it may be a web application firewall (WAF) doing this. Many hosting providers use the "mod_security" WAF, and you need to review the documentation of your hosting provider about what can be configured and how. Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 09/12/2021 22:07, Cricket Onebit wrote: I updated our website, and now get The requested URL /pmwiki/pmwiki.php/Main/HomePage?action=edit encountered error 406. Please contact the site administrator. It happens when I Save a page, or even when I Cancel a save, but only happens for some pages. Fingers crossed it's easy to fix if I look in the right place. I haven't used PmWiki for anything but updating content and software for this site for almost 10 years. (I miss it!) Thanks in advance, Sandy Schoen ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.144 released
Hello. PmWiki version 2.2.144 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.144.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.144.zip svn://www.pmwiki.org/pmwiki/tags/latest This version includes fixes for PHP 8 and an update to intermap.txt. The conditional markup "exists" was optimized when called multiple times. The functions CondExists(), MatchPageNames(), and MatchNames(), can now be called with an additional argument (set to false) when a case-sensitive match is needed. The documentation was updated. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist with RecentChanges trail : how to get rid of deleted pages which are listed ?
Next version should be released early next month, but you can already
try the pre-release now -- get it from the PmWiki/ChangeLog page. Only
pmwiki.php has changes related to this.
It already has the "if exists" optimization, which on large pagelists
may improve the stopwatch times by a factor of 10 or more. It is still
case-insensitive, and this is unlikely to change in the core, but will
allow a local configuration to override it or add a new one.
Petko
On 29/10/2021 16:05, ABClf wrote:
Thank you Petko ;
One, I believe I have used if="exists {=$FullName}" parameter with
defective syntax, and obviously failed in getting the expected result.
Two, since I want to collect recently changed pages among several
groups in one shot, using fmt for grouping the output, I use
trail=Site.AllRecentChanges group=Group1,Group2,Group3. Might not be
cost effective, yet it looks like it's working decently.
if="exists {=$FullName}" param can not be used in such a long pagelist
case ; with this parameter on, pagelist does too much for work, giving
:
23420: 09,42 (using if exists)
460: 00,52 (without if exists).
I will try with the next version.
Gilles.
In my case I don't mind about case.
Le dim. 24 oct. 2021 à 10:54, Petko Yotov <5...@5ko.fr> a écrit :
The most efficient should be this:
(:pagelist group=Main trail=Main.RecentChanges if="exists
{=$FullName}":)
group=Main is recommended if your pages are all from the same group.
I just found out that the "exists" conditional can be optimized a lot,
especially when called multiple times from a pagelist. This will be
released in the next version in a few days.
One other note, the "exists" conditional is case insensitive, like the
"name" and "group" conditionals, but unlike "match". This means if we
test for deleted pages "Wikisandbox" and "WikiSandBox", but there is
the
correct page "WikiSandbox", it will return true:
https://www.pmwiki.org/wiki/Test/CondExists2
I wouldn't want to change the current state and risk breaking existing
wikis relying on the case insensitivity, but in your situation this
can
be clearly wrong.
I'll have to think about what to do. Possibly adding a new conditional
for "case-sensitive exists" or a way to configure the current one to
be
case sensitive. Let's think about it.
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
On 22/10/2021 16:04, ABClf wrote:
> I have a pagelist using a RecentChanges as trail source ;
> page which have been deleted does appear in the RecentChanges trail (I
> believe it's the normal behaviour) ; thus they also get listed in
> pagelist result.
> I don't know how to get rid of the deleted pages ; I believe I have
> use the (:if exists:) param or set up a special list= parameter.
> How would you do ?
> Thank you,
> Gilles.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist with RecentChanges trail : how to get rid of deleted pages which are listed ?
The most efficient should be this:
(:pagelist group=Main trail=Main.RecentChanges if="exists
{=$FullName}":)
group=Main is recommended if your pages are all from the same group.
I just found out that the "exists" conditional can be optimized a lot,
especially when called multiple times from a pagelist. This will be
released in the next version in a few days.
One other note, the "exists" conditional is case insensitive, like the
"name" and "group" conditionals, but unlike "match". This means if we
test for deleted pages "Wikisandbox" and "WikiSandBox", but there is the
correct page "WikiSandbox", it will return true:
https://www.pmwiki.org/wiki/Test/CondExists2
I wouldn't want to change the current state and risk breaking existing
wikis relying on the case insensitivity, but in your situation this can
be clearly wrong.
I'll have to think about what to do. Possibly adding a new conditional
for "case-sensitive exists" or a way to configure the current one to be
case sensitive. Let's think about it.
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
On 22/10/2021 16:04, ABClf wrote:
I have a pagelist using a RecentChanges as trail source ;
page which have been deleted does appear in the RecentChanges trail (I
believe it's the normal behaviour) ; thus they also get listed in
pagelist result.
I don't know how to get rid of the deleted pages ; I believe I have
use the (:if exists:) param or set up a special list= parameter.
How would you do ?
Thank you,
Gilles.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] FW: pagelist with intext check
From the cookbook page it looks as if you would need to use {=$FullName}
otherwise it checks the currently browsed page instead of the remote
page:
if="intext 'text to check' {=$FullName}"
Does this work?
BTW in some cases you may not need to use this conditional, just add the
search terms in your pagelist like this:
(:pagelist group=Main fmt=#default separate terms all required
-excluded:)
or:
(:pagelist group=Main fmt=#default "some phrase":)
The one with separate terms should be orders of magnitude faster as in
most cases it doesn't need to open individual page files, just the page
index.
Unlike the cookbook recipe, the core finds directives like (:noheader:)
or (:table:) if you search for those.
Petko
On 19/10/2021 02:36, da...@classic-sf.com wrote:
I'm attempting to list pages containing specific text and failing. I'm
certainly doing something silly.
I have added 'if intext' to my config.php as per
https://www.pmwiki.org/wiki/Cookbook/ConditionalMarkupSamples#intext
and
using it as (:if intext 'x' ) works OK.
If I attempt to use in a pagelist it doesn't. (:pagelist if="intext
'text to
check'":). What have I missed?
Regards
Dave Cooke.
PS thanks in advance for any advice.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Custom block link : short html code rather than strict text link
Also this:
{{=$FullName}$:vedette}
can be replaced with:
{=$:vedette}
Petko
On 16/10/2021 22:46, ABClf wrote:
Well, thank you, you are right,
[[my link| %h5% Title %% Some text]]
is the way to go for me.
It does allow pretty verbose command and is good for clickable list
item
[[#listemots1]]
%apply=link class="class"%[[{=$FullName}|%h5%{{=$FullName}$:vedette}%%
%rfloat badge%{=$:attestation}%%\\
''{=$:sens}'']]%%
[[#listemots1end]]
Tested and adopted.
Le sam. 16 oct. 2021 à 10:14, Petko Yotov <5...@5ko.fr> a écrit :
This is not a WikiLink markup so it doesn't convert pagenames to URLs.
In the href="..." attribute you need to use the "page URL", not the
"page name":
(:blocklink href="{=$PageUrl}" :)
Note that the current markup allows for the link href to include
JavaScript code, e.g.:
(:blocklink href="javascript:alert(document.cookie)":)
which may allow editors to insert malicious code. So if untrusted
people
can edit the wiki, you shouldn't enable this markup in its current
definition.
Petko
On 16/10/2021 04:18, ABClf wrote:
> Playing with last solution ; almost working for my needs, excepted the
> blocklink output which gives me unexpected result :
> my pagelist is on GroupA, printing out a list of blocklinks linking to
> :
> https://www.mysite.fr/GroupA/GroupB.Page1
> where expected result is :
> http://www.mysite.fr/GroupB.Page1
>
> In my own case, I test the blocklink markup in localtemplates,
> defining a new format, like that (code shortened) :
> [[#listesynonyme]]
> (:blocklink href={=$FullName} class="list-group-item":)
> {{=$FullName}$:vedette}
> (:blocklinkend:)
> [[#listesynonymeend]]
>
> then, in group Synonyme, I have a pagelist using quoted format ; which
> gives me a list of blocks, linking as expected, but pointing to
> https://www.mysite.fr/Synonyme/Bob.15887 where
> https://www.mysite.fr/Bob.15887 is expected.
>
> To get rid of this Group issue, one working solution is to write :
> (:blocklink href="https://www.mysite.fr/Bob/{=$Name};
> class="list-group-item":)
>
> Not sure if I'm doing mistake, if the code works as expected or if it
> needs to be a little improved in how to handle the Group part.
>
> Thank you,
> Gilles.
>
> Le ven. 15 oct. 2021 à 23:45, ABClf a écrit
> :
>>
>> Thank you Petko for your top notch answer ;
>> I'm going to try the last one soon.
>> Gilles.
>>
>> Le ven. 15 oct. 2021 à 18:13, Petko Yotov <5...@5ko.fr> a écrit :
>> >
>> > Indeed, this is not possible with core PmWiki markup.
>> >
>> > In the past, the HTML standards required links to be inline elements
>> > which could not contain block-level elements like paragraphs or
>> > headings.
>> >
>> > So in PmWiki markup, you can have 2 links, one in the heading, the other
>> > in the text like this:
>> >
>> > ! [[my link|Title]]
>> > [[my link|Some text]]
>> >
>> >
>> > Or you can have a specially formatted and styled link text like this:
>> >
>> > [[my link| %h5% Title %% Some text]]
>> >
>> > then you style .h5 in your pub/css/local.css, for example:
>> >
>> > .h5 {
>> >display: block;
>> >font-weight: bold;
>> >font-size: 105%;
>> > }
>> >
>> > This will work well in lists for menus and navigation. I'd go with
>> > this solution id I needed the feature.
>> >
>> >
>> > Finally, and as usual, you can define your own markup rule to do this.
>> > For example:
>> >
>> >Markup('blocklink', 'directives',
>> > '/^\\(:blocklink(end|)(?: (.*?))?:\\)/',
>> > 'FmtBlockLink');
>> >function FmtBlockLink($m) {
>> > if($m[1]) return "<:block>";
>> > return "<:block>".Keep("");
>> >}
>> >
>> > Then in a wiki page, you type:
>> >
>> > (:blocklink href="https://www.pmwiki.org; class=myclass:)
>> > ! Title
>> > Some text
>> > (:blocklinkend:)
>> >
>> >
>> > Petko
>> >
>> >
>> > On 15/10/2021 14:09, ABClf wrote:
>> > > Something I don't know how to do with pmwiki markup, if doable,
>> > > is having an html output like that :
>> > >
>> > >
>> > > Title
>> > > Some text
>> > >
>> > >
>> > > (in order to have the full block working as a link, for easy click in
>> > > bootstrap-like list, and benefit of link's style).
>> > >
>> > > In other words, have some html code embedded in and (not the
>> > > sole text link).
>> > > I believe I can not use regular [[linkadress|linktext]] markup for
>> > > doing that.
>> > >
>> > > Thank you,
>> > > Gilles.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Custom block link : short html code rather than strict text link
This is not a WikiLink markup so it doesn't convert pagenames to URLs.
In the href="..." attribute you need to use the "page URL", not the
"page name":
(:blocklink href="{=$PageUrl}" :)
Note that the current markup allows for the link href to include
JavaScript code, e.g.:
(:blocklink href="javascript:alert(document.cookie)":)
which may allow editors to insert malicious code. So if untrusted people
can edit the wiki, you shouldn't enable this markup in its current
definition.
Petko
On 16/10/2021 04:18, ABClf wrote:
Playing with last solution ; almost working for my needs, excepted the
blocklink output which gives me unexpected result :
my pagelist is on GroupA, printing out a list of blocklinks linking to
:
https://www.mysite.fr/GroupA/GroupB.Page1
where expected result is :
http://www.mysite.fr/GroupB.Page1
In my own case, I test the blocklink markup in localtemplates,
defining a new format, like that (code shortened) :
[[#listesynonyme]]
(:blocklink href={=$FullName} class="list-group-item":)
{{=$FullName}$:vedette}
(:blocklinkend:)
[[#listesynonymeend]]
then, in group Synonyme, I have a pagelist using quoted format ; which
gives me a list of blocks, linking as expected, but pointing to
https://www.mysite.fr/Synonyme/Bob.15887 where
https://www.mysite.fr/Bob.15887 is expected.
To get rid of this Group issue, one working solution is to write :
(:blocklink href="https://www.mysite.fr/Bob/{=$Name};
class="list-group-item":)
Not sure if I'm doing mistake, if the code works as expected or if it
needs to be a little improved in how to handle the Group part.
Thank you,
Gilles.
Le ven. 15 oct. 2021 à 23:45, ABClf a écrit
:
Thank you Petko for your top notch answer ;
I'm going to try the last one soon.
Gilles.
Le ven. 15 oct. 2021 à 18:13, Petko Yotov <5...@5ko.fr> a écrit :
>
> Indeed, this is not possible with core PmWiki markup.
>
> In the past, the HTML standards required links to be inline elements
> which could not contain block-level elements like paragraphs or
> headings.
>
> So in PmWiki markup, you can have 2 links, one in the heading, the other
> in the text like this:
>
> ! [[my link|Title]]
> [[my link|Some text]]
>
>
> Or you can have a specially formatted and styled link text like this:
>
> [[my link| %h5% Title %% Some text]]
>
> then you style .h5 in your pub/css/local.css, for example:
>
> .h5 {
>display: block;
>font-weight: bold;
>font-size: 105%;
> }
>
> This will work well in lists for menus and navigation. I'd go with
> this solution id I needed the feature.
>
>
> Finally, and as usual, you can define your own markup rule to do this.
> For example:
>
>Markup('blocklink', 'directives',
> '/^\\(:blocklink(end|)(?: (.*?))?:\\)/',
> 'FmtBlockLink');
>function FmtBlockLink($m) {
> if($m[1]) return "<:block>";
> return "<:block>".Keep("");
>}
>
> Then in a wiki page, you type:
>
> (:blocklink href="https://www.pmwiki.org; class=myclass:)
> ! Title
> Some text
> (:blocklinkend:)
>
>
> Petko
>
>
> On 15/10/2021 14:09, ABClf wrote:
> > Something I don't know how to do with pmwiki markup, if doable,
> > is having an html output like that :
> >
> >
> > Title
> > Some text
> >
> >
> > (in order to have the full block working as a link, for easy click in
> > bootstrap-like list, and benefit of link's style).
> >
> > In other words, have some html code embedded in and (not the
> > sole text link).
> > I believe I can not use regular [[linkadress|linktext]] markup for
> > doing that.
> >
> > Thank you,
> > Gilles.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Custom block link : short html code rather than strict text link
Indeed, this is not possible with core PmWiki markup.
In the past, the HTML standards required links to be inline elements
which could not contain block-level elements like paragraphs or
headings.
So in PmWiki markup, you can have 2 links, one in the heading, the other
in the text like this:
! [[my link|Title]]
[[my link|Some text]]
Or you can have a specially formatted and styled link text like this:
[[my link| %h5% Title %% Some text]]
then you style .h5 in your pub/css/local.css, for example:
.h5 {
display: block;
font-weight: bold;
font-size: 105%;
}
This will work well in lists for menus and navigation. I'd go with
this solution id I needed the feature.
Finally, and as usual, you can define your own markup rule to do this.
For example:
Markup('blocklink', 'directives',
'/^\\(:blocklink(end|)(?: (.*?))?:\\)/',
'FmtBlockLink');
function FmtBlockLink($m) {
if($m[1]) return "<:block>";
return "<:block>".Keep("");
}
Then in a wiki page, you type:
(:blocklink href="https://www.pmwiki.org; class=myclass:)
! Title
Some text
(:blocklinkend:)
Petko
On 15/10/2021 14:09, ABClf wrote:
Something I don't know how to do with pmwiki markup, if doable,
is having an html output like that :
Title
Some text
(in order to have the full block working as a link, for easy click in
bootstrap-like list, and benefit of link's style).
In other words, have some html code embedded in and (not the
sole text link).
I believe I can not use regular [[linkadress|linktext]] markup for
doing that.
Thank you,
Gilles.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] background image
Actually, LocalCSS is now included in PmWiki but disabled, and only
needs to be enabled.
Otherwise, you can create a file pmwiki/pub/css/MyGroup.MyPage.css and
configure the background image there:
body {
background-image: url(my_image.jpg);
}
and place my_image.jpg in the same directory pmwiki/pub/css
If you do this with LocalCSS, you probably need to write the full URL of
the picture, like url(https://yourdomain/path/to/my_image.jpg);
See https://www.w3schools.com/cssref/css3_pr_background.asp for more
background options in CSS.
Petko
On 14/10/2021 19:17, Moni Kellermann wrote:
Am 14.10.2021 um 18:40 schrieb j...@dodin.org:
Hello,
I would insert a background image in *one* page of my pmwiki.
I use pmwiki responsive default style
is there a way to do so without adding a complete recipe like
https://www.pmwiki.org/wiki/Cookbook/BackgroundImages
I do *not* want the image to be changed from the wiki itself :-)
I think that https://www.pmwiki.org/wiki/Cookbook/LocalCSS would be a
good solution but that of course is a complete cookbook recipe as well
:)
moni k.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Page with many lines goes blank
On 13/10/2021 09:43, Johan Bengtsson wrote:
On Tue, 12 Oct 2021, Petko Yotov wrote:
@ini_set('pcre.backtrack_limit', 1000); # 10 Million
This helped, it is working now! So it hits some kind of limit in PHP?
Yes. This is a PHP limit on how far to look forward, and loop back, when
searching for matches of regular expressions. PmWiki uses regular
expressions in the markup rules.
You may want to split the very long page into several pages, or the very
long markup block into separate sections/blocks for example with a
single line containing [==] every few hundred lines, or you can increase
the PHP limits.
Added to PmWiki/Troubleshooting.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Page with many lines goes blank
On 12/10/2021 16:26, Johan Bengtsson wrote:
We have a strange little problem with a large page in one of our wikis.
The page in question is 3000+ lines of code long. When adding one more
line and saving it results in a blank page. Removing the line restores
the page, it seems the wiki-code is OK, it is just some of the html
that is not being rendered.
I pasted the code into another wiki with a different skin, that worked.
It seems it is not the size of the page that is the problem but the
number of of lines.
The skin in the non-working wiki is "pmwiki-responsive".
The code for the page is simple:
(:notoc:)
! ChangeLog for SCCM Applications and Programs (CDAv2)
2021-10-08: Created Application for Dolphin EasyReader 8.0.6.302
[+ thousands of more lines like the one above]
Any clue to why this is happening?
Is this a preformatted text, it looks like there is a space before the
date?
I have tried this (same line copied up to 83000 times) and it didn't
break on my wiki. Also pmwiki-responsive skin.
I wouldn't suspect this to be related on the skin, but can you
temporarily change the skin on this page and report? Say the older
"pmwiki" skin.
A long time ago there were reports of large texts blanking a page, and
these were fixed in 2007 by adding to pmwiki.php:
@ini_set('pcre.backtrack_limit', 100); # 1 Million
There are a number of reports in the mailing list, most were fixed with
this. You can find them by searching for "backtrack_limit" here:
https://www.pmwiki.org/search-ml.php?split=v
Some of the reports mention preformatted text, others a conditional
inside the GroupHeader page, always with a long page text.
You may try increasing this to say 10 million, set in config.php:
@ini_set('pcre.backtrack_limit', 1000); # 10 Million
If this doesn't help, can you send me the page text? (Possibly in
private.)
What is your PHP version, PmWiki version, and what other recipes do you
have installed?
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.143 released
Hello. PmWiki version 2.2.143 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.143.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.143.zip svn://www.pmwiki.org/pmwiki/tags/latest This version should prevent some errors from local customization or recipes with recent PHP versions, by disabling obsolete markup rules and replacement patterns. If such markup appears on a page, it will not be processed, it will be rendered like this: ⚠️ (:my-obsolete-directive params:) and a tooltip title should have some additional information. Care should be taken if you have custom calls to the deprecated function PCCF(), and incompatible custom replacement patterns processed via PPRE() or PPRA() are silently skipped, which may not work as expected. (Previously they wouldn't work at all.) If you experience any difficulties, please do let us know and we'll try to provide a fix. The documentation was updated. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Syntax use of %style=margin-left:50px%{=$:Version}
About:
%style="margin-left:50px%
This is not a valid wikistyle, you probably need:
%margin-left=50px% text %% or
%bloc margin-left=50px%
About:
%style="margin-left:50px%"
When you use quotes (not in this invalid case, but in others), the
closing quote needs to be before the closing % for example:
%p padding="2em 5em" border="4px dotted red"% text
Indeed these are somewhat complex to set and to maintain. Myself I would
make a CSS class in pmwiki/pub/css/local.css and use the classname in
the wikistyle instead of the actual code.
For example, in local.css:
.myclassname { margin-left:50px; }
On the wiki:
%myclassname% text %% or
%p myclassname% text or
%bloc myclassname% text
Petko
On 10/09/2021 18:20, ABClf wrote:
Hello,
I'm still playing with style and css and have a question about what
looks to me like unexpected behaviour related to the use and syntax
needed for inline styling :
while formatting pagelist, writing,
%style="margin-left:50px%{=$:Version}
does clean left marging ;
whereas writing,
%style="margin-left:50px%"{=$:Version}
or
%style=margin-left:50px%{=$:Version}
does print out an unexpected " (quote sign).
To me it looks like the parsing might not be working as it should.
Am I wrong somewhere ?
Test page done here :
https://www.pmwiki.org/wiki/Test/InlineStyle
Thank you.
Gilles.
___
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] Conditional expressions
On 07/09/2021 10:58, 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? Sorry, no, I can confirm there isn't. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] ape cookbook
You can define this in CSS or with wikistyles: %embed display=inline-block% https://youtu.be/MGj5K3oQZOQ %embed display=inline-block% https://youtu.be/xCEy028-Vzo See: https://galleries.accent.bg/Cookbook/Ape-Sandbox where I also defined the dimensions, considering your 2 videos are shot vertically (portrait) rather than horizontally (landscape) which is what Ape assumes. Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 04/09/2021 10:22, j...@dodin.org wrote: I just discover the wonderfull "ape" cookbook :-) https://www.pmwiki.org/wiki/Cookbook/Ape I use it right now to embed youtube video. However, I would like to have two videos side by side, like here http://dodin.me/wiki/pmwiki.php?n=Site.Ami-Amelioration-etancheite#toc-4.5 however to achieve this I had to create a table, which is not very friendly. Why is it not possible to simply write two embed video on the same line, like I do for images? (if I do so they are printed one above the other) thanks jdd ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Embed Facebook feed
On 04/09/2021 07:24, Simon wrote: Is there, or can someone recommend, a recipe to embed a facebook feed into PmWiki? Not AFAIK. Or is this something APE can do? Sorry, Ape cannot do this -- at some point it was possible to embed a video from Facebook, not sure if it still works. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Securing Directories in PmWiki
On 01/09/2021 23:56, Curtis Stalesky wrote: I searched through the archived user questions and answers and found that to secure directories requires an htaccess file which I think is generated by an apache http server software but not sure though. A .htaccess file is not generated by the server, it is added by you (or by PmWiki). So is this the only way to secure wiki directories on a server that the PmWiki is on or does PmWiki have the capability to secure or lock down specific directories within the PmWiki directory listing/tree? The "directory listing", if you mean the server's directory listings, can be disabled again with a directive with a .htaccess file which looks like this: Options -Indexes This, however, only disables the directory listings, not the access of files to which someone has the URL. E.G. create an html/help directory that contains some files that's referenced on a wiki page and then be able to secure that directory with a PmWiki login or admin permissions? If you mean pages managed by PmWiki, like the links I posted below, then yes, PmWiki can restrict these pages or groups with a password. In PmWiki, you can protect wiki pages and wiki groups (sections of the website) from within PmWiki, or with a local configuration, see: https://www.pmwiki.org/wiki/PmWiki/Passwords https://www.pmwiki.org/wiki/PmWiki/PasswordsAdmin You usually don't need to worry about .htaccess for the page text content, unless you have an unusual installation or a server other than Apache. If you enable uploads (file attachments), by default they are not restricted to signed in users, anyone with a link may be able to download them. There is a way to restrict this by setting $EnableDirectDownload to 0 in config.php, and either locking the uploads directory with .htaccess, or moving it outside of the web-accessible document root. See: https://www.pmwiki.org/wiki/PmWiki/UploadsAdmin#direct_download https://www.pmwiki.org/wiki/Cookbook/SecureAttachments PmWiki can create .htaccess files to protect directories with sensible data (wiki.d). If your server is Apache, and you want to lock the uploads directory, you can copy the file wiki.d/.htaccess into the uploads directory. If you have some content on the server unrelated to PmWiki, e.g. some static html pages, then no, PmWiki cannot restrict the access to it. There is a way to do this with Apache configuration and a .htpasswd file. In such a case, PmWiki can be configured to also use the .htpasswd file for authenticated users. This is a more advanced/complex situation, and somewhat difficult to maintain, but see: https://www.pmwiki.org/wiki/PmWiki/AuthUser#toc-5.1 Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Markup for button ?
Recent PmWiki versions have "input button" similar to "input submit": (:input button value="Red button" id=button_id class="btn btn-red":) This is translated to however, not to and unlike it the label or value can only be plain text. If you must have a element instead, you should make a custom markup. Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 01/09/2021 18:35, ABClf wrote: I'm playing with css now and I'm just discover I don't know how to create a button in pmwiki markup ; my purpose is to be able to create something rendering in html as : Red button ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.142 released
Hello. PmWiki version 2.2.142 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.142.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.142.zip svn://www.pmwiki.org/pmwiki/tags/latest This version hides some PHP 8 notices, and adds 2 new form element attributes "accept" and "autofocus". The documentation was updated. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] resize an image during uploading and redirect after uploading
On 23/08/2021 07:32, Benjamin Grassineau wrote:
1. Do you think there is a method to automatically (on the fly) reduce
the physical size of images uploaded to pmwiki ? I did not find a
simple solution.
I wouldn't call it "simple", but the recipes AutoThumber and
ImagesAutoResizing claim to do something like this:
https://www.pmwiki.org/wiki/Cookbook/AutoThumber
https://www.pmwiki.org/wiki/Cookbook/ImagesAutoResizing
2. I don't understand how the $ UploadRedirectFunction variable works.
I would just like to redirect the user to the page after downloading
in viewer mode. Would it be possible to have just one example because
my various tests are unsuccessful ?
This is a function that will be called instead of Redirect() with the
same arguments.
Here is an example:
$UploadRedirectFunction = 'BenUploadRedirect';
function BenUploadRedirect($pagename, $url) {
global $FmtV; # see $FmtV in HandlePostUpload (upload.php)
# if not successfully uploaded, go back to upload form
# (bad file type, larger file, other error):
if($FmtV['$upresult'] != "upresult=success")
return Redirect($pagename, $url);
# here you could do something else,
# possibly downscale pic, or log, or nothing
# redirect to page, not to upload form
Redirect($pagename);
}
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PDF conversion for PmWiki
[Resending to the mailing list.] Recently I found that the in-browser "Print to PDF" feature produces PDF files of acceptable quality. You can add a markup to make a link or a button that will launch javascript:window.print(). You may also often want to improve your "@media print" CSS queries. I'm using this on a high volume wiki and it works well, in both Firefox and Chromium-based desktop browsers, i.e. virtually all internet users on desktop. I feel this will be the way to go in the future, at least for my own projects. Per your points: A. I haven't used the recipes you listed, because when I tried them several years ago they didn't support international characters/UTF-8. B. A web search for "htmldoc", the first result on the first page is the project's current website, this allowed me to update the links on the Cookbook page. C. All seemingly abandoned recipes where the license allows modification and redistribution can be adopted by a new contributor. Out of courtesy, I'd try reaching the author/maintainer first. D. PrintGroup can convert individual pages or a full wikigroup to PDF: https://www.pmwiki.org/wiki/Cookbook/PrintGroup You probably need admin access to the server to install the additional software (like for the other recipes you listed). This recipe is designed to store daily backups of the wiki content, but it may be possible to configure for on-the-fly PDF generation with an invariable $PrintGroup['datefmt'] (latest version released today, also updated for PHP8). This recipe has no listed users on the PrintGroup-Users page, but if anyone requires it, I can make it skip new PDF generation if there is already a PDF newer than the page (like for thumbnails in Mini or Thumblist). Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 22/08/2021 02:36, da...@ellendee.co.uk wrote: I have been looking at PDF conversion for the last 2 days and it seems like the recipes available are all broken. 1. GeneratePDF doesn't work on the recipe page and if you look relies on a script called htmldoc. If you follow the link it seems that the URL was taken over in 2016 by someone who will write your dissertation for you. 2. PublishPDF (includes PublishWikiTrail and ePubCreation) this was a fantastic option although the software didn't comply with the latest PHP version. I started to update the software for myself and was about halfway through when I realised that the server which does the conversion is now locked and Affinity.co.nz appears to be de-registered. 3. PmWiki2PDF I had a look at this, but the files on github haven't been updated in 8 years. It's a real shame all these seem to be no longer an option. Is anyone else tinkering with this at all? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.141 released
Hello. PmWiki version 2.2.141 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.141.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.141.zip svn://www.pmwiki.org/pmwiki/tags/latest This version adds ways to define 2 custom functions: * $MultiFactorAuthFunction to enable custom MFA/2FA with AuthUser * $PageIndexFoldFunction to define a custom function normalizing the page terms while indexing and searching (by default PmWiki converts the terms to lowercase). The documentation was updated. Thanks, Petko -- If you upgrade : https://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.140 released
Hello. PmWiki version 2.2.140 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.140.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.140.zip svn://www.pmwiki.org/pmwiki/tags/latest This version has updates for PHP 8. The API of the source code highlighting library has changed and the PmWiki loader function was adapted; if you use this feature, please upgrade Highlight.js to version 11.0.0 or newer. Note: since version 11, Highlight.js doesn't preserve HTML in the preformatted blocks and issues a console warning, so you should only use the (space)[=escaped=] or the [@escaped@] markup blocks. The documentation was updated. Thanks, Petko -- If you upgrade : https://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Passing blocks of markup to an include
We have built-in PageTextVariables, see documentation:
https://www.pmwiki.org/wiki/PmWiki/PageTextVariables
In your page:
(:include Template.MyTemplate param1="{*$:Var1}" :)
(:Var1:my markup block:)
The above will work exactly as if you wrote:
(:include Template.MyTemplate param1="my markup block" :)
Note that the include markup doesn't expect line breaks in the
parameters, so your variable you can be a line, not a multiline block.
If I need to pass a multiline block, I would try passing a page section
to be included by the included page, something like:
(:include Template.MyTemplate param1="SomePage#start#end" :)
and then Template.MyTemplate has a line like this:
(:include {$$param1}:)
And SomePage contains something like:
[[#start]]
This is line 1.
Line 2.
[[#end]]
Petko
On 21/06/2021 22:04, Charlie Hayes wrote:
I would like to pass a block of markup to an (:include :)
Something like:
(:set var1:)
my markup block
(:setend:)
(:include Template.MyTemplate param1={$var1} :)
I’ve been playing around with and reading through the documentation
and can’t figure out a built in method or a cookbook plugin.
Any ideas?
-Charlie
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Internationalizations
That works, thanks. P. On 09/06/2021 09:36, j...@dodin.org wrote: Le 09/06/2021 à 09:27, Petko Yotov a écrit : Please add a prominent note that this is, either a read only copy from 2.2.139, or a "fork" that you branched, will maintain and support independently from the official distribution. sure. Is this ok? https://github.com/jdanield/pmwiki#readme thanks jdd ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Internationalizations
On 09/06/2021 09:09, j...@dodin.org wrote: I'm working on setting a github repo for pmwiki https://github.com/jdanield/pmwiki I uploaded pmwiki-2.2.139, as indicated :-) While the GNU GPLv2 allows you to mostly freely modify and redistribute the software, please do not let anyone believe that this is the official repo for PmWiki or that development is discussed and done on that website. Please add a prominent note that this is, either a read only copy from 2.2.139, or a "fork" that you branched, will maintain and support independently from the official distribution. note: please, do not add or branch anything now to this repo, I'm only at the beginning of learning git/github and so I can't promise anything as of the quality and even survival of this repo right now :-( wanting to allow Internationalization, I also followed the page https://www.pmwiki.org/wiki/PmWiki/Installation#toc-1.5 but it seems than this pmwiki version have already the necessary code (apart the content of the local folder of course) The list of languages is a pagelist to groups named PmWikiXy or PmWikiXyZw which look like the language groups pmwiki.org. PmWiki has the necessary code, but people need to add the PmWikiXy groups and enable in config.php the language(s) they want for the wiki or for individual groups of the website. Also, we process the PmWikiXy files for download to remove page history and most metadata, so these are not the actual page files from the pmwiki.org website. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki on github
On 15/05/2021 17:16, j...@dodin.org wrote: However, I can add any application, given I can provide an url like this: http://:some.git.forge.tld:USER/REPO For code versioning, we use Apache Subversion, not git. Check if they can pull PmWiki from our subversion repository. You'll find the address at PmWiki/Subversion. I'm not fluent about github, but somehow I will have to learn :-( I found this: https://github.com/walkingice/pmwiki is this a usable pmwiki instance? is there a better one? It says on that page it is from 11 years ago. It may be usable if your PHP version is similarly old, and if you run it in read-only mode, as in, filesystem read-only. (There have been a number of vulnerabilities found and closed since then.) Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.139 released
Hello. PmWiki version 2.2.139 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.139.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.139.zip svn://www.pmwiki.org/pmwiki/tags/latest This version removes empty "title" attributes in HTML tags (links and images), fixes warnings which appear with PHP 8 and updates the documentation. Thanks, Petko -- PmWeekly Blog : http://www.pmwiki.org/News If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.php: Function get_magic_quotes_gpc() is deprecated
On 05/05/2021 06:35, T. Michael Sommers wrote: I have a brand new installation of pmwiki, from a tarball downloaded a few weeks ago. I am using php 7.4.3 on FreeBSD 11.2-RELEASE-p3. I get a warning saying, "Function get_magic_quotes_gpc() is deprecated in /home/www/data/pmwiki/pmwiki.php on line 434" I don't know how to fix this. You can upgrade your installation to a more recent PmWiki version. This has been fixed since 2019, see: https://www.pmwiki.org/pipermail/pmwiki-users/2021-May/064756.html Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.php: Array and string offset access syntax with curly braces is deprecated
Thank you for the message and the diffs but this has already been fixed
this was fixed in 2.2.119 (2019-10-03), that is 19 months ago and 19
versions released since then:
https://www.pmwiki.org/wiki/PmWiki/ChangeLog#v22119
You must have started from a fairly old version (also the line numbers
are way off, like 188 lines of code missing against the dev snapshot, so
there may be other stuff wrong or missing).
You can see which version and which date you started from by looking in
your copy of pmwiki.php, the top comment block, there is a line like:
$Id: pmwiki.php 3699 2021-02-26 19:08:16Z petko $
That is the line from version 2.2.138.
Otherwise, look in in scripts/version.php.
If you can upgrade your installation to the most recent core version, it
may save you quite some work, work which we may have already done.
Bug reports and diffs are always welcome -- when possible against the
latest version, or against the latest development snapshot.
Petko
On 05/05/2021 05:34, T. Michael Sommers wrote:
I have a brand new installation of pmwiki, from a tarball downloaded a
few weeks ago. I am using php 7.4.3 on FreeBSD 11.2-RELEASE-p3. I
get a lot of warnings saying, "Array and string offset access syntax
with curly braces is deprecated" for pmwiki.php.
This is a diff that fixes them:
--- snip ---
--- pmwiki.php.orig 2021-05-04 23:00:53.048909000 -0400
+++ pmwiki.php 2021-05-04 23:25:24.454431000 -0400
@@ -703,7 +703,7 @@
array('.*', '.', '[', ']', '^', '-', '!'),
$pat);
$excl = array(); $incl = array();
foreach(preg_split('/,+\s?/', $pat, -1, PREG_SPLIT_NO_EMPTY) as $p)
{
-if ($p{0} == '-' || $p{0} == '!') $excl[] = '^'.substr($p, 1).'$';
+if ($p[0] == '-' || $p[0] == '!') $excl[] = '^'.substr($p, 1).'$';
else $incl[] = "^$p$";
}
return array(implode('|', $incl), implode('|', $excl));
@@ -733,7 +733,7 @@
foreach((array)$pat as $p) {
if (count($pagelist) < 1) break;
if (!$p) continue;
-switch ($p{0}) {
+switch ($p[0]) {
case '/':
$pagelist = preg_grep($p, $pagelist);
break;
@@ -1009,7 +1009,7 @@
foreach($a as $k=>$v) {
if (!isset($XL[$lang][$k])) {
if (preg_match('/^e_(rows|cols)$/', $k)) $v = intval($v);
- elseif (preg_match('/^ak_/', $k)) $v = $v{0};
+ elseif (preg_match('/^ak_/', $k)) $v = $v[0];
$XL[$lang][$k]=$v;
}
}
@@ -1151,7 +1151,7 @@
$x = "version=$Version ordered=1 urlencoded=1\n";
$s = true && fputs($fp, $x); $sz = strlen($x);
foreach($page as $k=>$v)
-if ($k > '' && $k{0} != '=') {
+if ($k > '' && $k[0] != '=') {
$x = str_replace($r0, $r1, "$k=$v") . "\n";
$s = $s && fputs($fp, $x); $sz += strlen($x);
}
@@ -1192,7 +1192,7 @@
$dirslash = substr_count($dir, '/') + 1;
$o = array();
while ( ($pagefile = readdir($dfp)) !== false) {
-if ($pagefile{0} == '.') continue;
+if ($pagefile[0] == '.') continue;
if ($dirslash < $maxslash && is_dir("$dir/$pagefile"))
{ array_push($dirlist,"$dir/$pagefile"); continue; }
if ($dirslash == $maxslash) $o[] = $this->PFD($pagefile);
@@ -1441,7 +1441,7 @@
## The caller is responsible for calling Qualify() as needed.
function RetrieveAuthSection($pagename, $pagesection, $list=NULL,
$auth='read') {
global $RASPageName, $PCache;
- if ($pagesection{0} != '#')
+ if ($pagesection[0] != '#')
$list = array(MakePageName($pagename, $pagesection));
else if (is_null($list)) $list = array($pagename);
foreach((array)$list as $t) {
@@ -1465,7 +1465,7 @@
while (count($args['#'])>0) {
$k = array_shift($args['#']); $v = array_shift($args['#']);
if ($k=='') {
- if ($v{0} != '#') {
+ if ($v[0] != '#') {
if (isset($itext)) continue;
$iname = MakePageName($pagename, $v);
if (!$args['self'] && $iname == $pagename) continue;
@@ -1478,7 +1478,7 @@
if (preg_match('/^(?:line|para)s?$/', $k)) {
preg_match('/^(\\d*)(\\.\\.(\\d*))?$/', $v, $match);
@list($x, $a, $dots, $b) = $match;
- $upat = ($k{0} == 'p') ? ".*?(\n\\s*\n|$)" : "[^\n]*(?:\n|$)";
+ $upat = ($k[0] == 'p') ? ".*?(\n\\s*\n|$)" : "[^\n]*(?:\n|$)";
if (!$dots) { $b=$a; $a=0; }
if ($a>0) $a--;
$itext=preg_replace("/^(($upat){0,$b}).*$/s",'$1',$itext,1);
@@ -1640,7 +1640,7 @@
$suffix = $txt[1];
$txt = $txt[0];
}
- if (!$fmt && $path{0} == '#') {
+ if (!$fmt && $path[0] == '#') {
$path = preg_replace("/[^-.:\\w]/", '', $path);
if (trim($txt) == '+') $txt = PageVar($pagename, '$Title') .
@$suffix;
if ($alt) $alt = " title='$alt'";
@@ -1785,7 +1785,7 @@
foreach($markrules as $p=>$r) {
list($r, $id) = (array)$r;
$MarkupToHTML['markupid'] = $id;
- if ($p{0} == '/') {
+ if ($p[0] == '/') {
if (is_callable($r)) $x = preg_replace_callback($p,$r,$x);
Re: [pmwiki-users] Have pagelist condition : if result not null, then print pagelist
Pagelist usually shows nothing if there are no pages in the list.
Unless you have a (:template none:) section -- it only appears when
there are no pages.
If you want to show something, like a heading, before the first result
(when there is a first result), then use (:template first:). That
section can be there in addition to (:template first {=$Group}:)
I suspect I don't understand what is the exact problem, if so, please
elaborate.
Petko
On 13/04/2021 05:21, ABClf wrote:
I don't know if it's possible to have a pagelist condition like : if
$MatchCount < 1 ;
in my case, I would like a pagelist to be printed only when there is
some positive result found.
If request gives nothing, then print nothing.
Specifically, I use pagelist like this to collect linked citations :
(:pagelist group=Citation link=Bob.{*$Name} list=all fmt=#citation2:)
and I would like to have result printed out only when results are
found.
Is that doable ?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] link in brackets
When markup rules are ambiguous, you can use the "null-space" [==] as a separator: [[==][[link|text]] page 3] Or, you can escape the first bracket which is not part of the markup rule: [=[=][[link|text]] page 3] In a similar fashion, mixed/glued markup for bold, italics, small and large where the markup engine may not guess which apostrophe relates to which markup, you may separate them with the null-space to become unambiguous. See a few examples, not fixed: https://www.pmwiki.org/wiki/Test/BasicEditing Petko On 13/04/2021 13:28, walter keller wrote: I wanted to bracket a link by writing [[[link|text]] page 3] and hoping to get [text page 3] it didn't work, because it was interpreted as an invalid link "[link". ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Include GroupFooter from another page
GroupHeader and GroupFooter are always related to the currently browsed
page.
If your GroupFooter shows PageTextVariables from the pages, then indeed
{*$:Variable} refers to the currently browsed page, not to the included
page. In fact, GroupFooter is just another included page at the bottom
of the current page, from the current group, it is never considered part
of the included pages.
Depending on the complexity of your GroupFooter, you may be able to
achieve what you want by manually including the GroupFooter with a
"basepage=" argument, possibly twice:
Something like:
(:include Page1:)
(:include GroupFooter basepage=Page1:)
(:include Page2:)
(:include GroupFooter basepage=Page2:)
If it is a different group, use Group.Page1 and Group.GroupFooter.
Optionally:
(:nogroupfooter:)
Petko
On 09/04/2021 17:07, da...@ellendee.co.uk wrote:
I am attempting to include 2 pages into a third page. Each of the
original
pages display using data in the page and template from the GroupFooter.
The part of the page which displays using the GroupFooter does not
display
when included. Is there any way around this? I suppose this mis
attempting
to use 2 levels of include?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Problem with conditional markup equal ?
On 30/03/2021 13:32, Petko Yotov wrote: Can you demonstrate this on a subpage of You don't need to demo this -- I've replied and forgot to delete this line. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Problem with conditional markup equal ?
Can you demonstrate this on a subpage of www.pmwiki.org/wiki/Test/Test ?
Petko
On 30/03/2021 12:47, Benjamin Grassineau wrote:
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 !
Here you have a typo " ] ":
"{Utilisateurs.{(substr '{*$Name}' 13)}$:ptv} ] "
You probably mean:
"{Utilisateurs.{(substr '{*$Name}' 13)}$:ptv}"
This will not fix it though.
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 !
It comes from the order of processing of the markup rules.
Your markup, without the typo, is:
(:if equal "{(substr '{*$Name}' 4 9)}" "{Utilisateurs.{(substr
'{*$Name}' 13)}$:ptv}":)
PmWiki first finds and processes "{*$Name}" -- page variables and page
text variables. "{*$Name}" is "InitGYheJLMrKtest". At that point, your
markup becomes:
(:if equal "{(substr 'InitGYheJLMrKtest' 4 9)}" "{Utilisateurs.{(substr
'InitGYheJLMrKtest' 13)}$:ptv}":)
It then processes {(substr ...)} and other markup expressions, so your
text becomes:
(:if equal "GYheJLMrK" "{Utilisateurs.test$:ptv}":)
At that point, that conditional is false, the 2 compared strings are not
the same. It needs to do one additional round of processing, which it
does not now, but at a later point, after the conditional has been
evaluated (to false).
So at this point you would need to immediately reevaluate the output of
the markup expression as another pagevariable and pagetextvariable. This
is not standard -- can be done but I am not sure of the consequences --
but if you must have it, here it is:
In config.php:
Markup('{(', '>{$var}',
'/\\{(\\(\\w+\\b.*?\\))\\}/',
"MyMarkupMarkupExpression");
function MyMarkupMarkupExpression($m) {
extract($GLOBALS["MarkupToHTML"]); # get $pagename
return PRR(MarkupExpression($pagename, $m[1]));
}
This redefines the core MarkupExpressions rule to call your own
"MyMarkupMarkupExpression" function which then wraps the call in PRR()
"PmWiki redo rules". So the result of the markup expression will have
all previous markup rules re-applied from the start, including replacing
the $:ptv with its value.
As I said, I'm unsure of the implications -- this may break something
that works now. Or it might work.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki mirrors
Yes, it is possible, I use this on a number of websites -- either a home
server like your case, or a "backup snapshot" of a website from the
previous night.
To do it, you can have in config.php a conditional based on the server
name or the server address.
It will help if you have the same server software (e.g. Apache) and PHP
version on both installations, or have slightly newer versions at home.
You don't need to use relative links, you need to define different
values to the $EnableReadOnly, $ScriptUrl, $FarmPubDirUrl, $PubDirUrl,
and $UploadUrlFmt variables.
if($_SERVER['SERVER_ADDR'] == '127.0.0.1') { # home server
# or possibly $_SERVER['SERVER_NAME'] == "localhost"
$ScriptUrl = "http://127.0.0.1/~user/www/pmwiki.php;;
$FarmPubDirUrl = $PubDirUrl = "http://127.0.0.1/~user/www/pub;;
$UploadUrlFmt = "http://127.0.0.1/~user/www/uploads;;
# this is to remind me I am on the home server
$HTMLStylesFmt['Local'] = '#wikitext {background-color: #ffe
!important;}';
$WikiTitle = 'Local wiki';
}
else { # online server
$EnableReadOnly = 1;
$ScriptUrl = "https://www.your-website.org/wiki/;;
$FarmPubDirUrl = $PubDirUrl =
""https://www.your-website.org/wiki/pub;;
$UploadUrlFmt = ""https://www.your-website.org/wiki/uploads;;
$WikiTitle = 'Online wiki';
}
I believe there are some aggressive caching recipes that you may have to
disable, or to skip the *,cache files from the home server when you
rsync.
The next step may be to have a static export and rsync that to the
online server (although, no search, authentication, PmWiki conditionals,
{(ftime)} markup expressions or other interactive server-side features).
Static export is not an easy task though.
Petko
On 29/03/2021 10:46, j...@dodin.org wrote:
I would like to have a pmwiki mirror at home, where I have a local
server.
May main site is on a shared server and is sometime very difficult to
use due to excessive load on this server and I want to make the
editing on my own network and rsync the result to the online shared
server.
my own local server may also be unavailable in case of power failure
(not that rare nowadays here).
But for this to works, I have to use relative links all over the wiki
pages as of course the domain name of the two servers will not be the
same. for example in local/config.php
is this possible without breaking pmwiki?
is it possible to make the online pmwiki read only for the web server
(of course not for rsync :-)?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki bug with text variable
Thanks -- fixed. It actually does what it is supposed to do -- if there are more than one PageTextVariables in the page of the same name and the same type, the later one wins. There was a one Summary: variable near the top, and a second (:Summary::) in the page text. The latter took precedence and had to be broken to [@(:Summary@][@:sss:)@] Petko On 26/03/2021 12:58, Johan Bengtsson wrote: https://www.pmwiki.org/wiki/PmWiki/DocumentationIndex the text after "Page Lists" is "s". It seems it is getting the value from the wrong place! ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki and php 7.4 (WikiSh, Peter Bowers)
It looks like the errors come from a Cookbook recipe, WikiSh. Try to reach the author/maintainer Peter Bowers and see if he can update his recipe for recent PHP versions. If he cannot, and if nobody can take over the maintenance, you should evaluate if you actually use and need this recipe. WikiSh is one of the most complex and powerful PmWiki modules and since it is not something I've ever used or reviewed, myself I will not volunteer to support it. If you disable this recipe and still have errors, please see the page Troubleshooting on how to detect where they come from: https://www.pmwiki.org/wiki/PmWiki/Troubleshooting Petko On 09/03/2021 22:57, john.wob...@gmail.com wrote: I have upgraded my site as thus: “This site is running pmwiki-2.2.138 (VersionNum=2002138).” I am trying to upgrade from php 7.1.33 to php 7.4 but I am getting errors Some Examples: Warning: Use of undefined constant toolbox - assumed 'toolbox' (this will throw an Error in a future version of PHP) in \cookbook\toolbox.php on line 68 Warning: Use of undefined constant WikiSh - assumed 'WikiSh' (this will throw an Error in a future version of PHP) in cookbook\WikiSh.php on line 41 \pmwiki.php on line 502 Warning: Cannot modify header information - headers already sent by (output started at C:\wa\cookbook\WikiSh.php:42) wiki\pmwiki.php on line 1397 Can anyone help ? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] totalcouter not working
I thought this recipe was abandoned by the maintainer a long time ago.
I now see a regular PmWiki user Said Achmiz has released the latest
version of this recipe. If he is not on the mailing list, I suggest you
contact him directly -- his email is on his profile page.
Petko
On 27/02/2021 19:15, j...@dodin.org wrote:
Hello,
I have totalcounter on my pmwiki and it don't works, the total count
is not displayed.
For discussion purpose, I wrote my sandbox with sone variables
(below). The page is
http://www.dodin.org/wiki/pmwiki.php?n=Main.WikiSandbox
The two first lines don't display numbers, the others do. I have
access to php setup throught cpanel but I'm lost in the number of
variables :-(
my totalcounter setup is rather default
any clue? (analyse don't show any problem, all green)
thanks
jdd
.
total {$TotalCount}
page {$PageCount}
{$TotalCounterVersion} displays the current version
{$TotalCounterVersion} displays the current version
{$TotalCounterMaxItems} displays the maximum count of items displayed
for each chart
{$PageCountToday} displays the count of pages visited today
...
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.137 released
This is a quick update to 2.2.137 to fix a bug with entities encoded twice in the quoted attributes. https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.137.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.137.zip svn://www.pmwiki.org/pmwiki/tags/latest Only pmwiki.php changed since 2.2.136. Thanks, Petko On 26/02/2021 15:10, Petko Yotov wrote: Hello. PmWiki version 2.2.136 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.136.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.136.zip svn://www.pmwiki.org/pmwiki/tags/latest This version fixes a XSS vulnerability for WikiStyles reported today by Igor Sak-Sakovskiy. The fix adds a second argument $keep to the core function PQA($attr, $keep=true) which by default escapes HTML special characters and places the values in Keep() containers. If you have custom functions that call PQA() and expect the previous behavior, set the second argument to false. If you have any questions or difficulties, please let us know. Thanks, Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.136 released
Hello. PmWiki version 2.2.136 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.136.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.136.zip svn://www.pmwiki.org/pmwiki/tags/latest This version fixes a XSS vulnerability for WikiStyles reported today by Igor Sak-Sakovskiy. The fix adds a second argument $keep to the core function PQA($attr, $keep=true) which by default escapes HTML special characters and places the values in Keep() containers. If you have custom functions that call PQA() and expect the previous behavior, set the second argument to false. If you have any questions or difficulties, please let us know. Thanks, Petko -- If you upgrade : https://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.135 released
Hello. PmWiki version 2.2.135 was published today, and is available at: https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.135.tgz https://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.135.zip svn://www.pmwiki.org/pmwiki/tags/latest This version fixes a number of PHP8 compatibility issues. This is a work in progress, if you uncover others, please report them at: https://www.pmwiki.org/wiki/PITS/01461 A work is underway to implement session tokens to prevent CSRF vulnerabilities -- suggested by Dominique Faure. I wanted to rework these functions but the PHP8 compatibilities are more urgent so at the moment the PmToken functions are transparent/non-functional. A defunct syndicated blocklist was disabled, a minor code refractoring was done for PmTOC to better support manual edit section links, and the documentation was updated. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Page In Page?
On 24/01/2021 13:25, Michael Elliott wrote: I love PMWiki and am a routine donor. Glad to learn that -- I'm sure Pm is grateful. If I have a page that has a lot of content where I want to keep it all on the same page. Is there a way I can have a page-in-a-page so as the content to maintain is more concise and easy to edit? In this way I'd only have to edit a "section" of the said page instead of a HUGE single text. There are at least 2 ways to do it. To have separate pages included in the current page you can use: (:include OtherPage:) See https://www.pmwiki.org/wiki/PmWiki/IncludeOtherPages To automate it, I suggest looking up pagelists, especially the "trail" option. This way you create a bulleted list of links to the subpages, and a pagelist that includes them in the correct order. Another way is to install the recipe SectionEdit: https://www.pmwiki.org/wiki/Cookbook/SectionEdit This way all your text can be in one page, and you open for editing individual sections separated by !!Headings. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Issues with Custom Fonts, Font Awesome, HTML
It may be possible. Instead of: $HTMLHeaderFmt['fontawesome'] = 'href="$FarmPubDirUrl/fontawesome/css/all.min.css" />'; Try with this: $HTMLHeaderFmt['fontawesome'] = 'https://kit.fontawesome.com/7ef8040ce0.js"</a>; crossorigin="anonymous">'; Let me know if it works and I'll update the Cookbook page. Petko On 19/01/2021 14:01, Jamie Ward wrote: Do you think it might be possible to make it pull from my Kit instead? Not all the icons I want exist in the Free version, but it seems like if you link to your online kit, you can make your own icons and put them in there. The kit code is https://kit.fontawesome.com/7ef8040ce0.js"</a>; crossorigin="anonymous"> I tried putting the URL into the code you gave on the Cookbook but that didn’t work. If this is too much trouble no need to respond as I can manage without them. But if you can answer it easily, I’d be grateful. Thanks, Jamie On 18 Jan 2021, at 10:01, Petko Yotov <5...@5ko.fr> wrote: 1. Installing custom fonts correctly and available cross-browser is sometimes tricky. Don't let it discourage you. 2. You should avoid enabling HTML, the feature you need can be done without it. 3. The recipe Cookbook:FontAwesome was indeed old and without a maintainer. I am now taking over the maintenance and I rewrote the installation instructions and most of the page. The font is now enabled on that page and can be tested. 4. That page contains instructions for the actual and current FontAwesome release, which has all needed files, styles, fonts, and settings for different browsers. If you are trying to use a font different from "FontAwesome Free", installing it will likely be different -- if you need assistance, please provide more information. Petko On 16/01/2021 23:16, Jamie Ward wrote: I’d like to be able to display symbols (PS4 or Xbox controller buttons) within my Wiki pages. On web pages, I use a custom font and font-face script. I could find no documentation at all about custom fonts, so looked for some workarounds. The first thing I could was using Font Awesome within PMWiki - which would satisfy (https://www.pmwiki.org/wiki/Cookbook/FontAwesome) However I followed the very simple instructions carefully, and it did not work, after several hours testing I gave up. The issue there was if you take the code it wants to use to implement, , then PMWiki just shows the code. I tried surrounding it like so (div: :)(:divend) - still didn’t work. Neither did (html: Then I tried to use both EnableHTML, and ConvertHTML to make PMWiki read that code These threw up config errors, and although people had published later code for different versions of PHP, none of those worked. And they all seemed to be from 2008-2014. Is all of this functionality deprecated and no longer supported? Or am I being really dense? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Issues with Custom Fonts, Font Awesome, HTML
1. Installing custom fonts correctly and available cross-browser is sometimes tricky. Don't let it discourage you. 2. You should avoid enabling HTML, the feature you need can be done without it. 3. The recipe Cookbook:FontAwesome was indeed old and without a maintainer. I am now taking over the maintenance and I rewrote the installation instructions and most of the page. The font is now enabled on that page and can be tested. 4. That page contains instructions for the actual and current FontAwesome release, which has all needed files, styles, fonts, and settings for different browsers. If you are trying to use a font different from "FontAwesome Free", installing it will likely be different -- if you need assistance, please provide more information. Petko On 16/01/2021 23:16, Jamie Ward wrote: I’d like to be able to display symbols (PS4 or Xbox controller buttons) within my Wiki pages. On web pages, I use a custom font and font-face script. I could find no documentation at all about custom fonts, so looked for some workarounds. The first thing I could was using Font Awesome within PMWiki - which would satisfy (https://www.pmwiki.org/wiki/Cookbook/FontAwesome) However I followed the very simple instructions carefully, and it did not work, after several hours testing I gave up. The issue there was if you take the code it wants to use to implement, , then PMWiki just shows the code. I tried surrounding it like so (div: :)(:divend) - still didn’t work. Neither did (html: Then I tried to use both EnableHTML, and ConvertHTML to make PMWiki read that code These threw up config errors, and although people had published later code for different versions of PHP, none of those worked. And they all seemed to be from 2008-2014. Is all of this functionality deprecated and no longer supported? Or am I being really dense? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bug? Filename case for Attach:
On 03/01/2021 00:28, Robert Riebisch wrote: This is not a bug but a documented feature. Okay. Where can I read about it? See $MakeUploadNamePatterns. may arise if you migrate your files from one hosting provider to another -- links may fail to resolve on the new location. Then I would probably run some sed or awk script against to PmWiki pages. ;-) Agreed, if you don't require support, you can change to an unsupported set of renaming rules. ;-) I suspect you and I can do this -- and have done this. But most people who install PmWiki cannot -- they neither use or know how to use UNIX-type operating systems and `rename` (the Larry Wall version), nor their hosting plan has SSH access. And if their local file system is case-insensitive, they cannot even rename the files manually. The decision made by Pm a long time ago was a pragmatic one, and at the time appeared suitable for the majority of the wiki administrators. I believe it still is, even more so today. BTW I have been burned by a case-insensitive file system on clients' websites, and in one case with thousands of uploaded files -- and since then I force the renaming of the whole filenames to ascii-lowercase-without-spaces, not only the extension part. (This also tends to work better with recipes from the Uploads category in the cookbook.) Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bug? Filename case for Attach:
This is not a bug but a documented feature. Some file systems are case insensitive, some are case sensitive, so FILE.ZIP and FILE.zip may be the same file or different files. A problem may arise if you migrate your files from one hosting provider to another -- links may fail to resolve on the new location. PmWiki will always rename the extension to lowercase. It will also strip some unsupported characters, both from an Attach: link and when you upload the file via the ?action=upload form. One workaround is to type the Attach link and/or use the upload form instead of FTP. I agree that if you have many files to upload, especially some that come from digital cameras or from DOS 8.3 filesystems the file extensions are uppercase and it may be annoying. In that case you can probably install DDMU from the cookbook and drop many files on the page -- they will be renamed automatically: https://www.pmwiki.org/wiki/Cookbook/DragDropMultiUpload Petko On 02/01/2021 22:49, Robert Riebisch wrote: Today I uploaded some files to my newest PmWiki installation via FTP. But if I write on my page: Attach:FILENAME.ZIP then PmWiki doesn't find the file and shows a ^ after the filename. When I hover above the upload link, I see "FILENAME.zip" at the end of the URL. If I now change the filename via FTP to FILENAME.zip, then PmWiki finds the attachment. I consider this a bug or bad behavior. :-/ ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Keyboard keys representation
A search for "kbd" in the wiki revealed that Cookbook:MarkupExtensions
has a markup:
https://www.pmwiki.org/wiki/Cookbook/MarkupExtensions
It uses '@Key@'.
Petko
On 02/01/2021 14:56, Petko Yotov wrote:
On 02/01/2021 13:03, Robert Riebisch wrote:
What's the preferred PmWiki way to make keyboard keys stand out from
the
rest of the text?
I had a quick look at the Cookbook group, but didn't find any
promising.
Currently I just (ab)use italic markup.
My preferred way is to use a wikistyle -- a concept and a wiki markup
already familiar to the users, and supported in the core.
Add this to pub/css/local.css (adapted from the Wikipedia page you
linked):
.key, kbd {
border: 1px solid #aaa;
border-radius: 0.2em;
box-shadow: 0.1em 0.1em 0.2em rgba(0,0,0,0.1);
background-color: #f9f9f9;
background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee);
color: #000;
padding: 0.1em 0.3em;
font-family: monospace;
font-size: 0.85em;
white-space: nowrap;
}
Then in a wiki page, use %key%C%% like this:
Type %key%Ctrl%%+%key%C%% to cancel.
Alternatively, if you must have semantic HTML, you can define a
wiki markup. Something like {@Key@}, for example:
Markup('kbd', 'inline', '/\\{@(.*?)@\\}/', '$1');
Petko
Examples from other Wiki engines:
1) MediaWiki: https://en.wikipedia.org/wiki/Control_key
2) DokuWiki: https://www.dokuwiki.org/plugin:keyboard
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Markup proposal for non-breaking hyphen and non-breaking space
On 02/01/2021 13:57, Robert Riebisch wrote:
I'd like to see \- (non-breaking hyphen) and \_ (non-breaking space)
used, because spreading your pages with lots of "" or ""
makes a page's source harder to read.
Or are there already other ways I didn't find?
Looks good.
Petko
I now added this to my local/config.php:
Markup('\-', 'inline', '/\\\-/', '');
Markup('\_', 'inline', '/\\\_/', '');
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Keyboard keys representation
On 02/01/2021 13:03, Robert Riebisch wrote:
What's the preferred PmWiki way to make keyboard keys stand out from
the
rest of the text?
I had a quick look at the Cookbook group, but didn't find any
promising.
Currently I just (ab)use italic markup.
My preferred way is to use a wikistyle -- a concept and a wiki markup
already familiar to the users, and supported in the core.
Add this to pub/css/local.css (adapted from the Wikipedia page you
linked):
.key, kbd {
border: 1px solid #aaa;
border-radius: 0.2em;
box-shadow: 0.1em 0.1em 0.2em rgba(0,0,0,0.1);
background-color: #f9f9f9;
background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee);
color: #000;
padding: 0.1em 0.3em;
font-family: monospace;
font-size: 0.85em;
white-space: nowrap;
}
Then in a wiki page, use %key%C%% like this:
Type %key%Ctrl%%+%key%C%% to cancel.
Alternatively, if you must have semantic HTML, you can define a
wiki markup. Something like {@Key@}, for example:
Markup('kbd', 'inline', '/\\{@(.*?)@\\}/', '$1');
Petko
Examples from other Wiki engines:
1) MediaWiki: https://en.wikipedia.org/wiki/Control_key
2) DokuWiki: https://www.dokuwiki.org/plugin:keyboard
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] $PagePathFmt sometimes not working for me
On 31/12/2020 22:44, Robert Riebisch wrote:
$DefaultGroup = 'Wiki';
$DefaultName = 'Start';
$PagePathFmt = array('{$Group}.$1','$1.{$DefaultName}');
...
Input: https://www.domain.tld/Foo
Output: The page "Foo" doesn't exist. (Create Foo.Foo).
Result: Wrong. I would expect: The page "Start" doesn't exist. (Create
Foo.Start).
This happens on the last line of ResolvePageName() which is such an
important function, with too many things and recipes depending on it,
that I am unwilling to change it if it doesn't work as you would expect
in your highly specific case (custom $DefaultName, custom $PagePathFmt,
missing group homepage).
As usual with PmWiki, you can fix that specific case in config.php:
if(preg_match("/^$GroupPattern$/", $pagename)) {
$pagename = MakePageName("$DefaultGroup.$DefaultName",
"$pagename.$DefaultName");
}
This should be placed after you configure $GroupPattern, $DefaultGroup
and $DefaultName, and after you include scripts/xlpage-utf-8.php where
$GroupPattern is redefined.
Is the behavior related to my .htaccess file
No, it would do the same if you browsed to pmwiki.php?n=Foo
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Show and Hide Sidebar Items to AuthUser Group
On 30/12/2020 19:00, Jamie Ward wrote: Very new to all of this. So I want to build my Wiki, and keep all the help and Basics stuff in the sidebar such as Initial Setup Tasks. But I don’t want my contributing authors to see any of that. I just want them to see the pages that they are working on. Is there a way to hide sidebar sections from user types? So only @admin could see the PMWiki and pmwiki.org sections. @authors could see the sections we are working on, say Chapter 1, Chapter 2, and the subsections. You can use a conditional in the SideBar, something like this (indented for clarity): (:if auth admin:) This is shown to the wiki administrator, as defined in $DefaultPasswords['admin']. See documentation at PmWiki/PasswordsAdmin. (:ifend:) (:if auth edit SiteAdmin.SiteAdmin:) Same as above, only the administrator can read or edit the SiteAdmin group. (:ifend:) (:if auth edit Chapters.Chapter1:) This section is shown to people who can edit [[Chapters.Chapter1]]. You can configure it to people in the @authors group, see PmWiki/Passwords and PmWiki/AuthUser. (:ifend:) Then you place the links to publicly accessible pages outside of the conditionals. See PmWiki/ConditionalMarkup. And non-logged-in users would only see pages that are designated complete. So I guess there would be an @public user group or something and as pages were completed, we’d grant access to them. Or, you can go without a @public user group -- if you can, simply allow reading to anyone without complicating the set. Its not high-security so I don’t think we need to prevent people from accessing pages via direct link. Just to only show in the sidebar, the things I want the groups to see I assume when a page is "complete" and ready to go public, someone will edit the sidebar and remove the link from the conditional section and place it outside of the conditional section. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users-fr] page text variable
Alors celui-ci serait plus simple avec une règle de conversion (Markup)
qui intercepterait la variable spécifique et réécrirait le texte désiré
à sa place.
Markup('ReelMaterialite', '<{$var}',
'/\\{(\\S*)\\$:ReelMaterialite\\}/', 'ReelMaterialite');
function ReelMaterialite($m) {
# nom des variables, dans le bon ordre
$ptv = explode(" ", "Matiere Presentation Valeur Repartition
Utilisation Materialite");
$out = "|| ";
$pn = $m[1];
foreach($ptv as $v) {
$out .= " {" . $pn. "\$:" . $v . "} ||";
}
return $out;
}
La fonction trouve {Groupe.Nom$:ReelMaterialite} et construit le texte
"|| {Groupe.Nom$:Matiere} || {Groupe.Nom$:Presentation} ||
{Groupe.Nom$:Valeur} || {Groupe.Nom$:Repartition} ||
{Groupe.Nom$:Utilisation} || {Groupe.Nom$:Materialite} ||"
qui est ensuite traité/transformé par PmWiki normalement.
Avec ça, la variable (:ReelMaterialite:...:) définie dans une page
serait ignorée.
Je ne suis pas certain que ça marcherait dans une "PageList template"
avec le raccourci {=$:ReelMaterialite} -- sinon on peut utiliser
{{=$FullName}$:ReelMaterialite} à sa place.
Petko
On 14/12/2020 10:36, Pierre-Marie Carette wrote:
Grand merci !
Le 14 déc. 2020 à 10:06, Petko Yotov <5...@5ko.fr> a écrit :
$DefaultUnsetPageTextVars['VarC'] = "{\$:VarA}\n{\$:VarB} »;
ça me crevait les yeux !
Mais
Et malheureusement seulement pour la page en cours, c'est à dire
{AutrePage$:VarC} ne marchera pas.
Le problème :
Dans chaque page je crée les variables modifiables
(:Matiere: Matière :)
(:Presentation: Présentation :)
(:Valeur: Valeur:)
(:Repartition: Répartition:)
(:Utilisation: Utilisation:)
Je peux partout y faire mention par {Groupe.Nom$:Matiere}...
Je construit dans chaque page la variable-synthèse
(:ReelMaterialite: || {$:Matiere} || {$:Presentation} || {$:Valeur}
|| {$:Repartition} || {$:Utilisation} || {$:Materialite} ||:)
Je peux partout y faire mention par {Groupe.Nom$:ReelMaterialite}
Cela m’oblige à répéter cette définition dans chaque page (et
j’ai 27 définition de variables-synthése)
Problème : répétition= lourdeur=illisibilité
But de. la question : Mettre la définition de ReelMaterialité dans
config
Ca ressemble à la deuxième proposition
utiliser la fonction PageTextVar($pagename, 'VarA') dans une
fonction $PostConfig ou après l'inclusion de pgcust.php.
J’en étais là (PageTextVariables) mais ça dépasse mes
compétences !
Merci
Pierre-Marie CARETTE (FidelioEspoir)
___
pmwiki-users-fr mailing list
pmwiki-users-fr@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users-fr
Re: [pmwiki-users-fr] page text variable
On 13/12/2020 19:57, Pierre-Marie Carette wrote:
Chaque page a deux variables
VarA:valeura
VarB:valeurb
Comment créer dans config.php une variable VarC concaténant VarA et
VarB ? tel que
{$:VarC} donnera
"valeura
valeurb »
C'est pour utiliser {$:VarC} dans la page, ou pour utiliser la valeur
dans config.php?
Le premier cas est facile, pour PmWiki 2.2.122 ou ultérieur, on peut
ajouter dans config.php:
$DefaultUnsetPageTextVars['VarC'] = "{\$:VarA}\n{\$:VarB}";
C'est documenté en anglais ici:
https://www.pmwiki.org/wiki/PmWiki/PageTextVariables#default
Ceci marchera quand il n'y a pas de "VarC:" définie dans la page. Et
malheureusement seulement pour la page en cours, c'est à dire
{AutrePage$:VarC} ne marchera pas.
Le second, pour utiliser la valeur dans du code PHP, c'est plus
compliqué. Je conseille d'étudier la section "Order of the commands in
config.php":
https://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-order
...et utiliser la fonction PageTextVar($pagename, 'VarA') dans une
fonction $PostConfig ou après l'inclusion de pgcust.php.
Petko
___
pmwiki-users-fr mailing list
pmwiki-users-fr@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users-fr
[pmwiki-users] PmWiki 2.2.134 released
Hello. PmWiki version 2.2.134 was published today, and is available at: http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.134.tgz http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.134.zip svn://www.pmwiki.org/pmwiki/tags/latest This is a documentation update version. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New recipe: ExternalLinksFavicons
On 29/11/2020 05:33, Simon wrote: Is it a replacement or update of https://www.pmwiki.org/wiki/Cookbook/LinkIcons ? Neither -- it does something different, as explained in the Cookbook page. Since LinkIcons uses a custom classname for external links, if you want to use both recipes you need a specific configuration of ExternalLinksFavicons, now documented in the page. Petko > This recipe places the favicons of external websites before their links. > >https://www.pmwiki.org/wiki/Cookbook/ExternalLinksFavicons ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] New recipe: ExternalLinksFavicons
This recipe places the favicons of external websites before their links. https://www.pmwiki.org/wiki/Cookbook/ExternalLinksFavicons Enjoy! Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PMwiki, counting page hits and flow off the login pages
On 26/11/2020 17:32, Foster Schucker wrote:
First On my left margin I have
* [[Main/HomePage]]
* [[Main/WikiSandbox]]
* (:if authid:) User: [[Main.{$AuthId} | {$AuthId}]] (:else:)
[[Site.AuthUser | Please login]] (:ifend:)
%sidehead% [[PmWiki/PmWiki]]
This shows either the link to Site.Authuser so the user can log in, or
their user name as a link to their personal home page.
After they do the authentication is there a way to send them off the
Site.Authuser page to some place else? The page they were on before
they did the Auth would be best but Main.{AuthId} or Main.HomePage
would also work. I'm kind of following along in scripts/authuser,
but not seeing how I can get it to return to do a redirect.
Yes, you can link to [[Main.HomePage?action=login]] however maybe you
don't need to -- a login form will appear when the user tries to access
a restricted area or action.
BTW by default the wikigroup for user profiles is "Profiles", not
"Main". This group is linked when a user signs with 3 or 4 tildes ~~~ or
and there is a shortcut [[~Foster]] that also links to
Profiles/Foster.
Second question is there a way to count the number of times a page has
been accessed? I found a cook book that seems to track edits, but
not just a plain read. That cookbook seems to be plugging into the
list of functions that are called as part of the edit/update cycle.
Having a page called Main.Pagecounts with a row for each page name
and the access count would be fine, or a variable that I could put in
the page to say "This page has been accessed {$Pagecount} times."
No, there is no recipe that would be reasonably performant or scalable.
If you have only a few visitors per day, you may try some of the recipes
on the PmWiki Cookbook.
I suggest using a web analytics software, see some free/open source ones
listed here:
https://en.wikipedia.org/wiki/Category:Free_web_analytics_software
Some hosting providers offer web analytics/statistics in their hosting
packages, based on the server access logs -- check your hosting panel.
Some people install Google Analytics, especially if they want to also
show ads. However, many visitors now have ad-blocking and
privacy-enhancing browsers or extensions, and external analytics may be
unreliable, notably with the providers that are known and popular.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How to unprotect specific -Talk page in groupA and groupB
On 17/11/2020 00:42, ABClf wrote:
well, in my project, no, regular doc password pages only say how to
protect full site, or group, or individual page, but I can not find
the conditional syntax for unprotecting a set of pages according to
its name.
Conditional syntax for passwords is not recommended.
If you want to have all talk pages with different permissions from their
content pages, you need to place them in different wikigroups:
Main.HomePage:
-> Talk-Main.HomePage OR
-> Main-Talk.HomePage
MyGroup.Page:
-> Talk-MyGroup.Page
The first one, with a Talk-* prefix, will probably need less markup to
cross-link.
In a GroupFooter, you can have something like this:
In Main.GroupFooter:
[[ Talk-{*$FullName} | Discuss this page]]
In Talk-Main.GroupFooter:
[[ Main.{*$Name} | Back to content page]] OR
[[ {(substr {*$FullName} 5)} | Back to content page]]
Possibly in Site.PageActions, or if you have something like
Site.AllGroupHeader (see cookbook) or AllGroupFooter:
(:if group Talk-*:)
* [[ {(substr {*$FullName} 5)} | Back to content page]]
(:else:)
* [[ Talk-{*$FullName} | Discuss this page]]
(:ifend:)
Then you set the passwords for the talk groups like explained in
PmWiki/Passwords, that is in
Talk-MyGroup.GroupAttributes?action=attr
If you want to leave them open, use @nopass in the form. It may be
better to have an "open" password to prevent spambots, I use a variant
of the solution posted here:
https://www.pmwiki.org/wiki/Cookbook/OpenPass-Talk
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
Could be something like locking everything first, then unlocking
special pattern name ones ; maybe :
$DefaultPasswords['edit'] = pmcrypt('mypassword');
if (preg_match('/-Talk$/', $pagename)) $DefaultPasswords['edit'] = '';
Le lun. 16 nov. 2020 à 10:26, Simon a écrit :
From https://www.pmwiki.org/wiki/PmWiki/Security
try https://www.pmwiki.org/wiki/PmWiki/Passwords
hope this helps
On Mon, 16 Nov 2020 at 10:20, ABClf wrote:
>
> I would like to give visitors the right to read/edit *-Talk pages in a
> bunch of Groups.
> I didn't find how to get it in the doc.
>
> as of now, my config has a site wide basic edit protection :
> $DefaultPasswords['edit'] = pmcrypt('mypassword');
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Double logins to be able to edit a page
1) How can I stop the double login (one on edit, one on save)?
This can happen if the browser does not receive cookies, doesn't store
them, or the website doesn't send them correctly or cannot store the
session data.
I assume that your browser does accept at least 1st-party cookies
(otherwise many other websites will look broken), and your own domain is
not somehow blacklisted in the browser preferences to disallow cookies.
Otherwise try with a different browser.
See on the page
https://www.pmwiki.org/wiki/PmWiki/Troubleshooting
the question
Why is PmWiki prompting me multiple times for a password I've already
entered?
I should add 2 cases that need to be checked for the script loading
pmwiki.php (if you have one, typically index.php) and all php scripts in
the local and cookbook directories:
1. if they are saved in UTF-8, they must be without Byte Order Mark
(BOM)
2. They must not have a closing "?>" PHP marker.
This is explained in the question on the same page:
Why am I seeing "PHP Warning: Cannot modify header information -
headers already sent by ..." messages at the top of my page.
Finally, review the question:
How do I make a PHP Warning about function.session-write-close go
away?
in case your server cannot save the session data.
Your PHP installation may be configured to not show any warnings -- some
hosting providers do this for "production" websites.
2) Is there a way that I can get a single login to be remembered?
Fixing 1) above should fix this too.
3) Is there a way to display the name of the current user inside a
page? I thought {$AuthId} would display it, but it's not showing a
value.
It does. Fixing 1) above should fix this too.
4) Is there a way to display the members of the @editors group?
Once you fix the cookie/session problem, you can add $EnableDiag = 1; to
config.php and as a logged-in user you can go to pmwiki.php?action=diag
This should show you your current permissions/groups in the
$_SESSION['authlist'] entry.
Note that PmWiki allows you to be logged in with more than one
username/permissions -- as it finds a protected area, it cycles through
all permissions/passwords you already have provided within the current
browsing session.
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
On 13/11/2020 14:45, Foster Schucker wrote:
I'm setting up a new instance of PMWiki. The site is running
pmwiki-2.2.133.
When I go to edit a page I get prompted for a user / password. But
when I save, I also get prompted for a user / password.
From my config.php file
## Set up some users
$AuthUser['Astro'] = pmcrypt('astropassword');
$AuthUser['Robot'] = pmcrypt('robotpassword');
$AuthUser['@editors'] = array ('Astro', 'Robot');
# Now give them edit ability
$DefaultPasswords['edit'] = array(pmcrypt('editpagepassword'),
#global edit password
'@editors'); # and the editors
## Turn on auth system
include_once("$FarmD/scripts/authuser.php");
I can edit pages as logging in as Astro and Robot with their
password. I can also edit with the global password. (The site Admin
has the same behavior)
I've been through the Password page and the Auth User page and didn't
see any other special setup info
Questions:
1) How can I stop the double login (one on edit, one on save)?
2) Is there a way that I can get a single login to be remembered?
When I go to edit the file, I put in the user / password, and on the
edit page I get View, Edit, History, Print and_ Logout_ links. But
once I do the save (with the second authentication) there is no longer
a Logout link. In a more perfect world I'd be able to login once and
have it stick.
a) I have tried using the Auth User form and it shows a logon, but it
does not seem to stay.
b) I've tried setting $EnableIMSCaching = 1; to both zero and one
and the results don't change.
3) Is there a way to display the name of the current user inside a
page? I thought {$AuthId} would display it, but it's not showing a
value.
4) Is there a way to display the members of the @editors group?
Thanks for your help!
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] $UrlLinkFmt
All InterMap links default to $UrlLinkFmt, unless there is a specific $IMapLinkFmt entry, like: $IMapLinkFmt['ftp:'] $IMapLinkFmt['PmWiki:'] $IMapLinkFmt['mailto:'] Note that if you have enabled ObfuscateLinkIMap (core function based on DeObMail), the snippet can be customized in: $IMapLinkFmt['obfuscate-mailto:'] Also note that the ObfuscateLinkIMap logic expects the snippet to have some recognizable properties -- classes, elements, otherwise it may not work. I suggest starting with the default snippet, make small modifications and test if it works. This is the default (for ObfuscateLinkIMap): $IMapLinkFmt['obfuscate-mailto:'] = "title=\"\$LinkAlt\">\$LinkTextclass='_m'>\$LinkUrl" Petko On 01/11/2020 02:37, Simon wrote: https://www.pmwiki.org/wiki/PmWiki/LinkVariables#UrlLinkFmt The documentation says $UrlLinkFmt The (HTML) string to output for URL-links that begin with 'http:', 'ftp:', etc. Defaults to \$LinkText but the "etc" does not encompass "mailto:; Should it? (I think so), or is there an equivalent for href="mailto:... ? e.g. $MailtoLinkFmt ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How to add a geolocalisation function to APE ?
After a discussion with Benjamin, I've implemented this in APE version 20201029, and at the same time I've updated the Leaflet.js library to its latest version. If you upgrade, all files need to be replaced, except if you have a custom pub/ape/ape-local.js file. A new button is added below the "+/-" zoom controls. When a visitor clicks on it, the program will request Geolocation permissions and if the user accepts it, the map will be zoomed in or out and centered over the user's position, and a round dark red dashed circle marker will be added. Notes: my previous comments about reliability and precision still apply. Also: the Geolocation feature only works in a secure context (both website and Ape on a HTTPS protocol). Petko -- If you upgrade : http://www.pmwiki.org/Upgrades On 28/10/2020 18:53, Petko Yotov wrote: On 28/10/2020 15:14, Benjamin Grassineau wrote: Do you think it would be possible to add a geolocalisation function to APE ? Or to create an independant function wich could be added by a markup ? It would be yet very useful for my website. Do you mean having an Openstreetmap automatically centered, or insert a pin, over the visitor's location? (1) Or do you want an editor to be able to add a pin while editing the source text of the wiki page? (2) Some hosting providers (e.g. OVH) have an ip2location module installed on their servers and you can get an approximate latitude and longitude in PHP from the $_SERVER array. It shouldn't be complicated to create a custom markup, or a GUI button, that inserts the coordinates in an APE definition list. While this would be easy and automatic, there are 2 difficulties -- 1. The coordinates may be incorrect or missing for some users -- for example my home location doesn't show, but others do. 2. If you change hosting providers it may not work on the new service. In fact, I've tried to do this with JavaScript but I did not arrived ! It's true that I am not very cumfortable with this language. I tried to use the |getCurrentPosition()| method. This would be the way to go for modern browsers, but it is done in 2 steps -- you first need to request location permissions from the browser, and then if the visitor grants them you can request the geographic coordinates. So depending on what you want to achieve (1) or (2) above, it needs to be done differently. (1) needs to be implemented in APE, (2) can be independent. Here too it is not 100% reliable: the user may refuse to grant the permissions, or the coordinates may be imprecise or incorrect, but this as good as it gets. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How to add a geolocalisation function to APE ?
On 28/10/2020 15:14, Benjamin Grassineau wrote: Do you think it would be possible to add a geolocalisation function to APE ? Or to create an independant function wich could be added by a markup ? It would be yet very useful for my website. Do you mean having an Openstreetmap automatically centered, or insert a pin, over the visitor's location? (1) Or do you want an editor to be able to add a pin while editing the source text of the wiki page? (2) Some hosting providers (e.g. OVH) have an ip2location module installed on their servers and you can get an approximate latitude and longitude in PHP from the $_SERVER array. It shouldn't be complicated to create a custom markup, or a GUI button, that inserts the coordinates in an APE definition list. While this would be easy and automatic, there are 2 difficulties -- 1. The coordinates may be incorrect or missing for some users -- for example my home location doesn't show, but others do. 2. If you change hosting providers it may not work on the new service. In fact, I've tried to do this with JavaScript but I did not arrived ! It's true that I am not very cumfortable with this language. I tried to use the |getCurrentPosition()| method. This would be the way to go for modern browsers, but it is done in 2 steps -- you first need to request location permissions from the browser, and then if the visitor grants them you can request the geographic coordinates. So depending on what you want to achieve (1) or (2) above, it needs to be done differently. (1) needs to be implemented in APE, (2) can be independent. Here too it is not 100% reliable: the user may refuse to grant the permissions, or the coordinates may be imprecise or incorrect, but this as good as it gets. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] PmWiki 2.2.133 released
Hello. PmWiki version 2.2.133 was published today, and is available at:
http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.133.tgz
http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.133.zip
svn://www.pmwiki.org/pmwiki/tags/latest
This version fixes a potential vulnerability to CWE-384: Session
Fixation, reported by Dominique Faure. The fix regenerates the session
identifier at the moment a password is submitted. In case this is not
desirable, a wiki admin can set the new variable
$EnableAuthPostRegenerateSID to false.
This version also fixes an unintended variable evaluation in link
markups.
The CSS from Cookbook:RecipeCheck will now be injected only when needed.
The responsive skin styles contained a reduced padding value
for numbered and bulleted lists in order to save space, but in
longer lists it could clip the item numbers. This value was removed
from the styles because it was complex to reliably override it from
local configuration. If you need to enable the previous values, add to
pub/css/local.css the following:
ul, ol { padding: 0 0 0 20px; }
@media screen and (min-width:50em) {
ul, ol { padding: 0 0 0 40px; }
}
Thanks,
Petko
--
If you upgrade : http://www.pmwiki.org/Upgrades
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Session (or authid?) and fastcache recipe issue
On 18/10/2020 00:49, ABClf wrote:
I still have a question Petko :
what is the session line – session_name('XXXSESSID'); – in config ?
This
This is the name of the session cookie, by default PHPSESSID.
You can read about PHP functions like session_name() in the PHP
documentation:
https://php.net/session_name
or in French:
https://php.net/fr/session_name
line is not in sample-config and I don't know what is the benefit of
it.
According to PmWiki/AuthUser#sessions it's mainly dedicated for users
running a PmWiki Farm. Does that mean it is useless for single (or
distinct) site installation ?
If you have other PmWiki installations with different sets of users and
passwords, you should use a distinct session name for each one.
If you have other PHP software on the same website storing session data
with the keys 'authid' and 'authpw': using the same session name may
cause these keys to be overwritten by it or by PmWiki and the user's
permissions may be discarded (so she will have to log in again). In that
case it would be sensible to use distinct session names.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Session (or authid?) and fastcache recipe issue
I made a small correction to the $FastCacheValid variable: since PHP 5.3 cookies are not in the $_REQUEST array by default. I don't have this installed and have no way to test it, please report -- you'll need to edit a page and save it to clear existing cache. Someone who uses this recipe should take over the maintenance -- the original author Eemeli Aro no longer uses PmWiki, and has released all his addons as free/libre software allowing modification and redistribution. For example, PmWiki may issue a session cookie even to people who don't have any permissions and are logged out. In this case, apparently the cache will be invalidated, that is, not saved. Someone who needs this recipe and uses it should take a look at the logic. FYI, on your website there is no session cookie when the visitor is logged out, so you should be mostly safe. Petko On 17/10/2020 16:41, ABClf wrote: Hello hello, It looks like I'm having a test page where condition (:if auth admin:)test(:if:) is written (i'm logged as admin of course) ; then saved using fastcache recipe on page1 (same code saved on page2 with fastcache recipe disabled). With fastcache : 1/ Logging out with action=logout 2/ If browsing the page with ?action browse, "test" is not printed (as expected) 3/ If browsing with no action, "test" is printed (unexpected). (I believe case 2 is because of the action query string ?, which tells fastcache not to run). Without fastcache : 1/ Logging out with action=logout 2/ If browsing the page with ?action browse, "test" is not printed (as expected) 3/ If browsing with no action, test is not printed (expected). I have read doc, talk and pits and it looks like there might be an issue with session, when using fastcache. My config has only one line related to session, at the very top of my config (just below ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] get rid of special characters in page names creation (when Tagger recipe is used)
When you type in a page [[Index.Pépé123]] (not Index:pépé), does it
create the page Index.Pepe123 or Index.Pépé123 ?
If Index.Pepe123 is created and linked, the problem comes indeed from
the Tagger recipe.
If it creates Index.Pépé123, there is a problem either with PmWiki, or
with your configuration.
If you type a link [[A group not in tagger/Pépé123]], what page is
linked, AGroupNotInTagger.Pepe123 or AGroupNotInTagger.Pépé123?
In the first case all is good, in the second you have a problem with
your configuration-- probably incorrect encoding of the config.php file.
As the wiki has utf-8 enabled, then the config.php needs to be in the
same encoding, see
https://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#encoding
Petko
On 03/10/2020 21:02, ABClf wrote:
I want internal links get rid of special characters, replacing for
example : é with e, ç with c, in such a way [[Pépé]] will link to page
named Pepe, and [[Garçon]] will link to page named Garcon.
I have some lines (1) in my config devoted to that purpose and it
looks like it's working.
But I have an issue with Tagger cookbook recipe (used together with
autocreate category).
Among other things, Tagger has these lines :
$TaggerGroups['index'] = 'Index';
$AutoCreate['/^Index\\./'] = array('ctime' => $Now);
Now, when writing something like
Index: myword
I automatically get a new page named "Myword" created.
If writing something like :
Index:pépé
then I get a page named Index.Pépé, where I am expecting a special
character free name (I want : Index.Pepe).
Is there something I could do to ask Tagger to create links, using
special patterns for naming pages ?
Thank you !
Gilles.
(1) My config has these lines
# UTF-8 & francisation
# The include_once line is recommended if you start a new wiki
# and it should be placed before the XLPage line (for languages with
alphabets other than the Latin, the include_once line is required).
# -- IMPORTANT -- These lines should be placed near the beginning of
config.php, but after any $WikiDir and $WikiLibDirs setting (if you
have such setting).
include_once("scripts/xlpage-utf-8.php");
#$DefaultPageCharset = array(''=>'ISO-8859-1'); # problématique
XLPage('fr','PmWikiFr.XLPage');
XLPage('fr','PmWikiFr.XLPageCookbook'); // S'il y a des modules
# standard patterns from pmwiki.php
SDV($PageNameChars, '-[:alnum:]');
SDV($MakePageNamePatterns, array(
"/'/" => '',# strip single-quotes
"/[^$PageNameChars]+/" => ' ', # convert everything else to
space
'/((^|[^-\\w])\\w)/' => 'cb_toupper', # capitalize first letter of
word
'/ /' => '')); #function
# additonal character conversion patterns for ISO 8859-1 character set
SDV($ISO88591MakePageNamePatterns, array(
'/Á/' => 'A', '/Â/' => 'A', '/Ã/' => 'A', '/Ä/' => 'Ae', '/Å/' =>
'Ao', '/Æ/' => 'Ae', '/Ç/' => 'C',
'/È/' => 'E', '/É/' => 'E', '/Ê/' => 'E', '/Ë/' => 'E', '/Ì/' => 'I',
'/Í/' => 'I', '/Î/' => 'I', '/Ï/' => 'I',
'/Ð/' => 'D', '/Ñ/' => 'N', '/Ú/' => 'U', '/Ó/' => 'O', '/Ô/' => 'O',
'/Õ/' => 'O', '/Ö/' => 'Oe', '/Ø/' => 'Oe',
'/Ù/' => 'U', '/Ú/' => 'U', '/Û/' => 'U', '/Ü/' => 'Ue', '/Ý/' => 'Y',
'/Þ/' => 'Th', '/ß/' => 'ss',
'/à/' => 'a', '/á/' => 'a', '/â/' => 'a', '/ã/' => 'a', '/ä/' => 'ae',
'/å/' => 'ao', '/æ/' => 'ae', '/ç/' => 'c',
'/è/' => 'e', '/é/' => 'e', '/ê/' => 'e', '/ë/' => 'e', '/ì/' => 'i',
'/í/' => 'i', '/î/' => 'i', '/ï/' => 'i',
'/ð/' => 'd', '/ñ/' => 'n', '/ò/' => 'o', '/ó/' => 'o', '/ô/' => 'o',
'/õ/' => 'o', '/ö/' => 'oe', '/ø/' => 'oe',
'/ù/' => 'u', '/ú/' => 'u', '/û/' => 'u', '/ü/' => 'ue', '/ý/' => 'y',
'/þ/' => 'th', '/ÿ/' => 'y'
));
# join to standard patterns
$MakePageNamePatterns = array_merge($ISO88591MakePageNamePatterns,
$MakePageNamePatterns);
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users-fr] bouton avec barre de défilement
Dans le fichier de styles:
https://www.toposcopie.fr/pub/skins/toposcopie/skin.css
il y a la règle:
select, textarea, input {
...
overflow: scroll;
}
Il faut mettre input[type="text"] et non juste input.
Sinon on peut mettre overflow: auto; et non overflow: scroll;.
Petko
On 05/10/2020 11:20, Pierre-Marie Carette wrote:
Après une longue absence retour à
https://www.toposcopie.fr/Methode/Essai
Tous les boutons apparaissent avec une barre de défilement
Je ne trouves pas l’erreur que j’ai faite
Merci
___
pmwiki-users-fr mailing list
pmwiki-users-fr@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users-fr
[pmwiki-users] PmWiki 2.2.132 released
Hello. PmWiki version 2.2.132 was published today, and is available at: http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.132.tgz http://www.pmwiki.org/pub/pmwiki/pmwiki-2.2.132.zip svn://www.pmwiki.org/pmwiki/tags/latest This is a documentation update version. Thanks, Petko -- If you upgrade : http://www.pmwiki.org/Upgrades ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Redesigning for accessibility: heading levels?
On 16/09/2020 18:25, Steve Glover wrote:
Is there a way, please, to include one line of text if a page is
rendered alone but another if it's rendered inside a holding page?
There are several ways to do it.
I suggest looking into the recipe SectionEdit which creates "edit" links
directly to the included pages, by overriding the "(:include...:)"
markup.
Another way would be to add a $QualifyPattern that inserts a link to the
included page at the beginning. Something like this:
$QualifyPatterns['/^/'] = "IncludeWithLink";
function IncludeWithLink() {
foreach(debug_backtrace() as $a) {
if($a['function'] == 'IncludeText') # prevent PTVs
return '(:nl:)%rfloat red
bgcolor=yellow%[[{$Name}?(action=)edit]]%%(:nl:)';
}
return '';
}
This will show a red on yellow link "OtherPage?edit", floating right, at
the beginning of the included text.
Note that PmWiki includes group headers and footers and you will see a
link to these too. Also some pagelists or inline templates, or skins,
use the include markup.
I'd enable this as a temporary measure while I review the pages.
A third way could be to override the Heading markup rule, so that the
first processed heading markup always becomes a H1 heading.
Petko
On 16/09/2020 18:25, Steve Glover wrote:
Hi,
One of the things I've come across when remodelling a PmWiki-based
site to fit with accessibility guidelines is the rather stricter rules
on header levels than I've been used to.
I can use a bulk search and replace on pages in the wiki.d folder to
ensure that each page starts with a first level header - that bit's
easy enough - but where I hit a problem is when I have one page that
includes others.
Is there a way, please, to include one line of text if a page is
rendered alone but another if it's rendered inside a holding page?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Sidebar and main part of page with no content
Both actions "source" and "diff" appear to work fine: http://www.elfgestirn.de/Verein/HomePage?action=source http://www.elfgestirn.de/Verein/HomePage?action=diff but not when the history has markup processed: http://www.elfgestirn.de/Verein/HomePage?action=diff=n so my guess is some markup processing causes the blanking of the pages. In the past, without any other warning or error message, the most frequent reason for a blank page or section was a call to htmlspecialchars() in a recipe/addon/skin. With recent PmWiki versions, any call to htmlspecialchars() can be replaced with a call to PHSC() which is a PmWiki helper function that safely calls htmlspecialchars(). Depending on how the server is configured, it is possible that another function call may cause this. (Recent PHP versions change the rules and something that worked fine in earlier PHP versions may stop working after a server upgrade. I try hard to follow and fix any such cases, or implement and document workarounds.) It may be helpful to enable PmWiki diagnostics and open the page http://www.elfgestirn.de/Verein/HomePage?action=ruleset where some custom markup rules may be marked as obsolete. Again, try disabling (commenting out) *all* recipes and local configuration, then enable one and see if it works or becomes blank. Then proceed to the next one. See https://www.pmwiki.org/wiki/PmWiki/Troubleshooting -- read all sections, including the first one and the one on blank pages (since source and diff actions work, it is likely NOT a problem with file permissions but with something else). Petko On 12/09/2020 17:47, Marcel Schweiker wrote: Dear all, I really hope you can help me out after a full day of trying to solve this. My page based on pmwiki was blank (no content) when I started this morning - despite working a few weeks ago, when I checked the last time. I then upgraded this morning from 2.2.8 to the latest version of pmwiki and also upgraded all recipes. The result is, that header and footer are visible and working, but all else (sidebar left and main content) are not there. I checked the $EnableRelativePageVars issue as I upgraded from 2.2.8 (no change with setting it to 0 or 1) and also manually activated/deactivated all recipes individually (no change in the pages behaviour). I am not sure how to work with a test page, because I cannot login for editing as the login fields are on the main part of the page, which is not displayed. I am using the maguila skin, which might be an issue, but I have the same behaviour when switching to pmwiki skin. Any help would be highly appreciated. The page is elfgestirn.de ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
