I'd like to create a technical wiki site and it requires the full use of HTML/CSS and maybe Javascript when editing a page. Is this something I can easily configure in MediaWiki? If not, is there any other wiki software that you'd recommend?
Thanks!
You can enable raw HTML support by setting $wgRawHtml = true; in your LocalSettings.php:
http://www.mediawiki.org/wiki/Manual:$wgRawHtml
However, as noted above this is rather insecure for a public site. (If locked down to registered usage only by known folks it's ok -- but you need to trust your users.)
There are some links on that manual page to extensions organized around letting you put specific known bits of HTML/JS in your output code as well, which may or may not fit your needs better.
Well, while MediaWiki itself does not support this, there are some extensions which allow at least HTML in a page. See for example this extension list. SecureHTML might so what you are looking for.
That said, I'd like to point out that allowing raw HTML rather defeats the purpose of a wiki:
it can and will mess up formatting and create weird problems (clashes between generated and user-provided HTML)
it makes it hard/impossible to convert the wiki to other formats (such as to print it)
it makes searching harder
it makes any kind of security impossible (think XSS)
This is doubly true for allowing Javascript.
So I'd like to ask why you need this. If you need special formatting that MediaWiki does not offer, consider using (or writing) an extension for this.
If you really need arbitrary HTML, a Wiki might not be the best tool for you. You should consider a CMS, or just put HTML files into Subversion.
So what are you trying to do?
Use nowiki tags. Docs can be found here: https://www.mediawiki.org/wiki/Help:Formatting
Related
What are some common use cases for implementing CFML Custom Tag (not CFX tag)? In 3 yrs of my CF exp I've never written one. Would someone please enlighten me, under which use case / situation would one choose custom tag over cfc / udf?
Remember that custom tags were, at one time, the only method available to extend CFML (up until version 4) - UDFs came later (CF 5) and CFCs later still (CF MX). They're not as commonly used as they once were for the simple reason that there are more options.
Custom tags are basically procedural in nature in a language that, with CFCs, become more and more OO in practice. This is another reason that they're not very common.
But there's still cases where they come in handy (but are never required) - mostly for interface work. The ability to create both a start and end state can definately come in handy. A simple example could be a "wrapper" for page content the opening tag might add the HTML header and page navigation while the closing tag would add the footer and end the page.
In this way your page content could be nothing more than:
<cfmodule... >
Page Content!
</cfmodule>
Of course there are other ways to do this as well - but sometimes the classics still have value. ;^)
Look at the CFUniform project for a great example of custom tag usage. Custom Tags are great when building reusable pieces for the UI portion of an application.
I think that, for the most part, custom tags have mostly fallen by the wayside since UDFs, CFCs, and integration with Java (and to a lesser degree .NET) allowed easier and more straightforward ways to do similar things.
Looking back to when I started in CF5, I can think of several examples. A good one might be CFX)Zip, which allowed interaction with Zip files before that was available directly through CF.
The only use I can think of offhand in a more modern context would be to provide precompiled code that wasn't written in Java or .NET, such as proprietary doodads written in C. That's a pretty niche use, though.
Honestly, I imagine at this point they exist more or backwards comatibility than anything else.
Ever since CFCs came out I've stopped using custom tags simply because of the overhead. They take too long to initiate and execute. But like #Jim Davis said, they may be useful where you need to write a tag that wraps around other content.
But in a well defined solution, you can do way with them all together.
In choosing an editor for my wiki-like site, I'm debating whether to allow HTML or a custom alternate markup (maybe like wikipedia/wikimedia's or BBCode).
HTML benefits:
Easy for users to deal with (copying and pasting, learning)
Somewhat future proof
Many more editing tools available, usually WYSIWYG too
Alternate markup benefits:
On the server side I don't have to worry about parsing malicious javascript or styles or HTML that I don't allow
Can be easy to learn
Can be easier to decipher if not HTML-savvy
Am I missing something, what's the best solution?
Depends on your target audience. If they're tech savvy, they probably know HTML, BBCode, etc. If they're not, they probably don't and a simplified markup might be more appropriate. Personally I like markdown for the non-tech savvy. There are editing tools available for both, also libraries available for handling each of them. So really it comes down to which do you want your users to use?
I would stick with wiki markup. You can make it easier by using a WYSIWYG editor like FCKEditor
For HTML, let moderators have control using e.g. Extension:RawMsg
Peroanlly as a user, I'm not a fan of html for things like wiki editing. Most of the time you dont need more than simple features so its too verbose and just makes life harder, and I dont really like using WYSIWYG editors either. I prefer being able to type Markdown or Textile myself directly into the editing field.
If ease of use is a concern, go with a WYSIWYG editor, and then it doesn't really matter what the underlying markup is.
We use DokuWiki to manage our internal documentation but the page renames / moves are not supported very well (there is no built-in way other than messing with raw files manually and the third-party plugin 'pagemove' is no longer developed). Which is a pain.
I'm looking for an alternative which will be similarly simple as DokuWiki (must be filesystem-based) but handle the page renames/moves well. Any suggestions?
For anyone whose search lands them on this page - you might also be interested in the plug-in that keeps links for moved and renamed pages in DokuWiki:
http://www.dokuwiki.org/plugin:move
Starting with Comparison of wiki software and sorting them by Data backend, there seem to be quite a few file system based wiki's. Skipping the webpages that are down or incomprehensible turns up the following viable candidates:
MoinMoin
Twiki
PmWiki (after installing a plugin)
JSPWiki
In the end it's up to you to decide which of these best suits your needs & supports migrating your existing contents to the new wiki (no small feat), but at least it's a start.
Currently I'm using DokuWiki to manage my apps/scripts documentation, some articles I write and stuff like that... I like DokuWiki very much, it's simple and powerful but it's still too much for the use I've given it in the last 1/2 years.
I need something else, something different...
I'm looking for a way to integrate the little things I like in DokuWiki into my own website without needing a script, like DokuWiki, with it's own admin page. The website itself, my homepage, I like to code myself most of the things so it becomes exactly what I want. However, somethings I don't have much time for, that is why I'm using DokuWiki.
I want to ditch DokuWiki and scripts like these because I don't even use half of their capabilities. A wiki is a platform where people join their efforts and collaborate together to write stuff, it also has a revision system. These are two very important aspects about wikis that I don't care about for my own. I'm the only one writing stuff there and I don't care about revisions, never needed them.
What I like about DokuWiki is that I can point my browser to any URL within the wiki domain and create a page from there if it doesn't exist. I also like DokuWiki's syntax very much but sometimes it's very limited and I can't do what I want. The way you link between namespaces and such is also very nice. Too finish, a media/file manager is also very handy. These are probably the most important aspects for me in DokuWiki.
Basically, I'm looking for something, maybe a script, that would allow me to do the stuff I described above in a way I could integrate into my own website without needing a special administration area.
Does anyone know about such thing or I'm better off coding my own since my requirements are not that tricky to begin with, I just didn't want to have the extra work...
Or maybe any other suggestions?
Maybe you'll want to have a look at something like TiddlyWiki, which is a single-file wiki, that you can even put on a USB stick.
I chose xwiki over dokuwiki.
Another simple wiki is the one included with fogbugz. It is hosted for free for up to 2 users and might suit your project.
I may be off but very simple wiki with no administration and no users is LionWiki. I don't know how easy it's gonna be to integrate it into your website.
It's just one file and does not use database (like DokuWiki).
It does not have a lot of features though. It also uses a different syntax from that of DokuWiki.
Currently our team is using MoinMoin as a wiki for IT and it's so nice.
We want to promote to use wiki for end-users because some of them are interested. On the wiki we'll share and edit requirements of aplications, for instance.
I think MoinMoin is not the more user-friendy (but I love to use it) that's why we are looking for the best user-friendly wiki for end-users/customers
For yourself MoinMoin is obviously user friendly. =) Seriously, consider all users and try to figure what kinds of usage patterns you have. MoinMoin is a reasonable choice since it's such a simple program. You can often help your non-programmer users by adding a feature or two to MoinMoin. Developers are up to speed with it and you have all the content there already.
That said. Mediawiki is used for lots of general wikis out there today. Including Wikipedia. An aspect of user friendliness is recognition. Mediawiki might feel more friendly because users are more familiar with how it works. And Mediawiki is widely adapted. Lots of extra features you might want to add to help your users are already written as extensions. And Mediawiki's extensions API is really good so you can easily automate your own verticals when the need arises. Mediawiki is reasonably feature rich without being totalluy overloaded. It has categories and templates which both come in handy for keeping things DRY and using the wiki in various processes. It shares lots of its syntax with MoinMoin since both have the same ancestor (syntax-wise).
I'd probably go with Mediawiki.
Visit Wikimatrix.org to determine what features you need and what tool is best for you. I often mention Foswiki.org as a very nice and userfriendly tool, but it really depends on the features that you need.
I have yet to see any Wiki that is more end-user friendly than Confluence.
Just the most important reasons:
While other Wikis say they have WYSIWYG editors, what they actually do is enclose selected text with markup when clicking an icon. That is not WYSIWYG, that's code injection! In Confluence 5 all editing is done from a visual editor (you actually DO see what you get right away straight within the editor). With the ability to add macros (markup) by powerusers.
In almost all other wikis the users are entirely responsible for creating and maintaining the link hierarchy. This means broken links and orphaned pages will be the norm. In Confluence all pages are automatically added to a page hierarchy and sorted by name. You can enable the tree browser via the Documentation theme to make browsing the wiki even without manually added links convenient. Lastly you have the ability to reorder pages in any order via drag & drop.
However, Confluence is rather costly for > 10 users. But well worth it if you can afford it, or you don't need more than 10 editors. Pure "readers" do not count towards users if anonymous viewing is enabled.