Design choice

> I regret
> all history and metadata are kept in the same files in pmwiki, I
> also guess it might impact a bit the performance if it loads the
> whole data when reading the content of the files, but I may be wrong
> on this point.

Data and history data in PmWiki's files are always stored 
most-recent-first, so PmWiki almost never has to read the entire
data file except when editing a page or displaying history.
When simply reading or scanning a page, PmWiki will stop reading
the file as soon as the first history entry is found.

Storing data and metadata in a single file was a very conscious 
design choice in PmWiki -- I wanted pages to be well encapsulated
and didn't want to ever have to worry about them getting out-of-sync.
Keeping them separate is also a perfectly valid design choice; for
my needs it just made much more sense to keep it all together.

> I also regret line breaks and such are mangled in pmwiki, which
> means you can't easily edit your data from outside a web browser,

I agree a fair bit on this point -- there are many times that I
wish for a plainer-text version of the files.  That's actually
quite pluggable, however; we could certainly have a module that
stores the files in a more plaintext form.  But there's also a
very strong issue of security at play -- part of the advantage
of PmWiki's encoding is that it also limits a variety of attack

Message from Pm at the mailing list. [1]

File extensions

I am trying to use a php replace tool, but it requires a file mask to identify the file; .htm, etc. Are pmwiki page files of any particular type? What would the file extension be? Jagtig.

The files are named Groupname.Pagename, there is no extension, or a tool could consider the extension to be .Pagename which changes for each page, eg. the file containing this page would be named pmwiki/wiki.d/PmWiki.PageFileFormat-Talk. --Petko November 02, 2011, at 09:19 AM


I had a bunch of pages incorrectly attributed to the PmWiki group in my instance, so being the admin I decided it would be easier to take care of this via the "backdoor". I changed the name of a bunch of files to the new group from the old, and everything seemed to work fine. I used VI to peer inside and noticed that the "name" attribute was equal to the old filenames. BE CAREFUL if you choose to edit pmwiki page content files in an editor like VI. You can lose all of your content so make sure to back everything up first! (I did)Most of my resaved files were fine, but files that had "line too long" issues in VI, clobbered all content. I did some further research and discovered that pmwiki will actually change the internal name file attributes if you just go into each page thru the pmwiki interface and Save them. No changes are necessary and the name attributes correct themselves once saved. --JJ

Perl snippet to pmwik-ize text:

    sub wikiize_text {
        my $t = shift @_;

        $t =~ s/%/%25/g;
        $t =~ s/\</%3c/g;
        $t =~ s/\n/%0a/g;
        return $t;
tamouse October 22, 2011, at 04:53 PM

Likely the page should mention ReadPage() and $page[] -- it's too hard to find on a search as a developer, so the background on how these variables can be accessed for config.php or recipes isn't on this page or cross-linked to info on ReadPage() (which maybe should have its own page, but that's us.). XES October 21, 2020, at 10:14 AM

This is a talk page for improving PmWiki.PageFileFormat.