Municipal sites for PNRR measure 1.4.1

Where the two sites started from

The two municipalities already had a Drupal site, with a content structure far from the municipal model. Their online services lived on the Maggioli platform, with a separate login: citizens looked for them outside the municipality's site and logged in a second time.

Measure 1.4.1 funds municipalities after an assessment, a check of the conformity criteria of the Designers Italia model. Many criteria are about structure: the first-level menu entries in the model's order, the titles of second-level pages, topics taken from the European vocabulary EuroVoc, the mandatory items of every service page. On those two sites they touched almost every page.

What I did on the two sites

• Content: I rebuilt the content types and vocabularies on the types of the Designers Italia municipal model, and migrated the existing content onto them with a custom script.
• Theme: the base is bootstrap_italia for Drupal, with a subtheme bringing the municipal model's styles.
• Services: pagoPA payments, applications and case files, and appointment booking from the Maggioli (opens in a new tab) platform each have their own page on the municipality's site, read from Maggioli's APIs.
• Performance: tuning and caching, to serve pages ready-made and keep them above the Lighthouse threshold the model asks for.
• Single sign-on: whoever logs in on one site is already in the other, and whoever logs out of one leaves both, through a remote logout at the provider.
• SPID and CIE: an external authentication intermediary verifies the identity, Shibboleth completes the flow, and the module I wrote finds or creates the Drupal user from the tax code.
• Editorial teams: I took the administrations through several training stages, above all on creating content and managing events.

How I migrated the content

The model defines the types: services, offices, documents, news, events, places, people in the administration, each with its own fields and links. I created the matching content types and vocabularies in Drupal, then a custom script reorganised the existing content onto them.

Rewiring the structure was the complex part, because types, fields, vocabularies, the menu tree and the links between pages all changed together. An old article could become a news item, a document or an office page, depending on what it told. The sorting rules all lived in the script, so they were fixed and run again in one place.

How the Maggioli services reach the site

The services are delivered by the Maggioli platform, which syncs and exposes their pages through its APIs. The municipality's site reads those APIs and presents each service with the page the model asks for, including the administration's maximum response time. The actual action, paying, submitting an application, booking, leads to the platform.

The service catalogue stays where the services are delivered, and the citizen starts from the municipality's site to reach the service.

How single sign-on is built

The module is written from scratch because the existing modules, spid and samlauth, assume that Drupal talks directly to the identity provider, while here Drupal sat at the end of a chain and the session had to hold on the Maggioli platform as well.

Logout works both ways, like login. Maggioli's specification asks for it from anyone who turns on single sign-on, because a session left open on a shared computer exposes personal data. To recognise the user the site keeps only the tax code: every piece of data the site keeps out is one less to protect.

This part took us much of 2025, because of the number of systems that had to talk to each other. The work ran smoothly, because Maggioli's documentation on the API integration was clear and thorough.

How the two sites stay above the Lighthouse threshold

Criterion C.SI.4.1 asks for a Lighthouse score of at least 50, in mobile mode, on every page of the site, and below that threshold the municipality publishes an improvement plan. On both sites we did tuning and worked on caching, to serve pages ready-made, including the ones that read the services from the Maggioli APIs.

Who I worked with

I did the project with I.T.Svil (opens in a new tab). On the other side were Maggioli, with the service platform and its documentation, and the municipalities' editorial teams. The staff who followed the training were skilled, and the sessions went entirely on the rules of the model: which type to use, how to write a service page, how to handle an event with its dates, its venue and the link to the office organising it.

What changes for a new project

Drupal 9 has been out of support since 1 November 2023, so a project today starts from Drupal 10 or 11, with a version of bootstrap_italia that supports them. And since the 28 March 2025 revision of Maggioli's specification, logging in with the CIE goes through OpenID Connect: the single sign-on bridge has to be designed on that flow.

Sources

All sources were checked on 1 October 2026.

• Conformity criteria of the municipal site model (opens in a new tab), Designers Italia. Primary source.
• Integrating the online service desk with the institutional site, rev. 6 (PDF) (opens in a new tab), Maggioli, 28/03/2025. Primary source.
• PA Website Validator NG (opens in a new tab), Developers Italia. Primary source.
• spid module (opens in a new tab) and samlauth module (opens in a new tab), drupal.org. Primary source.
• Drupal 9 end of life (opens in a new tab), drupal.org. Primary source.
• Bootstrap Italia for Drupal (opens in a new tab), drupal.org. Primary source.
• The work on the two sites with I.T.Svil. Author's experience.