# CERN's Online Presence: An Evaluation of WCMS **Table of Contents** [TOC] <small>_Contact: web-team@cern.ch_.</small> ## Executive Summary CERN has used Drupal, an open-source content management system, since 2012 and now more than 1200 publicly accessible CERN websites use it. Drupal 9 reaches end-of-life in November 2023 and migrating to Drupal 10, due to its underlying code dependencies, will be harder than any previous migration. We have already suffered the years-long migration to Drupal 8, intense efforts to Drupal 9, and the recent migration to PHP 8.1. However, with Drupal 10, content created using CERN-official modules risks being incompatible and websites may need complete rebuilding. It is time to evaluate CERN’s online presence. CERN chose Drupal in the hope to solve many requirements. But, more than a decade on, these requirements are only partially solved (e.g. ease of use), unresolved (e.g. search and accessibility) or worsened (e.g. maintenance). Many at CERN find Drupal difficult to work with, and its steep learning curve requires multi-day training. Drupal demands continuous effort and resources for ongoing maintenance and updates, such as monthly security patches, related to both the infrastructure and individual websites alike. As the Drupal ecosystem continues to wither (1.2% of websites use Drupal), this cost will increase. The IR web team and IT infrastructure team centrally manage the _CERN Drupal Distribution_, addressing Drupal's inherent fragmentation and dependency challenges. However, hundreds of CERN websites have been heavily customised, often without documentation. These are hard to maintain, their functionality often breaks during updates and they generate the most support queries. Huge effort would be needed to streamline these websites and remove their customisation, involving both IR and IT teams and individual website owners. A lighter, modern, and more flexible content management system is the market-leader: WordPress (used by 43% of websites). It is not a magic solution for CERN, but by building on lessons learnt, investing in a solid WordPress infrastructure, disabling customisations and improving overall web accessibility, we will meet virtually all the requirements initially set out when CERN chose Drupal. Additionally, WordPress costs are expected to be predominantly in the transition phase, after which CERN will benefit from a larger developer community, extensive backwards compatibility, and automated upgrades. The IR web team has tested automated content migration from Drupal to WordPress, and results are promising. Initial work on integrations with CDS, Indico, e-groups, and the CERN SSO, as well as official CERN themes, has started in earnest, but needs to be completed. The IT infrastructure team requires resources to create a new WordPress infrastructure, while maintaining the existing Drupal infrastructure during the transition. Another noteworthy alternative is to migrate certain Drupal websites to GitLab Pages and using a static site generator. This is useful for a subset of websites that are text-based, do not need to be updated frequently and are maintained by technically experienced people comfortable with using version control systems. Significant costs are associated with staying on Drupal and moving away from Drupal. But staying on Drupal means costs will increase proportionally with growing maintenance and compatibility demands. WordPress, on the other hand, requires an initial investment after which costs will decrease. A fast management decision and swift technical action is needed, given the end of life of Drupal 9 this November. ## Recommendation :::info Drupal is expensive to maintain and support. Major releases like Drupal 10 and beyond require substantial resources across CERN to successfully complete. As the Drupal ecosystem continues to wither, and the average age of CERN's websites continues to increase, the overall cost of merely keeping websites online increases. Currently, 6.25 FTEs across two teams are assigned to Drupal, effectively excluding all other projects that would otherwise have benefitted the wider CERN community. Additionally, and despite this investment, Drupal is unlikely to ever address our requirements.<br/> Migrating to WordPress is a significant undertaking, but also one, if done correctly, of huge potential. We will be able to tap into a modern and very active ecosystem running 43% of all websites (compared to 1.2% for Drupal); achieve responsiveness for mobile and tablet users; `AA`-level web accessibility; and much more while easing both support and future maintenance.<br/> Resource-wise, WordPress requires a new infrastructure (additional 2.0 FTEs), new integrations (additional 0.8 FTE), and a one-time website migration not entirely different from what Drupal 10 is already expected to require (additional 1.0 FTE). Additional expenses are necessary to outsource and coordinate the creation of CERN themes (additional 0.2 FTE). Detailed implementation information is available [here](https://codimd.web.cern.ch/s/0vGLgq87N#Implementing-WordPress). Importantly, these additional resources are only needed for the duration of the migration.<br/> Once a robust infrastructure built with the experiences we have from Drupal is in place, and websites have been migrated, we will begin to reap the benefits: a modern, secure, and flexible content management system that requires less maintenance while also meeting our requirements to fully support CERN's online presence.<br/> **We recommend moving away from Drupal to WordPress.** ::: ## Introduction Since 2012, CERN's online presence has been supported by the open-source content management system (CMS) Drupal (https://www.drupal.org/). As of 2023, more than 1200 publicly accessible websites (`.cern` and `.web.cern.ch`[^domains]) are running Drupal. However, despite significant infrastructure advancements and automation in recent years, the cost of supporting websites is increasing. The increase in material and personnel cost applies not only to IR and IT resources, but also to those owning or managing websites across CERN. A long-term strategy of CERN's online presence needs to consider the software underpinning that presence as well as the associated maintenance and support. As Drupal currently underpins CERN's online presence, the IR web team has conducted a thorough evaluation of Drupal with both technical, budget, and end-user considerations in mind. In particular, we evaluated: - (a) the current state of Drupal; - (b) what Drupal has accomplished at CERN; - (c\) the challenges we face today and why; and - (d) the cost of staying with Drupal. It is prudent to also evaluate alternatives to Drupal, as the requirements and alternatives applicable when Drupal was originally chosen have changed dramatically today. Accordingly, we conducted a feasibility study of - WordPress[^wp]; and - static-site-generators (via Gitlab Pages[^gitlab_pages]). These are both alternatives to Drupal that are widely used across intergovernmental organisations and large enterprises (e.g. https://www.whitehouse.gov/, https://www.ipcc.ch/, https://sweden.se/, and https://www.berkeley.edu/ for WordPress; https://digital.gov/, https://beta.gouv.fr/, https://devices.netflix.com/, and https://worldstatisticsday.org/ for static-site-generators). We present the results of this study alongside our recommendations in the second half of this report. In considering alternatives to Drupal, we further evaluate components of CERN’s online presence that are not currently present, but likely should be, such as web accessibility and enforceable design guidelines. ## Drupal at CERN The timeline below summarises CERN's experience with Drupal: - 2010: Decision to use Drupal following ENTICE meetings[^entice]. - 2010&mdash;2012: Initial work on Drupal (infrastructure, integrations, themes). - 2012: `home.web.cern.ch` launches on Drupal 7. - 2012&mdash;2017: Drupal 7 is rolled out across CERN. - 2015: CERN moves its main website to `home.cern`. - 2017: Contract to migrate to Drupal 8 begins. - 2018: `home.cern` launches on Drupal 8. - 2018&mdash;2020: Drupal 8 is rolled out across CERN. - 2020&mdash;2021: Migration to OpenShift infrastructure. - 2021&mdash;2022: Drupal 9 is rolled out across CERN. - 2022&mdash;2023: PHP 8.1 is rolled out across CERN. - 2023: Drupal 9.5 is rolled out across CERN. - *2023&mdash;2024: Drupal 10...* - *2024&mdash;: Drupal 11...* With limited backwards compatibility and numerous upstream dependencies with independent release schedules, **Drupal demands continuous effort and resources for ongoing maintenance and updates.** In addition, specific to CERN since 2021 is the _CERN Drupal Distribution_[^drupal_dist]. This curated distribution of Drupal contains both official CERN modules and themes as well as a collection of verified third-party, community-contributed modules. Indeed, a majority of the modules providing much of the functionality used across CERN are third-party, community contributed modules. Recognising the significant workload in developing and maintaining equivalent functionality via official CERN modules, we devised a rigorous verification process through which third-party modules can be included in the distribution. Two years in, the centralised _CERN Drupal Distribution_ has proven a substantial improvement compared to earlier iterations of Drupal at CERN where websites installed and managed individual copies of many of the same modules. However, any module not developed by the IR web team, but nonetheless used widely across CERN, is ultimately subject to its own release schedule and set of sub-dependencies. Managing the _CERN Drupal Distribution_ thus requires the consideration of both upstream (i.e. releases to Drupal itself, also known as _Drupal Core_) and downstream (i.e. individual modules adding functionality to Drupal) components and their individual requirements when ensuring overall compatibility. This flow is illustrated in `Figure 1`.  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 1: An overview of the flow of updates between CERN and the Drupal ecosystem. Click the diagram to zoom. </p> In 2022, the IT infrastructure team and the IR web team accommodated 38 minor Drupal Core releases[^d9_releases], several of which deprecated functionality in Core and/or community-contributed modules, demanding patches and additional updates. **As Drupal security patches are released on a monthly basis, CERN has to continuously upgrade**. In addition to Drupal itself, individual modules received hundreds of releases throughout 2022; both security, feature, and compatibility updates. CERN-official modules alone received more than 45 updates combined to ensure continued compatibility. All were ultimately bundled together by us with new versions of the _CERN Drupal Distribution_, when applicable. A new version of the _CERN Drupal Distribution_ requires us to perform extensive testing on development websites before rolling it out across CERN. It should be noted that the _CERN Drupal Distribution_ is what allows us to manage thousands of websites with a very lean team in the first place. In comparison, as we learnt at _DrupalCon 2022_[^presentations], most teams operate with an average of less than two websites per developer. At CERN, we have been managing more than 200 websites per developer. Thankfully, due to extensive behind-the-scenes work, automation, and strong collaboration between IR and IT, all websites have been updated seamlessly. :::warning The above workflow describes the **best-case-scenario** in which a website strictly adheres to what is offered by the central _CERN Drupal Distribution_. **The hundreds of websites across CERN that employ additional customisation face several compatibility and instability challenges, generating a significant majority of our support queries.** ::: A customised website would update `Figure 1` to what is shown in `Figure 2`. Some websites utilise just a few custom modules while others integrate more than 30. Additionally, due to sub-dependencies, many modules require specific versions of other modules or certain configurations directly in Drupal or in parts of the _CERN Drupal Distribution_. In many cases, customisations have been made by people no longer at CERN and documentation is lacking, making it challenging to support and maintain these websites. In some instances, the specific configurations result in circular dependencies, further taxing both support and security.  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 2: An example overview of additional customisation applied to a specific website. Click the diagram to zoom. </p> In short, if work with Drupal seems endless, it is because it is. ### What has Drupal accomplished? It is important to recognise that Drupal presents an improvement compared to the disorganised and decentralised state of CERN's online presence pre-2012. Indeed, the transition to Drupal was largely borne out of a desire to address or otherwise provide solutions to the requirements and wishes outlined in `Table 1`. <style type="text/css"> .tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-81ec{background-color:#ffffff;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-hx12{background-color:#efefef;border-color:#c0c0c0;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-4n2o{border-color:#c0c0c0;font-weight:bold;text-align:center;vertical-align:top} .tg .tg-f615{background-color:#efbbb6;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-wo29{border-color:#c0c0c0;text-align:left;vertical-align:top} .tg .tg-ainn{background-color:#f2d0cd;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-f1df{background-color:#7eeb7e;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-69tu{background-color:#f7f69b;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top} .tg .tg-hpxh{background-color:#7eeb7e;text-align:left;vertical-align:top} .tg .tg-eh5f{background-color:#f2d0cd;text-align:center;vertical-align:top} </style> <table class="tg"> <thead> <tr> <th class="tg-4n2o" rowspan="2"><br>Requirement<br></th> <th class="tg-4n2o" colspan="2">State</th> </tr> <tr> <th class="tg-hx12">pre-Drupal<br></th> <th class="tg-hx12">Drupal</th> </tr> </thead> <tbody> <tr> <td class="tg-wo29">clear URLs and structure</td> <td class="tg-ainn"></td> <td class="tg-f1df">fixed</td> </tr> <tr> <td class="tg-wo29">avoid duplication of data across webpages</td> <td class="tg-ainn"></td> <td class="tg-f1df">fixed</td> </tr> <tr> <td class="tg-wo29">web accessiblity</td> <td class="tg-ainn"></td> <td class="tg-ainn"></td> </tr> <tr> <td class="tg-wo29">navigation (to find correct resource)</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> </tr> <tr> <td class="tg-wo29">search (to find correct resource faster)</td> <td class="tg-ainn"></td> <td class="tg-ainn"></td> </tr> <tr> <td class="tg-wo29">enforceable design guidelines</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> </tr> <tr> <td class="tg-wo29">easy content management system</td> <td class="tg-81ec">N/A</td> <td class="tg-69tu">partial^†</td> </tr> <tr> <td class="tg-wo29">easy to edit content by end-users</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial^†</td> </tr> <tr> <td class="tg-wo29">reduce maintenance work and frustration</td> <td class="tg-ainn"></td> <td class="tg-f615">worse</td> </tr> <tr> <td class="tg-0lax">transparency of content and files</td> <td class="tg-hpxh" style="text-align: center">direct</td> <td class="tg-f615">invisible</td> </tr> <tr> <td class="tg-0lax">reasonable learning curve</td> <td class="tg-hpxh" style="text-align: center">shallow</td> <td class="tg-f615">steep</td> </tr> </tbody> </table> <p style=" text-align: left; font-size: 1rem; font-style: italic; color: light-grey;"> Table 1: An overview of the state of CERN's web requirements between pre-Drupal and Drupal. </p> _^†Drupal has a **steep learning curve** that requires multi-day training for most users[^training]. As of March 2023, **trainings for Drupal have been suspended indefinitely** by the L&D team following Valerie Huret's departure._ The current state of CERN's online presence is such that Drupal provides a system through which content can be managed and edited by users. This addresses the desires for clear URLs and structure, as well as reducing duplication of data across websites. However, the remaining **requirements have, more than a decade on, either not been met or worsened**. Similarly, even the requirements that have been partially achieved have introduced a new set of challenges and issues. The ease with which actual content management is achieved, for instance, greatly depends on the experience of the specific user. The _CERN Drupal Community Survey_ conducted in 2022[^survey] revealed that **a majority of users find Drupal difficult to work with**. Considering the relative simplicity of most CERN websites, this underscores the lack of transparency between which files are on a server, and what content is actually displayed to the user. The multitude of ways in which content can be created and configured, owing to Drupal's inherent flexibility, means that many websites adopt their own approach. Insufficient knowledge of Drupal, or merely unfamiliarity with a specific website, often results in inadvertent customisation in an attempt to achieve the desired results. This provokes a **vicious cycle of customisation, making websites increasingly difficult to maintain**. In many cases, the owners of a website might not even be familiar with the customisation underpinning their website. Indeed, hundreds of websites, including high-visibility websites such as `hr.cern` or `theory.cern`, share this issue. **Any website exceeding what is offered and managed centrally via the _CERN Drupal Distribution_ is increasingly at risk of breaking.** Unfortunately, it is often _easier_ to deal with customisation than to streamline a website, as stripping customisation typically requires existing content to be re-created or otherwise re-arranged. In a similar vein, older websites that started out on Drupal 7 face increasing compatibility complications as Drupal continues to advance; independent of them adhering to the _CERN Drupal Distribution_ or not. **The older and larger the website, the more work is involved in maintaining it**[^db_note]. `home.cern` required 15 independent, often time-consuming steps to ensure compatibility with PHP 8.1, for instance, whereas a newer website would require but a couple. In addition, elements such as **web accessibility and search remain unresolved**. Unlike other intergovernmental and scientific organisations such as the United Nations[^un_acc] and EMBL[^embl], web accessibility is poor at CERN[^cath]. This is excluding those with disabilities from accessing scientific results, press releases, applying for jobs, and more. We discuss web accessibility specifically in a later section. ### Drupal 10 (and onwards) As of March 2023, Drupal websites at CERN are running Drupal version 9.5. Drupal 9.x reaches end-of-life **1 November 2023**. When software reaches end-of-life, no further updates, including security patches, are made. This means that a migration to Drupal 10 must commence before that date to ensure continued compatibility, allowing CERN websites to remain safely online. As previously noted, because Drupal relies on its own set of upstream dependencies, major new releases of Drupal typically introduce new versions of these underlying dependencies. This can impact everything from existing functionality, content and integrations to how we manage our infrastructure. We experienced this moving from Drupal 7 to 8 to 9. In the case of Drupal 10, two major underlying dependencies change in addition to all the changes introduced to Drupal itself. This makes an extension of the Drupal 9 end-of-life date highly unlikely as both _Symfony 4_[^symfony_4] (underlying PHP framework) and _CKEditor 4_[^ckeditor_4] (Drupal's integrated content editor) reach end-of-life around the same time. Work that remains for Drupal 10 compatibility includes, but is not limited to, ensuring: - all CERN-official modules remain compatible[^pre_work]; - all community-contributed modules in the _CERN Drupal Distribution_ remain compatible; - existing integrations (CERN SSO, Indico, CDS) continue to work; - existing content continues to work and display as intended; and - important websites with customisation continue to work. Any issue with any module will require development work and subsequent patching, addressing any cascading changes through sub-dependencies. Additionally, necessary infrastructure work supporting the above will be required. Ultimately, this is the default amount of work pertaining to any Drupal release; major and minor alike. Since Drupal 9, we have relied almost exclusively on automated testing for minor releases. However, we cannot do so to the same degree for major releases. Indeed, major releases cannot be reverted due to both security concerns and general backwards incompatibility. Additional, manual verification is thus necessary. :::warning In addition to the above, **Drupal 10 presents a unique set of challenges**. </br> The WYSIWYG (what-you-see-is-what-you-get) editor, CKEditor[^ckeditor], used for all content creation on any Drupal website is being replaced. Drupal, and therefore CERN, has thus far relied on CKEditor 4. In Drupal 10 onwards, only CKEditor 5 will be available.</br> CKEditor 5 is fundamentally different from CKEditor 4. Indeed, CKEditor 5 has been created from scratch, and not merely upgraded, to both modernise and to address the identified shortcomings in CKEditor 4. This work is still ongoing, and per official documentation[^ckdocs] </br> - some (CKEditor 4) functionality has yet to be supported; - other (CKEditor 4) functionality might never be supported; and - existing functionality might behave differently (compared to CKEditor 4). </br> While compatibility work is ongoing, no guarantees are offered for a successful conversion[^ckconversion]. Indeed, the vast majority of Drupal CKEditor 4 plugins (i.e. additional functionality provided to CKEditor from Drupal modules) remain incompatible[^incomp]. Additionally, this work will not address custom content types. </br> CERN-official content types (e.g. CERN Landing Pages, CERN Story Pages, CERN News Pages, Indico Feeds, etc.) used broadly across CERN (including on mission-critical websites such as `home.cern`, `atlas.cern`, `alice.cern`, and `cms.cern`) will thus not be immediately compatible. **Consequently, all existing content created using CERN-official modules is at risk of being incompatible with CKEditor 5**. </br> **In short, Drupal 10 is a monumental task vastly exceeding prior migrations.** ::: It is important to accentuate that any website is a living and breathing piece of software that requires continuous maintenance; whether from a security or an accessibility perspective. However, content management systems and site generators can either amplify this workload or help ease it. In the case of Drupal, it is amplified. The Drupal Association subscribes to a two-year release schedule. This means that major releases are pushed every other year, putting the scheduled release of Drupal 11 in 2024 and Drupal 12 in 2026. In between each major release, we anticipate a minimum of 50 minor releases. However, this number is likely to increase following interim releases concerning any of Drupal's underlying dependencies. Nothing suggests this trend will change in any meaningful way. ### What is the cost of Drupal? The cost of running Drupal at CERN is significant, but not all is visible. Drupal at CERN is managed by the IR web team and the IT infrastructure team in close collaboration. In 2023, the web team has 4.0 FTEs assigned to Drupal-related tasks while the infrastructure team has 2.25 FTEs assigned to Drupal-related tasks. Non-Drupal work, of which there is plenty, therefore exceeds available FTEs. The resources of both teams are thus stretched thin, and have been for an unsustainably long time. While substantial automation efforts have been undertaken with great success, we are also moving closer to having automated what we can realistically automate. This leaves the team to develop and maintain CERN-official modules, patch community-contributed modules, test and verify releases, maintain our infrastructure in general, respond to enquiries and offer support. All things considered, and despite a robust infrastructure and a trimmed offering via the _CERN Drupal Distribution_, the overall effort required to keep Drupal running at CERN is likely to _increase_. This is a direct consequence of Drupal's increasingly fragmented community and years-long, downwards trend as illustrated in `Figure 3`.  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 3: The number of Drupal websites (y-axis) since 2013. Usage is declining and, as of March 2023, about 900k websites are running Drupal. Of these, 440k (49%) still run Drupal 7.x while CERN is part of the roughly 170k (19%) running 9.5.x. </p> Select groups of dedicated developers remain devoted to Drupal, but large parts of the ecosystem struggle to keep up with the continuous releases, prompting calls for contributors at keynote talks in the past several Drupal conferences. The community is split between supporting Drupal 7.x (accounting for 49% of all Drupal websites today) and supporting dozens of versions between 8.x and 10.1. This downwards trend is further reflected in the number of agencies actively supporting Drupal, something which in turn has reduced the number of professional maintainers for many central community-contributed modules. Many websites are thus relying on insecure and unsupported versions of Drupal. That these websites nonetheless remain suggest either a general fatigue with upgrades; an inability to upgrade due to outdated or otherwise locked dependencies; that resources have been allocated to migrating the website off Drupal; or a combination of the three. In any case, fewer and more fragmented websites mean fewer and more fragmented developers. This has already started to impact the otherwise carefully chosen third-party, community-contributed modules that our _CERN Drupal Distribution_ integrates and many websites rely on. Examples include critical modules such as `OpenID Connect` that enables integration between the CERN SSO and Drupal websites. We further anticipate the overall number and frequency of **support enquiries to slowly increase as deprecations and updates continue to break old functionality**. One way of potentially lowering support would be to streamline existing websites and strip away customisation. However, **any serious effort of streamlining Drupal websites and removing customisation will be extremely time-consuming**, require the involvement of current and potentially past website owners, and have little-to-no components possible to automate or scale in any meaningful way. Additionally, as the benefits of streamlining only materialise when a substantial portion of websites have been processed, it would necessarily involve the wider CERN community. As Drupal continues to develop, resources would also have to be split between streamlining efforts and continued maintenance. Ultimately, even if resources necessary to accomplish a CERN-wide streamlining of websites were found, no real changes would be made to the current state of Drupal outlined in `Table 1`. **This leaves several requirements underpinning the decision to choose Drupal in the first place partially resolved, entirely unresolved, or worsened.** Staying with Drupal becomes an active choice in favour of the above. ## WordPress WordPress (https://wordpress.org/) is an open-source content management system first released in 2003[^start_wp]. Originally conceived as a blog-publishing system, WordPress has evolved significantly and today powers more than 43% of all websites on the Internet (compared to 1.2% for Drupal). Of websites utilising a content management system, WordPress powers more than 63% (compared to 1.8% for Drupal)[^w3_tech]. Central to WordPress is its emphasis on usability, extensibility, performance[^wp_per], and security[^wp_sec]. WordPress prides itself as being easy to use for people without technical experience, offering a simple, intuitive user interface for managing a website. This interface includes different sections for managing content, updates, plugins, and so on. In 2018, WordPress introduced a new block-based editor at the beginning of their four-phase _Gutenberg project_[^gutenburg], enabling intuitive, full-site editing with the goal to facilitate collaborative editing, among several other features[^gutenburg_feat].  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 4: An example of how WordPress could look when creating new content. </p> Since its inception, WordPress has grown increasingly popular. This is reflected in the growing number of websites being built using WordPress as seen in `Figure 5`. As mentioned above, more than 43% of all websites on the Internet use WordPress. In comparison, Drupal has remained stagnant for many years before beginning its downwards trend in 2018 as also illustrated in `Figure 3`, sitting at a mere 1.2% in 2022.  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 5: Percentages of global websites that use each content management system over the last decade.</br>Data from W3 (<a href="https://w3techs.com/">https://w3techs.com/</a>). Kindly note that `None` refers to websites not using any content management system, e.g. traditional HTML websites. There are thus more online websites using WordPress than websites not using any content management system. </p> Thanks to the significant adoption of WordPress, a large and very active community exists. This in turn translates to extensive community forums, comprehensive documentation, and a large developer community supporting both free and paid plugins and themes. In the context of WordPress, themes control the styling and basic functionality of websites, while plugins add more advanced functionality. While similar to Drupal at first glance, the firm focus of WordPress on backwards compatibility and seamless upgrades enable even infrequently used plugins to stay up-to-date and compatible. Updates to WordPress itself can further be fully automated. Accordingly, the fragmentation of the community and developers that Drupal suffer from is, in practice, a non-issue in WordPress. ### WordPress at CERN Despite not being officially supported, WordPress is already used sporadically across CERN. This includes websites such as the LHCb's Outreach (https://lhcb-outreach.web.cern.ch/), the IT department's Computing Blog (https://computing-blog.web.cern.ch/) and QTML 2023 (https://qtml-2023.web.cern.ch/), as well as the externally hosted CERN Courier (https://cerncourier.com/). While centralised management (i.e. security updates, backups, permission management, etc.), design guidelines, governance, and several other important components are lacking, these websites, nonetheless, prove the viability of WordPress. Returning to the requirements initially posed for Drupal, we believe WordPress is capable of not only addressing everything Drupal addresses, but also improving on its shortcomings. However, like any piece of software, WordPress can be used correctly and incorrectly. Indeed, what WordPress represents is an opportunity to design, develop, and deploy an infrastructure using all the experiences we have accumulated running Drupal. <style type="text/css"> .tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-hx12{background-color:#efefef;border-color:#c0c0c0;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-fcd7{background-color:#7eeb7e;border-color:#c0c0c0;text-align:left;vertical-align:top} .tg .tg-ew5w{background-color:#f2d0cd;border-color:#c0c0c0;color:#efefef;text-align:center;vertical-align:top} .tg .tg-08kx{background-color:#7eeb7e;border-color:#c0c0c0;color:#000000;text-align:center;vertical-align:top} .tg .tg-jhfc{background-color:#f2d0cd;border-color:#c0c0c0;color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-f615{background-color:#efbbb6;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-x2l4{background-color:#efefef;border-color:#c0c0c0;font-weight:bold;text-align:center;vertical-align:top} .tg .tg-wo29{border-color:#c0c0c0;text-align:left;vertical-align:top} .tg .tg-ainn{background-color:#f2d0cd;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-69tu{background-color:#f7f69b;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-f1df{background-color:#7eeb7e;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-fzdr{border-color:#c0c0c0;text-align:center;vertical-align:top} </style> <table class="tg"> <thead> <tr> <th class="tg-x2l4" rowspan="2"><br>Requirement</th> <th class="tg-x2l4" colspan="3">State</th> </tr> <tr> <th class="tg-x2l4">pre-Drupal<br></th> <th class="tg-x2l4">Drupal</th> <th class="tg-hx12">WordPress</th> </tr> </thead> <tbody> <tr> <td class="tg-wo29">clear URLs and structure</td> <td class="tg-ainn"></td> <td class="tg-08kx">fixed</td> <td class="tg-fcd7"></td> </tr> <tr> <td class="tg-wo29">avoid duplication of data across webpages</td> <td class="tg-ainn"></td> <td class="tg-08kx">fixed</td> <td class="tg-fcd7"></td> </tr> <tr> <td class="tg-wo29">web accessiblity</td> <td class="tg-ainn"></td> <td class="tg-ainn"></td> <td class="tg-fcd7">with plugin</td> </tr> <tr> <td class="tg-wo29">navigation (to find correct resource)</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-69tu">partial</td> </tr> <tr> <td class="tg-wo29">search (to find correct resource faster)</td> <td class="tg-jhfc"></td> <td class="tg-ew5w"></td> <td class="tg-f1df">^†</td> </tr> <tr> <td class="tg-wo29">enforceable design guidelines</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-f1df">^†</td> </tr> <tr> <td class="tg-wo29">easy content management system</td> <td class="tg-fzdr">N/A</td> <td class="tg-69tu">partial</td> <td class="tg-f1df">^†</td> </tr> <tr> <td class="tg-wo29">easy to edit content by end-users</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-f1df"></td> </tr> <tr> <td class="tg-wo29">reduce maintenance work and frustration</td> <td class="tg-ainn"></td> <td class="tg-f615">worse</td> <td class="tg-f1df">^†</td> </tr> <tr> <td class="tg-wo29">transparency of content and files</td> <td class="tg-f1df">direct</td> <td class="tg-f615">invisible</td> <td class="tg-69tu">partial</td> </tr> <tr> <td class="tg-wo29">reasonable learning curve</td> <td class="tg-f1df">shallow</td> <td class="tg-f615">steep</td> <td class="tg-f1df">shallow</td> </tr> </tbody> </table> <p style=" text-align: left; font-size: 1rem; font-style: italic; color: light-grey;"> Table 2: An overview of the state of CERN's web requirements showing pre-Drupal, Drupal, and WordPress. </p> ^†_WordPress is not a magic solution, nor does it guarantee success. However, it has the potential to accommodate these requirements if deployed and configured correctly, drawing on the experiences we have from Drupal._ Note how components such as web accessibility (via plugins, e.g. those used on https://www.whitehouse.gov/ and similar) and search (via sitemaps and extensive search engine optimisation tools) become available with WordPress. Similarly, as updates to WordPress itself can be largely automated, a careful design and implementation of a _CERN Wordpress Distribution_ on a robust infrastructure will significantly improve maintenance work. While transparency between content and files will always be somewhat obscured by content management systems, WordPress can be configured such that fewer options are available, thereby streamlining content and files for the end-user. In order to facilitate a comprehensive and objective evaluation of the work involved in successfully adopting WordPress, the IR web team has developed and tested WordPress copies of the `international-relations.web.cern.ch` and `visit.cern` websites. We consider these websites representative of a significant majority of CERN's Drupal websites: `international-relations` aligns closely with the _CERN Drupal Distribution_ while `visit` contains additional customisation and dedicated internal pages. The following section outlines the work necessary to implement WordPress at CERN. ## Implementing WordPress It is first and foremost important to recognise how there are significant costs associated with both staying on Drupal _and_ moving away from Drupal. This applies independent of which system is chosen in favour of Drupal, WordPress included. However, as previously argued, staying on Drupal carries a cost that increases proportional with growing maintenance and compatibility demands. Additionally, this increased cost is highly unlikely to improve the remaining requirements and shortcomings currently present with Drupal. In evaluating the cost of WordPress, the following is considered: - infrastructure work (i.e. developing and deploying a WordPress infrastructure); - integration work (i.e. SSO, CDS, and Indico integrations as well as theming); - migration work (i.e. moving content from Drupal to WordPress) - verification work (i.e. verifying that migrated content displays appropriately); - communication work (e.g. creating new documentation, training sessions, etc.); and - future maintenance work. It should be noted that a small subset of websites are heavily integrated with the existing Drupal ecosystem. Such websites would require additional, case-by-case intervention and support to facilitate a successful migration. However, the very same websites already require significant and continuous resources to ensure compatibility with Drupal. Indeed, `home.cern`, for instance, required 15 distinct and time-consuming steps to migrate to PHP 8.1, not accounting for test and verification. While significant, the resources required by these websites to conform to Drupal 10 and what follows outweigh the resources necessary to migrate away from Drupal. ### Infrastructure Work As previously noted, WordPress is not automatically a magic solution. Indeed, WordPress, like any piece of software, can be used correctly and incorrectly. What WordPress does represent, is an opportunity to design, develop, and deploy an infrastructure, applying all the experiences we have accumulated running Drupal over more than two years. A solid foundation coupled with the robustness of WordPress will enable us to address many of the requirements that Drupal misses (both the requirements outlined in `Table 2`, as well as infrastructure-specific shortcomings such as improved operations and easier upgrades, blocking usage of custom modules, and better governance). Any work with WordPress at a meaningful scale can only be successful if the underlying components supporting that work are robust, maintainable, and scalable. Adequate infrastructure investments are therefore critical to the overall success. The stronger the foundation, the easier and more maintainable any subsequent work becomes. Accordingly, in terms of infrastructure, the bulk of the work comes upfront, but inherently supports anything that follows. However, we are not starting completely from scratch. Indeed, not only do we have substantial, largely re-applicable experience from Drupal, several websites across CERN are already running WordPress. The following infrastructure components are necessary: - A WordPress OpenShift cluster flavour from which we will serve the WordPress websites and automate its many required operations. Some components will be reused from the Drupal infrastructure with minor adaptations such as the *DB operator* and the *Velero operator*. But most components will need to be created specifically for WordPress such as, but not limited to: - WordPress operator and its many custom resource definitions: WordPress website and versioning resources; - WordPress Docker base images to allow building and serving the _CERN WordPress Distribution_; - a WordPress Helm chart in order to configure and install a WordPress OpenShift cluster; - operational scripts for managing and updating, cloning, restoring, upgrading and other required operations; - configuring deployment pipelines for automated processes; - integration with the Webservices Portal in order for users to create and manage their websites; and - WebDAV or similar framework for users to create, change and move documents on their websites. - A _CERN WordPress Distribution_ through which we manage which plugins (equivalent of Drupal modules) and themes are included. We would further want to **heavily restrict the customisability of WordPress, effectively locking websites to the central distribution**. This is critical as we would otherwise, in time, replicate the issue we have with customisation on Drupal websites. We know a centralised approach works as we can manage websites strictly aligning with the _CERN Drupal Distribution_. - A dedicated `.docs.cern.ch` website for user-facing documentation. Note how initial website migrations will be slower and require more manual work than subsequent migrations. While slower, initial migrations will allow us to tweak, test, and verify everything from monitoring to backup solutions. As downtime of existing websites is unacceptable, resources must also be made available to minimally support the existing Drupal infrastructure. This applies to both IR and IT resources. ### Integration Work As a result of Drupal's many custom modules, of which more than 40 are modules developed and maintained by CERN, we would want to rigorously streamline a centralised WordPress offering. Any plugin (WordPress equivalent of a Drupal module) must originate from the _CERN WordPress Distribution_. The ability to install custom plugins must be disabled. This not only reduces the overall development and maintenance costs, but also drastically simplifies the end-user experience. Additionally, work would not only become easier and more transparent, experience from actually using the website would, unlike Drupal, also be readily transferable between websites. We thus expect to also minimise frustrations associated with using WordPress compared to that of Drupal. We require a small selection of integrations with existing CERN services, namely: - CERN CDS; - CERN Indico; and - CERN SSO (and Grappa) Of these, we estimate the development of a _CERN CDS_ and _CERN Indico_ WordPress plugin to require approximately 0.2 FTE each. Indeed, a slightly outdated plugin[^wp_indico_plugin] providing an Indico widget already exists, which could feasibly be adapted to a custom Indico block in order to work with WordPress's newer block-based themes. We expect CDS integration to be similarly achievable. The development of the _CERN SSO_ integration is critical from a usability and security perspective as well as significantly more complex than that of CDS and Indico. We expect SSO development to involve both the web team, infrastructure team, and potentially the authentication team over the course of multiple months with a combined FTE of 0.4. Given the importance of these integrations, and to minimise future maintenance, we advise against outsourcing this development. Additionally, as each integration (i.e. plugin) is independent, development could commence simultaneously and in parallel with other work. Additional integration work includes: - the design and implementation of CERN-official WordPress themes. Initial work suggests that we can replicate much of what is available on Drupal, but not everything. Websites _will_ look different. However, this also presents an opportunity to modernise CERN's websites and introduce much-needed components such as improved web accessibility and mobile responsiveness at the theme level. As themes are independent of content in WordPress, it is possible to create multiple CERN-official themes, allowing some level of visual customisation. This could potentially address concerns from websites currently enjoying customisation on Drupal. However, in line with a centrally controlled _CERN WordPress Distribution_, we would want to retain complete control of what can, and what cannot, be modified by individual website owners. Indeed, this is our chance of ensuring CERN's design guidelines can be enforced.  <p style=" text-align: center; font-size: 1rem; font-style: italic; color: light-grey;"> Figure 6: A small selection showcasing some of the many theming options available in WordPress. </p> Since the look of WordPress websites depends on themes, creating and providing a CERN-specific theme can help achieve a consistent look and feel across CERN websites, as well as incorporate accessible design. Themes can be created based on existing themes, but also from scratch, and the theme creation can be outsourced to a professional designer and developer. As theme creation would re-use existing design guidelines and have Drupal themes available for inspiration, theme work need not necessarily start from scratch. **Central to WordPress themes is further their inherent responsiveness and support for mobile devices.** This is in stark contrast to what is offered via Drupal which is often lacklustre or non-existent. With a significant portion of visitors accessing CERN websites via mobile and tablet devices, this would be a much appreciated change. We recommend outsourcing work on themes with strict requirements to ensure both alignment with the infrastructure and CERN's design guidelines. We would further want to specify maintainability requirements and restrict the degree of customisation. Work on themes could commence in parallel to both infrastructure and integration work but would require oversight. In any case, this decision is pending discussions with relevant, internal stakeholders. Additional integration work includes: - CERN Search / search-as-a-service. The previous infrastructure hosting Drupal 7 on virtual machines was integrated with CERN Search, a solution based on Sharepoint that allowed Drupal websites to be crawled and become searchable and discoverable through https://search.cern.ch/. The requirement to integrate the current Drupal infrastructure hosted on OpenShift with the new search-as-a-service replacing the Sharepoint based search solution still has not been fulfilled. This requirement would pass over into a WordPress infrastructure. FTEs assigned to this integration thus remain unchanged. ### Migration Work The cost of migrating content is significant. Not only will content migration involve substantial work from the IR web team in automating as much as possible, it will also involve individual website owners who need to verify the migrated content. While a significant task, **it is likely to be similar in scope to that of accommodating Drupal 10 and CKEditor 5**. Websites with a lot of content, such as `home.cern`, will require dedicated resources for the duration of any migration. We recommend using a WordPress migration as an opportunity to also review publicly accessible content to ensure it is up-to-date and adheres to CERN's design guidelines and communication strategy. As this work largely falls on the individual website owners, a copy of their existing Drupal website would have to be created such that a switch to WordPress only occurs once everything has been checked and verified. Currently, we can create WordPress instances and use the paid _FG Drupal to WordPress_ plugin[^fgd2wp_plugin] to automatically migrate content from Drupal websites. This plugin has been tested by the IR web team and has successfully migrated content, users, and custom content types from Drupal to WordPress. While additional work is necessary to migrate all configurations, it is a powerful plugin that with little tweaking automises a significant portion of the work. For example, while the plugin imports custom roles and assigns them to the correct users, the permissions for each role are not copied. This is because WordPress manages permissions differently. To accomplish similar role permissions as Drupal, they should be specified using a plugin such as _Members_[^wp_members_plugin]. This aspect of the migration is likely also pending work on the CERN SSO integration. In terms of data privacy, there is no difference between that of Drupal and that of WordPress. Additionally, a WordPress website would connect directly to its own and its associated Drupal database to initiate the migration. All data is thus transferred and subsequently stored within the CERN network. ### Communication Work As with any new system, we anticipate a substantial increase in the number of support enquiries during the initial phase of WordPress. However, we expect Drupal 10 to produce a similar uptick in support enquiries. Ultimately, while WordPress is commonly praised for its simplicity and ease-of-use, end-users will have to grapple with a new system that both looks and behaves differently. This could cause frustration amongst some. On the other hand, per the _CERN Drupal Community Survey_[^survey], many users reported frustrations with Drupal and explicitly mentioned WordPress as a desirable alternative. While WordPress match or exceed the features of Drupal, the way something is done in Drupal will not necessarily translate to how it is done in WordPress. Attempts to (re)create Drupal-specific functionality in WordPress will likely account for many initial support tickets. However, where Drupal configurations and many workflows are site-specific, a _CERN WordPress Distribution_ would align all websites such that creating, reviewing, approving, and displaying content is done the same way across all websites. With the above, as well as our experiences from both Drupal and PHP migrations, in mind, we consider it crucial to devote time and resources to create comprehensive documentation with step-by-step guides on how to accomplish common use-cases known from Drupal (e.g. creating new content, updating menus, linking pages, adding images, etc.). We further want to ensure that users are aware of the changes that would be coming and what they need to do when. We propose dedicated community meetings and Zoom sessions akin to those held during the migration to Drupal 9. Additionally, we would want to involve Drupal superusers in the initial migrations to WordPress. This way, we engage the CERN-community as early as possible, inviting feedback and suggestions. ### Future Maintenance Work It is hard to approximate what exactly the future cost of maintaining WordPress will be. What we can do is to consider where Wordpress was both ten and five years ago and compare that to where it is today. Where Drupal has been on a steady decline and suffers from increasing fragmentation, WordPress has steadily increased in popularity supported by strong and dedicated developer communities. While the WordPress landscape is not immune to fragmentation in terms of which versions of WordPress are actively used, backwards compatibility and a large and active community minimise the impact of this. It should be noted that whilst prior releases are available, more than 62% of WordPress websites utilise one of the two newest releases. This is particular noteworthy considering how the newest version of WordPress, `6.2`, was released 29-MAR-2023. By 03-APR-2023, 37.2% of WordPress websites had already updated[^wp_stats]. These numbers are made more impressive considering the sheer number of websites running WordPress: ~810 million as of 2023[^num_of_wp]. This underscores the power and seamlessness of WordPress's automated updates and general update philosophy. Indeed, WordPress values backwards compatibility and seamless upgrades strongly; so much so that the IR web team was able to update a WordPress website originally created in 2015 to WordPress `6.2` with a single click. Similarly, we identified websites which were fully up-to-date without having required any active input for years. This is in stark contrast to Drupal. While individual plugins and integrations would continue to require continuous effort, a robust and lean _CERN WordPress Distribution_ would invariably require less maintenance than Drupal. In other words, WordPress costs are expected to be predominantly in the transition phase, after which we, with a proper foundation, will benefit from a larger developer community, extensive backwards compatibility, and automated upgrades. #### A note on security and maintenance As previously noted, WordPress has a significantly larger community compared to Drupal. This enables faster development, upgrades, and easier maintenance. Issues and solutions are found and provided at a significantly faster rate, improving overall maintenance. Indeed, we need not put in all the work ourselves, but can instead reap the advantages of a larger community. On the other hand, a larger community also introduces new security considerations. We note a recent example of a critical vulnerability in a widely used WordPress plugin that made millions of WordPress websites vulnerable to losing control of their own content[^wp_crit_vuln]. Ultimately, the fact that more than 43% of websites utilise WordPress also makes WordPress a popular choice for malicious actors. A fix to prevent this particular issue was released within hours, protecting sites as soon as the plugin was updated. This example underscores the importance of having a centrally managed _CERN WordPress Distribution_. Currently, we still have websites up and running in versions of Drupal which have long passed their end-of-life and are running without security patches. Specifically, we have websites in Drupal 8 and Drupal 9 with PHP 7. This is due to incompatibilities in custom modules to the current provided and supported Drupal version. If a critical vulnerability is found, they must be taken offline, moved behind SSO, or converted to a static site. **Moving to Wordpress, we advise little to no flexibility in allowing users to run outdated versions of the software**. We consider the risk of running outdated versions of WordPress higher due to the technology being more widely adopted and known. ### Resources The workload and complexity of migrating CERN to WordPress requires a larger team to ensure that we can complete it on time and with the highest quality, while taking advantage from the learnings taken the current infrastructure. Any migration, be it to WordPress or Drupal 10, must simultaneously keep all current websites online and accessible while preparing the migrated versions. This means continuing to support Drupal 9. To ensure the success of adopting WordPress and meet the requirements provided, we require additional resources for both the IT infrastructure team and the IR web team. Specifically, we would benefit from two additional FTEs for the IT infrastructure team in the form of _1 Origin_ resource and _1 Quest_ resource. The IR web team would similarly require two additional FTEs during the transition and migration phases. This is to ensure that ongoing projects can continue, existing websites remain online, and that we can create the best possible foundation for WordPress. It is important to accentuate that both teams rely on individual website owners assuming general test and verification work of their website(s) as part of any migration. We cannot, between production and development versions, manually review thousands of websites. Accordingly, if the web team is to assist in migrating specific websites in addition to developing centralised automation tools, further resources will fast become necessary. Outsourcing some of the tasks to a third-party provider, or resorting to external expert consultants, could be an option to fasten the development. ## Web Accessibility As previously mentioned, evaluating CERN's online presence also presents an opportunity to take stock and critically evaluate web accessibility across CERN websites. Indeed, at the moment, CERN websites largely exclude those who rely on accessibility tools from accessing scientific results, press releases, applying for jobs, and more. Issues such as low contrast, incorrect or misleading use of HTML tags, empty buttons and links, and missing alternatives for non-text content are unfortunately widespread across CERN websites. These issues are further amplified by the intricacies of Drupal complicating the process of accommodating accessibility. This creates major problems for visually impaired users and those who rely on keyboards or screen readers to navigate. Extensive principles have been established by the World Wide Web Consortium Web Accessibility Initiative (W3C WAI), outlined in their _Web Content Accessibility Guidelines_ (WCAG)[^wcag]. These guidelines formed the foundation for the European accessibility standards that all websites in the EU should comply with per the recently published _Web Accessibility Directive_[^eu_web]. Three different levels[^w3_rating] (`A`, `AA`, and `AAA`) are used to determine the level of accessibility, `AAA` being the most inclusive. Many intergovernmental and scientific organisations, e.g. the United Nations[^un_acc] and EMBL[^embl], strive for `AA`. As a large intergovernmental organisation, CERN should strive to improve its accessibility to be more inclusive, reach a wider audience and ideally serve as a model for progressive web design. Besides increasing outreach, CERN should ensure that our websites meet the European accessibility standards. This requires implementing WCAG 2 level `AA`. We suggest building on existing work conducted by Catharine Noble and implementing many of the recommendations presented in her thesis [^cath]. As introducing web accessibility by default across CERN websites is a significant task, we need to lay the groundwork for as much automation as possible. This would also heavily reduce the manual work required by individual website owners. Similarly, we need to coordinate these efforts centrally to ensure a uniform approach. Accordingly, the IR web team is in active contact with CERN's many _Diversity and Inclusion_ offices (ALICE, ATLAS, CMS, LHCb, and HR) to understand how we can best improve the experience of using CERN's websites. The web team is further in touch with individual groups and sections, such as the FAP-BC, who are allocating resources to improve accessibility. ### Accessibility in Drupal Drupal does offer a selection of custom modules which, if used correctly, could potentially address the question of accessibility[^drupal_accessibility]. However, any such installation requires significant manual work and configuration from the website owner(s), potentially impacting all existing content. With customised websites, years of existing content, and Drupal's steep learning curve, this becomes a difficult and very time-consuming task. ### Accessibility in WordPress To improve web accessibility using WordPress, it is important to use an accessible theme, as this is what determines the look and basic functionality of the website. In the case of a custom CERN theme, it should therefore incorporate the WCAG accessibility guidelines in its design. If the development of CERN's WordPress themes is outsourced, this would be a firm requirement alongside compatibility with the _CERN WordPress Distribution_. WordPress provides various accessibility plugins addressing different aspects. These can also be combined to extend a website's accessibility. A notable plugin is the _One Click Accessibility_ plugin[^wp_onecclickacc_plugin], which adds a button to the website so users can change contrast and font size. An example is the official website of the White House[^white_house]. No further action besides installing the plugin is required. More detailed plugins are also available, such as the _WP Accessibility_ plugin[^wp_acc_plugin], which adds a more comprehensive selection of accessibility settings for the user, as well as more detailed settings for admins. Since WordPress plugins are easy to install and update, they make improved web accessibility a very feasible and maintainable goal. We would examine the available options and include one or more in a _CERN WordPress Distribution_ such that all CERN websites automatically improve web accessibility. Regardless of the content management system, tools such as the WAVE browser extension[^wave_ext] can help catch and eradicate additional accessibility issues. This particular extension shows errors, warnings and features on the viewed webpage, along with descriptions of the issues and how to solve them. It needs to be stressed that no automated tool can catch all accessibility issues. Manual testing will always be required to fully achieve accessible websites, but using available tools in combination with manual testing can significantly improve CERN's largely inaccessible websites. We can draw on our experience from automatically testing Drupal websites. Ultimately, incorporating these considerations in adopting WordPress will allow CERN to meet European accessibility standards by attaining a W3 `AA`-conformance rating[^w3_rating], similar to what other intergovernmental and scientific organisations currently strive for. ## Static Site Generators Another noteworthy alternative is to migrate certain websites to GitLab Pages[^gitlab_pages] and using a static site generator. This option will not be a feasible option for most CERN websites, but could be highly beneficial to some. It is especially useful for websites that are not dynamic, do not need to be updated frequently, and are maintained by people who are experienced and comfortable with using version control. When using a static site generator such as Hugo or Jekyll, content is usually written in plain text, Markdown or a similar markup language, while the site generator constructs HTML sites from that using a templating language. The website styling is handled by the theme and can be easily adapted. We would want to provide a centralised, simple CERN-theme for both Hugo and Jekyll. The benefits of static site generators include a clear file structure, multilingual support, and improved website performance. Additionally, version control such as git can be used. This requires technical expertise but can facilitate collaboration and provide a history of changes. Several websites at CERN have chosen to adopt static site generators, such as https://geant4.web.cern.ch/. Additional benefits include making web development more accessibility, effectively distributing the task of maintaining a website to anyone with access to the associated Gitlab repository. <style type="text/css"> .tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-fcd7{background-color:#7eeb7e;border-color:#c0c0c0;text-align:left;vertical-align:top} .tg .tg-ew5w{background-color:#f2d0cd;border-color:#c0c0c0;color:#efefef;text-align:center;vertical-align:top} .tg .tg-08kx{background-color:#7eeb7e;border-color:#c0c0c0;color:#000000;text-align:center;vertical-align:top} .tg .tg-jhfc{background-color:#f2d0cd;border-color:#c0c0c0;color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-f615{background-color:#efbbb6;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-x2l4{background-color:#efefef;border-color:#c0c0c0;font-weight:bold;text-align:center;vertical-align:top} .tg .tg-wo29{border-color:#c0c0c0;text-align:left;vertical-align:top} .tg .tg-ainn{background-color:#f2d0cd;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-69tu{background-color:#f7f69b;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-f1df{background-color:#7eeb7e;border-color:#c0c0c0;text-align:center;vertical-align:top} .tg .tg-fzdr{border-color:#c0c0c0;text-align:center;vertical-align:top} </style> <table class="tg"> <thead> <tr> <th class="tg-x2l4" rowspan="2"><br>Requirement</th> <th class="tg-x2l4" colspan="4">State</th> </tr> <tr> <th class="tg-x2l4">pre-Drupal</th> <th class="tg-x2l4">Drupal</th> <th class="tg-x2l4">Wordpress</th> <th class="tg-x2l4">Static Site Generators</th> </tr> </thead> <tbody> <tr> <td class="tg-wo29">clear URLs and structure</td> <td class="tg-ainn"></td> <td class="tg-08kx">fixed</td> <td class="tg-fcd7"></td> <td class="tg-fcd7"></td> </tr> <tr> <td class="tg-wo29">avoid duplication of data across webpages</td> <td class="tg-ainn"></td> <td class="tg-08kx">fixed</td> <td class="tg-fcd7"></td> <td class="tg-69tu">^†</td> </tr> <tr> <td class="tg-wo29">web accessiblity</td> <td class="tg-ainn"></td> <td class="tg-ainn"></td> <td class="tg-fcd7">with plugin</td> <td class="tg-69tu">^†</td> </tr> <tr> <td class="tg-wo29">navigation (to find correct resource)</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-69tu">partial</td> <td class="tg-69tu">^†</td> </tr> <tr> <td class="tg-wo29">search (to find correct resource faster)</td> <td class="tg-jhfc"></td> <td class="tg-ew5w"></td> <td class="tg-f1df"></td> <td class="tg-fcd7"></td> </tr> <tr> <td class="tg-wo29">enforceable design guidelines</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-f1df"></td> <td class="tg-69tu">partial</td> </tr> <tr> <td class="tg-wo29">easy content management system</td> <td class="tg-fzdr">N/A</td> <td class="tg-69tu">partial</td> <td class="tg-f1df"></td> <td class="tg-69tu">git</td> </tr> <tr> <td class="tg-wo29">easy to edit content by end-users</td> <td class="tg-ainn"></td> <td class="tg-69tu">partial</td> <td class="tg-f1df"></td> <td class="tg-fcd7"></td> </tr> <tr> <td class="tg-wo29">reduce maintenance work and frustration</td> <td class="tg-ainn"></td> <td class="tg-f615">worse</td> <td class="tg-f1df"></td> <td class="tg-f1df"></td> </tr> <tr> <td class="tg-wo29">transparency of content and files</td> <td class="tg-f1df">direct</td> <td class="tg-f615">invisible</td> <td class="tg-69tu">partial</td> <td class="tg-f1df">direct</td> </tr> <tr> <td class="tg-wo29">reasonable learning curve</td> <td class="tg-f1df">shallow</td> <td class="tg-f615">steep</td> <td class="tg-f1df">shallow</td> <td class="tg-f1df">shallow</td> </tr> </tbody> </table> <p style=" text-align: left; font-size: 1rem; font-style: italic; color: light-grey;"> Table 3: An overview of the state of CERN's web requirements showing pre-Drupal, Drupal, WordPress, and static site generators. </p> ^†_Static site generators can support these requirements, but require website owners to be familiar with the necessary steps. It is possible to provide templates and schemes centrally to ease this development, but unlike WordPress, it cannot be enforced centrally._ Since GitLab handles the deployment of websites to GitLab Pages, the infrastructure for this already exists. Currently, the CERN GitLab contains built-in templates for GitLab Pages made with various static site generators, including Jekyll, Hugo and Gatsby, among others. Firsty, a decision for which static site generator(s) will be supported has to be made. Then, similarly to WordPress, integration with SSO, CDS, and Indico needs to be ensured to provide all the necessary tools for the migration, and a theme has to be created. The main cost of migrating websites to static site generators will be implementing these CERN-specific integrations. Moreover, a large amount of work will fall on the website maintainers for migrating the content. For some generators, notably Jekyll, tools to automate this process exist, but these have not been tested by the web team. To reiterate, although unfeasible for most CERN websites, static site generators can be beneficial for some. Specifically, they can be useful for static websites managed by technically experienced people, for example for documentations or manuals. However, they should not be considered for websites that are highly customised and/or rely on personalised content. This needs to be communicated clearly to avoid frustration and further issues if people try to migrate unsuitable websites to static site generators. [^entice]: [https://indico.cern.ch/category/3101/](https://indico.cern.ch/category/3101/) [^wp]: [https://wordpress.org/](https://wordpress.org/) [^gitlab_pages]:[https://docs.gitlab.com/ee/user/project/pages/](https://docs.gitlab.com/ee/user/project/pages/) [^drupal_dist]: [https://gitlab.cern.ch/drupal/paas/cern-drupal-distribution](https://gitlab.cern.ch/drupal/paas/cern-drupal-distribution) [^d9_releases]: [https://www.drupal.org/project/drupal/releases/](https://www.drupal.org/project/drupal/releases/) [^domains]: In addition to `.cern` and `.web.cern.ch`, some CERN Drupal websites are primarily served on `.org` (e.g. https://ippog.org/), `.tech` (e.g. https://white-rabbit.tech/), `.space` (e.g. https://ams02.space), `.eu` (e.g. https://acceleratingnews.eu/), and `.net` (e.g. https://cixp.net/) domains. All have a `.web.cern.ch` alias, however. [^presentations]: [https://drupal.docs.cern.ch/publications](https://drupal.docs.cern.ch/publications) [^training]: LMS offers [https://lms.cern.ch/ekp/servlet/FORMAT1?CID=EKP000044138&DECORATEPAGE=N&LANGUAGE_TAG=en](https://lms.cern.ch/ekp/servlet/FORMAT1?CID=EKP000044138&DECORATEPAGE=N&LANGUAGE_TAG=en) and [https://lms.cern.ch/ekp/servlet/FORMAT1?CID=EKP000044144&DECORATEPAGE=N&LANGUAGE_TAG=en](https://lms.cern.ch/ekp/servlet/FORMAT1?CID=EKP000044144&DECORATEPAGE=N&LANGUAGE_TAG=en), both of which are five half-days of (currently unavailable) Drupal training. [^survey]: [https://indico.cern.ch/event/1206895/](https://indico.cern.ch/event/1206895/) [^db_note]: There are several reasons for why this is. By default, Drupal stores configurations (be it for modules, views, specific pieces of content, and thus forth) in a database. The contents of this database never change between updates. Thus, the more configurations are stored in a database, the greater the risk of conflict. Conflict occurs when a module has been updated to a point where it diverges from its original configuration schemas. This can snowball and affect numerous pieces of content depending on the old configuration schemas. [^drupal_accessibility]: [https://www.drupal.org/about/features/accessibility](https://www.drupal.org/about/features/accessibility) describes Drupal's commitments to accessibility. However, any of the available modules require substantial manual work to ensure accessibility. [^w3_rating]: _Web Content Accessibility Guidelines (WCAG) 2 Level AA Conformance_ by the W3C Web Accessibility Initiative: https://www.w3.org/WAI/WCAG2AA-Conformance [^symfony_4]: https://symfony.com/releases [^ckeditor_4]: _How long will CKEditor 4 be supported?_ by Ludwika Slowikowska: https://support.ckeditor.com/hc/en-us/articles/115005281629-How-long-will-CKEditor-4-be-supported- [^pre_work]: Preliminary work was completed during the migration of PHP 7.4 to 8.1 in 2022, but as a stable release of Drupal 10 was not available at the time, we need to devote time again. [^embl]: _Improving the accessibility of the EMBL-EBI website_ by Nikiforos Karamanis: https://www.linkedin.com/pulse/improving-accessibility-embl-ebi-website-nikiforos-karamanis/ [^un_acc]: https://www.un.org/en/webaccessibility/ [^cath]: Noble, Catharine Alexandra. (2021). Development of Web Accessibility Recommendations for CERN. Zenodo. https://doi.org/10.5281/zenodo.5744899 [^ckeditor]: Homepage at [https://ckeditor.com/](https://ckeditor.com/) with code available at [https://github.com/ckeditor/ckeditor5](https://github.com/ckeditor/ckeditor5). [^ckdocs]: [https://ckeditor.com/docs/ckeditor5/latest/updating/migration-from-ckeditor-4.html#features](https://ckeditor.com/docs/ckeditor5/latest/updating/migration-from-ckeditor-4.html#features) [^ckconversion]: The Drupal Association notes: _“An enormous amount of effort went into the upgrade path. But even though we developed and tested it with as many edge cases in mind as we could think of, the strongest proof is testing it on real-world sites, with actual content.”_, see https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckeditor-5-module/testing-the-ckeditor-4-to-5-upgrade-path ↩︎ [^incomp]: _Upgrade coordination for modules providing CKEditor 4 plugins_ on Drupal's official documentation: [https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckeditor-5-module/upgrade-coordination-for-modules-providing-ckeditor-4-plugins](https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckeditor-5-module/upgrade-coordination-for-modules-providing-ckeditor-4-plugins) [^fgd2wp_plugin]: FG Drupal to WordPress plugin: [https://wordpress.org/plugins/fg-drupal-to-wp/](https://wordpress.org/plugins/fg-drupal-to-wp/) [^wp_members_plugin]: Members plugin for managing user roles and permissions on WordPress: https://wordpress.org/plugins/members/ [^wp_indico_plugin]: Indico widget WordPress plugin: https://gitlab.cern.ch/wordpress/indico-widget [^wp_acc_plugin]: WP Accessibility plugin: https://wordpress.org/plugins/wp-accessibility/ [^wp_onecclickacc_plugin]: One Click Accessibility WordPress plugin: [https://wordpress.org/plugins/pojo-accessibility/](https://wordpress.org/plugins/pojo-accessibility/) [^start_wp]: _WordPress Now Available_ by Matt Mullenweg: [https://wordpress.org/news/2003/05/wordpress-now-available/](https://wordpress.org/news/2003/05/wordpress-now-available/) [^w3_tech]: _Usage statistics of content management systems_ by W3 (Web Technology Surveys) [https://w3techs.com/technologies/overview/content_management](https://w3techs.com/technologies/overview/content_management) [^gutenburg]: The WordPress Gutenberg source code repository: [https://github.com/WordPress/gutenberg](https://github.com/WordPress/gutenberg) [^gutenburg_feat]: The WordPress Gutenberg project introduction: [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/) [^wp_sec]: The WordPress Security team: [https://wordpress.org/about/security/](https://wordpress.org/about/security/) [^wp_source]: The WordPress source code repository: [https://github.com/WordPress](https://github.com/WordPress) [^wp_per]: The WordPress Performance team: [https://make.wordpress.org/performance/](https://make.wordpress.org/performance/) [^white_house]: The official website of the White House: https://www.whitehouse.gov/ [^wcag]: WCAG 2 Overview by W3C (The Web Accessibility Initiative): https://www.w3.org/WAI/standards-guidelines/wcag/ [^wave_ext]: WAVE accessibility browser extension: https://wave.webaim.org/extension/ [^wp_crit_vuln]: _Hackers exploit WordPress plugin flaw that gives full control of millions of sites_, Arstechnica: https://arstechnica.com/information-technology/2023/03/hackers-exploit-wordpress-plugin-flaw-that-gives-full-control-of-millions-of-sites/ [^wp_stats]: Wordpress Statistics: [https://wordpress.org/about/stats/](https://wordpress.org/about/stats/) [^num_of_wp]: _WordPress Statistics: How Many Websites Use WordPress in 2023?_ by colorlib: https://colorlib.com/wp/wordpress-statistics/ [^eu_web]: _EC Publishes Results on Review of Web Accessibility Directive_: https://www.moodysanalytics.com/regulatory-news/may-19-22-ec-publishes-results-on-review-of-web-accessibility-directive