01412: PmWiki.org integrated developer platform

Summary: PmWiki.org integrated developer platform
Created: 2017-06-18 12:00
Status: Discussion
Category: Other
From: Sven
Priority: 1
Version: next
OS: all


Sven: Looks like PmWiki is still maintained in SVN. Is this still comfortable? I ask this of infrequent developers as well. I haven't worked with the source much in the last years but I'd imagine that if I were to start again, setting up SVN compatibility for my git would be my first hurdle and an annoying one. I found a total of two mentions of git in the devel mailing list archives, one of them relevant, but maybe the time wasn't right yet, three years ago.
For a moment I considered whether I should join the devel ML and ask there, but that's too tedious for my spoiled modern-day tastes, being used to near-daily Github/ Bitbucket/ GitLab use with code, discussion and issue tracker all on the same platform, with an option for easy WWW browser access. Looking at the devel ML's activity makes me feel exculpated for being too lazy to configure a new mailbox for the ML and joining it, so how about switching to a more integrated platform as well?
Sven June 18, 2017, at 12:07 PM

Update: Added "Browse the source online". I think this should also be on the Download page but I can't edit that one. Also the PITS needs Summary in its page titles, then my Firefox could have offered this ticket when I typed "SVN comfor" in its location bar. Sven June 18, 2017, at 12:50 PM

The link you added appears to have been last synced 2+ years ago. If you cannot update that repository ASAP, I wouldn't recommend people using that code, there have been critical vulnerabilities fixed in the mean time. --Petko June 18, 2017, at 03:17 PM

Using PmWiki for coordination/issue tracking is "The Wiki Way" (we eat our own dogfood). It *is* an integrated platform, you can have watch lists, you can be notified by e-mail or RSS or in the wiki itself for the changes, there are Talk pages for questions and for improving the documentation, you can vote in the PITS and on the Cookbook, the documentation is right here easy to fix/update, and PITS and Test groups are here so you can demonstrate any problem in the wiki itself. Github cannot compete with that kind of integration. OTOH, contributing with code is more difficult, as until now Pm preferred every commit to be done/reviewed by himself or by me. If this changes a migration to GitHub (or to a local Git repo) may be contemplated. --Petko June 18, 2017, at 03:17 PM

Sven: Well ok, considering all those features it seems the wiki way can work nice enough, it's just not yet as easy to discover all the possibilities. Maybe I'll try and help with that if I ever get really bored with too much spare time. ;-) In that spirit, I won't revert the link to where it first pointed (another copy that was just 3 days old but harder to clone), and instead try to fix the problem of browsing code via WWW right here on our integrated development platform. WebSVN looks nice in their demo, written in PHP (as far as I can tell) and is licensed as GPL v2, so how about giving that one a try? Sven June 18, 2017, at 05:47 PM

Good idea, let me think about it. --Petko June 19, 2017, at 10:03 AM

Sven: I tried to fix the UI problem of too hard to find PITS tickets via browser history, by putting a conditional title command in the PITS.GroupHeader. However, it seems to have no effect. :-( Could you have a look what I missed? Sven June 22, 2017, at 07:49 PM

Thanks for fixing it! :-) Sven June 23, 2017, at 04:09 AM

I discovered the new version input button in the PITS form. Looks like it wasn't easily feasible to automate the version comparison?

No, I just felt lazy, but your enthusiasm is contagious so I'll do it tomorrow. :-) --Petko June 23, 2017, at 05:54 PM

Sven: If we need the human reporter to compare versions visually, here's my suggestion for that part of the form: Display the correct numbers lined up perfectly below the user input. Use a text input with transparent border to achieve that with minimal browser assumptions. Make space between the numbers and the input's side borders to distract the eyes even less. (I like to center numbers in cases like this.) Include a concise version of the upgrade hint in the form area to reach those parts of audience that tend to assume that long text above the form is just usual introduction for people who've rarely used a bug tracker before.
I've made you a demo example in Test.PitsFormCheckVersionInput, even with CSS form validation for immediate feedback.
The version button in its current form wouldn't have reminded me to upgrade, but instead would have tempted me to report a wrong version, since I was convinced by a VCS misconfiguration that my checked-out (old) version was the latest release. That's why in my demo I avoid showing users the numbers at all, if their guess can be verified as just "correct" or "wrong".
Sven June 23, 2017, at 05:15 PM

Indeed, it is better to let people type their version by themselves. I added a small JS function (instead of tortured CSS) to sanitize the reported version, compare it with the latest one and display a message if they differ. See NewIssue and Cookbook:PITS. If the person has disabled JS, we can always tell her when the version is old. Thanks for the idea and for the efforts, much appreciated. --Petko June 24, 2017, at 06:32 AM

Sven: Today I read about the notifications, and it seems I'd need to create a page trail for the set of pages that I want to watch. I wouldn't want to clutter my Profile page with it, so how about we copy another feature of GitHub: A dedicated stuff storage for each dev? I couldn't find anything about this in the FAQ, so how about we introduce a "Using PmWiki.org as an integrated dev platform" section there, and use it to invite people to store their profile-related auxiliary pages in group "User{$Author}"?
We could even introduuce a simple form of self-registration by making the attr password default to some known default for not-yet-created User*.GroupAttributes, then whoever takes one of these groups has registered. (For a transition period we'd need some admin supervision against impostering already-in-use Author names.) Such a group could also be a starting point for simple credentials recovery, like storing a list of trusted exclusive abilities in User{$Author}.AccountKeys. Exclusive abilities could be stuff like "enter a cleartext that (:encrypt:)s to $2y$10$birDFMKOnqpKSXw4yO6i", "read e-mail to this address", "sign a challenge with a private key matching this public SSH key".
PS: I'm working on a self-reg system like this for one of my next wikis, so if the only hurdle is implementation effort, it's just a matter of time. :-) — Sven June 27, 2017, at 11:55 AM

I'll implement something to request passwords for known people to prevent impostering -- it already does this for Pm and for me, but I'll have to make it more scalable. (See also Cookbook:UserAdmin which may be of some use for you.) About uncluttering your watchlist trail, you could hide it with conditional markup, or place it in an external page like Profiles.Sven-Watchlist?. About personal pages, there is no problem to create a new group, see DaveG.RecentChanges or like in Wikipedia, add a page like Profiles.Sven-Sandbox4?. --Petko July 03, 2017, at 04:16 PM

Naïve question, but why not use stuff like AuthUser and HtpasswdForm? This is what I'm using on my own sites and I'm wondering if there's some flaw you guys see in it. sroracle? July 03, 2017, at 05:43 PM

No flaw, just different needs, so some writing to do. We want editing pmwiki.org to remain open and unrestricted for anyone, like now. But regular users should be able to "protect" their usernames, so when someone posts, we know s/he is the person we know, not a new user. This is different from AuthUser (and other recipes that rely on it) which enforce user:pass authentication but work great in other contexts. --Petko July 03, 2017, at 05:55 PM

Indeed, we could just use HtpasswdForm as interface. --Petko July 03, 2017, at 06:00 PM

The way my AuthUser is setup is the "author" is always the username of whoever's logged in. Couldn't you just remove this part (if I recall correctly it's not even part of AuthUser, just a config.php snippet) and allow anonymous editors to set the author field themselves, but throw an error if the author already exists (i.e. is registered under AuthUser - probably would only take another such config.php snippet)? sroracle? July 03, 2017, at 06:03 PM

Sven: I've seen the hyphenated subpages in the Profiles group, and they boost the number of "authors" on Profiles.HomePage. ;-) I tried to create UserSven.UserSven but it looks like I'd need a password to edit that page. – Sven July 18, 2017, at 09:35 PM

I've created the group. E-mail me to get the shared password most of us know. --Petko July 18, 2017, at 11:22 PM

Sven: We need more context in diffs. Example of a diff that gives no clue what really happened..
Sven August 05, 2017, at 01:49 PM

On that diff, two lines were permuted/swapped. I agree it will be better to have some context, I'm not sure it is easy to do. If implemented, only newer changes will have more context. --Petko August 07, 2017, at 04:41 PM

Source code extracts instead of WebSVN

From Sven's request to easily display source code snippets from the core, I've written Cookbook:ZCode and enabled it on the PITS group.

(:zcode 2.2.102:pmwiki.php@438..440:)

(:zcode 2.2.102:pmwiki.php@438..440:)

See Cookbook:ZCode for full documentation. --Petko August 11, 2017, at 07:43 PM

Glad I stumbled on this conversation. Is this what prompted the diff highlighting in PmWiki? I love the ZCode markup. Sven, my profile page XES shows how I integrated my "watchlist" (as "Pages I'm interested in") without hiding it, but a simple (:if false:) would hide it from the world without it showing up in HTML. And if you really want to hide it completely, perhaps it would be smart to implement (maybe even site-wide) ?action=attr that covers diff/source hiding as well? This is definitely 1 possible vulnerability for some pages, but on PmWiki.org we should probably have the ability to hide diff/source on our Profile pages…

A super-easy per-known-user auth mechanism? We can edit password our own Profile/User page, and PmWiki can check whether someone has the rights to edit the Profile/$Author page as an auth mechanism. If the page has no edit password, then obviously the name is up for grabs. If the user's profile is edit-protected, then the rights to edit-as-them = it's them. XES September 30, 2017, at 08:21 AM

No to the first question, "word level diff highlighting" has been available in the core for several years; this conversation here inspired the ZCode addon. About profile pages as password storage, I'd prefer to test the "attr" password rather than the "edit" password: some people don't mind to have their profiles either open for editing or protected with a shared password. I need to think about integrating this with AuthUser or not, also maybe have a way for people to recover their forgotten passwords (without my intervention). --Petko October 13, 2017, at 03:02 AM