Merry Christmas from the Organic Design team! although it appears that activity has dropped off a lot this year, things are still developing well behind the scenes. Our organisational system has been in use for the last six months in our private work wiki, it's almost ready for the demo version to be unveiled here on our public site for people to download and install. See wiki organisation for more information.
We're now ready to use Vanadium for our form validation, but there are some restrictions due to the dual-use nature of our forms (that the same forms are used for creation, updating and searching for records).
When the form is used for searching no validation should occur because a completely empty form is legitimate for a search query, and also every field must allow regular expression characters when searching.
For this reason the ":only_on_submit" option must be used so that the Vanadium validation only occurs when the form is submitted not dynamically as fields entries are changed. E.g.
<input class=':required :only_on_submit' />
In addition to this, when the form is submitted validation should not occur if it was submitted by the Search button (having id "ra-find"). To do this a patch has been added to the OD JavaScript which is loaded by all OD wikia wiki's.
We've been having a few "Too many database connections" messages being reported so we've had the RAM upgraded from 2GB to 4GB which should hopefully fix it. Also a second 500GB disk has been added so that one can be dedicated to content and the other to backup.
The site was running SimpleSecurity 3.4.8 which was an older version that hasn't been updated since July 2007. We hadn't been able to upgrade to the most recent version because it requires at least MediaWiki version 1.12, but since we've recently upgraded the site to MediaWiki 1.14 the upgrade to the latest version of SimpleSecurity was finally possible. So today the upgrade was made and we're now running the latest version (SimpleSecurity 4.3.0 from the MediaWiki subversion repository).
One of the issues with the upgrade from SimpleSecurity 3.x to 4.x is that the older version uses the #security parser function to apply permissions settings to articles, whereas the newer 4.x versions extend the native MediaWiki protection page. So to ensure that all the articles which had been protected with the old parser function would still remain protected, the SS3Dummy extension was created to make the #security parser function act as a category link. The result of this is that all articles containing the old #security parser function are automatically categorised into Category:Private which has been made readable only by administrators using SimpleSecurity4.
The new RecentActivity extension has been created over the last couple of days. It was a quick and easy extension to create but provides very useful information about the last articles which have been edited or created in the wiki by anyone, or by a specific user. We've added the "Recent Activity" folder to our sidebar tree which you can see on the left showing the new extension in action. Logged in users can also see the articles they've personally recently edited or created. Below is a list of the last ten articles created in the wiki.
We've urgently required an upgrade for a while since all our new RecordAdmin features which are part of the wiki organisation system could not be implemented on the older parser. The upgrade has been very difficult mainly due to DPL raising the infamous illegal mix of collations error. I tried exporting all the content as XML instead of SQL, but even that approach was fraught with problems, I finally got it to work by setting $wgDBmysql5 to false.
Now that we're on 1.14, we can no longer support the SimpleForms extension locally, but may later provide the examples on a 1.11 in our wikia. We're now focussing exclusively on the RecordAdmin extension for our form-based systems.
Over the weekend we migrated all our discussions, tasks and current work over from various talk pages and email in-boxes into our new wiki-based organisational system. This is currently in our private intranet wiki, but after we've worked with it and improved it over the next week or two, we'll create a wiki article package from it which can be imported into other wikis to serve as an example or template organisation.
We're working with a number of other organisations who are very interested in using a wiki-based organisational system, and this migration of our operations will give us an excellent repository of existing structure to work with in implementing in-wiki systems for them.
The initial record types we have operational are Person, Role, Project, Organisation, Activity and Issue. When used in conjunction with the CategoryWatch extension these give us a basic workflow and time management system through which we can collaborate on projects together and evolve them through feedback from the clients and users.
We're in the process of standardising our Role's portals so that they contain useful queries to aid in productivity such as the ability to quickly access current work they've been involved in or any issues assigned to them.
Other records which have been created are Lead, Account, Document, Procedure, Computer, Network, Order, Product, Transaction and Invoice. These will be made operational over the next few weeks and will mean that we can move our remaining procedures that involve the spreadsheet into the wiki. In preparation for this the ods2wiki.pl script has been developed which allows us to import our Open Office spreadsheet information into wiki records.
We have a lot of collections of articles which we tend to re-use a lot on many wikis in the field. We don't want to use cross-wiki transclusion because we don't want these wikis to rely on external content for their day-to-day use, so we needed a simple way to maintain these collections and export them when needed.
We've been working on the Packages extension for a while to solve this problem, but in the mean time I created Template:Export which offers a simple interface to the Special:Export functionality. Here's an example,
This wikitext
{{export:
News
Help
Sandbox
}}
Produces this export button
The list of articles to be used by the export doesn't have to be fixed, a DPL query or other kind of dynamic operation can be used to generate it. The query must be made to specify the results be simple textual names separated by newline characters as in the following example which exports all articles containing the {{book}} template.
The wikitext: {{export|{{#dpl:uses=Template:Book|format=,%NAMESPACE%:%TITLE%\n,,}}}}
The resulting export button:
We intend to maintain a number of "article packages" in this way in the wiki article packages article.
Organic Design has moved from a VPS with VPSLink to a dedicated server with eSecureData. It's an Intel quad-core Q6600 running at 2.4GHz with 500GB of disk, 2GB RAM and 2TB of monthly traffic allowance! The picture to the right is from this Google map and shows the building in Canada where our new server is situated.
Even though the Q6600 chips are desktop chips not server chips, it should still be faster than the quad-Xeon VPS we've moved from since the Q6600's cache is the same size (4MB) and the speed is 400MHz faster. Also we're no longer sharing our server resource with other unknown clients which can often cause sharp drops in responsiveness.
