UseMod Wiki: WikiCodeSuggestions

Add suggestions about how UseModWiki is implemented here, and please add suggested features at WikiSuggestions.

question: assuming we confine discussion to coding issues based on the current release of wiki, does refactoring cover every relevant suggestion? if not, what else is there?)

As anywhere else, suggestions are likely to be more welcome when accompanied by willingness to do/share the work. But if you can't do the work, it is probably worth making the suggestion. So I suggest you indicate whether you are making a suggestion alone, or a suggestion plus offer to do/share the work, or suggestion plus demonstration of completed work.

/Config refactor how config is held - suggestion and offer
/Resolved (redirects to WikiCodeSuggestionsResolved)

Please make changes to Editing page template

The editing page is pretty unusable in Emacs W3 mode. While it could certainly be argued that Emacs W3 can be improved, it would be very helpful -- and hopefully have only a very minor impact on what users of other browsers see -- if you could make a few small tweaks in the editing page.

For some reason, the textarea appears smack dab as a continuation of the <hr> element after the GotoBar, and predictably, extends past the right edge of the Emacs window. Could you include a
or something before the <textarea>?
Similarly, the Summary: field is slightly hard to handle in its current form; one would often like to make comments which are longer than 60 characters (maybe I'm a verbose kind of guy). Perhaps this too could be a <textarea>, with similar protections as in the previous suggestion?
And also similarly, do you think you could put a
before the "View other revisions" link?

I'm not particularly fond of using Emacs as a web browser, but it sure as hell beats the pants off the miserable "editor" widget in Mozilla for editing long text passages in forms, and so adapting the user interface so it works with the most popular Emacs web browsing extension would seem like a Good Thing.

(I'm aware of w3m and its facilities for editing Wikis, I just haven't gotten around to installing it yet.) -- era

Suggestions pulled from the top-page WikiSuggestions to do with changing the code base without substantially changing the output of the code...

support for multi-byte encoding

Like all Perl-based wiki's that I know of, UseModWiki can't handle multi-byte encodings such as Japanese EUC/SJIS. (Python-based wiki's seem to handle such encodings without any special work by the programmer.)

I'd like to see better control over preference defaults

Currently the wiki.pl code must be edited in multiple places to change a default.

More flexible script name control

If $FullUrl option is set, InitRequest should use that to get the script name instead of SCRIPT_NAME environment var.

sendmail or perl-mail?

Please change the use of sendmail to use the perl email libraries. Sendmail is a big dependency.

Keep Sendmail - it provides an easy way to implement the mail feature on Windows 2000 systems by using SendMail for Windows without making any changes to the usemod code. -- EdGray

Notification privacy

email notifications could bcc the list so that individuals are not given the complete list of people who have asked for notification. -- GlynNormington

automatic pages count

On Wikipedia people want automatic pages count. I even made a patch for very simple stats (mainpages and subpages counts, unfortunately it doesn't cache results and can't see difference between normal and rederected pages). Anybody interested in merging this patch with main UseModWiki ? Anybody could tell me how to fix these two problems ?

-- taw@users.sf.net

update your doctype

The default doctype in the source is very basic, and the W3C validators then think the page is meant to be HTML 2.0. You may want to use either of these two...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

In my local test version I use <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">, will be included in next version. For using strict some more work is needed

Perl Version

Extend action=version to display the Perl version. This would be handy for diagnosing problems such as diffs not working.

GlynNormington

: HIH, WikiPatches/ExtendedActionVersion --JuanmaMP

I've done a pretty massive overhaul of the UseModWiki for my use at http://www.technomanifestos.net . It still relies on the textfile database, which is probably a horrible bottleneck for speed and flexibility. But it's much better organized, into lots of subpackages, consolidates globals, uses the TemplateToolkit module for templates, etc. I've put up a version of it, calling it TmNetWiki. --AdamBrate

I've been planning a merciless refactoring of UseModWiki into Perl OO -- the idea being that new behaviour such as WantedPages?, Image uploaders etc can be easily slotted in as new child objects. There are some rough notes over on UnrealWiki, but I haven't really started yet. My plan is to stick to the current feature set for now, but segregate certain functions such as reading databases and opening wiki test, som in future this could be easily changed -- Tarquin

: The people looking at refactoring might be interested in the CPAN distribution [:Wiki] - it's still a little basic, but progressing fast. It's modular, it's OO, it uses existing modules (such as [:WikiFormat]) wherever possible, and it has tests. It's not a Wiki itself (though an example script is included), it's a set of tools for building Wikis. MySQL, Postgres and SQLite backends supported now, and there's an inverted index search plugin that will work with any of these three. The only formatter in the distribution at the moment is a very basic one, but it's easy to add new ones. I have [a test site running with a pre-release version of a usemod-style formatter], and [another test site running with a pre-release version of a POD formatter]. -- Kake

: A quick search on cpan also turned up [:pWiki]. Can anyone compare/contrast with CGI::Wiki?

: CGI::pWiki is an actual Wiki engine -- an application wrapped up in a module. It's more like Usemod than it is like CGI::Wiki, which is intended as a toolkit to help in the development of customised Wikis. --Kake

Lars Aronsson's Swedish wiki website at http://susning.nu/ ~DeadLink runs a 0.92 with lots of mods. (Believed to be the world's 3rd [BiggestWiki].) Some of the modifications could/should be cleaned up and released, and could be incorporated into a future version of UseModWiki. Here are some ideas:

The option to use FastCGI instead of plain old CGI, for speed.
Storing current versions of pages in a MySQL? database for faster searching.

: Storing the pages in a relational database has some advantages in additon to possible speed improvements. It can allow for more graceful recovery, it can provide a "history" for sites where that might be useful, it can provide infrastructure for complex searching, etc. If you do make this change, consider using the Perl DataBaseInterface? --DBI-- rather than coding for a specific database.

Extending the inter-wiki linking scheme to a module system, i.e. [[scheme:pattern]] means that the scheme name is the name of a module that interprets pattern and returns some link. ISBN links could be one example of this, and interwiki links would be another example. (This is how it should be implemented. Unfortunately this is not how it is currently implemented at susning.nu)

If a database backend is used, make sure the option not to have any backend is given too! one great thing about UseMod is the quick setup and the way you can use it on any ol' server with perl. -- BayleShanks

I completely agree with Bayle. -- DavidAndel

Spam blocker

I've added a patch at my group's site so that new edits that try to add 5 or more URL's at one time are ignored. It's a bit primitive - it doesn't give the user feedback if the edit is ignored. However, it has stopped the spam bots completely (knock on wood :-) ).

Here is my test page which has further details: [AddTheLinksTest]

Can something like this be added to the main line of development?

-- [RachelStruthers]

I know others have done the same patch, see [ShotgunSpam]. However, for some reason it doesn't seem to be in the latest UseMod release. This might be because it prevents legitimate users from adding a big block of text with legitimate links. It would be nice to have this as an option - you could turn it on or off or tweak the number of url's that can be added in new edits. [RachelStruthers]

The Summary field in an edit screen has a default value '*' (asterisk). According to SummaryField this was done on purpose, to avoid 'smart browsers' from making 'helpful' suggestions.

Thing is, in my case smart browsers making helpful suggestions is the desired behaviour. I don't want to have to remove the asterisk in order to type the same old, same old 'fix typo' or 'wikify' or 'new article' again.

Would it be possible to make the default value a setting? If that is too nonsensical a setting, then nevermind, I can patch the code myself.

-- Branko Collin.