Are you using MySQL or PostgreSQL? With mine we dropped MySQL for lack of robustness, and use PostgreSQL throughout, BUT there are issues with MW's imperfect support of each service! PGSQL is much much more robust and uses real SQL. Regrettably MySQL doesn't so one needs source code hacks at times. Yuck. How they ever manage to keep Wikipedia up is beyond me
Every time my business partner and I launch a new wiki we hold our breaths! Usually we explode form lack of oxygen.
.htaccess is "fun" for sure. I leave that to him! The extensions are ok, but don't always keep up to revision with the core.
I recommend embedded Youtube extension, Google Maps and, to an extent, the events calendar
On 19 Aug 2011, at 21:34, Eric Baird wrote:
> We're trialling MediaWiki as a prototype repository for more "visitor-friendly" information on exhibits. It currently looks a bit rough, but it's still officially at the prototype stage.
>
> The installation software happened to "like" our server, so it only took about half an hour to get up and running.
>
> The museum has one of the old "standard" Museum collections systems (and needs to keep using it for certification), but it's a bit of a pig. The catalogue was never intended to be publicly viewable, so the format of the existing entries is rather dry and not really suitable for presenting to the public -- even if we knew how to interface it. It has a lot of fine-detail entries that members of the public won't want to see, and a lot of major items that they /will/ want to read about aren't yet listed, as the indexers painstakingly work their way through the entire collection, in order.
>
> Another challenge was that the museum is extremely "dense" - it has a lot of very small items packed very closely together, which makes conventional labelling problematic. Ideally, we'd like the sort of more "conversational" background info that you might normally see on a museum plaque written into an online system that museum staff or visitors could access, with additional touches like QR-code "launchers" on the cabinets.
>
> So, basically, we needed second system that we could use for holding and displaying this "less formal" background information on selected exhibits and displays, starting with the big items. It didn't need to be complete, or to interface with an existing database. There was a lot of interesting information in people's heads, or tucked away in the paper archives that wasn't ever going to be in the "official catalogue", and we needed some sort of public "notepad" to let people jot this stuff down and make it available. The museum is also a tourist information point, so it was also legitimate to want the ability to add local information that didn't fit into any conventional museum database structure or schema. There's a famous Banksy mural opposite - that's worth adding as useful tourist info, even though it's not owned by the museum or even on museum property. We needed a multi-user, multiply-indexed, free-form, general-purpose knowledge-store that wasn't committed to any particular categorisation system.
>
> We also needed something that wasn't //too// difficult to learn for non-technical volunteers, had decent online documentation and community help, was robust, and had some sort of recognition factor (and nice reassuring brand-name) that wasn't going to give Museum staff the heebie-jeebies, or intimidate volunteers, or deter other people from learning how to maintain the system if the project leader upped and left.
>
> MediaWiki's recognition factor was a big plus-point -- Wikipedia is something that most people have heard of, and that makes volunteers more willing to invest time in it. They already know roughly what it does. We've even made a point of not changing the default layout templates (yet) ... partly as an exercise in expectation management. Content is still a bit patchy at this point, perhaps we might do an overhaul and give it a slicker interface once the information-set is more solid. Once all the main exhibits are listed, if some shiny new open-source option reaches release-quality status, we might even manually transplant the contents over so some other system. But for now, we need something that works //now//, and lets people throw as much information onto the system as quickly and easily as possible, with good indexing, and lets us track progress and edits on a per-user basis, with version control.
>
> Spam is an issue, but there's the option of creating new user-group categories by editing the setup text file, and restricting editing rights only members of categories like "Museum Staff" and "Invitee", with only "admin" users able to bestow those group memberships to other users.
>
> The downsides of MediaWiki relate to the way that its development is focused on the needs of Wikipedia (and to a perception that some people have that Wikipedia is somewhat dubious as an information-source). Lack of WYSIWYG editing is a downer (although it's useful that the editor strips out MSWord formatting nasties and only pastes "raw" text). WikMarkup is fine for things like headings and bullets, but sucks for tables. There's no default support for image-linking to create graphical buttons (although you can get extensions for this). Templates are useful for adding pre-formatted info boxes and the like, ad-hoc, to pages (and altering them globally) with the nasty scary coding encapsulated and hidden away out of sight of most editors (and protected if necessary), but ... all sorts of coding things work differently inside templates, for security reasons related to Wikipedia.
> Mediawiki's categories are great - they let you add multiple freeform categories to any page, and automatically generate listing pages for each active category, so they're a bit like superpowered "tags", but ... linking to category pages is awkward, and you can't browse the existing category list when you want to add a new one.
> There's also no default feature that lets casual users add tags easily, or add star ratings or the like, to say that this is a favourite exhibit (unless you can find a suitable extension that does what you want). You can get extensions for some cool things (like embeddable forum panels that can be added to any page), but the quality of the extensions is variable. There's a QR code generator extension, but it doesn't yet work on the latest MW release. Exporting data from MW isn't obvious.
>
> Conditional coding in MW is stinky. There's no conventional "if/then/else" or "select/case" (or data arrays), unless you install more extensions. I've had to do some of the ugliest, hackiest, most inefficient coding of my whole life to get some simple-looking things working flexibly inside templates and working with global parameter lists. It looks as if the MW markup system has grown piecemeal around arbitrary exceptions that have been added to protect WP from this or that security risk, in ways that'll have some programmers hitting their heads against the desk and screaming.
>
> And because the system is query-based, you'll need to do an "htaccess" hack to get neat and tidy wikipedia-style URLs, you can't really do offline editing from a local copy, and there's no obvious way to install the resulting site on a simple non-networked Museum terminal (which would have been nice). Perhaps an "export as a portable HTML-page website" tool exists somewhere, but it's not obviously part of the default package.
>
> So. By no means an ideal solution, and for a lot of cases, definitely the /wrong/ solution. But if you approach MediaWiki as a great big multi-user hypertext notepad-thing, with decent per-user and per-page edit-tracking and undo functions, which gives you an almost instant mini-Wikipedia for free, it does pretty much what you expect it to do.
>
> Eric Baird, volunteer
> Brighton Toy and Model Museum
>
>
> On 18/08/2011 14:12, Mia wrote:
>> On 18 August 2011 13:58, Joseph Padfield
>> <[log in to unmask]> wrote:
>>
>>> Would anyone consider using "Mediawiki" as a CMS ?
>> Two issues spring to mind - one, the usability of the authoring
>> interface is a real issue for non-geeks, and secondly, the 'anyone can
>> edit' content ethos isn't taken well in many publishing contexts.
>>
>> I'd be curious to know if anyone has overcome these issues to use it
>> as a CMS (as in content management, not collections management). The
>> Science Museum experimented with an object wiki, but it was before my
>> time so I'm not sure how the initial decant of objects was done to
>> know if it was able to hook into a collections management system.
>>
>> Cheers, Mia
>
> ****************************************************************
> website: http://museumscomputergroup.org.uk/
> Twitter: http://www.twitter.com/ukmcg
> Facebook: http://www.facebook.com/museumscomputergroup
> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
> ****************************************************************
Tim Trent - Consultant
Tel: +44 (0)7710 126618
web: ComplianceAndPrivacy.com - where busy executives go to find the news first
personal blog: timtrent.blogspot.com/ - news, views, and opinions
personal website: Tim's Personal Website - more than anyone needs to know
Important: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. This email and any attachment(s) are believed to be virus-free, but it is the responsibility of the recipient to make all the necessary virus checks. This email and any attachments to it are copyright of Meadowood Associates, owners of Compliance And Privacy, unless otherwise stated. Their copying, transmission, reproduction in whole or in part may only be undertaken with the express permission, in writing, of Meadowood Associates, at 16 Coombe Road, Dartmouth, Devon, United Kingdom TQ6 9PQ
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|
