view · edit · attach · print · history

Do PmWiki 2 supports users like PmWiki 1 supported it using UserAuth??


Why utf-8 is not used for all pages. I really liked the idea of mulltilanguage without changing the or opening a new . (Cookbook.MultiLanguage) - Carlos Alberto Bonamigo (Maybe it is related with the following bugs PITS:00035 and also PITS:00011)

C:Maybe it is somehow connected to the issue I've described below (at the bottom of this page)? --CleverFool

A: The basic issue is that regular expression support for utf-8 is still not completely available in PHP. See PITS:00168. --Pm

A: See also UTF8.UTF8?. --Pm

How can I display a html file from the same folder that pmwiki is installed , inside (i.e.) a PmWiki.HomePage wiki page file?

A: By default this isn't supported, because it poses a few security risks. But a cookbook recipe could be developed to support it. (See Cookbook:IncludeUrl for one example.) (and also the included markup.)

How can I place a mailing address in a page?

A: Use the mailto: markup, as in

How can I make a WikiWord link to an external page instead of a WikiPage?

A: Use either [[ | WikiWord]] or [[WikiWord ->]].

Is there a PmWiki-Forum, where I can ask queations like this: Is there a list of WebHosts about successful PmWiki-Installations? My experience with different WebHosts: 90 % of PmWiki installations failed!

I've to admit: all these installations failed due to no PHP support from webhost. If your car needs gas, you can't drive without it!

A: Let's just create one at WebHosts. And I'm very interested to know which installations failed and why. --Pm

C: O.k. I'll be there in more detail. But the major issue I can already disclose here: permission setting problems caused failed installations. --Armin

I have used one of the recent pmwiki 1 versions to create russian-language wiki site. I've specified UTF-8 as encoding for pmwiki and installation worked with cyrillic characters quite well, except for words with russian symbols was not recognized as WikiWords or FreeLinks (like this ВикиСлово and like this ). I've swithced encoding to Windows-1251 (Cp1251). It's fixed all language-related problems for Gecko (Mozilla) based web-browsers. However links to such pages weren't working in Interner Explorer (which is still often used everywhere:)). I've go a lot of fun trying to solve this issue and finished by adding code to pmwiki.php which URLEncodes and URLDecodes all links. This helped. I'm coming closer to my question:) Now I'm thinking if I need to upgrade to pmwiki 2. The question is: Is something changed in language-specific code in pmwiki 2 or it is still needed to hack pmwiki before using with russian language?


A: PmWiki 2 urlencodes its links (even PmWiki 1 is doing this to some extent). And also take a look at UTF8.UTF8? to see what's being done with utf8 characters in link names. --Pm?

I understand that PmWiki is designed for fast edit and fast saves; my question is: what about *rendering*?

I am a real newcomer as concerns wikis, I just tried a simple one (Wikini, too simple for me) and a "complicated" one (MediaWiki), and I clearly see a difference in reactivity: Mediawiki is far slower on the host I use. Thus, I'd like to know how fast PmWiki is at rendering, and specially, wether the fact its database is ascii-based is a help or a crawl in this area, compared to SQL which both wikini and mediawiki are using. I fear I can't really assess this with empty databases just by installing PmWiki... Hervé

A: Well, PmWiki comes with a complete set of documentation when you install it, so this would give you some idea of its rendering speed. And really the choice of saving the markup (ASCII) data in flat files versus SQL isn't a major speed differentiator (see FlatFileAdvantages)-- the real question is how quickly the engine can convert the markup text into HTML, and if the rendered text can be preprocessed or otherwise cached so that it doesn't have to be reprocessed at each page access. At present PmWiki doesn't do much in the way of caching or preprocessing rendered output (although we're working on it), but PmWiki is still reasonably quick given all that it does. Pm has placed timers in the code to evaluate it, and so far all page renderings observed, even for complex pages such as PITS:PITS, use less than 0.75 seconds of user-space CPU time, with most pages being processed in 0.25 seconds or less. --Pm?

FlatFileAdvantages indeed convinced me ;-) Thanks, too, for the very quick reaction -- Hervé

Default passwords in PmWiki 2.0.beta7?

My actual PmWiki installation is running quite well, except the problems I have changing passwords. I tried ?action=attr and always I get a password request, where I use an asterisk (guess I found it in config.php) and also 'mysecret' all failed. What's wrong in my installation or is there just another default password for the admin? --Armin

A: The default password is locked for Main, PmWiki, and the admin password until explicitly set. You'll first want to set an admin password in config.php (see PasswordsAdmin), and then you can use that password to begin setting other passwords. --Pm?

C: Thanks for your quick response (as you always do). But sorry, I'll keep you busy:

How's about a graphic oriented editing interface like wikipedia_firefox?

I found this in the web:

Looks quite nice.


A: found today the answer: Cookbook.EditBar?

Why not to document programming API's? and all those fancy calls like PZZ()? and SDV()?? This would help building extensions a much!


A: It's simply a matter of available time -- writing documentation takes a long time. I need to finish writing the basic PmWiki documentation first (see PITS:00122) and then I can work on documenting PmWiki's APIs. --Pm?

Which variables/functions do i need to set, in order to display dynamic content on a page, for example a contact-form. Thinking of a syntax like (:myscript mail:)?

For some layout-modifications on my site i needed to change background-images on different sites. Therefore i raped the "Attach:"-markup:

e.g. bgimage:flowers.jpg (within the page) and following script in my included bgimage.php.

 $BGImage = "bg_white.jpg"; ##standard-background-image

 function getit($pagename,$imap,$path){
	global $BGImage;
	$BGImage = $path;

... i don´t think thats very clean, but it works. that way i can change some environmental variables, but i also need to output dynamic content on the wikipage. - Please help!


view · edit · attach · print · history
Page last modified on December 21, 2004, at 05:34 PM