• View
• Edit
• History
• Attach
• Print
• Backlinks

EditTemplatesMenu-Talk

Editing wiki.d disk files instead of wiki pages

This recipe looks like exactly what I want (the ability to implement different templates for different locations in the wiki) but I cannot get it to work. I performed the three installation sets as stated and then created some templates for testing. However, when I click on a non-existent link, I get the default message "The page "Fantasy.Raven" doesn't exist. (Create Fantasy.Raven)." This is obviously a step backwards, not what I want at all. I have been through the setup multiple times and cannot figure out what I have done wrong.

Any help would be greatly appreciated. -- ~DougW March 21, 2017 at 13:53 EST

Do you have a translated interface (XLPage)? If so, then the Site.PageNotFound page has another name, eg. PmWikiFr.PageNotFound. If you edit that page, adding something else than the code, (eg. simply "Testing..."), does it appear when a link to an absent page is followed? Doesn't it show at least "Site edit templates"? Do you have any other changes to the PageNotFound page? --Petko March 21, 2017, at 02:45 PM

No to the translated interface. I am using the "out of the box" English files. I edited Site.PageNotFound to change the default message and that was successful, so I feel I am in the correct file.

Question. Step 2 of the instructions state to "Append" the given text to the Site.PageNotFound file, so I did exactly that: I appended it to the bottom (end) of the file. Should it instead replace the existing text? Or go somewhere else in the file? -- ~DougW March 21, 2017 at 7:14PM

You need to edit the "page" via the wiki interface like you edit other pages, do not modify the raw "file" on the disk. Same for the pages in EditTemplates/. Yes, keep the existing text in PageNotFound and insert the new code at the end. --Petko March 21, 2017, at 11:10 PM

And that fixed it. Note to self and other newbies: Use the Wiki interface to edit all pages. Don't edit the pages directly. Thank you! -- ~DougW March 22, 2017 at 7:14AM

Well, here I am four years later and I'm having exactly the same problem described above. Except that, very rarely, the pagelist in Site.PageNotFound has worked to show the list of templates. Then, as magically as it had appeared, the list disappeared again never to come back. I found that in order to bring back the list of templates I must delete and recreate EditTemplates.EditTemplates. This is weird because my pagelist doesn't even use trail=EditTemplates.EditTemplates anymore because the last time the trail stopped working I replaced it with group=EditTemplates name=New*. Like DougW, I made the mistake to edit Site.PageNotFound and EditTemplates.EditTemplates directly in my editor. Can that be the only reason this recipe behaves so temperamentally? And what pmwiki components are likely to break when one carefully edits the text of a page directly? Thank you. SteP 2021-02-10

The "recipe" is nothing but core PmWiki markup, so you probably mean that PmWiki behaves temperamentally. You could edit the disk files carefully, and forget to escape line breaks "\n" like Doug above -- in that case the extra lines are invisible to PmWiki; if you leave any carriage returns "\r", the result is unreliable/undefined depending on the operating system; if you forget to update the timestamp in that file, and/or the wiki.d/.pageindex file (or to remove it and let PmWiki regenerate it), pagelists/searches may not work well; if you edit the disk files on your computer you need to sync them to the live hosting. All the above has happened to me personally, and made me scratch my head. Indeed, if PmWiki cannot find the new content, or the timestamp tells it that it doesn't need to re-index it, I assume doing what it is supposed to do versus what I want it to do may be considered "temperamental". :-) This applies to any PmWiki page, not just this recipe. --Petko February 11, 2021, at 02:00 AM

I've added more prominent notes that the "pages" need to be edited not the disk files. I hope that helps other users. --Petko February 11, 2021, at 02:03 AM

Thank you for your answer. Given that I need to develop pages on my staging server, which procedure would you recommend to sync the changes with the live hosting server? Is ftping the updated wiki.d pages plus removing the live work.d/.pageindex and live work.d/pagelistcache/* enough? SteP 2021-02-11

On PmWiki.org we use a Subversion repository where the core is stored and versioned. I work on my own computer, test on my own Apache+PHP installation and push ("commit") the changes to the repository, then pull ("update") the code running on the website. The Documentation is the other way around -- we all edit it here on the website, and it too gets committed to the repository. For another PmWiki-based website I use rsync in a compartmentalized setting, I tell it which directories to sync and in what direction. For nightly incremental backups I use either rsync or lftp depending on the availability on the hosting. The above are most useful but require an initial work to set them up; I occasionally use Filezilla if the website is not configured for any of the above. --Petko February 12, 2021, at 08:21 AM

Thank you, Petko, your setup is like mine except for the choice of versioning and syncing tools: I use git and an ftp side-by-side file comparison tool. What is still unclear to me is what special steps do you take, if any, after overwriting live files in pmwki.d to ensure that pagelists on the live site will keep working without surprises. Do you overwrite the live pagelist caches and pageindex from your staging copies? Do you delete the live copies of those files after syncing from your staging server? Moreover, from your answer it seems that nobody ever edits the same file both on the live and the staging servers so file history clashes aren't a concern. Do you ever edit an existing documentation page on the staging server? I would guess not. SteP 20210214

Replace on Edit

A useful enhancement would be to allow templates to do a replace-on-load. For example, suppose I have a page called Main.MotherDiscussion, on which I've put a link to create a page called Discussion.Tangent at an anchor named [[#Comment1]]. I want the new page to include the following page text variable: "Context: [[Main.MotherDiscussion#Comment1]]". Each page based on New-Tangent would need a different value for Context, so I can't just use a simple template. It's a shame to ask a user to enter the link with anchor, when this could be done automatically. It would be nice to pass such information via the edit link, for example "?action=edit&template=New-Tangent?Context=%5b%5b{$FullName}%23Comment1%5d%5d", and have the edit form open with the proper value already entered for Context. The only alternative I know is to use PHP to dynamically build the proposed page content (as PITS does) rather than using the more flexible template system.

Is such an enhancement a possiblity? -- RandyB November 24, 2014, at 12:34 PM

It should be possible to enable specific $ROEPatterns for pages/groups other than the templates. This can apply for all edit templates, not just for this recipe. --Petko November 24, 2014, at 01:51 PM

Indeed, that works. Thanks. -- RandyB November 24, 2014, at 02:43 PM

Links open the edit form not the menu

Hello, I've found a bug. When you include links in the sidebar (I'm using the default skin) and click on them it takes you strait to the edit page, not the "choose template" one. Apart from that this is great :). Thankyou for spending the time to make and share it. - Stewart (Stew_822), 2010/8/23 (yy,mm,dd)

Hi. Normally, if you set the variable $LinkPageCreateFmt like it is explained in the recipe, all links to non-existing pages will lead to the "not found - select template menu" page. I just tested it from the sidebar. I think a complex skin might be able to change it, but the default skin doesn't. --Petko August 23, 2010, at 07:33 AM

Hello Petko! So I'm doing something wrong? When you tested it on the sidebar, did what I explain happen? "but the default skin doesn't". You mean it doesn't change where you go, to the templates or editing, right? Anyway, thanks for your quick response. :) (By the way, I'm testing it on localhost) -- Stewart August 24, 2010, at 7:13 AM

No, links in the sidebar to non existing pages show the page "not found - select template menu", and not the edit form. The default skin doesn't change $LinkPageCreateFmt. Have you set the line with $LinkPageCreateFmt like it is explained in the recipe? Did you set it in config.php (for the whole wiki) or in a local Group.php file (for a selected group)? In the second case it may work in the selected group, and not in other groups. Do you have some other recipes or configurations installed? It is possible that a later setting of $LinkPageCreateFmt overrides a previous one. --Petko August 23, 2010, at 04:31 PM

I did set it ($LinkPageCreatFmt), but I set it above another recipe. So I moved it below that recipe, and ta-da! It works. Thankyou very much for all your effort you've put into this! I would never have figure it out! You're awesome! :)