• View
• Edit
• History
• Print
• Backlinks

PmWikiPhilosophy-Talk

This is a talk page for improving PmWikiPhilosophy.

There are two additional principles that should be taken into account in the design of PmWiki. These strongly support the PmWiki Philosophy #1 so that a writer can expect PmWiki to support their use with orthogonal and economy of markup, and the writer's experience with related technologies such as PHP, HTML, CSS, Javascript produces expected results where facets of these are exposed in PmWiki markup, templates, styles, and where possible recipes.

1. Principle of least surprise

The outcome of using PmWiki markup or features should be be one that is expected from previous usage and experience of similar occurrences in PmWiki, other wikis, or more generally.

• Wikipedia: Principle of least astonishment
• Applying the Rule of Least Surprise
• Rule of Least Surprise: In interface design, always do the least surprising thing
• Wiki: Principle Of Least Astonishment

2. Consistency

Where a feature markup is implemented in several places it should be consistent in both is syntax (the way it is expressed), its semantics (the way its expression in interpreted), and its outcome (what it does). The means it is easier to learn, and easier to use. This principle strongly supports the Principle of least surprise.

PmWiki seems to be founded on a faulty premise, that of making core as simple as possible and relying on cookbooks, especially user created and maintained cookbooks, to provide additional functionality. The fact is that as this mountain of user generated content has grown, they inevitably have not been kept up to date with core upgrades (this happens with all software that allows optional user generated features... is the creator of a simple cookbook expected to maintain it in perpetuity?) and have thus been broken along the way. Maintainers of PmWiki core have kept certain cookbooks (likely the ones they use) compatible with current PmWiki, or even adopted them into core, but those they have not maintained have been broken by the core upgrades. The way forward I feel is to never make breaking changes (that includes php updates or moving functions to different files) in a core version ie: 2.2.xxx. This way we know for sure that a cookbook made for a certain version will reliably work with any revision in that version, and that if you want to use that cookbook you have to use a revision within that 'last supported version'. This would get us closer to becoming reliable software imo --Naturevault October 27, 2022, at 08:59 PM

While you are correct many people don't maintain their recipes, you are completely wrong to blame this on the PmWiki core philosophy, design, implementation or updates. The recipes (and the core) break because the PHP programming language often deprecates or removes features that were working in the past. The core works both in old and in new PHP versions, and both with old and with new recipes. The amount of effort to keep the core working both in the latest PHP versions and in older ones, is considerable. Even very old recipes will work with the latest PmWiki version, on an older, compatible PHP version. If the PmWiki core rarely introduces API changes, I document them and I am always available to people who need help upgrading. So no, the PmWiki philosophy and the core updates have not broken any recipes -- the PHP philosophy and updates have done so. --Petko October 27, 2022, at 09:26 PM

It certainly is a problem with PmWiki philosophy when people select PmWiki based on cookbook features that they have no idea will inevitably break in future versions. Like I said, a significant improvement will be made when the core developers agree to never make breaking changes within a version (ie:2.3.xxx). Right now, wiki runners have no idea if upgrading from 2.3.12 to 2.3.13 will break their wiki. --Naturevault October 29, 2022, at 01:17 PM

This is again unfounded, or you need to point out exactly which PmWiki version has introduced breaking changes to which recipes. There are never breaking changes in the PmWiki core without a strong reason, and a simple workaround. PmWiki core developers don't make breaking changes -- this is PmWiki Philosophy #5, "easy to maintain". Please review the pages Release notes and Upgrades for the major core changes.

We have a policy that a PmWiki upgrade should not break existing installations (unless people modify core files) and we are always ready to help admins and authors of plug-ins if that happens: either revert the core changes, set some config variable, or apply some fix on the plug-in. --Petko October 29, 2022, at 01:46 PM

A wiki owner who uses recipes has a responsibility to keep them up to date (see Analyze Results and Recipe Check). Recipes are contributed by community members on an open source basis, for free, and are often updated by their maintainers to work with newer versions of PHP.
Many recipe authors continue to maintain their recipes, some authors have moved on, and some recipes are picked up by the community and have new maintainers. A recipe author is no more obligated to maintain a recipe than the PmWiki core developers are.
Where a recipe is not maintained it may break due to breaking changes in PHP. The wiki owner has a choice to: stop using the recipe; ask the author or community to fix it; pay the author or community to fix it; or if it is valuable to them fix it.
I cannot think of a change to the PmWiki core that has broken a recipe I have used or maintained.
Actually, the core has had a number of widely used recipes added to it (after consultation with the community) in the last few years, check the release notes for details, adding to the workload of the PmWiki core developers (who's only renumeration for their long hours is donations or contracted work).
As a community member, and recipe tinkerer, I would welcome your assistance in supporting the PmWiki community by adopting a PmWiki recipe or three and maintaining them.