This is the complementary blog post for my DrupalSouth Brisbane 2022 session.

Have you ever wondered how popular Drupal is in your local state and at the Australian Federal Government level? This blog post will help to answer that question, using open source tooling. The hope is that you gain some insight to the relative popularity of Drupal and appreciate more the impact you and Drupal have in Australia.

Existing solutions

There are a number of websites that will claim to be able to give you this information. However they all will likely want you at some point to pay them money.

• wappalyzer.com
• semrush.com
• builtwith.com
• whatcms.com
• similartech.com
• larger.io

“I wanted an open way to do this”

As it turns out, you can plug a few things together to scrape the technologies in use

• Wappalyzer library (open source)
• Puppeteer (open source)

Problem #1: How to get a list of all Australia Government domains

If anything, there are too many sources of this information:

• https://github.com/tb0hdan/domains
• Let's Encrypt Certificate Transparency (CT) logs
• SecurityTrails

A crawling method could also be done, loads of suitable seed sites, e.g.:

• https://www.australia.gov.au/
• https://www.directory.gov.au/departments-and-agencies

The main issue is that just having a list of sites, does not convey the importance of the site relative to another site.

Enter DomCop to which publishes a list of the top 10 million domains on the internet, including a rank and Open PageRank.

DomCop's top 10 million websites with a filter of .gov.au applied.

On top of suppling 5,795 Australian Government domains, there also is an "Open Page Rank" field. The PageRanks are calculated based on the Open data provided by Common Crawl and Common Search.

Problem #2: What is PageRank?

PageRank is a system for ranking web pages that Google's founders developed in 1996. A PageRank score of 0 is typically a low-quality website, whereas, a score of 10 would represent only the most authoritative sites on the web. It is logarithmic (with a base of 5).

A site with PageRank 3 is 5 times more authoritative than a site with PageRank 2.

Problem #3: Machinery of Government (MoG) and link rot

Australian Governments sites are never static, they are constantly evolving. Sometimes several sites merge into 1, or sometimes 1 site splits into move sites.

DHS Victoria is now closed. 3 sites now replace this 1 site.DESE is also now closed. 2 sites replace this 1 site.

Just show me the graphs

Disclaimer:

• This is based on Sept 22, 2022 data
• The scoring is based off PageRank data, so the percentages are not raw counts of websites, but an approximation of how important the respective sites are compared to others (assumes a logarithmic base of 5).
• Wappalyzer detection is not perfect (see the end of this blog post for upstreamed PRs), and there is still a fairly large portion of sites where the CMS cannot be identified
• MoGs make this tricky (PageRank relies on incoming links, which break due to MoGs)
• Only *.gov.au domains considered (some Government sites use other TLDs)
• Unlikely newly created websites are in the top 10 million just yet (due to how PageRank works)

All sites (*.gov.au)

All sites (*.gov.au)

Federal sites (not state based domains)

Programmes like GovCMS are having an impact here.

Federal sites (every non-state based domain)

Victoria *.vic.gov.au

The Single Digital Presence (SDP) programme makes a mark in Victoria.

Victoria (*.vic.gov.au)

New South Wales *.nsw.gov.au

Large Drupal sites like https://www.nsw.gov.au/ and https://www.service.nsw.gov.au/ help to make Drupal dominant in NSW.

New South Wales (*.nsw.gov.au)

South Australia *.sa.gov.au

South Australia (*.sa.gov.au)

Western Australia *.wa.gov.au

A lot of unknown CMSs in WA, including sites like https://ww2.health.wa.gov.au/ which I still have no idea what the CMS used is.

Western Australia (*.wa.gov.au)

Tasmania *.tas.gov.au

The lowest usage of Drupal for any Australian state or territory and the highest percentage of Wordpress.

Tasmania (*.tas.gov.au)

Queensland *.qld.gov.au

Queensland (*.qld.gov.au)

Australian Capital Territory *.act.gov.au

The highest percentage of Squiz compared to any other Australia state or territory.

Australian Capital Territory (*.act.gov.au)

Northern Territory *.nt.gov.au

Northern Territory (*.nt.gov.au)

Open Source Software (OSS) CMS vs Proprietary CMS

For the CMS' that can be identified, splitting them into 2 categories, OSS and Proprietary.

Open Source Software (OSS) CMS vs Proprietary CMS

Drupal sites by major version

For sites reporting as Drupal, Drupal 9 and 7 are the most popular.

Drupal by major version

Observations and other unusual findings

#1 - Drupal usage

“Drupal powers roughly 27% of all digital experiences that you use in the Australian government”

#2 - Top contender

“Squiz Matrix is the top contender with 15%, and has a clear state led mandate in certain states/territories”

#3 - TLS coverage

TLS coverage is not 100% - 129 domains found with no TLS

Domain

CMS

Page Rank

Score

http://www.bom.gov.au/

unknown

5.51

7,101

http://handle.slv.vic.gov.au/

unknown

4.47

1,332

http://www.mbsonline.gov.au/internet/mbsonline/publishing.nsf/Content/Home

hcl-notes

4.45

1,289

http://onesearch.slq.qld.gov.au/primo-explore/search?vid=SLQ

unknown

4.41

1,209

http://www.majorprojects.planning.nsw.gov.au/

unknown

4.41

1,209

The second most trafficked site in the Australian Government does not support TLS. Instead this awkward redirect page is used. And a sad face emoji. Sad face indeed.

#4 - If in doubt, add a number

19 domains found with ww[number] as a subdomain.

Domain

CMS

Page Rank

Score

https://www2.gbrmpa.gov.au/

drupal

4.85

2,455

https://www1.health.gov.au/

unknown

4.62

1,695

https://ww2.health.wa.gov.au/

unknown

4.49

1,375

http://www9.health.gov.au/

unknown

4.3

1,013

https://www0.landgate.wa.gov.au/

squiz-matrix

4.25

935

When you run out of subdomains, just add a number.

#5 - You cannot kill Dreamweaver

15 sites found in 2022.

Extending this for the future

• Crawl other domain spaces, e.g. the New Zealand government domain space *.govt.nz
• Make a website and publish this data quarterly (DomCop's data updates around this frequency)
• Measure trends over time

Upstreamed enhancements

These are all to make the detection of CMS' and Javascript frameworks more accurate for Australia Government sites.

• Ripple #6827
• Dreamweaver #6828
• HCL DX #6829
• MODX #6832
• Squiz Matrix #6833
• Optimizely CMS #6834
• Umbraco #6835
• Elcom #6836
• Lagoon #6861
• OSS flags and links #6902
• Squiz Matrix #2 #6925
• Ektron CMS #6924
• SiteCore #6926

Raw data

If you want to do your own analysis, here is a link to a full CSV dump.

Comments

I am keen to hear feedback on this data, and what can be done to improve the scoring. Also, if you can help fill in some of the 'unknown' data, let me know, I am happy to craft another PR into Wappalyzer.

Drupal has a number of coding standards and best practices that govern the way code should be written. This has many benefits but can allow for a consistent and maintainable code to be created.

All Drupal modules and themes are written with coding standards in mind and that allows Drupal developers to look at any project and see a similar style of code. If you ever submit code to Drupal or a contributed project you will be required to adhere to these coding standards, so it makes sense to get used to knowing about them.

The main tool that is used to test coding standards in Drupal is PHP_CodeSniffer, which is a widely used static analysis tool for testing PHP coding standards. It comes with a set of coding standards built in, but it is possible to add the Drupal coding standards for the tool to use.

In this article we will look at installing PHP_CodeSniffer and adding the Drupal coding standards to it. We will also looking at some of the more common coding standards violations that might be encountered and how to solve them.

Installing PHP_CodeSniffer

There are two ways in which to install PHP_CodeSniffer, globally and as a dependency on the project you are working on. Each of these approaches has different pros and cons, so we will address those whilst looking at how to install each.

Read more.

How long should a website last for? The average lifecycle of a website is about two and a half years. At Evolving Web we aim to develop products that will last between five and ten years. However, this sort of longevity can only be achieved through ongoing improvements. 

In March 2022 we published a blog post on the 10 signs your website is outdated. This post is worth reading in full, but to briefly recap, these are 10 signs that you might be due for some investment and serious improvement:

1. Users find it hard to navigate.

2. It’s content-heavy and hard for users to understand what you do.

3. It lacks clear calls to action.

4. You have outdated or incorrect content.

5. Search results aren't relevant.

6. Load times are too slow.

7. You need developer help anytime you want to make a change.

8. There are too many PDFs or content that's not accessible.

9. It doesn't allow you to implement SEO best practices.

10. It’s not optimized for mobile devices.

If one or more of these issues apply to your site, you definitely need to consider an overhaul. How extensive an overhaul is required depends on a number of factors, which can be addressed in a website transition plan.

Looking For the Signs

A website is a lot like a house. Fixtures and appliances age. Paint jobs, roofs and other elements occasionally require touch-ups or complete replacement. Clutter builds up and needs to be dealt with. Families expand, creating new demands.

The main difference between a website and a house is that your house is a private space, whereas your website is your company or organization’s gateway to the world, making it all the more pressing that it be up to date. Your house will survive without the latest developments in interior design. Your website, not so much.

Just as homeowners need to keep an eye out for signs that their houses might need minor or major repairs or remodelling, website owners need to do the same with their sites. That two-and-a-half-year lifecycle is not a long period of time. In fact, there are steps that are well worth taking as soon as your website first goes live.

Websites benefit from periodic, scheduled benchmarking. This means looking at competitors’ websites and seeing what they may be doing better (or at least differently) than you. Are your competitors using new keywords? Are they offering online features that you aren’t? Are they doing a better job at directing traffic to their sites through digital channels? Consider doing a benchmarking analysis every six months or so.

User testing is an important element of any website development project, but it is also a useful tactic to re-employ after your site is operational. This is especially useful for budget-conscious companies or organizations, as virtually anyone can find a handful of external stakeholders from a target audience willing to offer feedback on a website. Chances are that said stakeholders have also spent time on competitors’ sites and can offer comparative feedback.

Employing these and other tactics should give you ample warning that your site is perhaps not performing as well as it could be and that improvements are overdue.

For more on testing, read our recent blog post Design, Test, Design Again: Our Approach to Usability Testing.

10 Steps in Planning Your Website Improvement Project

Once you’ve identified that your site has shortcomings, it’s time to drill down to the heart of the problem. Is navigability a problem? Does your content not pass muster? Is your site falling short of accessibility standards? Here are ten steps you can take to identify the problems with your site that will enable you to take action.

1. Do a Content Inventory.

The first step to take in any website transition planning process is to map out your website’s content from top to bottom. Once you have a complete sitemap, you should be able to identify any problems your users might be having in navigating your site.

2. Conduct a Content Audit.

The next step is to do a full content audit. The purpose of this is to identify what content is serving you well (i.e. drawing traffic), what content is gathering dust and how specific pages and types of content have fared over time. Metrics to examine include page rankings, user behaviour (page views, bounce rate etc.), engagement and sales.

While companies or organizations may opt to undertake this internally, Evolving Web has extensive experience conducting content audits and would be happy to help you arrange this process.

3. Assess Your Tone of Voice.

Does your organization have guidelines around brand voice and tone? If so, is the voice and tone of your website consistent with those guidelines? A site that may have started off with a consistent tone of voice may start to lose this over time. As such, a check-in on brand identity is well worth the effort.

4. Review Your Company or Organization’s Mission Statement.

A website is a tool that should be embodying your company or organization’s mission statement, and if it no longer is there’s a problem. It’s worth reexamining if your mission statement comes across on your website – more than just a brief mention in your “About Us” section.

5. Review your Keywords.

While juggling keywords is no longer a valid search engine optimization strategy in itself, it still matters that you use the right keywords. Use Google Analytics to find out what terms people are using to find your site. Research related search terms by searching your current keyword in Google and see what the search engine suggests.

You can also use a keyword search platform like Google Keyword Planner, SEMrush or KWFinder to get the latest on what keywords people interested in your industry are using. You can also reach out to us directly for help with your SEO strategy.

6. Research Alternative CMS Options.

If there are mechanical issues with your website, like overly slow loading times, it could be that your CMS is no longer the best fit for the type of content you’re seeking to provide. It could be time to start looking into alternative CMS options.

7. Do an Accessibility Scan.

As with Step 2, conducting an accessibility audit should be achievable internally, through your own stakeholder network. At the outset of a website development project, it is wise to develop a network of people who either have disabilities or work with assistive technology who can assist with an initial accessibility audit and follow-up checks to ensure that your site continues to be accessible to all.

8. Do QA Testing for Mobile Devices.

This test can easily be done internally within a team – provided the people on that team operate mobile devices. Just as it’s crucial to test your site on mobile devices at the outset, it is equally critical to continue doing so as the site ages.

9. Keep an Eye on Analytics and Digital Trends.

How are people reaching your site? Has this picture changed over time? What digital channels are your competitors using? Keeping your eye on your analytics picture as well as on trends in digital media will alert you to dynamics that could affect how people interact with your website.

10. Get Help.

Much of the work involved in these steps, and the actions needed to remedy the situations, can be done in-house by most teams. However, if you’ve been through all these steps and found multiple issues requiring extensive overhaul, it’s probably time to call in the professionals. At Evolving Web we are well-versed in all these aspects of website transitions and would love to assist you with your site revamp.

The Role of an Agency 

Ever wonder why we chose the name “Evolving Web”? Simply put, we chose it because it reflects our view of websites as continuously evolving entities that need to be nurtured and guided over time. Websites have changed significantly since we first put out our shingle in 2007, and the work we do has evolved with them – as have our relationships with our clients. Constant evolution has been the theme of our work since the beginning.

The circumstances in which we enter into relationships with our clients are as diverse as the clients themselves. In some cases, our role is a simple migration from WordPress to Drupal, or from an older version of Drupal to the latest version. In other cases, a web project may involve a migration plus a significant content or UX overhaul – changes akin to a major house remodelling. And in some cases, we’re building a house completely from scratch.

At times we’re faced with a site with particular issues. In the case of Royal Roads University’s Our People site, we were tasked with fixing a site that was failing to deliver content to its intended audiences due to problems with information architecture. Through extensive interviews and surveys and a thorough content audit, we were able to reorganize the site in a way that satisfied all the university’s internal stakeholder groups.

Not sure where to start? We offer a wide range of different website audit services, which can help determine the state of your existing site and what it might need in terms of transition. These include a general-purpose audit (the most thorough version we provide), a strategic UX and content audit, a high-level in-depth technical audit, an accessibility audit or a pre-migration audit. An audit can help determine whether a straightforward migration is all that’s needed or if a more thorough redesign is necessary at this stage.

We can help you craft a website transition plan based on the audit's findings. A good transition plan should reflect the unique needs of your organization and map out a plan to get you to the website you need. Wherever you are in your “evolving website”, we can meet you there. 

 

//-->

+ more awesome articles by Evolving Web

I am pleased to announce that Juraj Nemec (poker10) has accepted our invitation to become a provisional Drupal 7 core maintainer!

Juraj is based in Slovakia and has been working with Drupal for more than 12 years. He works at ActivIT as the Tech Lead and Senior Drupal developer. As a backend specialist, he most likes optimizing large-scale systems, performance tuning and digging into what can be improved to bring the best user experience.

He recently contributed to fixing Drupal 7's PostgreSQL tests, helped to improve PostgreSQL performance with several important backports, and is actively working on improving Drupal 7's compatibility with PHP 8.1 and 8.2. He is also helping to get the jQuery Update module ready for its first big update in several years.

Juraj is excited about the opportunity to contribute to the Drupal community. He will work with the Drupal 7 maintainer team (Fabianx and mcdruid).

Please join me in welcoming Juraj to the committer team!

During the Drupal TechTalk the October 20, I discussed the urgency that comes with upgrading to Drupal 10. Because Drupal 9 will be End-Of-Life (EOL) on november 1, 2023 and that is much sooner than most people expect! I argued why it is important to start thinking and planning as soon as possible. Drupal 9 will be EOL on November 1, 2023. This date will not and cannot be extended, like Drupal project is doing with Drupal 7. The problem is that Drupal 9 is built on Symfony 4, and support will end on November 1, 2023. As the Drupal project cannot offer support for a version that has…

I've been working on multiple client projects where we needed to automatically import CSV files and display them on a site and I couldn't find a handy existing solution. Our typical scenarios include tables that changed daily like court data or stock information. With these and other possibilities in mind I came up with an idea to create a universal viewer module for different types of files. Basically this is a View module but for files. I started the Viewer module by adding support for CSV and later for XLSX/XLS and PDF.

At least one distribution of Drupal is already declared a Digital Public Good. Another will qualify blindly. Why not Drupal core distribution itself? The 20-year-old project was already meeting Sustainable Development Goals even before the UN formulated it. So the community is putting together an application before the DPGA.

Over the last few months, a group of Drupal community members from the Community Health Team have been working on updates to the Drupal Code of Conduct, with the assistance of a diverse group of community leaders and stakeholders from around the world.

The draft version of that updated Code of Conduct is now available for community review.

We are asking community members to provide constructive, actionable feedback in the Community Working Group's issue queue or share their thoughts privately via this form between now and November 30.

Feedback will be reviewed by the Code of Conduct committee to inform any changes to the draft document before it is finalized and shared with the Community Working Group prior to adoption.

Why do we need to update the Drupal Code of Conduct?

The current Code of Conduct was adopted in 2010 and last revised in 2014. Over the last five years, the Community Working Group (CWG), which is responsible for maintaining the document, has received consistent feedback that the Code of Conduct should be updated so that it is clearer and more actionable:

• A set of recommendations for improving the Code of Conduct was shared as one of the high-level findings from the community discussions facilitated by Whitney Hess in April and May 2017.
• 63% of respondents to a community governance survey held in July 2017 said that updating our Code of Conduct should be prioritized as part of the process of overhauling community governance.
• Improving the community Code of Conduct so that it is clearer and more actionable was also one of the key takeaways of the community governance discussions that occurred in the fall of 2017.
• In the spring of 2019, the CWG solicited feedback from community members about the current Code of Conduct and what steps should be taken to review and update it. The conclusions of that survey echoed earlier community feedback:
  • Respondents were overwhelmingly glad that Drupal has a code of conduct and liked its positive language
  • They felt that the current Code of Conduct is not specific enough when it comes to anti-harassment language, scope, and consequences
  • When it came to updating the Code of Conduct, respondents wanted the CWG to include members of Drupal Diversity and Inclusion, as well as camp organizers and other consultants.

What changes are in the updated Drupal Code of Conduct draft?

Overall

• All new and existing copy has been reviewed for readability and rewritten to use plain language wherever possible.
• Section headers have been reworded to provide more context.
• Examples of positive and unacceptable behaviors have been added to each section. These may be put in expandable fieldsets in order to improve readability.
• Instructions for reporting Code of Conduct violations are now broken out as a separate sidebar to make them easier for people to find.

Introduction

• The introduction has been rewritten to make it more consistent with Drupal’s Values and Principles.
• A pledge to welcome and support people of all backgrounds and identities has been added
• An explanation of what the Code of Conduct covers, who it applies to, and where it is enforced has been added
• An explanation of the consequences of violating the Code of Conduct has been added

We are considerate of the needs of others (formerly “Be considerate”)

• A recognition that community members communicate in different ways and use different languages has been added
• A reminder that community members should be valued equally whether they are volunteers or paid to participate in the community has been added

We treat each other with respect, even when we disagree (formerly “Be respectful”)

• Language on resolving disagreements has been moved from “When we disagree we consult others” into this section

We are collaborative (formerly “Be Collaborative”)

• Language that community members should take responsibility for the impact of their words and actions has been added
• A reminder to listen to others and keep an open mind has been added.

We do not tolerate abusive behavior (formerly ”When we disagree, we consult others”)

• Language about disagreements and conflict resolution has been moved into “We are collaborative”.
• Added language that taking action against harassment and abuse is a shared responsibility.
• Added language clarifying how the Conflict Resolution Team reviews and responds to incident reports

We ask for help when we need it (formerly “When we are unsure, we ask for help”)

• Added language about documenting work
• Added language that contributors may not always have time to answer questions
• Added language about reviewing existing documentation before asking for support
• Added language about updating inaccurate or outdated documentation

We step down considerately (formerly “Step down considerately”)

• Added language about being being able to take a break or step away
• Added language about leaving things better than we found them

We are here for each other (new section)

• Reiterates shared commitment to a diverse, welcoming, and inclusive community.

Who was involved in developing the updated Code of Conduct draft?

This effort was led by a group of Community Health Team members:

• George DeMet
• Nikki Flores (resigned from the Community Health Team on November 8 following her election to the Drupal Association Board of Directors)
• Julian Taylor
• Jordana Fung
• Mark Casias
• Donna Bungard
• Mike Anello

This group also involved a number of community stakeholders in the process including the full membership of the Community Health Team, and over a dozen other community leaders including members of Drupal Diversity and Inclusion, the Event Organizers Working, the Drupal Security Team, and past and present Drupal Association staff members. These community members were asked to provide feedback based on their personal perspectives and experiences, not on behalf of their affiliated groups or teams.

The group also solicited feedback on draft versions of the document from community members based in different areas of the world, including North and South America, Europe, Africa, and Asia.

What process was followed to create the Code of Conduct draft?

The group began with a chartering exercise to define shared goals, measures of success, opportunities, and constraints. A timeline was then created with key milestones, divided into two-week sprints.

The group then identified a set of existing open source codes of conduct to review along with the existing Drupal CoC. Different CoCs were assigned to different team members to identify their distinct elements (e.g., “examples of positive and negative behaviors”, “statement of scope”, “enforcement expectations”). The group met to discuss the different elements and voted on which ones they felt were “must haves” “should haves” and “nice to haves” for an updated Drupal CoC. The text of those elements was then collated into a single document and shared with community stakeholders for review and comment.

Following the initial review of that document, the group then worked to create an initial draft using clear and consistent language. This draft was shared with community stakeholders for review and went through multiple rounds of revision based on their feedback.

Updates were posted to the Drupal Community Working Group’s blog throughout the process.

What’s next?

Following the community review period, the group will meet to review all feedback and determine what changes need to be made to the draft document before it is finalized.

The finalized draft will then be shared with the CWG’s Conflict Resolution Team, which is responsible for maintaining the Drupal Code of Conduct and related documentation. They will consult with others and make any final changes before updating the Code of Conduct page on Drupal.org with the updated copy.

The Drupal and wider DXP community are embracing low-code development.

Low-code development is a broad topic, but at its core, it’s an approach to building digital applications that aim to reduce the gap between developers and non-developers. In other words, it lets you do more things while using less code. 

Instead of writing code, compiling it, and running it to view the results, low-code development lets teams work the other way around: users manipulate elements via a visual interface, and the full code quietly adjusts itself behind the scenes.

Gartner estimates that by 2024, more than 65% of application development will follow a low-code approach, so here’s what you need to know about this fast-growing trend: who it’s for, what it looks like, and what pros and cons come with its adoption. 

Low-code tools and platforms

Low-code is everywhere, and it’s for everyone. 

 identifies two major audiences for these types of platforms: 

• So-called citizen developers (also known as power users) rely on low-code platforms to accomplish various tasks despite their lack of formal technical knowledge (e.g. marketers, designers, managers)
• Development teams, who benefit from low-code solutions through the ability to utilize their existing skill set faster and more efficiently

One of the most recognizable examples of a low-code platform geared to the former audience is the WYSIWYG (what-you-see-is-what-you-get) website builder, which lets users manipulate visual elements as they would appear on the page, and the underlying HTML, CSS, and JavaScript is generated accordingly. This means that marketers and designers can collaborate on landing pages without having to work with a front-end developer. 

Common types of low-code platforms and apps include:

• Enterprise app creation platforms like Zoho and QuickBase
• WYSIWYG page builders and visual layout editors for content management systems, such as DXPR Layout Builder for Drupal or Elementor for WordPress
• Workflow automation software like IFTTT, Zapier, Integromat, and Microsoft Flow (for end-users), or Microsoft PowerApps (for developers and IT professionals)
• Ecommerce-in-a-box solutions such as Shopify
• Marketing automation software like MailChimp and Marketo

Low-code development advantages

There’s a reason why low-code development is seeing a surge in popularity: it comes with a host of benefits for marketers, designers, developers, and entire organizations. It’s also a great way for self-taught people - who make up a growing part of the workforce -  to quickly acquire new skill sets, as it greatly reduces the learning curve for complex technical concepts.

Easy to learn (for everyone)

Low-code applications enable everyone in an organization to benefit from powerful workflows and capabilities that were once the sole realm of those with development or scripting knowledge. 

For marketers, this could mean no longer relying on developers to build new landing pages and forms for a website; for designers, it might look like automatically exporting visuals as code rather than having to translate them manually before handing them over to the dev team.

Accelerates work

Even if you know how to accomplish something via programming, it doesn’t mean you wouldn’t prefer a quicker way to go about it. 

Low-code development speeds up processes on multiple levels: not only are fewer people needed to create a given asset, but the ability to create flexible, reusable components eliminates considerable effort from recurring tasks.

Lowers bug risk and increases security

Manually writing code is a task that’s particularly prone to mistakes, and anyone who’s had to parse through dozens upon dozens of lines of code to pinpoint a problem will agree that those mistakes often take quite a bit of time to fix. 

By automating code generation based on visual inputs and reducing the amount of “hand-written” code required, low-code applications take things like typos and open tags out of the equation entirely. Another advantage of working with low-code solutions is the enhanced security that comes with large-scale, extensively tested, and monitored platforms. Comparatively, entirely custom-built solutions tend to be at a higher risk for vulnerabilities.

Reduces costs

Thanks to all the aforementioned benefits, adopting low-code solutions is often the most cost-effective move for businesses. It’s a great way to make operations more efficient while saving time and effort for everyone involved. It also eliminates many of the more minute aspects of quality assurance and streamlines the testing process.

It also gives teams the means to take their skills further, so what might previously have required expensive third-party consulting can now be accomplished in-house.

Low-code development drawbacks

Nothing is perfect. While their benefits outweigh their downsides in many, if not most, cases, low-code platforms do have certain disadvantages when compared to fully custom solutions.

• It might make things harder to fix. If you build something without fully understanding what you’re doing and how it works, it’s likely going to take more than a quick glance under the hood to identify and solve potential issues.
• It can lack nuance. With low-code platforms, a single person can often build what would otherwise require input from multiple sources. This is a clear benefit in most situations, but it does mean that certain more specific elements risk being overlooked. 
• It can skew perceptions of scope. If building a landing page typically takes only a few minutes thanks to reusable components, requesting additional resources such as developer hours when a more complex version is required can be slightly more challenging to justify. It’s important to keep everyone on the same page when it comes to the limitations of a given platform or tool.

Low-code solutions for website development

One of the areas where low-code solutions really shine is streamlining website development thanks to user-friendly visual tools. Content management systems such as Drupal offer increasingly intuitive ways to build complex information architectures and data retrieval systems without the knowledge of PHP or SQL. When it comes to user-facing elements, DXPR provides a low-code solution that empowers marketing teams to unlock the full potential of Drupal sites. If you’re interested in building better sites, faster (and really, why wouldn’t you be?), check out the DXPR demo to see how easy it can be.

One of the reasons I love going to DrupalCon is that it’s a way to absorb everything new coming out of the Drupal community, and all the good things we have to look forward to in upcoming versions of Drupal. Here’s a summary of what I’m excited about right now!

New Goodies for Content Creators

Content editing features have been a focal point for Drupal in recent years. CKEditor 4 (the WYSIWYG editor that ships with Drupal) will soon be replaced by CKEditor 5. This new version provides improved editing features for content creation and editing features. These include track changes and revision history, intelligent text predictions and the ability to export to PDF. CKEditor 5 is now stable in Drupal 9.5 and undergoing testing so it’ll be ready when Drupal 10 is released.

The Drupal community has also made massive improvements to Localize.Drupal.org. This website, which is a means of incorporating languages into Drupal Core, promises to better translate the Drupal admin UI, which will result in a better UI for people who edit Drupal in other languages.

There is also an initiative underway to overhaul the Drupal toolbar in a way that is beneficial for content editors. The existing toolbar lacks submenu navigation and takes up too much space on the page in vertical mode. The goal is to adapt the toolbar so that it’s easier to use and more accessible for both content editors and site builders by introducing an up-to-date UI navigation pattern, adapting the information architecture and opening the possibility to include multiple menus that are built for the needs of different types of users.

Changes for Site Builders

DrupalCon Prague also brought news from the distribution and recipes initiative. Another tool that promises to make site building easier, recipes represent a more granular way of adding configuration to your site, allowing for a mix and match of a sort that you can’t do with distributions.

The current goals of the Distribution and Recipes initiative are to improve distribution discovery, allow for multiple distributions to be used on the same project, be installable at any time in a project's life cycle, provide for easier updates and enable distributions to ship demo content. A patch that can install modules, create and update configuration and apply other recipes is ready to use. More information is available at https://drupal.org/project/distributions_recipes.

Another exciting new initiative for site builders is the new project browser tool under development. This will enable site builders to search for contributed modules more easily through Drupal’s admin UI. Currently site builders are presented with an overwhelming selection of 55-plus categories of modules on Drupal.org. The new browser will simplify this with a more limited set of categories (which were brainstormed at DrupalCon), featuring useful information to help builders select modules that are good fits for specific projects.

Changes for Developers

A major piece of news from DrupalCon Prague of relevance to developers was the introduction of GitLab as a standard tool for developers to use to manage code and keep track of changes. This replaces the development tools offered on Drupal.org with a more complete set of tools (such as more streamlined merge request processes) and a whole product behind it. GitLab integration has already been added to Drupal, now it is now being added to all modules.

Automatic updates for Drupal Core were a major theme at DrupalCon Portland earlier this year and were again discussed at DrupalCon Prague. The Portland event featured considerable beta testing of the new update system, which brought this important feature closer to completion and ready for inclusion in Drupal 10. This is one of Drupal's most frequently requested features and will ensure that all Drupal websites stay secure throughout their lifecycle.

The future of Content Management

At DrupalCon I had the opportunity to give a presentation on the future of content management and how Drupal has evolved beyond simply being a content management system. It still functions as this, but it is also a digital experience platform and a platform that’s optimized for implementing your content strategy, whose strengths lie in its flexibility in terms of layering functionality on top of content in a way that actually integrates with your content.

I discussed how one of Drupal’s core strengths is its flexibility in creating structured content that matches your content strategy. This means you can create a strong strategy and build your Drupal platform to support it. Drupal can also integrate with other data sources and marketing tools in an open way, giving you choice as to what technology and marketing stack you want to use.

To sum up, I made a case for Drupal as an open digital experience platform. Focusing on content strategy first typically yields better results in terms of how you structure your content and the functionality, technology and marketing stack you layer on top of it. I also made the case that you need a strong content governance plan to keep your content strategy in place and in use in order to leverage Drupal in this way.

The roadmap for Drupal 10 and Beyond

One source of information for what’s coming down the line in the Drupal project is the twice-yearly Driesnotes, presented at each DrupalCon. In his customary keynote speech at DrupalCon Prague in September, Drupal founder Dries Buytaert expressed a certain frustration that his company doesn’t promote itself as well as it could. He began by discussing his discomfort with social media platforms and other forms of proprietary software while lauding Drupal as an open web champion, citing the freedom it provides to users to own their own content and code.

In his keynote, Dries spoke at great length about the many initiatives underway as part of the Drupal project, including the introduction of GitLab, which he cited as a major step towards making it easier for people within the Drupal community to contribute to the platform. He also noted that since his previous DriesNote in Portland, Drupal has achieved stability for Olivero and CKEditor 5, made preparations for the introduction of PHP 8.2, upgraded to Symfony 6 and made Drupal Core smaller – all of which will be included in the Drupal 10 launch at the end of 2022.

Dries also touted project browser and automatic updates as major initiatives that, while not set to be ready for Drupal 10, will probably factor into Drupal 10.2 or beyond. He cited these as features that enable average users to be part of Drupal and the open web (and will facilitate upgrading to Drupal 10). These features also help promote the great work done by Drupal developers, making that work more accessible to all Drupal users.

Have a migration project in mind? Join our migration workshop to learn more about moving your content and configuration into Drupal 9. This course takes Drupal 10 readiness into account, so you’ll also be ready for Drupal 10’s release or to migrate directly to Drupal 10, depending on the timing of your migration project.

 

//-->

 

+ more awesome articles by Evolving Web