These Question/Answer pairs may be moved to the FAQ page.
This page is for Question/Answer pairs. If you want to post a question, please use the Questions page.
In the future it would be possible to see some plug-ins that will export a wiki document in a different format, like: man pages, pdf, latex, simple html.
I saw a project that might be interesting for this, it is called txt2tags.
Yes it's possible. Check the Cookbook:HomePage. If you're a coder, maybe you can develop the plug-in.
I've begun a markup for txt2tags: http://www.pmwiki.org/wiki/Cookbook/Txt2tags but it's maybe the opposite of what you want, it only allows to use the txt2tags markup instead of the pmwiki markup in your wiki pages.
Why when writing pmwiki did you decide to put much of the code, if not all, in pmwiki.php?
There is virtually little white space and comments. I want to easily edit it, but it is proving to be a headache.
Yes -- I get headaches understanding the code too.
Take it slowly. First, there are a LOT of modules under scripts/ that are probably the keys to whatever you are looking for. I don't read the code from pmwiki.php out. I suggest that if you want to analyze edit functionality, then find the module that supports that function. Then filesystem text searching through the code (recursive greps with line numbers) can be the key to find function definitions.
In the Cookbook modules I (XES) wrote, I was careful to comment the code. It took me a while but by analyzing the rss.php module to make my Cookbook:RssImproved module, I have caught on to a lot of the code habits in the main body. It took a lot of cursing PM out, pacing, and banging my head -- but I did it.
Major headache: SDV($variable,"value"); -- Set Default Value (or that's how I think of it) -- PmWiki allows setting nearly every variable from config.php. So before PmWiki or it's modules can set a value, they have to check whether it was already set. This function checks if a variable is set -- if not, it applies the value to it.
I had to find where that was defined to figure it out. Painful :)
Watch out for important variables with nonsense names like $t or $u for something like a timestamp or uptime (and consider it luck if the initial variable matches what it stands for). I do a careful global search&replace on them when I figure out what they are -- this way the rest of the code becomes so much easier to read.
I think PM codes much faster than he can comment
Is there a statistic tool for PmWiki
What type of statistics are you referring to?
Most website statistics software should work, but is independent of PmWiki.
If you know what you want, though, it might be easy to "cook up".
2) I cannot tell which statistics the author referred to, but I can tell that I would like a tool that would
I am certain that a lot of these are already built in to the system, but with my non-existant PHP abilities I have not been able to find them.
Is there a sectioning plugin which makes it possible to segment a page into several sections with their own edit button?
This feature exists in dokuwiki and is described wiki:section_editing | here. It's a nice feature...
I've had a load of spam links appear on the Edit page on my wiki at http://www.petty.me.uk/pmwiki/pmwiki.php.
How can I get rid of it? I can't seem to find where these links would be. Are they in a PHP file? Or in one of my wiki entries? -- MatthewPetty?
I realise I need to fix the passwords, I'm in the process of doing that.
They're here: http://www.petty.me.uk/pmwiki/pmwiki.php?n=PmWiki/EditQuickReference. Scroll down on that page to see them. Use history and restore. -- TeganDowling
Thank you Tegan, that's fixed it. I didn't know the Quick Reference was a wiki page (but it's obvious now!). The moral of the story is - set an admin password as soon as you can. Secure your pages first, then open them up bit by bit. -- MatthewPetty?
You're very welcome - that Edit Quick Reference page is kind of neat (note that there have been some changes to it, here on PmWiki, recently). BUT I think the moral of the story is that you should be going to your Main.AllRecentChanges every single time you log on (if not even more often). It's your site, and you should know everything that happens on it. -- TeganDowling
See also Security.
How does my PmWiki site get logged by the search engines, can they see the content within? I noticed that google has seemed to lose my site in the search findings ever since I went from HTML to a PmWiki site. What can I do to get back my rankings?
A: Normally PmWiki pages are scanned by search engines -- same as any other pages. As an example, do a search for "PmWiki" and see just how many PmWiki pages have been indexed by Google. Also, don't forget that Google's re-indexing isn't instantaneous -- it may take several weeks before the Googlebot gets around to re-indexing your site and finding the new content at its new location. (Also, make sure you don't have a robots.txt file that is turning the search engines away.) --Pm
Google also likes site maps(approve links), make sure you create one for your PmWiki web site.
How to markup external links like Wikipedia does?
It would be nice for some applications (at least mine ;-)) to show READERS (unfortunately the majority in most Wiki-installations): this link is an external one. Similar as the question mark shows empty internal links. Maybe, there's already a function implemented. If not, I can try to write such a markup with my limited PHP 4 experiences. --Armin
Made it. Changed a function inside pmwiki.php (I know, not a nice way). Results can be seen at: http://www2.100mb4free.de/sonja/pmwiki/pmwiki.php?n=Blg.Main (well, in German, but easy to understand what I mean). I can post the source if there is any interest. --Armin
Its better to do it in the "Wiki way". Define your own
$UrlLinkFmt = " <a class='urllink' target='_blank' title='\$LinkUrl' rel='nofollow' href='\$LinkUrl'>\$LinkText <img src='$PubDirUrl/external.png' alt='External Link to \$LinkUrl' title='External Link to \$LinkUrl' border='0' /></a>";
put your wanted external link-icon in the
Armin, how did you manage to get the Google adwork running on a wiki page. I tried that before but don't know where to add the Google code. Thanks, Oliver
I guess, I've added the Google Adsense lines to the .tmpl file, for the skin I'm using. Have to check source code at home.Armin
My wiki has been up and running for a month now. I'm really happy with it. Except I have a problem with search engines, Google in particular. It's not indexing it.
Things I've done differently: I changed pmwiki.php to index.php because it only made sense for me to do so. Was that wrong? Also, I have a edit protected site. so you can't edit w/o the password. Any of these things limiting me? do I need to verify some directory permissions or something? Both of my straight pmwiki sites are non-googled. smick.net japancouncil.org.
Keep in mind that Google sometimes takes a month or more before it will crawl a site. If you can check your site's access logs, see if you've been visited by the GoogleBot at all. Even after GoogleBot visits, it may be a couple of weeks before Google updates its indexes on its public sites.
How can I change the name of the months when using $[$CurrentTime], because my page is in Portuguese and it is displaying the month in English. What can I do?
C:yes I have seen it all and even the PmWikiPtBr page displays the months in English.
Final A: I have just changed the locale value on the XLPage from pt to pt_BR and $[$CurrentTime] displays the months in Brazilian Portuguese. :) Carlos AlbertoBonamigo
I have done the same in the Catalan page, but it still shows the months in English. I've seen it correctly displayed in the Catalan language pages of this site, so wtf?
I love PmWiki and am using it for an English and Japanese bilingual site. I want to keep the function labels in English but edit in both languages.
I changed the setting in config.php to use the Shift_JIS character set. Editing is working fine in Japanese but I can't get the double bracket function to create Japanese page titles. They show up as gibberish on the edit page. Any ideas?
Hi, we need to collaborate, I'm doing the same thing, using Japanese and English, only I'm trying to enable UTF-8 on my site. It's more up to date than Shift_Jis from what I've read.
Fancy that, I'm working on a Japanese site too! It's not ready yet, but UTF-8 support seems to be the ideal (and the only) solution for Japanese in pmwiki.
Bonjour I am working on english, french, chinese and japanese one... What I need is; when reader clic on chinese or french a corresponding blanc page appear if there is nothing or the corresponding translation already made. Like I was cliquing on chinese of this page it would be an internationalise chinese blank page appearing if nothing was translate.
Is there a way to change the character encoding to UTF-8?
I know there is discussion in this FAQ, but it's not clear. My .tmpl file is UTF-8. But the page will not default to it, and the pages I have some Japanese on are displaying gibberish by default, until you manually change the browsers character encoding. This is kind of frustrating for some of my users as they aren't very savvy to do that kind of thing.
Download the internationalizations code, then add the line
I have just recently upgraded my php version to 5.0.2 and now the wiki is broken with error message: Fatal error: Call to undefined function preg_replace() in /usr/home/tomtux/public_html/pmwiki/pmwiki.php on line 82.
I am not too savvy with the php and figured you just need to define that function to work but I do not know how I searched google for some answers but came up with nothing. --tomtux
preg_replace() is one of those "basic" functions that is supposed to be available in every version of PHP. It's totally bizarre that your 5.0.2 doesn't have it -- do you have any details of how PHP was upgraded...? Contact pmichaud [snail] pobox [period] com for more assistance on this one... --Pm
I had figured it out after doing more research, since the box was freebsd and by default when you install php from the port section it does not include php-extensions, so once I installed php-extension package from the freebsd ports, it is working now. --tomtux
Are you planning adding something like a captcha to prevent bots from spamming non-password protected wiki sites?
Actually, adding "UrlApprovals" seems to have largely resolved the spamming problem, at least on pmwiki.org. The next step for PmWiki will be to add user-based authorization capabilities (PITS:00010), and then if we still need it we might look into a captcha-like system. But this would add slightly to PmWiki's base system requirements and I'd prefer to avoid that. --Pm
Why utf-8 is not used for all pages. I really liked the idea of mulltilanguage without changing the group.name or opening a new group.name .
(Cookbook:MultiLanguage) - Carlos Alberto Bonamigo? (Maybe it is related with the following bugs PITS:00035 and also PITS:00011)
Maybe it is somehow connected to the issue I've described below (at the bottom of this page)? --CleverFool
The basic issue is that regular expression support for utf-8 is still not completely available in PHP. See PITS:00168. --Pm
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?
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.)
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!
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?
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é
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é
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
PmWiki is cool and easy. But how can i achieve that when i upload a file, the Attach:xy.file Link is automatically created in the page i am Uploading to ? --Adrian
Try this solution: it uses the Cookbook:Attachtable recipe which you will need to install. Then add the directive