If you like LiipRokkaImagineBundle extension, the github star will be very much appreciated. Please also do not hesitate to create tickets or pull requests, if you notice any issues or would like to make an improvement to the new extension.

Since the architecture of the framework has drastically changed, I expected many troubles. But in fact, it was even a little bit easier than for M1. From the development point of view it was definitely more pleasant to work with the code, but I also wanted to test the complete path to the fully merged pull request.

Step #0 (Local dev setup)

For the local setup I decided to use Magento2  docker devbox, and since it was still in the beta state I ran the first command without any hope for smooth execution. But surprisingly I had no issues with the whole set up. By executing few commands in terminal and cup of coffee, Magento 2 was successfully installed and ready to use. Totally positive experience.

Step #1 (Configuration)

All I had to do is to declare my search model in di.xml, not too hard, right ?)

app/code/Magento/Backend/etc/adminhtml/di.xml

Step #2 (Implementation)

Implementation of search itself was trivial, we just have to look for matches for a given keyword in the ConfigStructure object using  mb_stripos().

app/code/Magento/Backend/Model/Search/Config.php

Step #3 (View)

The same as for M1, the result of the search is a list of URLs to the matched configuration label. When the user clicks the selected URL, they are redirected to the config page and the searched field is highlighted.

That would be it regarding the implementation :)

Step #4 (Afterparty)

Too simple to believe? You are right. I thought that it is enough for submitting the PR. But I completely forgot about tests :) This one of main requirements for accepting pull request by Magento Team.

Since all implemented code was well isolated (had no strict dependencies), it was pretty easy to write tests. I have covered most of the code with unit tests, and for the main search method I wrote the integration test.

Conclusion

I would like to point out that during the whole cycle of the pull request, I had fast and high-quality support from the Magento team. They were giving useful recommendations and consulted me sometimes even during their vacations. This is what I call outstanding interaction with the community!

My special thanks to  Eugene Tulika and  Igor Miniailo, and of course Dmitrii Vilchinskii for the idea for creation this handy feature.

The February 2nd 2017, I have presented a talk entitled Hello, Rust! — An overview about the Rust language. This language describes itself as safe, concurrent, and practical. The goal of this presentation was to give an overview of several features brought by the language, such as its strong safety guarantees, or speed and memory performances.

The slides are available online

First slide from the Hello, Rust! talk

This talk has been presented during the first TupperRust meetup event in Lyon (France) . This is a serie of meetups focusing on Rust. The interaction was exceptional: The audience has been a great actor of this talk, and we even had a live-coding session on projects made by someones in the room. It was a great moment to talk about concrete problem, memory safety, performance etc.

It was also an opportunity to present a project that I have started here at Liip, called Tagua VM, which is an experimental PHP Virtual Machine that guarantees safety and quality by removing large classes of vulnerabilities thanks to the Rust language and the LLVM Compiler Infrastructure.

If you have any question, feel free to ask anything!

Issues with unaccessible application

Accessibility is not just a matter of helping people with disabilities. Of course, it is very important that an application can be used by everyone. But, have you ever considered that robots are visitors with numerous disabilities? What kind of robots you may ask, well: Search engine robots for instance, like Google, Bing, DuckDuckGo, Baidu… They are totally blind, they don't have a mouse, they don't have a keyboard, they must understand your content only with the source code.

Whilst it is easy to consider a man or a woman with a pushchair having a bad time in public transport, someone color-blind, a widespread disability, could also have issues browsing the web.

Several domains are concerned by the accessibility of an application:

• Content description , the use of appropriated HTML tags and attributes help to structure the content of a document (like nav, main, article, aside, footer etc.),
• Design of the content , the use of appropriated colors, contrasts, size of elements, layouts, animations etc.,
• SEO , a content that is understandable by a robot can be well referenced, and search engines can print more content, like associated links or menus (with “Jump to”, or “Related section” etc.),
• Development framework , using ARIA recommendations help to create rich applications with good, clear and relevant practices (aria-hidden to hide an element, aria-describedby to describe objects, all roles like tab, tabpanel, progressbar, alert, dialog etc. to create your own component),
• Legal , where more and more foundations or group of people attend to sue companies for not respecting common recommendations. Unfortunately, while this might be good to improve the status of accessibility for Web applications, it also turns into a juicy market…

In other words, from an editor's point of view, making a product accessible is unavoidable, and even beneficial.

Do not think that the mobile market is somehow different. iOS and Android are gently becoming the first screen readers of the market, even for Web content.

However, testing the accessibility conformance is often a matter of money. It is costly because it takes time to check everything. Now, this is no longer the case.

E-commerce solution of a luxury brand

Our client, a famous watchmaker's application is an important e-commerce solution, with more than 16 domains, 10 languages, 1000+ products, and hundreds of thousands of visitors from around the globe.

A simple calculation quickly shows that it is very hard to check the application page by page (better say URL by URL). Content can differ according to language, the business constraints, available products, localized features etc.

For this reason, we were looking for a tool that does 3 things:

1. Crawls an entire application based on a starting URL,
2. Tests each URL against pre-defined conformance levels/accessibility rules,
3. Can be installed locally for privacy concerns.

Searching online, we found several awesome tools doing either point 1, or point 2, or point 3, but never all 3 at once. So we decided to develop our own tool, called The A11y Machine (a11ym for short). More below.

Conformance levels

Several accessibility recommandations exist, like:

• W3C Web Content Accessibility Guidelines (WCAG) 2.0, including A, AA and AAA levels ( understanding levels of conformance),
• U.S. Section 508 legislation.

We might consider the following recommandation too:

• W3C HTML5 Recommendation.

Conforming to the HTML specification guarantees that the document is not broken, which is a good basis.

Our client's goal was to reach the WCAG 2.0 AA conformance level, with HTML recommendation. Some other specific SEO rules have been added, like: Only one h1 per page, or no link with an empty target ( Learn how to write your own rules).

Results

In less than 100 hours, we have been able to fix more than 1300 strict errors and 400 warnings. As a result, with a team of 3 motivated developers, it took around 4 days to fix everything (including developing The A11y Machine)!

Given a starting URL, The A11y Machine extracts each URL from this document. For each extracted URL, the same operation is repeated until the maximum of URL to compute is reached.

In parallel, several tests are ran on each URL. They are categorized in 2 groups: Accessibility (e.g. WCAG) and other (e.g. HTML). Test results are stored as standalone HTML reports. Why standalone? Because it makes it possible to simply attach the report to an email, so that everyone is able to read and interact with it, even offline.

A report contains only errors. They are classified in 3 classical categories: Error, warning and notice. A CSS selector is provided to better select and analyse the culprit element, in addition to a very complete description, and a link to the recommendation. For instance:

• Error: “This button element does not have a name available to an accessibility API. Valid names are: title attribute, element content”,
• Code: H91,
• Rule name: #BRAND.Principle4.Guideline4_1.4_1_2.H91.Button.Name,
• Selector: #reel-collection_product-section-580456752a01b > button:nth-child(1),
• Code extract: <button class="reel__previous btn btn--bare btn--disabled" data-navigate="previous">.

A typical error message

With all these information in hands, it is really easy for a developer to target the element and fix it. Accessibility recommendations are not always hard to apply. Indeed, they are mostly hard and long to detect. This tool really eases this step, thus reducing the costs of making an application accessible.

Automated testing and reports

Every Monday, a11ym  computes a new report. It crawls a set of pre-defined URLs that are important for our customer, and applies all the tests on these URLs.

A board displays the evolution over time. For obvious confidentiality reasons, we cannot display anything about our client. Consequently, the following screenshots are reports from our own website: liip.ch.

Example of a typical a11ym dasboard.

We regularly check this board to see if we have introduced a regression or not. When developing, we can also run The A11y Machine on our local server and check if everything conforms. It takes less than 10 minutes to check hundreds of URLs.

The following screenshot is the index of all reports per URLs.

A typical index of all reports generated by a11ym.

The following screenshot is a detailed report for one specific URL.

A typical report generated by a11ym

Build upon awesome tools

The A11y Machine is mostly an orchestration of several tools:

• node-simplecrawler to crawl the Web application, but a custom exploration algorithm has been developed to detect various errors with the lowest similarities (all products may have the same portion of errors because the HTML structure is rather the same, so we need diversity to target more relevant errors). This exploration algorithm also supports parallelism,
• PhantomJS to open a headless browser and executes HTML_CodeSniffer in order to check the accessibility conformance. This step is semi-automated with the help of pa11y,
• The Nu HTML Checker for the HTML conformance.

Learn more about how these tools are used and orchestrated.

We ❤️ Open Source

The A11y Machine is open source, under a BSD-3 license. It is developed on Github, under the liip/TheA11yMachine repository.

If you need anything or would like to contribute, you will be very welcome. Let's break the barriers together and make the Web more accessible!

The current result is a starterkit providing the essential bricks to start in a snap a website project for the federal government running with Drupal 8, based on the version 3 of the official styleguide.

Navigation modules, multilingual environnement per default (German, French, Italian, Rumantch and English), responsive layout following the Web Content Accessibility Guidelines, we threw the fundamental stones for bootstraping a web platform for the Confederation.

con~foederatio : to build a league, together.

In other words, joining forces, to support a common cause. From the very start of the project we decided to opensource the code, as a participatory initiative.

Learn more about this intent.

Any developer working on a new website for the swiss government can now quickly start developing with this Drupal starterkit, then modify, contribute and improve it collegially. Pulling requests and opening issues on GitHub is the recommended way to help us extend further the project.

What's inside the box

The Bund-Starterkit provides theme and elements based on the official styleguide (version 3.0.0) of the Swiss Federal Administration.

This starterkit also contains a base to quickly implement a website running on Drupal 8 for the Swiss Federal Administration. Currently, it provides the following Drupal and frontend elements:

• Multilingual main navigation blocks
• Multilingual service navigation blocks
• Multilingual footer service navigation blocks
• Logo block
• Language switcher block with German, French, Italian, Rumantsch enabled
• All the assets (CSS, SASS. JS files) provided by the official styleguide
• A ready-to-use SASS workflow

Installation process, an overview

Please check the Readme file to quickly start your project. But let's have a look at the details of the installation process. First of all, Composer (a PHP dependencies manager) is binding together for us the following repositories:

• a Drupal 8 installer
• a theme:  bund_drupal_starterkit_theme
• an installation profile:  bund_drupal_starterkit_profile

• a module for importing menu content:

  bund_drupal_starterkit_dummycontent

After downloading the sources with Composer and setting your vhost and hosts files, you have two options. Continuing with a few drush commands to run the Drupal installation process, or following the installation wizard in the browser. If you choose this last option, don't forget to select the «Bund profile» option when the wizard ask you to choose a profile:

Continue with the last steps of the wizard and that's it. you should be able to see an empty Drupal 8 website, painted with the swiss administration's corporate sauce.

Inserting menus content

With the help of a .CSV file and some drush commands, you can quickly import your menu structure. Once done, create and assign your content the the freshly created menu items through the Drupal administration interface.

Theming

Don't forget to create a personal Drupal sub-theme from the bund_drupal_starterkit_theme, as a Drupal best practice.  Don't edit the existing theme directly or you could loose your changes after a future update.

Frontend

This starterkit use the official styleguide (version 3.0.0) as a submodule. All existing CSS/JS files and assets are imported and available per default, but not necessary integrated as a drupal module at the moment. We highly encourage you to check the official styleguide before adding any new CSS style or JS files to your project. Based on the existing styles, it should be possible to create a lot of Drupal templates without modifying or extending any CSS. And as already said, we invite you to share any Drupal template matching the styleguide you would develop for your project.

Further reading

• Official styleguide
• Official announcement by Jenny Bächtold
• The Drupal starterkit repository
• An article  about the realization of the Style Guide of the Swiss Confederation
• A blogpost by Ludovic Turmel

The Drupal 8 starter kit from Liip affords the federal administration a considerably high degree of flexibility in how it develops its digital presence and online services. This powerful and freely available tool set will dramatically cut the time the federal authorities and their respective partner agencies have to spend on developing a new website, thereby letting them invest resources in those areas will real added-value potential. Liip is a firm believer in open source software and actively encourages its uptake across the public sector. With the opening of its brand-new office in Bern, Liip is one step closer to realising this ambitious goal.

Liip hopes that the release of the starter kit will lead the Swiss Drupal community and other agencies to get on board too. The kit is on Githuband can be used by all federal offices and agencies free of charge.

Background information

What is a style guide?

A style guide is basically a website made up of filler text which makes it easier to establish a consistent corporate identity across multiple channels. It explains how the various components should be used, how they should appear and how they interact with each other. A style guide lets businesses and agencies build websites that are not only compatible with commonly used devices and browsers but also comply with the latest corporate design rules.

As the US Federal Government and the UK Government Digital Service prove a style guide is a long-term, flexible solution for anyone with a multiplatform digital presence.

Why do the Swiss authorities need a style guide?

Every single one of the assorted official websites of the federal authorities has to comply with the “Corporate Design of the Swiss Confederation”. A style guide in HTML, CSS and JS ensures that these rules are applied correctly.

In Version 3 of the federal style guide, all elements comply with the latest technical guidelines and the corporate design rule book of the Swiss Confederation. They are also accessible from and compatible with all popular browsers.

To the style guide

Why develop a Drupal 8 starter kit?

Given the sheer number of federal websites and their individual specifications, it takes more than just one CMS to do the job. However, the open-source CMS, Drupal, offers a viable and tried-and-tested alternative to the single standard system. Added to this is the fact that there are no licencing costs involved, which is welcome news for smaller-scale projects or for government offices that have to work on a limited budget. Also, as the style guide is in the public domain, it makes it easier to exploit the full potential that Drupal offers.

The Drupal starter kit defines the navigation modules and comes with a multilingual environment as standard – German, French, Italian, Rumantch (Switzerland's four national languages), and English. It also has a responsive layout that is compatible with all end devices and follows the Web Content Accessibility Guidelines. What this means in practice is that the various offices, departments and partner agencies of the Swiss government are able to build a basic website within the space of five minutes and save valuable time setting up different content types, thereby allowing them to focus their energies on developing the relevant additional applications. 

The technology behind it

Courtesy of Liip, the official web style guide of the Confederation comes as a Git sub-module which automatically connects to Drupal via Composer, allows users to important sample content easily and effectively. Web developers also receive an integrated modern front-end development tool kit. Together, the  workflow tool Gulp, the test tool BrowserSync, and AutoPrefixerare a user-friendly and efficient SASSset-up.

Why open source?

Having worked on the official style guide, the Liip team decided to take it one step further and make it available as a Drupal theme.  They open-sourced the code in order to prevent time being wasted on needlessly reinventing the wheel, and to ensure that a wider network was involved in the implementation of the starter kit.

Thanks to the starter kit, project managers and developers within the federal administration or working for partner agencies can now get stuck into new web projects straight away. The Liip team also hopes that a new kind of working relationship will emerge, with users joining forces to adapt and improve the the kit in a cooperative and constructive way.

Liip firmly believed that open civic technology can play a key role in the digitisation of government services in Switzerland.

Who is Drupal 8 starter kit?

The Drupal starter kit is ideal for any institution that has multiple websites and portals which share more or less the same design and for which the use of an open-source CMS like Drupal could be an option. The ideal candidates are websites that require a high degree of flexibility and feature embedded applications.

The federal authorities and cantons often have multiple websites that are maintained by different institutions but still have to be visually consistent, hence the use of a style guide in HTML, CSS and JS. The starter kit is the ideal solution when multiple websites are involved as it not only guarantees a uniform appearance but it also saves valuable time and money.

We live in a time where more and more goods are purchased online. May it be your airline ticket or the diapers for your newborn, many things are often cheaper and more conveniently purchased online. As comfortable it is for the customer buying things this way, as challenging it can be for the seller. They need to have an online presence that is easy to use and need to have all goods in stock to sell and send them quickly.

This means that selling physical products requires sufficient storage space on-site, people that handle picking, packing and shipping and someone that handles returned goods. All this factors can sum up to a costly venture, especially when you don't have any infrastructure from other sales channels already.

The PHP-YellowCube interface is part of all YellowCube extensions for PHP based web stores

What is order fulfillment?

This is where YellowCube comes in handy. YellowCube is a fulfillment service offered and run by Swiss Post. But what is a fulfillment service anyway? In the case of YellowCube it means everything to do with the storing and shipping of the products you sell on your store. This means receiving and storing of the products, handling of the inventory, picking, packing, shipping and handling of returns.

How to implement it into your web shop?

So far so good, but how does this translate into real life? Liip has, in close collaboration with Swiss Post, developed a PHP-YellowCube-SDK and also the integration for Magento and Drupal web shops. The PHP-YellowCube interface provides an object-oriented wrapper to the SOAP based interface provided by Swiss Post. The code is readily available on Github. Please feel free to contribute to the PHP-YellowCube-SDK, as well as the  Magento extension or the Drupal extension.

Please explain…

Now that we know about the SDK, we need to know how the basic process works. I want to show you what needs to happen in order to implement YellowCube successfully into a web shop. The process is agnostic to a certain integration, so I won't go into details how it is integrated in a specific shop extension. I will explain the basic process, which applies to all web shop integrations in the same manner (more or less).

Go with the flow

The flowcharts below show you the process and the different “actors” involved (swim-lanes). The red coloured lanes represent the web shop and the yellow lanes show the services provided by YellowCube and exposed by our SDK.

First we need to have products in our web shop. For simplicity lets assume that all the products in our web shop are products handled by YellowCube.

Feeding data into the system

As Swisslinux.org member, I again had the opportunity to take part to the Rencontres Hivernales du Libre (roughly translated as ‘Winter Libre meetup'), up in the jura, in St-Cergue. This week-end-long meetup, organized for the second time this year, aims at gathering all libre-related actors. This article, originally written in french, tells you the story of what happened there, who attended and did what.

Les Rencontres Hivernales du Libre, deuxième édition

Dans le cadre de l'association Swisslinux.org dont je suis membre, j'ai à nouveau eu le plaisir de participer aux Rencontres Hivernales du Libre, du 8 au 10 janvier passés. Ces rencontres, organisées pour la deuxième fois en 2016, ont pour but de rassembler les acteurs romands du Libre, dans sa définition la plus large.

30 geeks à St-Cergue

Dès la première édition, l'idée a été de profiter d'une période et d'un cadre moins usuel, en allant chercher la neige là où elle est. Viser une expérience de “conférence” plus large; entre informatique et loisirs extérieurs. Lors de l'édition 2015, le beau temps avait permis à plusieurs participants de profiter de chacun de ces deux aspects, entre ski et surf.

Le lieu choisi cette année a de nouveau été le Centre du Vallon, à St-Cergue, pour son bon compromis entre proximité aux transports publics, enneigement et coûts.

Malheureusement, les conditions météorologiques de l'édition 2016 ont été moins profitables, avec un faible manteau neigeux, arrosé de pluie durant tout le week-end. Bonne surprise cependant, avec l'incinération des sapins de Noël de la commune, organisée devant le local par les pompiers, qui a amené une grande bouffée de chaleur à ce week-end maussade.

Il s'y est passé quoi ?

Répondant à l'appel de Swisslinux.org, plusieurs associations et organismes étaient présents, favorisant ainsi les échanges inter-disciplinaires et les discussions animées. Petit tour de présentations.

Les bricoleurs du Post Tenebras Lab(le hackerspace genevois) ont profité d'une salle d'atelier pour travailler sur un système de paiement sans fil entièrement libre (matériel et logicel). ATICOM, association orientée vers l'enseignement et la pédagogie, a présenté ses activités lors d'une conférence. Doxel.org a présenté ses dernières avancées en photo-grammétrie avec des senseurs optiques non-calibrés: impressionnante combinaison de technologies pour la reconstitution de scènes tri-dimensionnelles à l'aide de photos prises par des téléphones portables. L' IAPC a amené et mis en place tout le matériel nécessaire pour l'implantation d'une station radio-amateur: entre l'antenne d'un mètre cinquante et les équipements électroniques, l'ensemble en a impressioné plus d'un. Axel & Frank, venus de loin, ont présenté leur projet collaboratif de livre sur les techniques d'empaquetage pour  Debian (en allemand). La présentation a abordé les défis éditoriaux (trouver, puis convaincre un éditeur de la viabilité et de l'intérêt d'un livre libre) et les défis techniques (collaboration à deux personnes géographiquement distantes sur un même ouvrage, ouverture de la rédaction aux contributeurs externes, assurer la construction et la distribution du livre dans différents formats, etc.).

Défis et Organisation

20 personnes étaient déjà présentes vendredi soir, pour un souper en commun “ à la bonne franquette“. Le lendemain soir, 8 caquelons de fondue ont été servis aux 35 participants. Ensuite, si d'aucuns restaient sur leurs laptops, d'autres ont laissé leurs claviers de côté pour des discussions ou des jeux de société. Autant dire que la soirée ne s'est pas terminée tôt!

L'organisation d'une telle conférence, bien que modeste en nombre de participants, est tout de même une suite de défis à relever. Au niveau des repas, la décision a été prise de prendre une équipe professionnelle pour la cuisine: ce fut une bénédiction culinaire! Si mettre en place et maintenir une infrastructure sans fil pour 30 participants n'est pas si compliqué en théorie, en pratique, ce n'est pas le WiFi qui a failli, mais l' uplink Swisscom. La conférence s'est donc terminée en accédant à l'Internet par la 4G.

Swisslinux.org remercie les différents parrains qui ont permis la tenue de cet événement: le GULL et  ATICOM pour les soutiens financiers et Liip pour avoir assuré la logistique et le financement du café pour tout le monde.

À l'année prochaine, pour une nouvelle édition, qu'on espère enneigée!

Problem description

Imagine a usual Drupal installation already deployed on a live server. Imagine further that there is a demand to update at least one module of this installation without human interaction, any downtime, and data loss. The default work flow when updating configuration information would either demand human interaction and/or the complete deinstallation and reinstallation of the module which, when the hook_uninstall() correctly implemented, will cause data loss. A third option is to write a script to setup the new module after the installation process is done but this would challenge the deployment system to support some kind of a post_deployment process.

What was the goal?

The goal of this hackday was to propose a solution which enables a development team to continuously deploy and maintain a Drupal installation without being forced to uninstall modules to do a major update. Further more there should be some kind of a mechanism making it possible to update modules without human interaction when deploying the modifications.

Solution proposal

One of the most beneficial Drupal extensions is the Drupal shell (short: drush). It provides an extensive variety of commands to maintain Drupal (e.g. managing modules, users, and basic drupal configuration). The nice thing about drush it can be handled by any shell script just calling the specific commands and processing their outcome. Extending drush was therefore the most natural thing we could think about when we were confronted by this task.

So we came up with a drush extension providing a new Drupal hookhook_vm_update().

Custom hook_vm_update

Located in the *.install files the hook_vm_update() will be invoked by the drush extension. Further does the extension detect the existence of the custom hook and indicates this on the command line.

$drush vm-update  "myCustomModule, myOtherModule"

Updating myCustomModule ... no »vm_update« hook available        [warning]
Nothing to update for module »myOtherModule«                     [warning]

Custom scripts

In order to keep track of previous installed module versions we wrote two scripts. One does write down the currently installed version into a text file. The other one invokes drush to for modules which got changed since last deployment.

Further ideas

Add version information to hook_vm_update

Currently the update hook will always be called when the drush command is invoked and the previous installed version is smaller then the just installed one. Having only one hook implies that this hook knows which steps needed to upgrade from one version to another (including steps in between). What about a naming convention for hooks combined with version number and a logic to call them in chronological order, up to the target version (like Drupal core updates use schema update hooks).

Since the hook should not invoke actions potentially dangerous or harmful in terms of data loss et. al. this should not be much of a problem. But since we can already imagine situations where it is useful to either step through past updates or make the hook decide whether it an update is to be invoked or not one of the next steps for this drush extension will be to provide version information for an update.

Persist version information into the database

The versions.json file resists on the file system and could be potentially overwritten by a new installed package. An alternative could store the version information into the database (e.g. by using the Drupal configuration with variable_set() ?).

Final thoughts

We had some fun working on a solution for this given problem. We had the chance to look deeper into drush. We learned yet some php functionality we never used before. Unfortunately the weather was not nice and we could not fire up the grate for lunch.

Last but not least thanks L//p for this opportunity!