BlueSpice MediaWiki Customizing

Customizing: How we adapt BlueSpice and MediaWiki to our customers’ wishes.

In short interviews with our employees we illuminate aspects and questions of our daily work with BlueSpice and our customers. In this article, we will focus on the topic of customizing. An interview with Sabine Gürtler, Team Lead Service & Support at Hallo Welt! GmbH.

Sabine, tell me: What does customizing mean in the context of our product?

In our case, customizings are adaptations to our BlueSpice wiki software that go beyond the product standard.

So the customer has the possibility to “rebuild” BlueSpice according to his wishes?

Exactly. But it’s not the customer himself who does this, it’s us. Specific customer wishes are always the starting point for a customizing project. It doesn’t matter whether our customer uses a MediaWiki or BlueSpice – the enterprise version of MediaWiki. Our developers implement adaptations for both systems on customer request.

What exactly can be adapted within the scope of the customizing project?

Quite a lot. For example, it is possible to intervene in the standard workflow of BlueSpice. This concerns, for example, the modification of rules with regard to the release or comment options of an article. Beyond that, some customers request an individual interface design. While minor adjustments to the corporate design guidelines of the customer are usually covered by our “branding package”, sometimes we have to go a step further. A good example to underline that example would be the implementation of two different user interfaces for wiki admins and wiki users.

Another customer runs a public medical wiki and wants to deliver his wiki in the “look and feel” of a website. No problem for us. Yet another one wants an individual wiki homepage with the “portal look” of an intranet to provide employees with special information and encourage them to use the company wiki.

Sounds exciting. Is there more to it?

Absolutely. Some customers, for example, wish to adapt or extend existing wiki functions. In this context we are currently implementing special upload notifications, a PDF export of various wiki page types and a push-and-merge function where content is transferred from one wiki to another – including an automated check for redundant content.

When it comes to customizing, one should not forget the development of technical interfaces to existing IT systems, like the connection of the wiki search engine to the customers’ intranet.

Furthermore data migration or synchronization routines can be adapted. A great example is a customer who requested that Microsoft Word files stored on his internal drive be automatically imported into his company wiki. This is realized with technical solutions like “CronJobs”. You see, almost everything is feasible.

Almost everything? Are there any exclusion criteria?

Yes, there are. Since we avoid so-called “core hacks”, the prerequisite for customizing is a corresponding interface (hook / API) in MediaWiki, the core software of BlueSpice. We do not interfere with the MediaWiki code, because otherwise problems would arise during update and maintenance of the system. This would have negative effects on the stability, system security and sustainability of the system. However, we always try to find a solution via workarounds for critical adjustment requests. It is important that the cost-benefit ratio fits. Of course, we advise our customers beforehand whether an adaptation makes sense from our point of view or not.

And how do customizings affect the standard product?

Normally, customizings are realized with customer-specific extensions. However, customizations that are useful for all BlueSpice customers are transferred to the standard product. Recently, this has involved, for example, usability optimizations, improvements in statistical evaluations or a simplification of the image insertion routine in the visual editor. In case of adaptations that involve a deep intervention in the programming code, we also check whether standardization makes sense. Either way, the decision whether an adaptation becomes a standard lies with us, the Hallo Welt! Ltd.

O.K. But what’s the benefit for the customer if his adaptation becomes a  product standard?

That’s a good question. The customer of course benefits. On the one hand there is the maintenance effort, which doesn’t apply as soon as the customization is transferred to our standard software. Thus the customers’ investment in “his” customization pays for itself in the long term. If an adaptation similar to that desired by the customer is already on our agenda, we also contribute to the implementation costs. This significantly reduces the customers’ financial input. Plus, by incorporating the adaptation into the standard product, we ensure that the function is continuously optimized and further developed. Good for the customer, good for us.

Last but not least: How does a customization process work?

In a few words: After the customer has articulated a wish, our technical team checks the effort. Then we write an offer or submit an alternative suggestion. In case of larger adaptations we work out specification book, which is the foundation for technical implementations.

At the end of the day, one thing is particularly important to us: a customer who gets exactly the BlueSpice wiki he needs for his day-to-day work in his company.

Let’s Wiki together!


More information about our migration services can be found here:

Test BlueSpice pro now for 30 days free of charge and without obligation:

Visit our webinar and get to know BlueSpice:

Contact us:
Angelika Müller and Florian Müller
Telephone: +49 (0) 941 660 800

Author: David Schweiger

You Might Also Like

Leave a Reply