Lucius Digital: OpenLucius beta-1 released | A Drupal social collaboration distro

Planet Drupal - Tue, 2021/05/25 - 9:08am

Last week we released a new version of OpenLucius: a lean and fast Drupal social collaboration distribution with features like: groups, social posts, messages, group chats, stories, file -and folder management, notebooks, categories, activity streams, notifications, @-mentions, comments and likes.

OpenLucius 2.0 has been in production for the last ~5 months, it's stable enough to go into beta! We also keep on improving: what we globally did since last release:

Categories:

OpenSense Labs: Leading open source the right way

Planet Drupal - Tue, 2021/05/25 - 7:08am
Leading open source the right way Akanksha Mehta Tue, 05/25/2021 - 10:38

All open source thrives on collective inputs and collaboration, there is the need for a centralised channelizing force every now and then to bring out the best in the existing resources. For any organisation that indulges in open source, it is important to remain proactive and constantly reflect upon and retrospect the direction in which their open source investments are heading. 

In any project leadership provides the much-needed vision pathway and blueprint for progressing in a certain direction. Even when something is collaborative, there needs to be a supervisor's perspective to solve problems and meet goals efficiently. 

More often than not, companies have open-source programs with objectives in place that they aim to achieve through the program. Assigning a lead not only improves the overall efficiency of the project but also helps in a number of other ways.

Some of the reasons why organisations care about diving into open source are as follows -


The Seven Laws of Leadership in open source

Leading an open source program varies greatly from the same role in other dimensions in the sense that it is not as straightforward and upfront. And a lot of times people might mistakenly assume that leadership is not required in such a project but they could not be more wrong. Something as vast, spontaneous and continuously evolving needs to be managed and utilised well at every point and in turn needs more supervision than regular platforms.

Let's move ahead and explore some mutually agreed and understood laws of open-source leadership that make a good leader in these platforms.

Competence

Open source leaders are very different from conventional bosses. It can be seen by the personality of Linus Torvalds, founder of Linux or Jim Whitehurst, CEO of Red Hat that their personalities spark liveliness and dialogue. They are highly approachable and remain open to the community base that they are a part of, and can be seen acknowledging and crediting their success to the community regularly. 

It can hence be deduced that rarely does a successful open source leader think just for himself, and it is always the values of togetherness and teamwork that take away the cake when it comes to allocating credit to the platform's success and growth. This is exactly the mentality that is required in an open source leader - somebody who drives their authority not from the designation that they hold but from the millions of people that toil everyday to keep the community thriving.

Being a teamplayer

Conventional leadership is largely surrounded by the aspects of authority charisma and holding onto the crown as long as possible. It is hierarchical and depends on the concept of formal leadership. 

On the contrary, an open-source leader isn't supposed to be perfect and utopian. He is more like the first among equals - he is as good as his team members and is not required to show his complete hands above the others in the team. He is supposed to be on the ground and lead the team by example. An open-source leader, hence, is not an unattainable figure, but he is just one commoner who has the ability to manage and improvise. 

Being spontaneous

For a platform that is as fast moving and evolutionary at every second, a laid-back leader just won't make the cut. You should be someone who is capable of taking spontaneous decisions as the leader here should be someone who can formulate and execute ideas quickly. Swift decision making is the key to succeeding in open source, and it must be the central idea of all plans of action. 

The open-source crowd is not patient enough for leaders who will slowly drop suggestions or complain about an issue or expect their contemporaries to resolve the problem at hand. Spontaneity and team spirit are integral to an open source leader and he is expected to pull up his socks and be the first one to start working.

Autonomy

In open source, autonomy replaces hegemony in the leadership role. The management does not exercise coercive control to get everything done, rather, all the tasks are worked upon and pulled together as a team. The job of the leader here is to lay down the framework of all the initiatives to be taken, within the community and establish related objectives to bring those initiatives into action.

This shows that authority and control are obsolete concepts when it comes to this dimension and creativity and autonomy are the desired qualities of an ideal open source leader instead. He is not only supposed to collaborate and lead but also to empower the team members by facilitating every tool and piece of knowledge that is needed to get the work done. 

Delegating it right

Leadership in open source focuses on the right delegation and decentralization of duties. As stated above, blending in well with the team and keeping everybody on the same same page is essential, hence each team member should be enabled to take the authority and ID fix any minor issues that arise from time to time and not reach out to the leader for every minor inconvenience. 

Never ignore the soft skills

Sure, getting the technicalities right is pretty important, but soft skills are the ones that pay off in the long run. More than anyone else, a leader requires a 'human touch' and needs to be empathetic and engaging with the team to keep each member's spirits high and productivity maximum. A leader should be able to perform, communicate explicitly, be very clear with the expectations along with being result oriented. Humility also accounts for a great soft skill and shines above everything else.

Say no to micromanaging

Needless to say, micromanaging can be detrimental to such a vast project as you might be biting off more than you can chew. It is physically impossible to manage everything that goes on in the ground in an open source platform, and one needs to realise that they cannot manage every project from tip to toe. A safer bet is to teach the skills required to your team members and delegate tasks to them regularly - along with trusting them with what they're doing.

Understanding the Leadership Role
 


Gaining leadership in an open source project can lead an enterprise to great commercial success. This is because

  • A lot of products depend on open source software technologies 
  • The path to Innovation unfolds much faster in open source
  • The software ecosystem is more or less dominated by open source.
  • Software can make or break your online business and is one of the biggest differentiating factors in present industries. Therefore, the best one matters now more than ever.

Now that we have covered the basic tenets of open source leadership, let's dive deeper into the model and understand the leadership role better. As widely recognised, this role is said to be the embodiment of an integration of these interrelated characteristics.

  • The first trait is to be awake about any intolerance or discrimination experienced by the team. Nothing kills team spirit quicker than bias. With such things to worry about, it would be a big hurdle for any person to look beyond being undervalued or excluded and perform to their full potential. The primary goal is to empower and motivate everybody and take care of all of their insecurities and weaknesses.
  • Branching out from the first characteristic is the second one - and it is trustworthiness. To act as the glue amidst the chaos, the first quality that you need to develop is being trustworthy. Honesty of the team members is extremely important to bring out the best in each resource and you need to give them an open slate to chalk out their aspirations, fears and problems. 
  • A trait exclusively important to open-source leadership is being agile and quick as the world would not wait for you to formulate an idea and implement it, and will move on at its own pace. If you are left behind there's nothing you could possibly do about it. 
  • Lastly, and most importantly, be accessible!  You do not want good ideas to be silenced or issues to not be brought to your notice until the last minute. An open-source leader must acknowledge that authority and responsibility go hand in hand and it is imperative for him to stay proactive and respond to each and every query and argument of his team.

This is how a leadership role in an open source project is outlined. After these essential requirements have been met, the next step would be to break the project down into consecutive steps and work on it one at a time.

Defining the project structure

Most open source projects follow the rule book in having a common repository that defines all the major principles and objectives of the project's governance model, structure, rules and processes. An open source project mein have any one of the three common governance structures - BDLF, meritocracy and liberal contribution.

Allocation of resources

Allocation of resources also includes assignment of roles to different team members. A member might be 

  • A contributor - someone who creates or follows up on an issue.
  • A committer - someone who has been given the access to write access to the repository.
  • A maintainer - someone who sets priorities and directions for a project or a special interest group. 
Mapping out the requirements

This is actually one of the most difficult parts of the process. The requirements in conventional projects are already defined by the company's authorities, but open source requirements come from users and contributors. Working in open source has to be very agile and swift due to this. Needless to say, the pipeline keeps changing and evolving by each passing day.

Defining coding standards

The team must have rules and standards related to both the overall process and coding explicitly mentioned in some documents and shared on a common platform that ensures easy day today communication. A set of directions on how to proceed with the code would avoid unnecessary conflicts and irregularities later on in the projects and save crucial time. 

Mentoring 

While everybody is expected to perform at their individual level, the leader is also expected to go the extra mile and establish a homogenous flow to help everyone on the team. Regular interactions and stand ups might help reinstating the common agendas. A simplistic pathway should be put in place for volunteers to start contributing to the project. Learn more about the perks of contributing to open source here.

How to make the most of open source?

Utilizing and making the most of an open source platform can become significantly easier when you have a strategy in place. 

  • Owing to the dynamic nature of open source goals should be set and reset on a regular basis. Once the agenda has been finalized, it needs to be reviewed annually or biannually for projects to sustain themselves and not go obsolete by the time you get them done. Therefore, even the long term plans in open source can only stretch up to a certain extent.
  • Needless to say, the planning needs to be proactive and there is absolutely no place for neglect in an open source platform specially from the leaders' end. Even when a project is complete it needs to be maintained in order to adapt to the present software trends for your targeted ecosystem.
  • The tech team should remain in sync with every other stakeholder so that the product that they are engineering is always close to the final idea in everyone's mind. To stay updated, after every milestone achieved, try to get appropriate feedback and incorporate it in the execution.

Lastly, one of the most important leadership roles is to foster a culture of psychological safety where the contributors feel free and excited about contributing to a project and not worried about the response that they will get. This is how Michael Cardy, Red Hat's Chief Technology Strategist puts it.

“The culture has to treat failure as an opportunity for learning, and failure is only bad when lessons are not sought and shared with the rest of the organization.” blog banner blog image Open Source open source leadership Blog Type Articles Is it a good read ? Off
Categories:

#! code: Drupal 9: Setting Up Multilingual Content Views

Planet Drupal - Sun, 2021/05/23 - 9:49pm

Drupal Views is a powerful module. The ability to generate lists of things in Drupal means that it is used everywhere. It even has a powerful plugin system that allows other modules to interface with it and create more functionality.

With multilingual sites there is a common issue I come across quite a lot that is quite easy to fix. A View will be created (usually via the Views wizard) that is intended to list a type of content. When an item of content is translated the content is duplicated in the View and you end up with a single list containing both translations of a single content item.

Let's take an example of this on a site with English and Welsh as the two languages present. I set up a standard View that shows articles content types in a list and then generated a few items of content using devel generate. After translating one of the articles the list looks like the image below with the first article in the list being duplicated. Since the original version was in latin (thanks to devel generate) I have just added the name of the language to the start translation title to show the new content.

This is clearly a problem as it creates lists of content containing duplicated items.

Here is the administration for this article listing View. As I said there is nothing wrong with how this is set up as it was done through the Views wizard, it is just that it doesn't support multilingual content.

Read more.

Categories:

Penyaskito: A Drupal JavaScript behavior for marking edited line items in the cart

Planet Drupal - Sun, 2021/05/23 - 6:14pm
By penyaskito, 23 May, 2021 A Drupal JavaScript behavior for marking edited line items in the cart

There are lots of ways to learn about something, and everyone learns in a different way, having best results with different options: some people get better results with articles, others with videos, or others with examples. My favorite way is with examples. And when trying to learn how to achieve something with Drupal, my favorite examples are Drupal core itself.

If you need to get something done and not sure where to start, try to think: where have I seen that before?

You might even have an example in your codebase already. This article covers a real use-case I faced with Drupal Commerce, just simplifying it a bit for the sake of keeping it short. The user story is something alike: As a customer, I need to refresh the cart page instead of continuing checkout after editing the units of any order line, so I can see any better discounts that apply because of volume.  

So in terms of our form, this will mean: when in the Cart form page, disable the Checkout button when the user edits any quantity field, and enable the Update cart one.

Drupal commerce shopping cart form after applying some ugly styling with the purpose of having better differentiation between disabled and enabled buttons.

But for a better user experience, we want the user to notice which line item they modified. Where have I seen that before? In the locale translations interface.

If you enable the locale module, and add a second language to your site, you have an interface translation page where you can fill the translations of the interface strings.

The locale translation interface UI already marks edited translations, and that's a valid example in Drupal core.

So we will look at the code and inspect how that's achieved. For me, the easiest way if you are not familiar with this piece of code is searching the UI strings or the url path of that page in my IDE, and dig until I find how that's working. In this case, if you search for "Changes made in this table" you end up in web/core/modules/locale/locale.admin.js, which is part of the drupal.locale.admin library defined at core/modules/locale/locale.libraries.yml. If you search for that library, you end up finding some forms that include the library with:

$form['#attached']['library'][] = 'locale/drupal.locale.admin';

So that's everything you need.

Let's create our module. Fastest way is using drush, so I executed

ddev drush generate module-standard

And picked commerce_cart_forcerefresh as the name. From the next options, I only generated the libraries file, which I edited to look like:

commerce_cart_forcerefresh: js: js/commerce-cart-forcerefresh.js: {} css: component: css/commerce-cart-forcerefresh.css: {} dependencies: - core/jquery - core/drupal - core/drupal.form - core/jquery.once

 Our css will only be

form#views-form-commerce-cart-form-default-1 tr.changed { background: #ffb; }

And our JavaScript:

(function ($, Drupal, drupalSettings) { 'use strict'; Drupal.behaviors.cartForceRefresh = { attach: function (context) { var $form = $('form#views-form-commerce-cart-form-default-1').once('cartItemDirty'); var $updateSubmit = $('form#views-form-commerce-cart-form-default-1 #edit-submit').prop('disabled', true); if ($form.length) { $form.one('formUpdated.cartItemDirty', 'table', function () { var $marker = $(Drupal.theme('cartItemChangedWarning')).hide(); $(this).addClass('changed').before($marker); $marker.fadeIn('slow'); }); $form.on('formUpdated.cartItemDirty', 'tr', function () { var $row = $(this); var marker = Drupal.theme('cartItemChangedMarker'); $row.addClass('changed'); var $updateSubmit = $('form#views-form-commerce-cart-form-default-1 #edit-submit').prop('disabled', false); var $checkoutSubmit = $('form#views-form-commerce-cart-form-default-1 #edit-checkout').prop('disabled', true); if ($row.length) { $row.find('td:first-child .js-form-item').append(marker); } }); } }, detach: function (context, settings, trigger) { if (trigger === 'unload') { var $form = $('form#views-form-commerce-cart-form-default-1').removeOnce('cartItemDirty'); if ($form.length) { $form.off('formUpdated.cartItemDirty'); } } } }; $.extend(Drupal.theme, { cartItemChangedMarker: function cartItemChangedMarker() { return '*'; }, cartItemChangedWarning: function cartItemChangedWarning() { return '' + Drupal.theme('cartItemChangedMarker') + ' ' + Drupal.t('Update the cart for the changes to take effect.') + ''; } }); })(jQuery, Drupal, drupalSettings);

Note that the form id is being used in some parts of that code, and that depends on the view id. Take that into account if you are not using the default view, you have multiple line item types, etc. In my real case, I was able to use a class that my theme was adding to that form.  

The last thing is ensuring this behavior is added to our form. The easiest for this demo is using hook_form_FORMID_alter(). Our commerce_cart_forcerefresh.module:

<?php use Drupal\Core\Form\FormStateInterface; /** * @file * Primary module hooks for commerce_cart_forcerefresh module. */ function commerce_cart_forcerefresh_form_views_form_commerce_cart_form_default_1_alter(&$form, FormStateInterface $form_state, $form_id) { $form['#attached']['library'][] = 'commerce_cart_forcerefresh/commerce_cart_forcerefresh'; }

And that produces the desired result:

The Checkout button is disabled, the Update cart button is enabled, a cue is added on the line item, and a warning on the top of the page.

Hope this helps!

Tags
Categories:

Debug Academy: I help diverse groups of people land jobs in tech. These are my top 10 tips for getting hired in 2021.

Planet Drupal - Sun, 2021/05/23 - 12:29am
I help diverse groups of people land jobs in tech. These are my top 10 tips for getting hired in 2021.

The hiring landscape in tech isn’t what it was 10 years ago. Here’s what you need to know to get hired now, no matter who you are

Regardless of the stage of your career you’re in, trying to land a solid job in tech can be stressful.

And the hiring landscape isn't what it was 10 years ago — lots of advice is outdated, or doesn't take into account the needs of underrepresented folks in the industry.

I help diverse groups of people land jobs in tech. Here's what you need to know in 2021.

ashrafabed Mon, 05/24/2021
Categories:

Droptica: How to Create a Homepage in Droopler

Planet Drupal - Fri, 2021/05/21 - 2:24pm

The homepage is the most important element of a website. The first impression of the user depends on it – whether they'll stay on the website, whether they'll be interested in the company's offer and the company itself. In just a few simple steps, we'll show you how to create a homepage that will help you keep your visitors' attention.

  What elements should a homepage contain?

A prospect enters the homepage. You have a few seconds to interest them and make them continue to check out your offer. How can you do that? You need to correctly convey the most important information that will immediately answer the customer's questions.

Banner with a call to action

First of all, you need to briefly describe what your company does. This type of information is often displayed in a banner at the top of the page. In this section, you can add a CTA (Call to Action). It's a link which when clicked redirects the user the destination area, e.g. to the next section of a page or to a contact form.

Blocks with content

You should also put blocks that contain information about what your company can offer to a potential customer and why they should choose your offer. Various types of representing information are suitable for these purposes: from simple text blocks to advanced interactive carousels that allow you to put more content into a fairly tight framework of one block.

Once you know what elements to put on the home page, the matter of creating the page in a fairly quick and easy way arises. Website builders – one of which is Droopler – are suitable for solving such a problem.

 

Create a homepage in Droopler

Droopler is an open source website builder based on CMS/CMF Drupal. It contains ready-made components and tools that allow you to quickly create modern webpages. Droopler is simple to edit and easy to expand. Let's try to create the most important elements of a homepage with its help.

Banner paragraph

As we've already mentioned, one of the most important elements of a homepage is a banner with brief information about the company at the top of the page. In order to add a block of this type, press the “Paragraph overlay” button on the top right of the page.

 

Next, you have the option to add a new block in the selected area. After pressing the "Add" button, select the "Banner" component in the pop-up window.

 

In the next window, you need to add a banner background. Additionally, you can add a title, subtitle, icon that appears at the top of the block and some brief text. It’s also possible to add the already mentioned Call to Action button and configure its main attributes.

 

In the "Settings" tab, you can choose the shape of the block: placing the text in the central part of the banner or on the left side with a translucent background. It’s also possible to set different colour versions of a paragraph and define your own colours to ensure good readability of the text. Additional options include configuring the margins and padding, as well as adding additional classes for the block.

 

After pressing the "Save" button, the first block of the main page will be put in the lower right corner of the window:

 

Carousel paragraph

A carousel is a type of block that contains a looped slideshow that can be controlled by the user. In order to create such a block in Droopler, select "Carousel" in the component list window.

 

As in the case of a banner, you can add a title, icon, description and CTA. In the "Settings" tab, it’s also possible to set the margins. In addition, you can define the number of columns - how many elements should be displayed in this block.

 

The carousel items are added in the "Items" tab. You can choose your own title, image, description and link for each of them. The same as for the entire paragraph, for every element, you can set separate graphic themes - change the colour of the background or text. The next picture shows a finished carousel.

 

About Us section

You can create a block with information about the company using the "Text page" paragraph type. It's a simple section where you can enter a title, subtitle, add an icon, text and link. The available settings are the same as for a banner and carousel. After all the fields are filled in, the section will look like this:

  Summary

In this article, we explained how to create the most important elements of a homepage in a fairly easy and quick way. We used Droopler – a modern website builder, which not only allows you to build websites without coding, but also facilitates Drupal development.

Categories:

undpaul: Once Drupal, always Drupal

Planet Drupal - Fri, 2021/05/21 - 11:47am
Categories:

Promet Source: Provus Tapped for Top Pantheon Innovation Award

Planet Drupal - Fri, 2021/05/21 - 4:14am
This year, Pantheon set out to evaluate the digital landscape and recognize the world’s best WebOps leaders for creating web experiences that “drive deep, positive change.”  
Categories:

Dries Buytaert: Join the first Drupal Project Browser Initiative meeting

Planet Drupal - Thu, 2021/05/20 - 7:28pm

When I ask people why they fell in love with Drupal, most often they talk about feeling empowered to build ambitious websites with little or no code. In fact, the journey of many Drupalists started with Drupal's low-code approach to site building.

With that in mind, I proposed a new Project Browser initiative in my DrupalCon North America keynote. A Project Browser makes it easy for site builders to find and install modules. You shouldn't need to use the command line!

Making module discovery and module installation easier is long overdue. It's time to kick off this initiative! I will host the first meeting on May 24th between 14:30 UTC and 15:15 UTC. We'll share a Zoom-link on the Project Browser Slack channel before the meeting starts. Join our Slack channel and mark your calendars.

We'll start the meeting with high-level planning, and we need people with all kinds of skills. For example, we'll need help defining requirements, help designing and prototyping the user experience, and much more.

Categories:

Nonprofit Drupal posts: May Drupal for Nonprofits Chat

Planet Drupal - Thu, 2021/05/20 - 4:26pm

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, May 20, at 1pm ET / 10am PT. (Convert to your local time zone.)

No set agenda this month, so we'll have plenty of time to discuss whatever Drupal-related thoughts are on your mind. 

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org and open to everyone.

View notes of previous months' calls.

Categories:

Evolving Web: Accessibility, Applied: Chatting with Firat Ikiler, UI Engineer

Planet Drupal - Wed, 2021/05/19 - 5:26pm

Last week I got to chat with Evolving Web’s UI engineer, Firat Ikiler. Firat has extensive experience in web design and frontend development, and he’s now one of our foremost experts on accessible design. We talked about how he acquired his accessibility skills, how accessibility plays into his day-to-day work, and some of the critical concepts (and common misconceptions) involved in accessible digital design.

“I learned about accessibility when I started with Evolving Web,” Firat told me. It wasn’t at all something that was on his radar only a few years ago, but now it’s in the mainstream.

According to him, training, whether self-guided or via a structured program, is the best way to learn about accessibility. It isn’t something you’re likely to have learned much about in school, so you’ll need to seek out the right resources to get a good understanding of the fundamentals.

📰 Read next: How we plan a UX workshop, with UX lead Annika Oeser

This is essential, he says, because whenever accessibility is part of a project, “it’s impossible to fix everything all at once”. Any tool you use for auditing will undoubtedly uncover a host of issues—sometimes hundreds, even thousands—which can easily overwhelm someone who doesn’t have a firm enough grasp on accessibility fundamentals.

“When I use a tool such as SiteImprove, I often find myself looking up the different issues that are flagged in order to make sure that they’re relevant and actually need fixing.” You learn a lot as you go along, researching things as they arise, according to Firat; especially since best practices tend to be in constant evolution.

The author (right) and Evolving Web's UI engineer and accessibility extraordinaire, Firat Ikiler (left)

All in all, while formal accessibility training will definitely give you a solid head start, there’s no better learning experience than “experiencing an issue and solving it yourself.” “This is a huge part of the learning process for accessibility, in my opinion,” Firat says.

When I asked him if accessibility was something we needed to tell clients about or rather something they’d request, he told me that in the past two or three years it’s become a requirement in almost every request for proposal we’ve answered. This is likely due to a number of factors, such as the growing body of accessibility legislation and standards and a general increase in awareness towards the importance of digital accessibility.

“One or two years ago it wasn’t really an obligatory thing, but now companies are required by law to comply with accessibility requirements, so they’re definitely aware and asking for it.”

I asked Firat how accessibility played into his day-to-day work as a front-end developer and UI engineer. “I try to apply accessibility rules while the project is in an ongoing state,” he told me. “Trying to fix all accessibility issues at the end of a project would be too much work”

“Every day I’m checking all of the components I develop, making sure they follow accessibility best practices,” he continued. “I try to correct issues as they arise”.

My next questions were about the popular wisdom surrounding accessibility. One of the most common misconceptions in accessible design, in Firat’s experience, is that you always need to provide an alt text when displaying an image.

“If an image is for decorative purposes only,” he explains, “not only does alt text provide no useful context or information, but since it will be read by screen readers, it can make things even more confusing.” (It should have an alt text attribute, however; just make sure it’s set to “empty”.)

This type of misunderstanding comes back to what we’d discussed earlier about needing a good understanding of fundamentals. It’s easy to fall into the trap of blindly applying rules from a list of best practices; knowing how to prioritize and evaluate accessibility issues and solutions is a key skill for today’s web designers and developers.

When designing for a CMS, Firat says, it’s always good to “think about the components as Lego bricks and work to make them accessible wherever a user might place them”. One challenge this introduces involves heading hierarchies: headings go in order —H1, H2, etc.—and the components’ heading structure needs to be constructed as not to break this order when switching their placement on the markup. “That’s the hard part of designing with a11y rules.”

Beyond these intricacies, “design,” he says, “is the more obvious part” when it comes to creating accessible experiences.

He went on to explain that when most people hear the word accessibility, their mind goes straight to things like alt text and colour contrast. Those things are, of course, essential, but they represent the tip of the accessibility iceberg, according to Firat.

So what’s beneath the surface? One word: markup. “The big part happens when you start to develop the page.”

“The big part happens when you start to develop the page.”

“We need to put ourselves in the position of people who actually need to navigate the page with assistive technology,” says Firat, “and develop in ways that retain the full meaning for them.” Even if your site has perfect contrast and every image has an alt text, poor markup can make your content difficult to understand for a large audience.

“We need to put ourselves in the position of people who actually need to navigate the page with assistive technology,” says Firat, “and develop in ways that retain the full meaning for them.”

One important thing to consider is semantic HTML. It's essential in ensuring that the layout of the page’s information makes sense regardless of how it’s displayed via CSS. “Semantics refers to the meaning of the code”

Ensuring that a site’s underlying HTML is written in a way that’s easy to understand for assistive technology like screen readers or mouse alternatives is another critical consideration.

A lot of the flagged issues you’ll come across in an accessibility audit involve missing WAI-ARIA labels. If you don’t have an alt text for an image link, for example, you need to have an ARIA label to indicate what’s going on.

Landmarks are another issue. For example, in Drupal, if you create a navigation menu with the nav landmark, it also creates a role attribute (role=navigation). In all cases, two attributes together that provide the same information are unnecessary and can cause confusion.

Aditus has a great visual overview of how the Government of Canada and Yale University websites look with VoiceOver and landmark navigation, if you’d like to see what this looks like in practice.

Master the art and science of accessible digital experiences

Firat’s first foray into the world of accessible design was with Evolving Web’s accessibility training. Fast-forward a few years, and he’s now one of our in-house accessibility experts. If you’d like to embark on a tried-and-true path to mastering accessibility, sign up for our upcoming training.

+ more awesome articles by Evolving Web
Categories:

Tag1 Consulting: The future of application development in Laravel (with VILT and TALL) - Pt. 3

Planet Drupal - Wed, 2021/05/19 - 3:13pm

In our final installment of our series on Laravel, Senior Software Engineer Laslo Horvath and Managing Director Michael Meyers talk about the future of application development, and Laravel’s role in that future. Laravel’s strengths include a strong push towards reusable components. This methodology enables developers and designers to take advantage of using the things they need, and leave everything else behind. Laravel-based stacks enable website builders to more easily switch from developer to designer, and back. Application development in Laravel is growing rapidly. Integrations with other software are common, and they’re bringing tools together that help developers work together more smoothly and efficiently. VILT (Vue.js, Inertia, Laravel, TailwindCSS) and TALL (TailwindCSS, Alpine.js, Laravel, Livewire) combinations really start to highlight the potential of these packages in concert. Learn more about how these stacks are being used, and where they're headed. * Part 1 * Part 2 ### Related content * Laravel * Vue.js * Tailwind CSS * Inertia.js * Alpinejs * Livewire For a transcript of this video, see Transcript: Laravel with Laslo - Part 3. Photo by...

Read more lynette@tag1co… Wed, 05/19/2021 - 06:13
Categories:

Oomph Insights: Asynchronous Messaging Platform helps the State of Rhode Island Departments Inform One Another

Planet Drupal - Wed, 2021/05/19 - 2:00am
The Challenge The platform had many business requirements, and one stated that a global notification needed to be published to all department sites in near real-time. These notifications would communicate important department information on all related sites. Further, these notifications needed to be ingested by the individual websites as local content to enable indexing them for search. The hierarchy of the departments and their sites added a layer of complexity to this requirement. A department needs to create notifications that broadcast only to subsidiary sites, not the entire network. For…
Categories:

Oomph Insights: Is a Microservices Architecture Right for Your Platform?

Planet Drupal - Wed, 2021/05/19 - 2:00am
Why are microservices growing in popularity for enterprise-level platforms? For many organizations, a microservice architecture provides a faster and more flexible way to leverage technology to meet evolving business needs. For some leaders, microservices better reflect how they want to structure their teams and processes. But are microservices the best fit for you? We’re hearing this question more and more from platform owners across multiple industries as software monoliths become increasingly impractical in today’s fast-paced competitive landscape. However, while microservices offer the…
Categories:

Community Working Group posts: Welcome Donna Bungard, newest member of the Conflict Resolution Team

Planet Drupal - Tue, 2021/05/18 - 10:24pm

The Drupal Community Working Group (CWG) is happy to announce the addition of Donna Bungard to the Conflict Resolution Team. Based in New Hampshire, United States, Donna has been contributing to the Drupal project and community for more than five years. She is the Accessibility Manager and a Senior Project Manager with Kanopi Studios, a skilled writer, and accessibility expert. 

Over the past year, the Drupal Community Working Group has expanded to include a Community Health Team, of which Donna has been a member since the inception. One of the goals of the Community Health Team was to provide an on-ramp to the Conflict Resolution Team.

In addition, we have formalized our on-boarding process for the Conflict Resolution Team with the goal of making it easier for us to add additional members in the future, and making participation on the team more sustainable for all members. As part of the on-boarding process Donna will act as a provisional member of the Conflict Resolution Team with limited access to previous issues as well as mentoring on current issues.

As per the CWG charter, Donna has been approved by the CWG review panel.

We would like to thank the other 5 candidates we interviewed for the Conflict Resolution Team; we hope that all of them continue to remain active in Drupal Community health issues in the future. As we have decided to make the expansion a slow and deliberate process, we will be discussing additional options and future contributions with them.

The CWG is responsible for promoting and upholding the Drupal Code of Conduct and maintaining a friendly and welcoming community for the Drupal project. To learn more about the group and what we’ve been up to over the last year, check out our recently-published annual report
 

Categories:

Mediacurrent: Drupal 9 Upgrade Guide: Auditing Your Codebase

Planet Drupal - Tue, 2021/05/18 - 10:08pm

To keep your organization at the forefront of open source security and innovation now's the time for a Drupal upgrade or migration to Drupal 9. Drupal 7’s end-of-life is November 2022, but if you’re currently on Drupal 8 the end-of-life hits in November 2021.

In this guide, we’ll cover Mediacurrent’s tried and tested approach to upgrading sites of all sizes. Kick-off with a codebase audit. Then, tackle code and compatibility issues. In the final mile, run a first-attempt upgrade to find and fix any remaining issues. And finally, the actual Drupal 9 upgrade.

Introduction

As you think about your upgrade path (whether moving from Drupal 7 or 8), a good starting point in preparing for Drupal 9 is performing a readiness audit. An audit will assess the level of effort and provide recommendations and preparations for a smooth upgrade or migration path to Drupal 9.

At a high level, a Drupal 9 upgrade process would look like this:

  1. Audit the codebase for deprecated code

  2. Audit the codebase for composer compatibility

  3. Fix deprecated code issues

  4. Fix composer compatibility issues

  5. Attempt Drupal 9 upgrade and see what’s left

  6. Perform actual Drupal 9 upgrade

In the first blog post of this Drupal 9 Upgrade series, I will focus on the first two steps and show you how to audit a codebase for Drupal 9 readiness. By the end, you will have a better understanding of the process and level of effort required for a successful upgrade and be more prepared to estimate a budget and timeline.

Audit for Drupal 9 Readiness

Performing an initial audit on the codebase is straightforward. This process should result in tickets in your task management system of updates to be performed way before the actual Drupal 9 upgrade release date.

Scan for deprecated code

Drupal-check is an invaluable tool for scanning files in a codebase to check their Drupal 9 readiness by looking for deprecated code -- basically code that was previously lingering around in Drupal 8 but is now removed from Drupal 9.

If drupal-check helps you during this process, and I’m sure it will, consider sponsoring the ongoing development and improvements of the project.

Install drupal-check

The most typical way to install drupal-check is to install it as part of the project via composer as a dev requirement. Be sure to review the drupal-check installation documentation.

composer require --dev mglaman/drupal-check Run drupal-check

The drupal-check command can be run on any single file or directory. These steps assume it was installed in the project with composer, therefore the executable exists in the “vendor” folder and can be run as follows.

Here is an example of running the command against a contributed module that contains some deprecated code issues:

vendor/bin/drupal-check docroot/modules/contrib/allowed_formats

Now would be a good time to create a task in your task management system for addressing that deprecated code issue. Thankfully a solution already exists for the Allowed Formats contributed module that fixes this one particular issue.

That issue and fix were found by visiting the module’s project page that you are working on making Drupal 9 ready, search for “drupal 9” in the issue search box, and review what Drupal 9 related issues exist.

There is typically an issue labeled “Drupal 9 Deprecated Code Report”, but it may be named something else, and there may also be multiple related issues.

Here is another run of drupal-check against another contributed module, which in this case, has no deprecated code issues.

vendor/bin/drupal-check docroot/modules/contrib/crop

While it appears at this time that this module is Drupal 9 ready per the drupal-check tests, it may not be completely Drupal 9 ready yet. In the next section, we’ll look at ways to check composer compatibility, which once the module is both composer compatible and no code deprecations present, it will be in great shape for the Drupal 9 upgrade.

Good, but not perfect

The drupal-check tool is very helpful, but it is not perfect. Again, consider sponsoring the project to help continue future development and improvements!

One of the false positives drupal-check may report relates to class usage. For example, it may be validating a class that is used by a module that no longer exists in the codebase, e.g. old code from a Drupal 7 migration that’s no longer used, so there’s nothing to do about that.

Also, sometimes drupal-check does not catch certain issues. For example, the codebase had a custom module that still contained a call to the `path.alias_manager` service, but that service is no longer available in Drupal 9 and was moved to `path_alias.manager`. However, drupal-check did not report this as an issue - I only found out about this issue once the Drupal 9 site was built and I tried to access the page that was controlled by the code that contained that old, removed service class call.

An alternative to drupal-check is to use the contributed module, Upgrade Status, to check on the Drupal 9 readiness of your existing site.

You should now have a good understanding of what custom and contributed packages need work to make them Drupal 9 ready. Be sure to keep notes or skip to the Issue Tracking section below.

Check composer compatibility

In addition to the deprecated code issues, the codebase also needs to be compatible with Drupal 9 from a composer perspective. Without packages being Drupal 9 supported in composer, composer will simply not allow the codebase to upgrade to Drupal 9.

What’s Not D9 Compatible?

A quick test you can do right away is to run this command, which will list all packages that are only supported by Drupal 8. These will need to be updated to also support Drupal 9.

composer why drupal/core | grep -Ev "\^9"

Essentially, this command tells us which other packages depend on Drupal core that do not yet have a 9 version in its composer metadata. Composer will not allow a Drupal 9 upgrade. Read more about the Composer Why command.

The output of the command will look something like the following:

These values come from the composer.lock file and are basically the list of packages used in the codebase that depend on drupal/core, specifically packages that only work with Drupal 8. This should be pretty much all of the themes, modules, and profiles, unless they have been kept updated on a regular basis and when security releases are available and necessary.

Just to be clear, the first lines that start with “drupal/core” can be ignored, the only ones to focus on are the other lines that reference contributed (or custom) modules.

For instance, in the example above the Facets module has a current version of “1.4.0”, or 8.x-1.4. This module will need to be updated to a later version, or a patch added that makes it Drupal 9 compliant; it might also be worth testing the current dev snapshot, the necessary fixes might have been committed, just not available as a full release yet. It appears for Facets module, the 8.x-1.5 version adds the Drupal 9 support.

Results in this output should be added as new tickets in the ticket management system of packages needing updates to address the deprecated code and composer compatibility issues.

Issue Tracking

To track the status of packages and their Drupal 9 readiness, I recommend creating a spreadsheet that helps track the ongoing upgrade process and what needs to be done. The below is just a small subset of changes needed, but I do recommend having multiple rows per package, in the cases where there may be multiple Drupal.org issues to cover all the D9 related fixes you’ll need.

Without getting too deep into it right now (saving for the next blog post), I’ve seen deprecated code issues be addressed in one Drupal.org issue, and the fix was committed to the latest version. But simply updating to the latest version did not make it Drupal 9 ready, because there were still composer compatibility fixes, and in some more rare cases, even still some deprecated code issues that were missed in the first pass. So, those issues may be split among multiple issues on Drupal.org.

This planning, tracking, and documentation will help you as you continue through the Drupal 9 Upgrade process and keep tabs on what is remaining along the way. It may also serve as a good starting point or baseline for the next Drupal 9 upgrade process you may be involved in.

Conclusion

This blog post focused on the up-front audit process and preparation work required to understand the amount of work required to get into Drupal 9 readiness status. In the next blog post in this Drupal 9 Upgrade series, we will work on fixing the deprecated code and composer compatibility issues we discovered and documented as a result of this audit process.

Mediacurrent is a top 10 contributor on Drupal.org and has created solutions to accelerate, ease, and enhance the upgrade process. We can help you prepare for a Drupal 9 upgrade. Reach out anytime if you want to discuss your Drupal upgrade path or are interested in our team performing a Drupal 9 audit on your site and how we can help you succeed.

Categories:

Lullabot: A Plan for Upgrading from Drupal 8 to Drupal 9

Planet Drupal - Tue, 2021/05/18 - 9:04pm

With Drupal’s new versioning and release planning came the promise of easy upgrades between major versions. No more major database overhauls. No more rewriting business logic just to keep things working. No more major investments in expensive migrations to maintain feature parity.

Upgrading to Drupal 9 from Drupal 8 provides the first test of these promises. Have the promises been fulfilled? 

Yes.

Is it as simple as flipping a switch?

No.

Categories:

Ben's SEO Blog: The File (Field) Paths Module

Planet Drupal - Tue, 2021/05/18 - 3:03pm
The File (Field) Paths Module The File (Field) Paths module allows you to automatically sort and rename your uploaded files using token based replacement patterns to maintain a nice clean filesystem.
Categories:

Palantir: Streamlining Drupal Multisite Maintenance with Config

Planet Drupal - Tue, 2021/05/18 - 2:00pm

Create and maintain a family of Drupal sites using shared configuration instead of install profiles.

Several of our clients manage multiple small sites for independent centers or groups within their organization. These sites often share an information architecture and key features like SSO integration and editorial workflows. They differ mainly in their content, and who manages the content for each site. They  are visually distinguished by logo and color, but share much of their page layout and components, meaning they can share a design system and theme as long as it provides a few options.

This group of sites can be run as Drupal "multisites", where multiple Drupal installations run on the same Drupal codebase and hosting infrastructure. A typical approach for setting up these sites would be either to install and configure each independently, using the same underlying code but re-creating the content types, taxonomies, and content management workflows for each -- or, to create one site and clone it. What this does is create multiple distinct Drupal sites that need to be updated independently when the content types or module configuration needs to evolve.

At this point you could consider building a Drupal "install profile", which lets you create identical new sites. However, the process for maintaining shared configuration after installation is to write update hooks, a tedious process compared to Drupal's config management.

Sharing base configuration

The approach we took instead was to share a base set of configuration -- the bulk of the Drupal config -- between all of the sites. This means that sites start from a complete set of features, including content type, taxonomy, and menu configuration as well as modules like SSO and workflow. A limited number of configuration items -- like the site name and 404 page, the logo and color theme settings, and others as needed -- are split out into site-specific config folders.

Not only do sites start from a complete shared set of features, but as features are added to the main configuration, each of the sites receive the new functionality at the same time.

Consider a case where you want to install a new module across all of the sites. For multisites set up with an install profile and independent configuration, you would need to enable and configure the module on each site independently. This would require careful attention to ensure the changes were applied on each of the sites, and verifying that you made exactly the same configuration decisions on each. When you discover that an option needs to be tweaked, you go back into each site and update it.

For multisites set up with shared config, you can install and configure the module once. The shared config will propagate the changes to each of the multisites. As you tune the module configuration, these changes too will go out to the multisites using straightforward config management processes -- no update hooks required.

Step by step

Here's how this works:

Set up

  1. Start by installing and configuring the first site
    1. Export the configuration to what will be the shared config directory
  2. Install Config Ignore, and configure it to at least ignore “system.site” (and probably “blocks.*”). Any other settings that vary across sites (ex: theme settings, colors, etc.) will also need to be added here.
    1. Configuration that is ignored will still be used when a new site is installed -- they act as "base config" -- but won't be imported again after installation
    2. If there's configuration that shouldn't be used as base configuration (often relevant for blocks), there are two options for making the Config Ignore workflow cleaner:
      1. Config Export Ignore will prevent certain configuration objects from being exported
      2. OR add a .gitignore in your config directory to exclude the files
  3. Install Config Split if there are modules that only need to be enabled on certain sites; when using Config Split, each site or group of sites will need their own split configuration directory.
  4. Now your config is ready for re-use.

Adding more sites

  1. Set up the scaffolding for a new multisite using the normal multisite set up process
  2. Make sure each multisite uses the shared config directory that you've created
    1. See Drupal's documentation on changing the storage location of the sync directory
  3. Install the new site from config when running install.php
    1. Using the web interface, select "install from config"
    2. OR using the command line, run drush si --uri=MULTISITE_URI --existing-config

Updating sites

  1. To make a change across all sites:
    1. Edit any site
    2. Export configuration -- this will update config in the shared config directory
    3. Check the changes into your repository
    4. Import config on the other sites
  2. To make a change that will only affect one site (this change will live in the destination/prod environment only)
    1. Make the change on the one site, locally
    2. Add the config to Config Ignore and export the configuration
      1. Both the Config Ignore settings and the changed config will be exported!
      2. Commit the changes to Config Ignore, but NOT the config file that you're ignoring
      3. You may want to add the specific files to the .gitignore so they don't accidentally get checked in and used as base configuration on new sites
      4. Note that the Config Ignore rule won't prevent the new configuration from being imported unless it is present BEFORE the new config is present
    3. Deploy the Config Ignore changes
    4. Make the desired change on the prod site
    5. If you're ignoring an entire class of config (like all block configuration), you only need to do this the first time you set up the Ignore
  3. To update core or modules across all sites
    1. Managing updates across multisites follows the standard process -- update the shared codebase and then run the update hooks on each site individually<
    2. Config that is changed by a module update only needs to be exported once
Making Multisites Easy

There's always a balancing act between the specific needs of one website among many, and the stability and maintainability of a single codebase and feature set. Creating a family of multisites is a great way to isolate editorial responsibilities, allowing divisions or centers independent control of their content and navigation; sharing the code AND configuration between these sites allows sustainable maintenance and iterative feature rollouts.

Airstream Ranch by Carlyle Ellis Photography/Human Quotient, licensed under CC BY-NC-ND 2.0.

Drupal Site Building
Categories:

OpenSense Labs: Why Update PHP: An All Inclusive Guide

Planet Drupal - Tue, 2021/05/18 - 1:30pm
Why Update PHP: An All Inclusive Guide Gurpreet Kaur Tue, 05/18/2021 - 17:00

A computer is a marvellous creation, it can be used to build and execute any number of software and instructions that we may want. What is even more marvellous is that it understands exactly what we want it to do. And this extraordinary task is possible because we have programming languages that speak in computers. 

One of them is PHP or Hypertext Preprocessor. It is an open source programming language that runs on a web server, which has been popular throughout its life cycle being the go-to language for web development.

PHP with its server-side scripting together with HTML and its execution in the browser are immensely popular especially when creating dynamic websites is in question. Majority of Drupal sites are built on it, the entirety of Drupal is written in PHP, I think that should be proof of the language’s epic capabilities. 

Source: W3Techs

The above image further clarifies the doubts about PHP’s capabilities and well, its popularity. 

There are numerous adjectives that I can use to describe PHP’s competencies, however, the one that is appropriate for how the language is going right now would be ‘behind schedule.’ And sadly this adjective isn’t for the language itself but for the websites and developers using it. The reason is the delay in its update. 

Today we’ll try to understand the language in regards to its versions and the capabilities that come with each of these versions and then we’ll get to the important question as to why PHP is not being updated and what you stand to lose, if you keep delaying. 

Let’s start by understanding PHP’s Life Cycle

Like everything else in this world, PHP also comes with an expiration date. Each of the PHP versions has a fixed life cycle, beyond which using it can be detrimental. Usually this life cycle is around three years, once those three years are completed the version becomes unsupported, you can still use it, at your discretion though.

When a PHP version is released, it is actively supported for the next two years. This active support entails the frequent fixing of bugs and security issues and their consequent patching. The third year, sometimes even fourth, will only entail releases pertaining to critical security issues. This is also the time when the next version becomes available. 

Once these three years have been completed for that particular version, it becomes unsupported. There won't be any fixes or patches, not even for security and using such a version would mean you are making yourself vulnerable.

As of now, 

Version 5.6;
Version 7.0;
Version 7.1;
Version 7.2;

Have reached their end of life, meaning they are no longer supported, yet many sites are still on them. So, which are the versions that are supported and should be ideally used? The answer is 7.3 and above. 

Source: php.net

Any version that is still actively supported would be the only one ideal for your web projects. Talking about projects under the Drupal flagship, the same three supported versions are the only ones recommended by the CMS; proving that there is truth to what I am saying.

Source: Drupal.org

Taking the supported PHP versions under the microscope

I have said a number of times that using a supported version is ideal, now let’s understand the why. Yes, they would get new updates, fixes and patches quite frequently, but that is not it; these versions are also perfect to use because they have features that are unfound in the previous versions. It’s like being on Android 9, you are missing out on a lot of features that Android 10 is powered with and there is no advantage in that. 

Let’s look at each of the supported PHP versions to understand this. 

Version 7.3 

The third version of PHP 7, version 7.3 was released in December, 2018 and is said to be faster than its predecessor. There weren’t changes in this version, but the improvements that were made proved quite helpful. 

  • The 7.3 came with more flexible heredoc and nowdoc syntaxes; 
  • The 7.3 came with multibyte string functions; 
  • And the 7.3 also had Argon2 password hash enhancements; 

All of these made this release better than the last.

Version 7.4 

Released almost an year after the launch 7.3, PHP 7.4 brought along significant in two key areas; 

  • Performance, by adding the preload functions to speed up loading significantly; 
  • And code readability, with features like typed properties and custom object serialisation. 

PHP 7.4 also marked the end of PHP 7 as this was the last version before 8 came along.

The Newest Kid on the Block: PHP Version 8 

PHP 8.0.0 is the latest version of the scripting language. Released on 26 November, 2020. This was a major release for PHP coming almost three years after version 7 was released. Although there are a lot of new features added to this new release, speed optimisation that was introduced in PHP 7 will continue improving on it. 

JIT Compiler, union types, type annotations and reflection signatures are some of the new features found in this release. Here is a video highlighting and explaining the prominent new additions in PHP 8.

What will the update mean for you?

Up until now, you must have gotten a fair idea that updating PHP will be beneficial for your web project. Yes, sometimes updating can seem like a mistake, but that isn’t the case with PHP, not in the least. 

There are the additional features that were lacking in the preceding version of the update, you definitely benefit from that. Apart from that bonus, three discernible reasons to update PHP that should make the process all the more worthwhile.

Heightened Security 

The paramount benefit of always updating PHP is security. With every update, you’ll be more secure in the site because that running version is going to be fully supported and patched frequently for any and all security vulnerabilities. 

As we’ve already discussed, as versions come to their end of life, they do not get patches and fixes, making your project unprotected from threats. 

Source: CVE Details

Looking at this graph, it is clear that PHP experiences security vulnerabilities, with 2016 being the year marking the highest level at 106. 

Source: CVE Details

Talking about vulnerabilities by type, denial of service, overflow and execute code are the ones topping the ranks. An update is what will prevent these security threats from being a threat and if you don’t update, you’ll have to be extra diligent about them. Is that something you want to do instead of working towards achieving your goals? I doubt it.

Perpetual Support

Then comes support, which becomes almost absent in older versions of PHP. Much like every other advancement we see, whenever a new one rolls by, interest in its older version starts diminishing and it is understandable. For PHP, this diminished interest means that the preceding versions would not get the kind of support from the community that it used to and its compatibility would lessen.

Think about it from the developers’ perspective, since they are the ones creating plugins and themes for every version. When they can devote their entire time and attention in creating something wonderful for a new version, do you think they’ll be interested in doing the same for something that is almost antiquated? I do not think so. 

There is also the concern of time, developers become occupied with the newer versions, so they do not get the time to oversee support for the older versions, making them somewhat incompatible for newer browsers and general development. 

So, when you keep updating PHP, you will continue to get support for it in the form of new plugins and themes and any issues you may face will be resolved quite quickly. You won’t ever see a 2000 comment thread for an issue in a new version, since there will be perpetual support to fix that.

Superior Performance

New technology will always outshine old in terms of performance, right? The same is true for PHP versions. When you update, security and support benefits would be there obviously, however, the more apparent benefit would be the one related to performance. You will be able to tell the difference almost immediately. 

Things that you had to work for diligently to achieve will come out of the box. From better latency rates to being able to handle more requests per second, everything would improve when you update.

Here are two images that show PHP Benchmarks for performance in version 5.6 and 8.0 and the improvements in performance are more than evident between the two versions.

Source: PHP BenchmarksThen, why are the older versions still active?

When an update brings along such benefits, it should be a no brainer. Yet there are umpteen sites that are still on the older versions of PHP. 

Source: W3Techs

The fact that more than one-third of PHP sites are still on version is kind of sad and hard to digest even. I mean version 5.6 reached its end of life on 31 December 2018, almost two and a half years ago, yet it is still active without any support.

So, why is that? Why are these sites keeping themselves vulnerable when they can be secure? Let’s try to understand the reasoning. 

The obliviousness about the update 

The foremost reason for not updating is the obliviousness surrounding the update itself. The thing about web projects and websites in general is that, although they are built by developers, the people running them on the daily may not have knowledge about its technical sides. All they are concerned about is the fact that the site is running and functional and that it looks good. 

For these non-technical site owners, updating PHP isn’t something to be concerned about. Half the time they are oblivious about the fact and even if they do know it, they’d not pay much heed to it. Many a time, it is the developers and web hosts, who have to push the site owners for the update and they don’t always win that battle based on the W3Techs statistics.

The investment of time

If we talk about updating PHP to version 8.0.0, it is fairly easy to do so. However, that ease is contingent upon the code being updated. If the code is up-to-date, you’ll have an easy-breezy update. If not, you’ll be looking at a huge investment of time and resources. And that is the second reason why sites don’t update.

  • Developers who have older plugins and themes will have to put in a lot of time and effort to update their code because the newer version would not be compatible with an outdated code. 
  • Then comes the testing that needs to be done to ensure the compatibility of the update, which is quite extensible because there will be a great deal of plugins to test.
The apprehension surrounding the update’s effects

Lastly, it is the apprehension that comes with the thought of the update that makes site owners immensely hesitant about updating. 

What if the update breaks the site?
What if the update results in additional support tickets?
What if the update makes the site stop functioning altogether?

These what if pose a massive roadblock even before the road to update has begun. Fortunately, all of them are unwanted and misguided. 

Remember the previous reason, it talked about updating the code before updating to a newer version. If you update without making the code compatible your site will break, there isn’t a shadow of doubt about it. 

Apart from that the update won’t affect your site in a negative light. Upon updating PHP on a site built on a CMS like Drupal, you’ll instantly see an improvement in performance and that isn’t something to be apprehensive about, rather you should be looking forward to it.

How do you go about the update?

Now that we’ve discussed everything concerning the PHP update and have established that it is more than imperative to keep PHP updated, we have come to the final aspect of the process, which is how to update PHP.

The update is done in two parts, one is a prerequisite and the second is performing the actual update itself.

Checking PHP version compatibility

The first part of the PHP update is to check whether your site is even compatible with the version you are trying to update to, in regards to the themes and plugins, they should be updated to their latest version. This is also one of the reasons I mentioned in the previous section as to why sites don’t update PHP.

You would need your developers for this, since they’d be the ones who would add or fix support for the version to be updated. There is also the option of choosing alternate plugins, if that is what you prefer. 

Once your themes, plugins and current code is updated, you’ll be ready to perform the update. 

A little side note; You should remember though, that updating the staging site before updating the production site is the better way to go. This is because if you do encounter any mishaps during the update, you’ll be able to fix them on the staging site without any effect on the live site.

Choosing the suitable way to update 

The actual update can be done in three ways depending on the build of your site and the kind of tools you have access to.

Through the cPanel 

If you have access to a cPanel or your host provides access to the same, you can simply go to the control panel, log in and change the version of PHP to the one you want; it’s as simple as that.

Through your own server 

You can update PHP using the migration guide provided by php.net, that is if you are the administrator of your own server. This guide covers the migration procedures from version 5.5 to 8.0 and clarifies all the details related to the update from new features to backward incompatible changes and deprecated features.

Through a web host 

If the aforementioned ways don’t work for you, that is you don’t have access to the cPanel and you are also not the administrator of your site, then you can simply ask your web host to perform the update for you. 

Conclusion 

There comes a point in life when you have to say goodbye to what has been normal for you because something else has taken its place. And it’s almost never a bad thing. Has anyone ever felt sad after updating their iphone? I don’t think I know anybody who has, maybe a little upset about the hefty bill, but never about the product. 

The same is the story with PHP updates. It may seem like a daunting task to undertake, much like paying a thousand dollars for the iphone, but in the end, it’ll be you, who’ll be basking in the benefits of the update. Is that not something you’d want?

blog banner blog image PHP PHP versions PHP lifecycle Blog Type Articles Is it a good read ? On
Categories: