Now even more user-friendly with impressive new features
We have great news: we are proud to announce the new BlueSpice release 2.27.2. After scarcely three months, we are already publishing the second release of the year.
Looking forward to the release of BlueSpice Version 3 in 2018, we are already working hard on many small adjustments, making BlueSpice even more user-friendly, so you can operate it more intuitively. This means that the new version already contains valuable features and improvements, so it is more convenient to use and working on it is more efficient.
Vienna! A city of music, culture and avant-garde. And, notably, the host of this year’s Wikimedia Hackathon, an annual tech event where roundabout 200 developers, maintainers and users of MediaWiki gathered to experiment, discuss, plan and, of course, enjoy the company of like-minded people. Naturally, BlueSpice, being the largest professional flavor of MediaWiki, was also represented in various ways, getting glimpses at the most recent turns in development, making connections among colleagues, and exchanging experiences and ideas. Continue Reading
In this two-part article, we give a detailed comparison of the wiki top dog MediaWiki and Confluence.
We already wrote a few words about MediaWiki and Confluence some years ago. At that time, we wrote about the main objections to MediaWiki.
That article is still worth reading and remains largely valid. Ultimately the key argument then was that the choice of tool did not depend only on features, but also on the concept behind the software. This is a timeless truth.
However, MediaWiki does not need to fear a direct feature comparison. Importantly, the enterprise distribution BlueSpice has already decided the feature question in my view. This can be seen on our newest internal feature-comparison table, published here and offered for free download:
Administering several individual wikis is technically intricate because all too often, a confusing “wiki chaos” develops, which is difficult to take care of. In this area there is already a concept which has proved itself: the wiki farm.
Several wikis can be created, archived or deleted quickly and easily by using a wiki farm. When creating wikis, the user has the option to create an empty wiki or to clone what is known as a “master wiki”. Such a master wiki can be already filled with content (e.g. handbooks), or contain files and configuration data, all of which can be transferred and supplied.
From a technical point of view, by using the farm concept, one can provide several wikis with just one wiki installation. The wiki software is only installed and saved once on the server and all the wikis use this installation together.
We have had an increasing number of enquiries from customers over the last few years for whom the best possible solution is provided by a wiki farm. Many have the problem that a single wiki is no longer sufficient, because they need to reflect the most differing topics, languages and permissions concepts. In such cases, we always recommend the use of several wikis via our wiki farm solution.
Why does one need several wikis?
By providing several wiki instances within one organisation, we can ensure that data and permissions structures are absolutely separated. While access to information can be controlled within a wiki by assigning permissions for separate namespaces, this harbours risks and gaps. The basic software MediaWiki does not recognise the regulation of access by namespaces and presents loopholes which an experienced user might make use of. On top of this, there is the risk of errors creeping in when permissions are assigned, making data available for non-authorised users. This can have fatal consequences, particularly in divisions with sensitive information like personnel, research and development or management.
Creating new individual wikis is also especially useful in project management. In general, projects with wikis can be excellently organised and monitored by including, structuring and keeping up to date the content of the project or data like the points of contact and costs, schedules and milestones or the current status and the to-do list. The security obtained by separating the data makes it possible to share a project wiki with, for example, external service providers or customers, so you can work together and exchange ideas without risk. When a project is concluded, then the wiki can be archived so that the information and data can be made available again if needed at a later time.
Single wikis are not intended to implement multilingualism. There are differing concepts around for solving this, but using separate wikis for each language is still the most elegant and cleanest option (see Wikipedia). This is an indispensable requirement for companies working across the globe, which can be optimally fulfilled with WikiFarm. BlueSpice even has its own special features here. Linking individual articles in different languages is done with InterwikiLinks. In such cases, BlueSpice automatically adds a menu for navigating between languages (see fig. 1).
Because multilingualism is just as much a hot topic and just as involved as before, we will devote a blog entry just to this topic so we can give more detail.
How does a wiki farm pay off?
So that the creation and maintenance of a number of wiki instances can be managed quickly and simply, there are farm solutions with which organisations and users can practically “host” as many single wikis as they want.
We have developed the technical basis of the BlueSpice farm solution a great deal further, and tailored and optimised it with a view to the individual use-cases of our customers. Not only MediaWikis, but also BlueSpices can be administered by the solution.
The great advantage of using a wiki farm is that the systems are simpler to maintain, which reduces the costs. Patches, updates and upgrades are only carried out in a single system but are available in all wikis of the farm.
Wikis with a limited “lifespan”, like project wikis, are better organised in a wiki farm: if there are processes and tasks that occur again and again, they can be put in a prefabricated structure in the master wiki and content which repeats can be populated. As soon as one needs to, one can clone this wiki so the project can begin immediately. After finishing the project documentation, the wiki is archived in such a way that it is no longer active. The information contained within it, can still be recalled at a later date.
Farm management is configured to be very clear (see fig. 2). Along with a description, keywords can be assigned to individual wikis. The list of wikis can be sorted, filtered and grouped according to different criteria. This makes all wiki instances simple to keep an eye on, and redundant wikis and unused relics can be avoided.
Putting together the biggest advantages of a BlueSpice WikiFarm, we have:
1 click installation for new wiki instances
Very little effort needed to update and upgrade
Provision of standardised content via master wikis
Data security because content and rights can be separated
The clear presentation, sorting and filtering of wikis
If you would like to create and manage several wiki instances in the twinkling of an eye, WikiFarm is exactly the right solution for you. Even when operating just a second (Media)Wiki, the software’s architecture and administration interface save time and costs.
It is that time again: we are very pleased to announce the new BlueSpice release 2.27.1, and it is difficult to believe that this is only a patch release.
When we consider the new features, Version 2.27.1 is right at the forefront. The first release of this year focuses on the optimisation of usability and applications in quality management, alongside bug-fixes.
The installation of wikis and quality control of the wiki software is still generally done by hand. Obviously, this increases the costs for the customers. And the software producers do not find this repetitive work much fun either. Continue Reading
With BlueSpice 3, we replace the previous VisualEditor with the MediaWiki VisualEditor, which some people will already know from Wikipedia. This leads to questions, for example: Why are we changing now? What potential does the editor have? And what is the situation with real-time editing? Continue Reading
Everything used to be simple: database queries for structured data and full-text search functions were conceived separately. But that is now history. In new search engines, metadata can be searched for much more selectively. These new possibilities blur the distinction between a database query and a search function. What does this mean for the technological development of wikis? Continue Reading
We are currently fitting out the new Version 3 of BlueSpice with a new search engine. So this is a good opportunity to explain what actually happens in a search engine and why we have decided to make this change. Continue Reading