Tag Archives: wiki

Adding TinyMCE to EE Wiki

Having found several requests in the forums and no tutorials online or in documentation, I’ve documented the steps I took to add the TinyMCE editor to my ExpressionEngine wiki.

I am using the EEDocs wiki theme to provide documentation for my users. Here are very quick and dirty instructions to add TinyMCE to your EE Wiki which basically follows the default instructions provided by the TinyMCE Wiki.

  • Download TinyMCE, extract it.

  • Upload the TinyMCE to your webserver, note the path.

  • Find the default PHP file for the EE wiki theme you are using. Mine was in my siteroot/themes/wiki_themes/eedocs/ folder and is called eedocs.php. The default them would be in the themes folder under wiki_themes/default/default.php. Open this in the editor of your choice. You may want to create a backup copy in case you need to revert later.

  • Add the following code to the <head> area:

    <script type="text/javascript" src="http://yoursite.com/yourpathto/tinymce/jscripts/tiny_mce/tiny_mce.js"></script>

    Note you may want to test that path in your browser and make sure it is linking to the tiny_mce.js path as intended.

  • Add the following inline script to the <head> area :

    <script type="text/javascript">
    mode : "textareas"

This will turn all of your textareas into TinyMCE editor fields. There are many other ways to configure this, you could specify exactly which textareas to use TinyMCE, for example. For all your TinyMCE customization options, see the TinyMCE wiki and for help knowing where to put what, check out the ExpressionEngine User Guide section on the Wiki Theme Template.

I can’t say I’ve done extensive testing yet, but the default TinyMCE install has not (so far) interfered with wiki markup at all, which is to say that [[Category:Foo::Bar]] and regular [[wiki links]] seem to be working happily.

ExpressionEngine Wiki with TinyMCE

Update: Installed the MarkItUp editor in a similar fashion, I like it a lot more than TinyMCE out of the box. May be looking at Textile Editor Helper (TEH) and CKEditor as well, so check back for a WYSIWYG / markup editor showdown. In the meantime, consider what you need a WYSIWYG for and what markup under the hood you’re willing to live with in the long-term before settling on a solution for your site – here’s a good article that sums up that issue: WYSI-dangerous: Why WYSIWYG editors are bad for your website on redcloth.org.

Google Doctype Screams “Fork ME!”

The newly released Google Doctype is intended to be the Wikipedia of web design. There’s a video introduction on the landing page of Mark Pilgrim explaining what Google has been internally calling the the “Hitch Hikers Guide to the Web”. He’s been working on Google Doctype, said it is supposed to be the cross-platform alternative to MSDN. MSDN? I don’t know any web designers that rely on MSDN as the go-to spot for quality cross-platform client-side code! Maybe they’re targeting ASP.NET developers…and that could explain the very un-wiki linear treestyle navigation.

Google Doctype Screenshot

The Good

My own private wiki, largely comprised of web development documentation for my own projects, code snippits and links to online resources, is invaluable to me – so the potential benefits of an open wiki of this nature is obvious and I’ve often wondered why there isn’t one (with critical mass) out there already. Certainly this project, or at least the idea of it, could be an invaluable tool to professional web designers and client-side developers. Some take-aways:

  • “Written by web developers, for web developers” and by that they mean client-side developers…most of the current content is specific to JavaScript DOM stuff and cross-browser CSS considerations. I think this fills a knowledge gap as a lot of CSS and even Ajax resources are designer-oriented (lacking meaty technical details) and many developer resources gloss over or ignore web standards or a lot of the details professional programmers take for granted (like finding a viewport or using javascript to manipulate classes)
  • It’s built on the Google Project framework so you can download the whole thing via SVN.
  • The licensing is pretty unrestrictive, so you could SVN everything and put it up on an intranet statically or keep an off line copy, as was mentioned in the intro video.
  • Discrete code snippets. Rather than a long tutorial with examples that are specific to a given situation, many of the HOWTOs are broken down into more abstracted uses. This style of documentation will help a lot when your stuck on specific area of a bigger project. Personally, I learn more this way – I like the big step-by-step tutorials but when I cut and paste a lot I don’t retain very much.

The Ugly

Google suffers from chronic ugliness (IMHO) and this project is no exception. Don’t get me wrong, I’m GOOG fangirl all the way, but there always seems to be some basic user interface and user experience problems with their apps/portals/projects/whatever. And here’s where I think Google Doctype has need of improvement:

  • No indication of off-site links. Not only does a link to MSDN look just like the internal links, there are links to other Google Code project without any indications that you’re leaving Google Doctype, in fact, the logo is still Google Code. Navigation is a little confusing in general.
  • Lack of Style Guidelines. There is something to “just putting it out there” and I’m glad they did, but if a lot of people do start adding to this resource it could turn into quite a mess. It would have been ideal to have a written style established that would make sense for an open wiki. For example, statements like “generally, we recommend the following…” and “I’m not sure if this works on IE”. This type of thing would never fly on Wikipedia – now that the docs are open to the whole internets, such statements are ambiguous, lack authority and create a bad example that others are sure to follow.
  • Not really a wiki. First there’s the linear tree/node navigation pane (which seems to collapse by itself and disappear or reappear for no apparent reason) . There is no discussion page (although there are comments, sort of like PHP.net), no page history (but you can manually add a free-form line to a log file, if you notice the option), there’s no obvious way to check to see what links to a page, the list goes on.
  • Screaming “Fork Me”. A fork may be inevitable, and if a fork emerges using MediaWiki or any of a myriad of much more robust wiki platforms, I would be more likely to invest my time in that in spite of the Google mind share.

A Web Reference To Rule Them All

When I first read that Google published a web design wiki I was thrilled. I tried to think of other, similar resources. There are some great blogs, lists and forums out there but I’ve yet to find the one web reference to rule them all. If you know of one, please let me know! In the meantime I’m looking for domains…webwiki.com is just a db error, webwiki.net is a half-baked attempt at a wiki version of the Million Dollar Homepage. Hrm. If I come up with a load of extra time and a brilliant idea I will let you know. In the mean time, here are a few of my favorite web coder sites:

  • W3C.org – start at the top, right?
  • HTML Dog – very well organized reference and tutorials for CSS and (x)HTML
  • A List Apart – high quality articles published by those web standards freaks at Happy Cog.

How To Make Your MediaWiki Private

USE THIS INFORMATION AT YOUR OWN RISK. Any information found on this website is offered only as informational and includes no warranty, guarantees or support. The author claims no authority on any subject whatsoever.

I've been using an amalgamation of hacks to track all the information I want to be able to recall later: del.icio.us for bookmarks, gmail for contacts and random notes, private blog entries for some organized content, and tracks for tracking projects. Blech. It's just too much. My memory is too weak. What I really want is a comprehensive PIM (Personal Informatio Manager). And so I installed MediaWiki because that's what Wikipedia uses and that's what Dreamhost offers as a One-Click Install (e.g. the path of least resistance).

I thought I'd share with you all the the process of customizing the default install to create a private wiki. Following are the specifics to my install but this will probably be helpful to many with a different host or newer version.

  • Create a subdomain for your MediaWiki install, such as, wiki.yourdomain.com. Select PHP 5.x (not 4.4.2) and leave Extra Web Security.
  • Install MediaWiki. Dreamhost walks you through this and it's also covered at the Dreamhost Wiki so I'm not going to go into detail here. But be sure to move the newly generated LocalSettings.php to the parent directory, and delete the config directory with its content.
  • Chmod LocalSettings.php to 600
  • Create a backup copy of LocalSettings.php, rename it something like .BAK instead of .PHP or something. Put it back in your Wiki install directory right away so it's safe and available if you need it later.

Restrict Wiki Access

Before bothering to put up our own cute logo or other fun stuff like enabling image linking and using clean urls, we're going to lock down our install. I didn't find a lot for this particular intent on the official MediaWiki Docs or the Dreamhost Wiki, but I did find this old Meta Wiki Article

  • Prevent new user registrations. Add the following line to the bottom of LocalSettings.PHP:
    # This snippet prevents new registrations from anonymous users
    # (Sysops can still create user accounts)
    $wgGroupPermissions['*']['createaccount'] = false;
  • Make sure it's working by trying to create an account. You should receive an error message that says username not found, please create an account. To change the message login as yourself (you should have set up a Sysop login when you configured your wiki) and point your browser to wiki.yourdomain.com/index.php?title=MediaWiki:Nosuchuser&action=edit.
    I changed my message to:
    There is no user by the name "$1". This wiki is private and therefore closed to new accounts. Please contact Mahalie if you have any questions.
    I intentionally failed to provide contact information. If a user doesn't even know how to contact me, they really don't need an account on my private wiki!
  • Prevent anonymous users from reading by adding the following to LocalSettings.php: # Disable reading line, for anonymous (not-logged-in => * ) :
    $wgGroupPermissions['*']['read'] = false;

    # ... and enable anonymous to read the followings pages :
    $wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );

    # ... same in an other language (French, with one UTF-8 special characteres) :
    # $wgWhitelistRead = array( "Page Principale", "Special:Userlogin", utf8_encode('Aide en fran├žais'));
  • Verify setting by logging out of your wiki and attempting to browse. You should get a 'Login Required. You must login to view other pages.' when clicking on any local link and the page should redirect to the main page after a few seconds.
  • If you want to hide the side navigation if the user isn't logged in (because, perhaps you have private project names or something) edit includes/Skin.php and change the function buildSidebar(). Add these lines near the very top, after the globals.: global $wgUser; if (! $wgUser->isLoggedIn()) { return array(); } This will hide the navigation on sup-pages (not the default main page)

p.s. WebWorkerDaily just published 15 Productive Uses for a Wiki in case you're wondering why someone would want to do this!

Update: Check out a new tutorial on Lifehacker, Customize Mediawiki Into Your Ultimate Collaborative Website - it's not a PIM implementation but it offers some good information on quickly re-skinning and mods to consider.