If you need a simple Views display switch to toggle e.g between a list and a grid display of a view, there are a couple of plug & play options already.

Display Suite and Quick Tabs are modules which provide this functionality but they seem to be quite an overkill for a simple display switch. View modes on the other hand seems to be exactly what is needed, however there is no stable version and the development one did not work for me.

How it needs to work

Our use case dictates that while switching a display, the view needs to retain the exposed filter values and page number. The page will be reloaded, no AJAX magic here.

So let's create our own views display switch. In order to do that you will obviously be needing a view with at least two page displays showing content in different ways. You will also have to put some code into your custom module. If in doubt, refer to the countless other tutorials.

Set up your view

In the view named [view] set the path of [display_1] to e.g [page/grid], the path to [display_2] to e.g [page/list].

Create callback function

Create a simple callback function which will provide the switch in ready-to-be-displayed HTML.

Please note the date of the article - it may not be current nor does it necessarily reflect the author's current opinion on the matter. See this comment.

The ability to fork is a wonderful thing.

In the open source community, the ability to fork software projects is a wonderful thing, as it allows taking a software snapshot in a completely different direction from what was intended by its current maintainers.

Projects get forked for reasons that can be categorized in political (changing ownership rights, controversial decisions made by the project maintainers, etc.), technology related (where maintainers disagree about the direction of development and implementation) and personal.

Forking is a bad thing.

Wait... did you not just say forking was wonderful?
The ability to fork is wonderful, as it gives great power to the community. But forking itself is bad for the project, as it results in two projects with weaker development and support, a weakened potential to grow and a divided and confused user base. It leads not only to separate code bases, but also to a divided developer and user community and should be considered last resort.
In the best case scenario, forking is choosing the lesser evil.

No matter how much effort is put into collaboration between the fork and the original project, in the end it always ends in lack of compatibility and refusal to provide support to confused users in the different camp. This is why the Backdrop creators' reassuring statements about cross contribution should be taken with a grain of salt.

Why check if term is associated to a node prior to deletion?

In cases where taxonomy terms are used only for categorizing content on a Drupal powered web page, there should be no harm in deleting them. However sometimes taxonomy is used to store terms critical to the content they are referenced from and in this case steps should be taken to prevent an accidental deletion.

I have encountered such a case on a project I am working on which is soon to become a web platform for university students. When creating a faculty node, its name is being defined by choosing a term from the 'faculties' vocabulary. Deleting a term assigned to such a faculty node would lead to... well undesired effects.

Approach

When looking for the right hook you will find that there is no hook_taxonomy_pre_delete and using the existing hook_taxonomy_term_delete would be too late (the term would be deleted by then). (By the way, this problem persists across other entity types, like nodes - hoping to see some added hooks in D8.)

I will describe an easy way of preventing the deletion of a used taxonomy term, but be warned, this will only prevent the deletion of a term in the UI, it will not react to programmatically deleted terms.

Here is how this is going to look like:

Some code:

Once is a Drupal library - available on npm - that ensures your JavaScript only runs once when working on any item.

Host Matt Kleve assembles a crack team of Lullabot experts from various company departments to share their hands-on experiences and insights into how innovative technology influences and enhances our field.

We discuss integrating AI into coding, design, and tasks like writing emails and RFP responses, along with the broader implications for the future of web development.

Join us as we navigate the complexities, challenges, and vast potential of Generative AI in shaping our world.

It's been three years since DrupalCon Amsterdam, the last time we were able to bring our American and European teams together at a DrupalCon. In remote work years, that's practically an eternity, so we're stoked to be back together again during DrupalCon Prague. 🤘🏼

This time around we decided to "focus on us" after a busy summer of client project launches coordinated around vacation schedules. Instead of staffing a booth, we'll be hosting a weeklong Drupal Commerce maintenance sprint focused on various Commerce Core, Commerce Kickstart, and Centarro certified project issues.

Feel free to reach out if you'd like to join us physically or remotely. If you have a patch ready for review already in one of the related queues, tag it with KickstartPrague2022 and we'll do our best to take a look!

We've packaged three releases of Commerce Core this year, from the 2.29 release in February to this month's 2.31 release. While DrupalCon, Kickstart development, and client launches have kept us busy, we wanted to take the opportunity to share the good news while we take a breather before DrupalCon Prague.

Each release includes general maintenance and modernization work, improving PHP 8.1 and Drupal 10 support while keeping up with tax rate changes around the world. They also include a variety of minor bug fixes and enhancements, like database indexes to improve performance or new permissions to support finer grained store management. Altogether, we've seen 87 issues resolved by dozens of contributors.

In this blog post, we'll review the more significant new features, including for BOGO promotions, product display pages, and order management.

"Buy One Get One" promotions

Commerce Core 2.x has always included BOGO promotion support, including the ability to adjust the quantities (which is why we call it "Buy X, Get Y" in the UI) and fine tune other rules around applicability. Thanks to a variety of merchants pushing the limits of what core can do, we found fixed a few bugs and found ways to improve the feature. In particular, we've ensured that: