Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 6 hours 24 min ago

DrupalEasy: Easily remove the "Request new password" functionality

Mon, 02/08/2021 - 10:00

This may be the quickest quicktip we've ever written - if your site doesn't require the "Request new password" functionality, the No Request New Password module makes it pretty easy to remove it. 

Before:

After:

Also - the module doesn't just hide the "Request new password" link, it removes the functionality completely, so if a user navigates directly to /user/password, they'll be redirected back to the login page. 

MidCamp - Midwest Drupal Camp: Community Onboarding Day: A new virtual “welcome table”

Sun, 02/07/2021 - 23:52
Community Onboarding Day: A new virtual “welcome table”

Edit: After publishing, and based on community feedback, we've modified our naming slightly. "Community Day" is now "Community Onboarding Day".

At every pre-pandemic MidCamp attendees were welcomed by a team of volunteers with shirts and badges and stickers and funny hats and answers to every question possible. Our 2020 event had a few warm human moments, like when a room moderator asked 100+ people to come off mute simultaneously before our opening remarks, but ultimately recreating the human-ness of our prior events in a virtual setting proved challenging. This was not only draining for prior attendees but challenging for new community members.

This year, our new “Community Onboarding Day” sets out to provide a more human on-ramp by:

  1. introducing new community members to the product, the community, and the kinds of conversations that will go on during the event, and 
  2. engaging all attendees in planning the event itself.

In our prior post, we began to define our audience. We’ll begin community day with a morning of short talks and discussions split up into three audience-specific tracks:

  • I’m new to Drupal: these discussions could include a review of the tools on Drupal.org, learning opportunities around the community, or a panel of folks discussing why they’ve stuck around the community.
  • I do Drupal, I’m new to the community: Many folks Drupal, but not every Drupaler knows how they can leverage our incredible community. Here we’ll talk about issue queues, documentation, and novice contribution opportunities.
  • I do Drupal, I’m involved in the community: This group could discuss Drupal core initiatives, triage Contribution Day tasks, or review mentoring opportunities.

If you’re interested in presenting or have a request for a topic, please comment on this Drupal.org issue.

In the second half of Community Onboarding Day, we’ll open the “Call for Activities/Topics” for our Thursday and Friday Unconference. 

  • Thursday will be focused on building relationships in the community through social events, games, and lightning talks, and other activities that are welcoming to all.
  • Friday will take more of a traditional Unconference schedule, with Birds of a Feather (BoF) discussions and more.

To encourage diversity in discussions, we’ll also be holding a workshop for marginalized, underrepresented, and historically excluded speakers on Wednesday afternoon. 

So, that’s Community Onboarding Day. With it, we hope to:

  • give new attendees the confidence to bring a topic or activity to the table,
  • give everyone a plan of what they can expect for the next two days,
  • provide opportunities for connection and mentorship.

In the end, this MidCamp we’re encouraging all attendees to:

  • come as you are, 
  • bring your excitement and ideas, 
  • plan for lots of opportunities to engage, and 
  • feel free to step away as you need.

MidCamp - Midwest Drupal Camp: Community Day: A new virtual “welcome table”

Sun, 02/07/2021 - 23:52
Community Day: A new virtual “welcome table”

At every pre-pandemic MidCamp attendees were welcomed by a team of volunteers with shirts and badges and stickers and funny hats and answers to every question possible. Our 2020 event had a few warm human moments, like when a room moderator asked 100+ people to come off mute simultaneously before our opening remarks, but ultimately recreating the human-ness of our prior events in a virtual setting proved challenging. This was not only draining for prior attendees but challenging for new community members.

This year, our new “Community Day” sets out to provide a more human on-ramp by:

  1. introducing new community members to the product, the community, and the kinds of conversations that will go on during the event, and 
  2. engaging all attendees in planning the event itself.

In our prior post, we began to define our audience. We’ll begin community day with a morning of short talks and discussions split up into three audience-specific tracks:

  • I’m new to Drupal: these discussions could include a review of the tools on Drupal.org, learning opportunities around the community, or a panel of folks discussing why they’ve stuck around the community.
  • I do Drupal, I’m new to the community: Many folks Drupal, but not every Drupaler knows how they can leverage our incredible community. Here we’ll talk about issue queues, documentation, and novice contribution opportunities.
  • I do Drupal, I’m involved in the community: This group could discuss Drupal core initiatives, triage Contribution Day tasks, or review mentoring opportunities.

If you’re interested in presenting or have a request for a topic, please comment on this Drupal.org issue.

In the second half of Community Day, we’ll open the “Call for Activities/Topics” for our Thursday and Friday Unconference. 

  • Thursday will be focused on building relationships in the community through social events, games, and lightning talks, and other activities that are welcoming to all.
  • Friday will take more of a traditional Unconference schedule, with Birds of a Feather (BoF) discussions and more.

To encourage diversity in discussions, we’ll also be holding a workshop for marginalized, underrepresented, and historically excluded speakers on Wednesday afternoon. 

So, that’s Community Day. With it, we hope to:

  • give new attendees the confidence to bring a topic or activity to the table,
  • give everyone a plan of what they can expect for the next two days,
  • provide opportunities for connection and mentorship.

In the end, this MidCamp we’re encouraging all attendees to:

  • come as you are, 
  • bring your excitement and ideas, 
  • plan for lots of opportunities to engage, and 
  • feel free to step away as you need.

Ny Media: Why we decided to migrate from Travis to Github Actions, and why you should consider doing the same

Fri, 02/05/2021 - 12:46
Why we decided to migrate from Travis to Github Actions, and why you should consider doing the same jakub February 5, 2021

At Ny Media we’re quality-oriented and our main objective is to provide secure and reliable solutions, giving our clients all tools they need to run successful online projects. To ensure the quality of solutions and meeting the client’s acceptance criteria we’re developing test cases to cover all critical parts of their business logic. In order to achieve this, we are facilitating different testing frameworks, just to name a few:

  • PHPUnit - for unit testing
  • PHPStan - for static code analysis
  • Behat - for user-story testing and acceptance criteria

This is not a complete list (that’s material for a separate blogpost) but should at least provide some perspective on what is our testing stack which varies between different projects.

Travis CI

For many years we were using travis-ci.com, which is a paid version of travis-ci.org - the popular among FOSS (free and open-source software) maintainers, a continuous integration platform, that allows running customized test cases on your private Github repositories. For us, one of the reasons to become paying customer of Travis is to support the company that was promoting FOSS. Many of us, developers here at Ny Media, were using Travis on daily basis for our own open-source side-projects, so integrating Travis into our company workflow was the only logical thing at that time.
Unfortunately, lately, Travis became highly unreliable both to their customers but also their own employees. They have also made it impossible for FOSS maintainers to keep using their services. Therefore we decided it’s time for a change.

Github Actions

Since we’re using Github as our main remote git repository, the natural choice for us was to explore Github CI (aka Github Actions) capabilities. Github has been working hard the last couple of years since the initial announcement of Github Actions to provide everyone with access to their product.

I’d like to name a couple of features that immediately caught our eyes:

  1. GitHub-hosted runners
    You don’t need a custom infrastructure to run your tests - Github can provide it for you at a reasonable price. All our tests are running on linux-based platforms and the price, at the time this blog post was created, is 0.008 USD per minute. There is some package of minutes included in your Github plan. Moreover, all public repositories are free to run Github Actions!
  2. Self-hosted runners
    You can run your tests on Github infrastructure or use your own infrastructure - either physical or virtual. And the best part is - you don’t need to pay extra for utilizing that infrastructure as a Github test runner
  3. .“Unlimited” concurrency
    The number varies depends on your plan but it is quite generous even for Free accounts (20 concurrent runners). At the time of writing this blogpost Travis charges 249 USD for 5 concurrent runners.
  4. Powerful infrastructure
    A few years back Github was acquired by Microsoft, and as a side effect of this acquisition, it got access to cloud infrastructure - Azure. Therefore they can provide a quite powerful infrastructure at reasonable prices making it hard to beat.
  5. Exceptional documentation and support
    Github is quite great at documenting all features regarding the new platform. Even if the moment of doubts I’ve been able to reach out to the support team and get my answers within the same day.
Migration

Since our tests on Travis were running within a dockerized environment and not directly on the worker instance, we were able to finish the migration within one day. It required the following steps few steps.

Create .github/workflows/test.yaml file

Here’s the example file you can use as a template:

name: Run tests on: push: branches: - develop - master pull_request: branches: - develop - master jobs: build: name: Run tests runs-on: ubuntu-latest timeout-minutes: 20 steps: - uses: actions/checkout@v2 - run: /bin/bash run-tests.sh

In the example above run-tests.sh script represents all the steps your test suite requires to execute. It may need to build dockerized environment, it may need to download all dependencies, run test scripts, it’s up to you. In our case it all the above.

I want to highlight 2 things in the template above. This workflow will only be triggered when you push to branches master and develop or if you open a Pull Request against those 2 branches and push some commits to the branch associated with such Pull Request.
Here’s what you’ll be seeing in your Pull Requests

You can see 2 steps being run as a part of this job. Please mind the difference betwee keywords used for each of those steps. The run marks what script or sequence of commands should be run on your runner host.  The uses provides a way of utilizing from the whole marketplace of pre-cooked actions. The one used in the template - actions/checkout@v2 - is provided directly by the Github team. It allows your project to be cloned in a certain directory (by default the current one) and the commit which triggered the build will be checked out. Very simple, yet powerful - more about it in our future blogposts.

Make sure checks passed before merging the Pull Request

Do that by setting up the protected branch in repository Settings -> Branches


Disable Travis

Now that your tests are running using Github CI you can safely remove all references to Travis in 3 easy steps:

  1. Cancel your plan. If you’re paying for Travis just go to https://travis-ci.com/plans and switch to plan Free.
  2. Go to https://github.com/organizations/yourorganization/settings/installations and remove the Travis App
  3. Delete .travis.yml from all repositories that you used to test with Travis. You don’t need that anymore.
Summary

Are we happy with the migration? Yes, very much so. Without making any change to how we run tests (initially, we started with 1:1 test migration from Travis to Github CI) our test times were decreased by ~20% due to much more powerful test runners on Github vs. Travis. In addition, Travis was limiting us to a certain amount of runners that can run concurrently (depending on pricing plan). That restriction was increased by the order of magnitude when we migrated to Github CI, giving our developers much quicker feedback. On top of that, despite the increased performance, we’re actually paying less for using Github CI compared to Travis.

But this is not the end of this story. We have barely scratched the surface of possibilities when it comes to utilizing Github CI API. In the next blog post, we’ll talk about what can you do to further improve your workflow and optimize time spent on testing. Stay tuned.

 

Agiledrop.com Blog: Top Drupal blog posts from January 2021

Thu, 02/04/2021 - 08:23

This January was a particularly exciting time for the Drupal community, with the open-source project celebrating its 20th birthday.

READ MORE

myDropWizard.com: Drupal 6 Long-Term Support Extended to 2023 - and What About Drupal 7?

Thu, 02/04/2021 - 06:55

One more year? Sure. Why not!?

When we originally announced that we'd be providing Drupal 6 Long-Term Support, we committed to supporting our customers until at least February 2017.

We've made pretty regular announcements in the past extending things far beyond that original end-date.

Today, we're announcing that we'll be extending our Drupal 6 Long-Term Support (D6LTS) until at least February 2023!

Amazee Labs: Video: DrupalCon Europe 2020 Speaker Replay

Wed, 02/03/2021 - 11:47
<img src="https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/Speaker-Video-Replay.jpg?h=994a2424&amp;itok=B3R9UndF" width="1120" height="630" alt="Replay of Amazee Labs DrupalCon Europe 2020 Speaker videos" title="Video: DrupalCon Europe 2020 Speaker Replay" class="image-style-leading-image" /> Thanks to all the hard work of the organiszers, speakers, attendees and, of course, contributors from the open source community. Without a doubt, DrupalCon Europe 2020 was a great time for everyone who was able to attend and an excellent opportunity to share and sharpen our experience design, web development, and web maintenance skills. Of course, the on-going mission to improve all things open source and Drupal 9 projects continues, so if you weren’t able to attend the event, missed a few sessions that you weren't able to fit into your schedule, or just want to refresh your memory — we’ve got you covered. In this article, we’ve pulled together the replays of our best sessions for you to watch — all in one easy place!

DrupalEasy: Interesting tidbits of Drupal.org usage in 2020

Wed, 02/03/2021 - 10:00

I was poking around the Drupal.org project usage page over the holidays checking out some trends and making sure there weren't any up-and-coming contrib projects that haven't been on my radar. Since Drupal 8 was released (over 5 years ago!) I've been bothered by the fact that this page can't be filtered by the Drupal core version.

Along the way I fell into a bit of a rabbit hole and decided to dig much deeper into Drupal.org statistics. But first, let's take a look at contrib projects.

Most installed contrib projects

An incomplete workaround to finding the most installed contrib projects by Drupal core version is to use the module search page and filter it by Drupal core version and sort by "most installed." While this provides a list of modules, it doesn't provide historical trends as the project usage page does. Regardless, here's some data:

Top 5 installed Drupal 8 and 9 contrib modules 

Top 5 installed Drupal 7 contrib modules

Top 5 installed Drupal 9 contrib themes 

Top 5 installed Drupal 8 contrib themes 

Top 5 installed Drupal 7 contrib themes

While this data is somewhat interesting, there really aren't any surprises.

Drupal.org usage statistics

For that, I recently requested, and received access to the Drupal.org analytics from the Drupal Association with the goal of looking at some usage statistics from 2020 and to dig a little deeper into what Drupal developers were up over the past 12 months.

I wasn't interested in doing a complete statistical analysis of the data and comparing it with historical data, rather I was just looking for things I thought were cool. Plain and simple.

All data below is for the time period of January 1, 2020 - December 31, 2020.

First off, I'm not a data scientist - I'm just a nerd who likes to look at data sometimes, so some of the assumptions I make below may be off-the-mark. If so, feel free to correct me.

Let's start off with some basic stats - in 2020, there were about 50,000 users on Drupal.org on any given weekday. Anecdotally, the daily December average was around 5,000 users/day higher when compared with January.

Who are we and how are we accessing Drupal.org?

Where are the users coming from? Not surprisingly, the largest percentage came from the United states, but more visitors came from India and China (when combined). Clearly, we need to do a better job in recruiting from these areas to be more involved in Drupal leadership. 

Country

  • 20% US
  • 12% India
  • 11% China
  • 5% Sweden
  • 3% United Kingdom

Interestingly enough, when looking at the top 10 cities where Drupal.org traffic originates, 6 of the top 10 are from China and India. In order, they are: Beijing, unspecified, Stockholm, Chicago, Bengaluru, Chennai, London, Mumbai, Hyderabad, Pune

The majority of visitors' browsers report their language as English, with Chinese the next largest share. This seems to imply that many of the visitors from India speak English well enough to have their browsers set to use English.

Language

  • 49% English (US)
  • 12% Chinese
  • 9% English (GB)
  • 3% English (unspecified)
  • 3% Spanish

Some other interesting statistics about who is visiting Drupal.org:

  • 85% are new visitors - this seems (very) high to me, and I'm going to attribute (at least a portion of it) to folks with privacy controls that make it seem like they're a new visitor.
  • Over 60% of visitors use Chrome, with almost 50% on some version of Windows, and 80% using a desktop browser.
  • Over 60% of users arrive via an organic search - this is not surprising to me at all, as I routinely (multiple times a day) use Duck Duck Go to search for content on Drupal.org rather than use Drupal.org's search tool.
What are we looking at?

Now for the data I was really I was interested in finding - which topics, issues, and projects we were actually looking at in 2020. To do this, I focused mainly on the top 100 most visited pages on drupal.org. 

Hash-tagged numbers indicate the page's position in Drupal.org's overall most visited pages ranking.

Most visited contributed projects

No huge surprises here, except I'm still amazed by the popularity of Bootstrap (keep in mind there are multiple Bootstrap-based base themes as well!) I was also a bit surprised at the popularity of Commerce, not because it isn't an amazing tool, but because I would've guessed other projects would be above it (Redirect module, for example, is #46).

It's also interesting that Webform was the most visited contributed project page, but didn't appear in any of the "most installed" lists above.

Most visited topic-specific documentation pages

Unsurprisingly, the top 2 most visited documentation pages (that aren't landing pages) were related to Composer. 

Most visited contrib project issues

This was probably the most unexpected and unexplainable data I found. No way I would've ever guessed that the most visited contrib project issue would be for the Commerce Braintree module. Luckily, it is marked as "fixed", I can only imagine that the traffic was primarily to access the patch? 

Then, the second most visited issue is related to the Image module for Drupal core version 5.x? It's traffic is pretty consistent for all of 2020. The only thing I can think of to possibly explain this is that the thread has a magic combination of keywords that put it high in organic search results (well over 90% of the traffic to this page originates from search engines).

Most visited forum post

How to login to Drupal admin panel (from 2017!) #84

Yes, the Drupal.org forum is still alive and people are still accidentally getting locked out of their sites.

Most visited page without a path alias

How to fix "The following module is missing from the file system..." warning messages (from the "Reference" section) #43

Oh yeah - I've definitely been someone who has searched for, and landed on this page.

Most visited Drupal core issues 

I didn't know what to expect when I went looking for the most visited Drupal core issue, but as soon as I found #216, it made perfect sense. I feel like you are in the minority of users if your Drupal core 8.8 update went smoothly.

Most visited Drupal core release pages 

I'm at a loss to explain why these core release pages were visited more than any others. Overall, there were 6 Drupal core release pages in the top 200 most visited pages.

Most visited pages overall

After the home page, the top visited pages were the project search, the download page, Drupal core, user Dashboards, the theme search, the User Guide, and Try Drupal.

None of these are all that surprising or interesting, at least to me, but included here for completeness. 

Finally, I was curious as to how many of the top 100 most visited pages were documentation pages (12) and contributed project pages (46).

Conclusions

A few things that I took away from this exercise:

  • Traffic to Drupal.org increased during 2020.
  • Composer continues to be a pain point in the community.
  • The contributed module ecosystem continues to be one of the crown-jewels of the Drupal community.
  • Pathauto should be in core (try to convince me otherwise)
  • Should the community consider tweaking metadata for pages related to older versions of Drupal core so they don't rank as high in search engines?
  • There seems to be an opportunity for new contributors to be provided with a list of the most visited forum, reference, and issue pages and convert those that make sense into documentation pages.
  • Why aren't a commensurate percentage of people from places with high numbers of users community leaders, and what can we do collectively to remedy it?

Thanks to Tim Lenhen from the Drupal Association for providing me with temporary access to the Drupal.org analytics.
 

MD Systems blog: Global Contribution Weekend 2021

Wed, 02/03/2021 - 08:32
It’s this time of the year again! Late January is the Global Contribution Weekend in the Drupal community.

Promet Source: 8 Reasons: Drupal Proves Top Pick for Government Sites

Wed, 02/03/2021 - 02:20
More so than ever before, government and public sector websites are called upon to multi-task,  functioning as the digital town square -- a central spot for connecting, conducting business, keeping informed, showcasing top attractions, and a lot more. 

DrupalCon News: Last chance for Early Bird DrupalCon Registration!

Tue, 02/02/2021 - 19:01

Don’t miss your last chance to register for DrupalCon at the early bird rate.

Specbee: Boost Up your Drupal 9 SEO game - Implementing the RobotsTxt module in Drupal 9

Tue, 02/02/2021 - 09:50
Boost Up your Drupal 9 SEO game - Implementing the RobotsTxt module in Drupal 9 Ankitha 02 Feb, 2021 Top 10 best practices for designing a perfect UX for your mobile app

The Robots.txt file is a very underrated on-page SEO factor. Not everybody realizes the value it brings to the table. The Robots.txt file is like an access control system that tells the crawler bots which pages need to be crawled and which ones don’t. It is a rule book for your website which is read by the various web spiders before it attempts a crawl on your website.

There are tons of amazing Drupal SEO modules in version 9 and 8 that help make our jobs easier and boosts SEO ranking. And one of them is the RobotTxt module. The RobotsTxt module in Drupal 9 (and 8) is a handy feature that enables easy control of the Robots.Txt file in a multisite Drupal environment. You can dynamically create and edit the Robots.txt files for each site via the UI. Let’s learn more about this utility module and how to implement it in Drupal 9.

But how does Robots.Txt help with SEO?

So, Robots.Txt files restrict crawlers from crawling some pages. But why wouldn’t you want all your pages/files to be crawled, right? Why do you need to have any restrictions whatsoever? Well, in this case, the more isn’t always merrier.

  • Without a Robots.txt file, you are allowing web spiders to crawl all your webpages, sections and files. This uses up your Crawl Budget (Yes, that’s a thing) – which can affect your SEO.
  • A crawl budget is the number of your pages crawled by web spiders (Google bot, Yahoo, Bing, etc.) in a given timeframe. Too many pages to crawl could decrease your chances of being indexed faster. Not only that, you might also lose out on indexing the important pages!
  • Not all your pages need to be crawled. For example, I’m sure you wouldn’t want Google to crawl your development / staging environment web pages or your internal login pages.
  • You might want to restrict media files (images, videos or other documents) from being crawled upon.
  • If you have a reasonable number of duplicate content pages, it is a better idea to add them to the Robots.Txt file instead of using canonical links on each of those pages.
How to Install and Implement the RobotsTxt Module in Drupal 9

The RobotsTxt Drupal 9 module is great when you want to dynamically generate a Robot.Txt file for each of your website when you are running many sites from one codebase (multisite environment). 

Step 1: Install the RobotsTxt Module for Drupal 9

Using composer: 

composer require 'drupal/robotstxt:^1.4' Step 2: Enable the module

Go to Home > Administration > Extend (/admin/modules) and enable RobotsTxt module.

  Step 3: Remove the existing Robots.txt file

Once the module is installed, make sure to delete (or rename) the robots.txt file in the root of your Drupal installation for this module to display its own robots.txt file(s). Otherwise, the module cannot intercept requests for the /robots.txt path.

Step 4: Configure

Navigate to Home -> Administration -> Configuration -> Search and metadata -> RobotsTxt (/admin/config/search/robotstxt), where you can add in your changes to “Contents of robots.txt” region. Save the configuration.

Step 5: Verify

To verify your changes please visit https://yoursitename.com/robots.txt

RobotTxt API

If you want to implement a shared list of directives across your multisite environment, you can implement the RobotsTxt API. The module has a single hook called  hook_robotstxt(). The hook allows you to define extra directives via code. 

The example below will add a Disallow for /foo and /bar to the bottom of the robots.txt file without having to add them manually to the “Contents of robots.txt” region in the UI.

/** * Add additional lines to the site's robots.txt file. * * @return array *   An array of strings to add to the robots.txt. */ function hook_robotstxt() {   return [    'Disallow: /foo',    'Disallow: /bar',  ]; }

The RobotsTxt module in Drupal is just one out of tons of effective Drupal SEO modules that can help you up your SEO game. Implementing the Robots.Txt file is of course not mandatory but it is definitely a great tool to have if you want to improve your website’s visibility. Looking for expert Drupal SEO services to help you with your next project? Or just need more information on this module? We’d love to talk to you!

Drupal Drupal Planet Drupal 9 Drupal 8 Drupal Tutorial Drupal Development Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image Boost Up your Drupal 9 SEO game - Implementing the RobotsTxt module in Drupal 9 Image Top 7 Remarkable Education Websites Built on Drupal (and Why was it Chosen) Image Drupal 9.1 and its compatibility with PHP 8 – Learn what’s new and how to check compatibility Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

A Drupal powered multi-site, multi-lingual platform to enable a unified user experience at SEMI.

link

Discover how our technology enabled UX Magazine to cater to their massive audience and launch outreach programs.

link

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

link

DrupalCon News: Register for DrupalCon while you can still get the early bird discount!

Mon, 02/01/2021 - 18:02

Buy your ticket before 11:59 p.m. ET (UTC -5) on February 3 to get the early bird rate and save $50 on admission.

DrupalEasy: 10 things to avoid when writing a Drupal job posting

Mon, 02/01/2021 - 10:00

As part of the 10 year anniversary of Drupal Career Online, we're continuing a blogpost theme as we start off the year posts that involve lists of 10. 

As an organization that trains aspiring Drupal developers, evaluates individuals' Drupal skills, and provides skill assessments to potential employers, we’ve developed what we feel is some key insight into what makes a good Drupal job posting.

Over the past few years, as I've reviewed job postings for Drupal jobs on jobs.drupal.org and other job-related web sites, there are (more than) a few things that always make me cringe…

  1. Jobs advertised as junior and intermediate and advanced skill level. Which is it? All of the above? Job postings like this especially scare away junior developers (for fear they will be in over their head) and advanced developers (for fear they will not be challenged). If you're writing a job posting, be specific. If you're hiring for multiple skill levels, then post multiple listings.
  2. Not clearly stating the "minimum skills required". This is always really perplexing, especially when reviewing expert-level job postings. The list of requirements for a single job is often virtually unattainable by most applicants. I've been developing Drupal sites for more than 14 years and I often see advanced-level job postings that I'm not qualified for. If you're looking for someone with years of experience in Drupal, WordPress, Laravel, Symfony, Magneto, administering servers, Behat, site performance, SEO, React, Angular, then prepare to either be disappointed or pay top-dollar (if you can even find someone who meets your criteria). I recommend splitting up your requirements into a few groups: "absolute minimum", "willing-to-pay-a-bit-more-for", and "bonus".  If you're not willing to hire someone who only has the absolute minimum, then maybe you need to rethink the posting.
  3. Not clearly stating if the position is customer-facing or not. Some developers do not want to interface directly with customers. In some cases, interfacing with customers directly isn't in someone's skill set. By making it clear whether or not the developer will need to interface with a client (online via a ticketing system, for example) you can help avoid unwanted situations. 
  4. Junior-level positions that do not mention on-the-job training and/or mentorship. Here's a secret, junior level developers don't want to be junior level - they are usually hungry to learn and advance. If you want to hire a junior level developer, then your organization must be willing to invest in them to help advance them. 
  5. Not specifying if the position includes design as well as development. In this case, "design" may or may not include visual design as well as software design. There are some developers that absolutely love the design aspect of building sites (information architecture, class hierarchy of custom modules, etc…) and some who do not. Be specific in what is required.
  6. Junior-level positions that include front-end, back-end, site-building, project management, multiple Javascript frameworks, etc.. (you get the idea). There's a reason that junior-level developers exist - because they don't have all the skills and experience yet. Job descriptions like this do one thing very well - scare off talented junior-developers that don't want to be put in a no-win situation. 
  7. Advanced skill level positions that don't pay market rate. If you're looking for an expert developer then you need to be willing to pay for it. Drupal is (and has been for a long time) a seller's market - if you manage to find someone willing to fill an expert position at a far-below-market-value rate, you're going to be disappointed one way or another.
  8. Junior-level positions that require more than 1 year of experience. If you're looking for a junior developer with more than a year of experience, then you're not actually looking for a junior developer. More than likely, you're looking for at least an intermediate developer.
  9. Not providing benefits other than salary. As mentioned above, Drupal is a seller's market. Want to attract top Drupal talent, regardless of skill level - then beef up your offering to make it stand out. Most developers enjoy professional development - provide them with a budget and time to learn new skills that will benefit your organization - and don't double-book them with work while they are learning new skills. Another HUGE benefit to offer is to allow developers to spend company time making contributions back to the Drupal community. This is a form of professional development as well often a very healthy thing for remote workers to participate in. Finally, send your developers to Drupal events - nothing will accelerate your developers' skills than interacting with other developers. 
  10. Labelling a position as junior-level because it doesn't pay very well. Don't. Please just don't. 

Do you have a junior Drupal developer that you move into a more intermediate developer role? Then consider sending them to Drupal Career Online - it's only 2-3 times/week for 12 weeks, and you can be confident that they'll be learning best practices around Drupal development. 
 

Golems GABB: A tour of the Drupal Rules module for automating website actions

Mon, 02/01/2021 - 09:54
A tour of the Drupal Rules module for automating website actions Editor Mon, 02/01/2021 - 10:54

Imagine a smart website that automatically performs the right actions in response to particular events. Even complex scenarios are easily achievable. The cherry on top of the cake is that all this is possible without long lines of code — all you need is your Drupal admin dashboard. Interested? Welcome to get acquainted with the Drupal Rules module! See how one of the most popular modules in the Drupal development history can help you with website workflow automation.

The main principles of the Drupal Rules module’s work

The Drupal Rules module provides an interface for creating automated workflows on your website. You “teach” your site to perform streamlined and repeatable actions based on what is happening.

heykarthikwithu: Send Mail with Custom Email Template & with Dynamic values via Drupal Mail Service

Mon, 02/01/2021 - 04:09
Send Mail with Custom Email Template & with Dynamic values via Drupal Mail Service

Sending an email works with defining an email template (subject, text and possibly email headers) and the replacement values to use in the appropriate places in the template. Processed email templates are requested from hook_mail() from the module sending the email. Any module can modify the composed email message array using hook_mail_alter(). Finally \Drupal::service('plugin.manager.mail')->mail() sends the email, which can be reused if the exact same composed email is to be sent to multiple recipients.

karthikkumardk Monday, 01 February 2021 - 08:39:35 IST

The floating-point divide: How to generate an image derivative for an image style by visiting a URL

Mon, 02/01/2021 - 02:19
How to generate an image derivative for an image style by visiting a URL Posted by jstrecker on 2021.01.31 @ 20:19 Filed Under: Drupal Drupal 8.x Drupal 9.x Planet Drupal Software Development PHP

Recently I was adding a photo gallery page to a Drupal 9 site. When a photo was clicked/tapped, the link was supposed to take you to a larger version of the image. Instead, to my surprise, it gave a “page not found” error.

James Oakley: Checking for modifications to default.settings.php

Sat, 01/30/2021 - 17:45

Drupal sites contain a settings.php file with site-specific settings, that is based off default.settings.php at the time the site is installed. As Drupal evolves, default.settings.php will change. Sometimes, it's worth incorporating those changes into the settings.php file for an already-installed site. This post runs through a low-friction way to keep on top of this house-keeping.

Blog Category: Drupal Planet

#! code: Drupal 9: Preventing Enumeration Attacks

Fri, 01/29/2021 - 21:38

A recent Wired article about the Parler data hack talked about how a hacker group was able to steal publicly available information from the Parler website using an Insecure Direct Object Reference (IDOR) or enumeration attack. This type of attack involves a hacker looking at the structure of the site and attempting to guess the next available resource by looking at the URL. Apparently, terabytes of Parler's data was downloaded by simply enumerating through the ID's of their publicly available posts.

Taking an arbitrary example in Drupal, let's say that you had a content type called post that was loaded using the type and ID of the content in the URL. This means that when a user visits the post they might see a URL with the path /post/1. If a user wanted to see the next available post on the site then they could just increase the ID by one and see if the next post loads or not. It becomes almost trivial to build a script to download every post on the site by just looking through the ID of the posts. This is almost what happened in the Parler attack, although that attack was done through their API service rather than through their website, but the principle is the same.

You might not think this is much of a problem, but you can actually leak a lot of information from a site like this without even realising it. Especially problematic is user profiles where improperly controlled user profile pages can mean that a site can leak all of their user data without hackers needing to break into the system. It doesn't have to be user profiles though, many users will post identifiable information in public posts and so any system that allows all of these posts to be enumerated will leak quite a lot of information that can be easily linked back to users.