[pmwiki-users] The Philosophy of PmWiki: adding to the core

Simon nzskiwi at gmail.com
Tue Nov 5 18:07:15 CST 2013


reflecting on your reply I apologise for my very poor choice of words.

in no way did I mean to in any way diminish or be critical of the fantastic
job you have done on PmWiki,
you have in every way continued to keep the PmWiki platform current,
address security issues, fix bugs, etc as you list below and more (eg
ThumbList <http://www.pmwiki.org/wiki/Cookbook/ThumbList>,
and other recipes),
and exceed expectations in every way when it comes to supporting the
community, being accessible, and being responsive.
I wish there was some way I could help more to spread the load. Personally
I have to acknowledge the hugely appreciated assistance you have given me
over the years.

It seems almost churlish, then, to continue to discuss my seeming minor
I maintain 5 PmWiki sites, 3 for separate community sites, another for an
internal organisation wide wiki (approx 3,000 staff), and my own personal
These are all hosted separately, and therefore maintained separately.

I do not advocate developing an automated add-in manager, we have Site
Analyse <http://www.pmwiki.org/wiki/PmWiki/SiteAnalyzer>r to check which
recipes are up to date, this to my mind would be the bloatware we a proud
PmWiki isn't, and to be frank I would prioritise many other PITS entries

When it comes to voting on PmWiki for PITS entries, or registering as a
user of recipes, I think that only a minority of PmWiki enthusiasts
contribute in this area.
I for one, don't create PITS entries trivially, or for what I consider to
be gratuitous features, readers are welcome to browse
PITS entries I have contributed over the years and be the judge.
I create PITS entries where I have had an authoring problem, or a display
problem, that I think could be addressed usefully within PmWiki, and would
benefit everyone.
Creating a PITS entry takes research, testing and work. Therefore I respect
PmWiki users who are motivated enough to make constructive suggestions for
PmWiki features and improvements.

Having said that I would still like to see some PITS entries and minor
feature requests be taken up.

Petko, all power to your keyboard, and thanks again for the work you do



On 4 November 2013 02:05, Petko Yotov <5ko at 5ko.fr> wrote:

> Simon writes:
>> My concern is that if PmWiki is 'all recipes' and 'no improvements' it
>> leads
> I'd prefer using the correct words. You use 'no improvements' when you
> mean 'not adding additional features that have had about a single vote in 4
> years'.
> I'd like to imagine that PmWiki has somewhat improved during the years -
> it works with newer PHP versions, many bugs were fixed, including critical
> security vulnerabilities, internationalization support and tracking changes
> are better now.
> It is also easier to find active recipes, thanks to the *-Users and *-Talk
> pages. Even the new recipe template is better.
>  to a 'balkanisation' by recipe of PmWiki (and some recipes themselves are
>> balkanised - which to use?), that is to say that while my wiki(s) might use
>> a number of these great recipes, other don't, and writers can't reply on
>> the same markup or features across different PmWikis. Consistency and
>> completeness (orthogonality) have a place.
> If you cannot use a farmconfig.php file with all your local customization,
> for all your wiki fields, you can create a file with the features you need
> and include it from config.php. I use a file named francais.php which is
> included in the French language wikis I maintain.
>  Now personally I don't use C2 wiki, or Usemod engines, because they don't
>> have 'enough' features. PmWiki fits for me in the sweet spot, good
>> features, easy to install, extremely responsive developers, doesn't try to
>> be to much or all things to all people.
> Yes, and when in almost 10 years of PmWiki usage others and I never needed
> some feature, I'd be happy if PmWiki doesn't add it and try to be all
> things to all people. If PmWiki is lacking some function or hook to allow a
> recipe to enable that feature, we will add the function or hook, so that
> the people who need the feature can add it.
> There are wiki admins here who deactivate some core features they don't
> need.
>  But I'd like to see the core PmWiki improving too.
> It probably is. But we may have to disagree on what "improving" means.
>  As an administrator of several wikis I'd like to see more 'out of the
>> box',
>> We don't have any way of installing recipes automatically (think app
>> store), so both an ongoing maintenance effort is required and quite some
>> knowledge of Pmwiki is required to carry out such customisations and recipe
>> installs.
> Installing recipes automatically, if not done properly, can introduce
> security vulnerabilities. So, someone has to write the app store, decide
> how it works and how one can enable and configure the 'apps' (per wiki, per
> group or per page?), debug it, publish it, debug it, support it.
> Are there any obstacles in the current PmWiki core that stand in the way
> of, or hold up the writing of an appstore by someone? I'll fix them ASAP.
> Petko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20131106/e16a8909/attachment-0001.html>

More information about the pmwiki-users mailing list