Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 09:23:12PM +0200, Oliver Betz wrote: > Peter Bowers wrote: > > [...] > > >Thus if I need $group or $name early on in my config.php I can either > > just to avoid misunderstandings: This is verbatim $group and $name > from the HTTP request and might be different from the final value used > to find the requested page. ...which is exactly why PmWiki doesn't try to impose its own notion of "group" and/or "page" until after the customization files have had a chance to manipulate it a bit. :-) ResolvePageName() is Pmwiki's official function that means "determine the group and page from the available information using PmWiki's standard page resolution algorithms". Calculating pagenames from specialized requests requires custom solutions (and pmwiki.org does a fair bit of this in its configuration, e.g. to enable XLPage() in various groups). What PmWiki _does_ do is guarantee that at the start of customization, $pagename is set to 1. Any value of ?n= if it's set, or 2. Any value of ?pagename= if it's set, or 3. The "path info" information from REQUEST_URI (whatever follows SCRIPT_NAME), or 4. Blank otherwise If it would help to have PmWiki save this value in another variable as well ($requestedname) for use by customizations and recipes, we can do that. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 09:07:43PM +0200, Peter Bowers wrote: > On Sun, May 22, 2011 at 8:19 PM, Patrick R. Michaud > wrote: > > The correct solution for getting/setting the group and > > pagename in config.php is already given at > > http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-group-page > > > > ## Get the group and page name > > $pagename = ResolvePageName($pagename); > > $page = PageVar($pagename, '$FullName'); > > $group = PageVar($pagename, '$Group'); > > $name = PageVar($pagename, '$Name'); > > Am I mistaken in thinking that we've periodically run into > difficulties with this solution related to caching? > > ResolvePageName calls MakePageName which calls FmtPagename which calls > PageVar which (a) calls PCache() (first problem) and (b) also calls > PageTextVar which calls RetrieveAuthPage which normally calls > PmWikiAuth (second problem). ResolvePageName (and its calls to MakePageName) doesn't normally expect to be using variables that would cause any caching issues. In fact, it doesn't expect to be doing any page reads at all -- it expects to be able to resolve a pagename using just the information in a url. I'm having trouble imagining a situation where converting a url to a pagename requires the use of PageTextVars, or the actual reading and caching of a page file. That said, just because I can't imagine it right now doesn't mean it won't happen for some configurations. I don't think it would be a problem at all to have ResolvePageName also clear the caches after it's done its work, or to disable the caches altogether until some "we've reached a stable configuration point" is reached (e.g., at the beginning of stdconfig.php). > PITS/01177 is related. This answer would seem to also address #01177. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
Peter Bowers wrote: [...] >Thus if I need $group or $name early on in my config.php I can either just to avoid misunderstandings: This is verbatim $group and $name from the HTTP request and might be different from the final value used to find the requested page. Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On 5/22/2011 3:07 PM, Peter Bowers wrote: ResolvePageName calls MakePageName which calls FmtPagename which calls PageVar which (a) calls PCache() (first problem) and (b) also calls PageTextVar which calls RetrieveAuthPage which normally calls PmWikiAuth (second problem). My recollection (I can search thru archives to confirm -- I may be remembering it wrong) is that the static $acache in PmWikiAuth as well as the general $PCache can both cause problems if they are called/cached early in config.php... You are correct. Any calls to PageVar or PageTextVar cause issues with caching. This in turn can cause issues with cookbook include sequencing when they both need access to page and group names. Thus if I need $group or $name early on in my config.php I can either take a chance with $pagename without calling ResolvePageName or else take a chance that I will open the door to later difficulties with cached values (which are notoriously difficult to debug)... Agreed. Had a lot of issues with this when creating blogit. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 8:19 PM, Patrick R. Michaud wrote: > The correct solution for getting/setting the group and > pagename in config.php is already given at > http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-group-page > > ## Get the group and page name > $pagename = ResolvePageName($pagename); > $page = PageVar($pagename, '$FullName'); > $group = PageVar($pagename, '$Group'); > $name = PageVar($pagename, '$Name'); Am I mistaken in thinking that we've periodically run into difficulties with this solution related to caching? ResolvePageName calls MakePageName which calls FmtPagename which calls PageVar which (a) calls PCache() (first problem) and (b) also calls PageTextVar which calls RetrieveAuthPage which normally calls PmWikiAuth (second problem). My recollection (I can search thru archives to confirm -- I may be remembering it wrong) is that the static $acache in PmWikiAuth as well as the general $PCache can both cause problems if they are called/cached early in config.php... Thus if I need $group or $name early on in my config.php I can either take a chance with $pagename without calling ResolvePageName or else take a chance that I will open the door to later difficulties with cached values (which are notoriously difficult to debug)... Now one "solution" is to say "just don't call ResolvePageName() until near the end of config.php". And this is generally possible... But there are certain circumstances (Oliver's appears to be a good example where he needs the values related to XL which needs to be early) when there needs to be a non-cache-dependent solution... PITS/01177 is related. -Peter ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
"Patrick R. Michaud" wrote: [...] >The correct solution for getting/setting the group and >pagename in config.php is already given at >http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-group-page > >## Get the group and page name >$pagename = ResolvePageName($pagename); >$page = PageVar($pagename, '$FullName'); >$group = PageVar($pagename, '$Group'); >$name = PageVar($pagename, '$Name'); I didn't dare to do so because the same page says that "any direct function call in config.php, like ResolvePageName()... ...if possible, should be done near the end of config.php". And other warnings say that XLPage has to be called early. Does ResolvePageName() cache anything, IOW can I set $XLLangs and $DefaultPage after calling ResolvePageName()? Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
Peter Bowers wrote:
[...]
>>>My understanding of pretty URLs is that they simply change
>>>www.example.com/pmwiki/Group/Page to
>>>www.example.com/pmwiki/pmwiki.php?n=Group/Page behind the scenes.
>>>Thus the $_REQUEST['n'] (or $_GET['n']) is still available regardless
>>
>> I don't think so if someone is using "$EnablePathInfo = 1;"
>>
>> Look at mwiki.php, lines 302ff. There is also another request method,
>> with the "pagename" parameter instead of "n".
>
>Yes, I saw that, but I *believe* it is something left over from
>something obsolete in pmwiki. As I look at the Cookbook/CleanUrls
>page It appears that all the .htaccess examples I see there end up
I never use rewrite rules but the (IMO much simpler) PmWiki setting
"$EnablePathInfo = 1;"
In addition, I use a wrapper script like
> Can I call MakePageName() early in config.php?
>
>No, this is the function that often causes caching issues. It calls
>FmtPagename() which calls PageVar() which caches various info about
>the page, perhaps prematurely.
I didn't follow the code enough to see under wich circumstances
FmtPagename() is called.
>>>Unfortunately $pagename can still be blank if the user is just looking
>>
>> Correct, I missed this. But this is more a skin problem - the "Logo"
>> link has to be a full URL to the current default page instead of
>> $ScriptUrl, else the language information is lost anyway.
>>
>> A link to $ScriptUrl will always start the default language.
>
>Sorry, you've lost me here. $ScriptUrl always points at pmwiki.php,
>right? I'm not sure I'm seeing the connection to a pagename or a
No. In my example above, it's "http://myhost.tld/wrapper";
>language or anything else...?
>
>And the "Logo" link is normally set using PVs which are handled long
>after farmconfig.php and config.php unless I'm misunderstanding
>something... (Isn't this set during the call to MarkupToHTML()?)
PmWiki does a good job assembling the correct value for $ScriptUrl
(used my most skins for the "Logo" link). No need to set it manually
in config.php.
>Maybe I've misunderstood the basic question. Are you trying to get
>access to the name of the page early on in config.php?
No. I just want to get the group name to make language settings
depending on patterns in it:
foo_en, bar_en should get English settings while foo_de, bar_de should
be German.
$DefaultPage is also switched depending on the language, and the
"logo" link in the skin is changed to point to the the full URL of the
default page, so the user stays in the selected language.
[...]
>add to config.php towards the top:
>===(snip)===
>if (!$pagename) $pagename = $DefaultPage;
>$pagename = preg_replace('/\.html$/', '', $pagename);
>list($group, $name) = preg_match('/^(.*?)[.\/](.*)$/', $pagename);
>===(snip)===
You are right, I should not make it more complicated than it is. Since
the scenario is well controlled (internal links), I don't even need to
handle the .html extension.
If the user provides a wrong URL, he gets the default language start
page.
Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] %block...% anomaly
On Sun, May 22, 2011 at 02:18:25AM +0100, Brian Tibbels wrote: > Hi everyone, > > Sorry to interrupt the WYSIWYG debate... > > * %block id=leftmenu%line one > * line two > * line three > > Why does pmwiki produce this when all I want is the id added to the "ul" tag > > > line one Because both the "" and "" tags are example of block markup. You have to use either "list" or "item" to distinguish between them. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 05:27:34PM +0200, Peter Bowers wrote:
> Could someone comment on the relative merit of putting this in
> conjunction with
> http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-order
> to try to give people an option:
>
> add to config.php towards the top:
> ===(snip)===
> if (!$pagename) $pagename = $DefaultPage;
> $pagename = preg_replace('/\.html$/', '', $pagename);
> list($group, $name) = preg_match('/^(.*?)[.\/](.*)$/', $pagename);
> ===(snip)===
The correct solution for getting/setting the group and
pagename in config.php is already given at
http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-group-page
## Get the group and page name
$pagename = ResolvePageName($pagename);
$page = PageVar($pagename, '$FullName');
$group = PageVar($pagename, '$Group');
$name = PageVar($pagename, '$Name');
Note that ResolvePageName() will already strip a ".html" suffix from the
request url if it happens to exist.
> I'm still not convinced this solves 100% of the issues, but presumably
> takes it a lot closer... Not being confident that it covers enough of
> the instances I hesitate to document it in PmWiki/LocalCustomizations.
The example given above doesn't cover partial pagenames -- i.e., where
a group is given without a page within a group. It also doesn't honor
various configuration settings that affect page name formatting.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 03:22:19PM +0200, Peter Bowers wrote: > On Sun, May 22, 2011 at 12:26 PM, Oliver Betz wrote: > I would love to see either (1) a change to core to provide access to > $pagename (validated), $name, and $group throughout config.php and > farmconfig.php. Can't do this, because resolving the pagename depends on the values of other variables ($DefaultPage, $DefaultGroup, $DefaultName, $GroupPattern, etc.) that might be set in config.php or farmconfig.php. > Or (2), at least an "officially sanctioned" way to > access these values via PHP early on in farmconfig and/or > config.php... The officially sanctioned way is to use $pagename = ResolvePageName($pagename); It's okay if the $pagename argument is blank or partial when the function is called -- resolving a blank or partial name is exactly what ResolvePageName does. :-) Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 4:36 PM, Oliver Betz wrote:
> Peter Bowers wrote:
>
Suggestion: get the language code from the URL by writing a PHP
function to return the language code embedded in the page's group
(the first part of the "?n=" parameter. Since that doesn't require
>>>
>>> since I'm using "pretty URLs", there is no ?n parameter.
>>>
>>> There are several possibilities of group and name encoding (dot,
>>> slash, order of appearance) that I don't want to duplicate the PmWiki
>>> functions if I can avoid it.
>>
>>My understanding of pretty URLs is that they simply change
>>www.example.com/pmwiki/Group/Page to
>>www.example.com/pmwiki/pmwiki.php?n=Group/Page behind the scenes.
>>Thus the $_REQUEST['n'] (or $_GET['n']) is still available regardless
>
> I don't think so if someone is using "$EnablePathInfo = 1;"
>
> Look at mwiki.php, lines 302ff. There is also another request method,
> with the "pagename" parameter instead of "n".
Yes, I saw that, but I *believe* it is something left over from
something obsolete in pmwiki. As I look at the Cookbook/CleanUrls
page It appears that all the .htaccess examples I see there end up
putting the page name in ?n=X... Theoretically someone could change
these .htaccess to ?pagename=X and presumably it would work, but I'm
not seeing code within pmwiki that would result in a link with
pagename=X.
>>of the use of pretty URLs. But that's somewhat irrelevant because
>>$pagename is already set to that value by the time config files are
>>included...
>
> Can I rely on pagename being set to the request when config.php is
> processed?
Yes, insofar as it is set. But see below...
> Can I call MakePageName() early in config.php?
No, this is the function that often causes caching issues. It calls
FmtPagename() which calls PageVar() which caches various info about
the page, perhaps prematurely.
>>Unfortunately $pagename can still be blank if the user is just looking
>
> Correct, I missed this. But this is more a skin problem - the "Logo"
> link has to be a full URL to the current default page instead of
> $ScriptUrl, else the language information is lost anyway.
>
> A link to $ScriptUrl will always start the default language.
Sorry, you've lost me here. $ScriptUrl always points at pmwiki.php,
right? I'm not sure I'm seeing the connection to a pagename or a
language or anything else...?
And the "Logo" link is normally set using PVs which are handled long
after farmconfig.php and config.php unless I'm misunderstanding
something... (Isn't this set during the call to MarkupToHTML()?)
Maybe I've misunderstood the basic question. Are you trying to get
access to the name of the page early on in config.php?
>>I would love to see either (1) a change to core to provide access to
>>$pagename (validated), $name, and $group throughout config.php and
>>farmconfig.php. Or (2), at least an "officially sanctioned" way to
>>access these values via PHP early on in farmconfig and/or
>>config.php...
>
> Exactly that's what I'm looking for.
>
>> Currently a simple preg_match on $pagename will work in
>>probably 99.5% (?) of situations, but it would be great to have a 100%
>
> Looking at MakePageName(), I'm afraid it's not so simple.
I think you'll find that the vast majority of MakePageName() is
irrelevant in this context (calling MPN() to get an accurate $pagename
during the execution of config.php). [1]
In actual but limited testing (tracing the value of $pagename in
config.php and then throwing a lot of different values at it) it
appears that only the case of a blank $pagename (when looking for the
default page) and the case of the trailing .html (both of which are
handled in ResolvePageName() ) are the issues. The difference between
. and / between group and name is easy enough to solve to be
irrelevant.
But whatever the case, whether 80% or 99.5%, I believe what is needed
is a 100% case we can depend on...
Could someone comment on the relative merit of putting this in
conjunction with
http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-order
to try to give people an option:
add to config.php towards the top:
===(snip)===
if (!$pagename) $pagename = $DefaultPage;
$pagename = preg_replace('/\.html$/', '', $pagename);
list($group, $name) = preg_match('/^(.*?)[.\/](.*)$/', $pagename);
===(snip)===
I'm still not convinced this solves 100% of the issues, but presumably
takes it a lot closer... Not being confident that it covers enough of
the instances I hesitate to document it in PmWiki/LocalCustomizations.
-Peter
For instance, MPN() removes characters that shouldn't be in a pagename
from $pagename. But in the vast majority of cases people are going to
access pages via links and those links will already be pointing to
correctly named pages (and in any event, line 310 would solve that).
MPN() removes anchors, but they aren't appearing as part of the value
of $pagename in my farmconfig.php (although I don't see where pmwiki
is removing them -- mus
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
Peter Bowers wrote: >>> Suggestion: get the language code from the URL by writing a PHP >>> function to return the language code embedded in the page's group >>> (the first part of the "?n=" parameter. Since that doesn't require >> >> since I'm using "pretty URLs", there is no ?n parameter. >> >> There are several possibilities of group and name encoding (dot, >> slash, order of appearance) that I don't want to duplicate the PmWiki >> functions if I can avoid it. > >My understanding of pretty URLs is that they simply change >www.example.com/pmwiki/Group/Page to >www.example.com/pmwiki/pmwiki.php?n=Group/Page behind the scenes. >Thus the $_REQUEST['n'] (or $_GET['n']) is still available regardless I don't think so if someone is using "$EnablePathInfo = 1;" Look at mwiki.php, lines 302ff. There is also another request method, with the "pagename" parameter instead of "n". I don't want to duplicate this code or portions of MakePageName(). >of the use of pretty URLs. But that's somewhat irrelevant because >$pagename is already set to that value by the time config files are >included... Can I rely on pagename being set to the request when config.php is processed? Can I call MakePageName() early in config.php? >Unfortunately $pagename can still be blank if the user is just looking Correct, I missed this. But this is more a skin problem - the "Logo" link has to be a full URL to the current default page instead of $ScriptUrl, else the language information is lost anyway. A link to $ScriptUrl will always start the default language. >I would love to see either (1) a change to core to provide access to >$pagename (validated), $name, and $group throughout config.php and >farmconfig.php. Or (2), at least an "officially sanctioned" way to >access these values via PHP early on in farmconfig and/or >config.php... Exactly that's what I'm looking for. > Currently a simple preg_match on $pagename will work in >probably 99.5% (?) of situations, but it would be great to have a 100% Looking at MakePageName(), I'm afraid it's not so simple. Oliver ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On Sun, May 22, 2011 at 12:26 PM, Oliver Betz wrote: > Randy Brown wrote: > >> Suggestion: get the language code from the URL by writing a PHP >> function to return the language code embedded in the page's group >> (the first part of the "?n=" parameter. Since that doesn't require > > since I'm using "pretty URLs", there is no ?n parameter. > > There are several possibilities of group and name encoding (dot, > slash, order of appearance) that I don't want to duplicate the PmWiki > functions if I can avoid it. My understanding of pretty URLs is that they simply change www.example.com/pmwiki/Group/Page to www.example.com/pmwiki/pmwiki.php?n=Group/Page behind the scenes. Thus the $_REQUEST['n'] (or $_GET['n']) is still available regardless of the use of pretty URLs. But that's somewhat irrelevant because $pagename is already set to that value by the time config files are included... Unfortunately $pagename can still be blank if the user is just looking for a default page or have trailing ".html" or etc. This can be fixed by a call to ResolvePageName(), but you are correct in noting that this causes problems with caching (due to the call to MakePageName() IIRC) if used too early in config.php... :-( I would love to see either (1) a change to core to provide access to $pagename (validated), $name, and $group throughout config.php and farmconfig.php. Or (2), at least an "officially sanctioned" way to access these values via PHP early on in farmconfig and/or config.php... Currently a simple preg_match on $pagename will work in probably 99.5% (?) of situations, but it would be great to have a 100% solution that doesn't cause caching problems... -Peter ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] How to customize default search pagelist ?
Hi all !! I know I can customize my search results to get layout different from the one automatically used by the default search ; but how can I customize the default search layout ? I mean, if I want my default search results layout use some dedicated pagelist ? Thank you :) -- --- | A | de la langue française | B | http://www.languefrancaise.net/ | C | languefranca...@gmail.com --- ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Funding?
Hello All, although the WYSIWYG project was no that successfull, what do you think about funding in general? Maybe the idea to let market economy influence the development is not so bad. Should there be a central place to start polls? What about commercial "clients" - they usually need an invoice for tax deduction. Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
Randy Brown wrote: > Suggestion: get the language code from the URL by writing a PHP > function to return the language code embedded in the page's group > (the first part of the "?n=" parameter. Since that doesn't require since I'm using "pretty URLs", there is no ?n parameter. There are several possibilities of group and name encoding (dot, slash, order of appearance) that I don't want to duplicate the PmWiki functions if I can avoid it. Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmWiki 2.2.26 released
Petko Yotov wrote: >> Recently I saw many edits in PmWikiDe by mfwolff, do you know him? It >> would be great to have a new i18n download when he is "ready". > >I am thankful to this user, who not only translates, but also finds and fixes >errors and typos in the English documentation. :-) I also. >I can create a translation archive at any moment, just tell me when I should. >(Just did.) Thanks! Regarding UTF-8 (my wuestion from th e other thread): As far as I see, the following commands should do the conversion: sed -i s/^charset=ISO-8859-1/charset=UTF-8/ * recode ISO-8859-1..UTF-8 * Sadly, my web hosting provider doesn't offer "recode", so I did the conversion on my Windos XP workstation using "UnxUtils". UnxUtils's recode seems to work only with admin rights. Since I'm no gnu tools specialist, I would appreciate a comment before I add this hint to PmWiki.org Petko, can you imagine to offer i18n downloads also in UTF-8 in the future? Greetings, Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: WYSIWYG Reality Check: It Ain�t Working
Petko Yotov wrote: [...] >The WYSIWYG feature is very much requested and if it is done well, it may* >break the barriers to PmWiki adoption by users unwilling or unable to read the >BasicEditing page from the documentation or even the cheatsheet under the >editing text area. It is on my todo list, but without contract deadlines, as >we spoke earlier. "users unwilling or unable" is an apt description of the problem. I've seen such users (but can't say whether they are unwilling or whether it's really a hard for them). Luckily, most other users _are_ able to use Wiki markup, and after a kind reminder, they are even able to use "Preview" instead of "Save". >That doesn't mean that nobody else could work on an implementation. > >Other features, often requested and arguably very useful are UTF-8 migration + >RTL support + encode filenames, multiple file uploads, image manager (rotate, >rename, edit metadata), section editing, table of contents, PDF generation, >zip export, easier user watchlists, admin interface, notify on upload, ... >review and update the doc translation in French, ... ..."self registering"... >Some existing recipes already provide some of these functions, but only work >in some cases, or do much more than what is really needed. For example, a PDF e.g. the current "attachtable" version with image metadata handling got a bit extensive. I would love to see a stripped version. Oliver -- Oliver Betz, Muenchen (oliverbetz.de) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] WYSIWYG Reality Check: It Ainât Working
Why not to place some advertisement about WYSIWYGFundDrive on the PmWiki.org, so that everyone could see it? Finar. 2011/5/22 Petko Yotov <5...@5ko.fr> > On Saturday 21 May 2011 21:35:15 Al Louis Ripskis wrote: > > On May 21, 2011 3:03 Petko Yotov wrote: > > >Note that a WYSIWYG editor may eventually be written anyways and you > won't > > >have to pay. > > > > Petko, can you give us the details on the above? > > By "may eventually be written" what do you mean? > > "May" : http://en.wiktionary.org/wiki/may > To have permission to, be allowed. > Expressing a present possibility; possibly. > Expressing a wish. > > "Eventually" : http://en.wiktionary.org/wiki/eventually > In the end, at last, finally, yet, ultimately. > > > What time frame are we talking about? In weeks? A couple of months? > > And who will write it? > > I don't have this information now (please don't ask me when I will have > it). > > The WYSIWYG feature is very much requested and if it is done well, it may* > break the barriers to PmWiki adoption by users unwilling or unable to read > the > BasicEditing page from the documentation or even the cheatsheet under the > editing text area. It is on my todo list, but without contract deadlines, > as > we spoke earlier. > > That doesn't mean that nobody else could work on an implementation. > > Other features, often requested and arguably very useful are UTF-8 > migration + > RTL support + encode filenames, multiple file uploads, image manager > (rotate, > rename, edit metadata), section editing, table of contents, PDF generation, > zip export, easier user watchlists, admin interface, notify on upload, ... > review and update the doc translation in French, ... > > Some existing recipes already provide some of these functions, but only > work > in some cases, or do much more than what is really needed. For example, a > PDF > generator able to work with UTF-8 and with languages not based on the Latin > alphabet might be useful. > > 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
