The Drupal 7 translation system including the internationalization package is a heavy beast and while it mostly gets the job done, it is all but intuitive in use.

For high volume translations it is recommended to use the translation template extractor and translate the strings externally. For small corrections however, it is often much more convenient to use the translation interface (admin/config/regional/translate/translate).

Now that you've created that shiny module/template and made it translatable by passing all strings through the t() function, you may be wondering why your newly created string is not showing up in the translate interface.

To save you some trouble, here is a short list of things to check:

1. Include the project version number within the module/theme .info file.
Without the project version information, the translate interface will not register new translatable strings in your module/theme. Make sure to add version = 7.x-1.0 into the module/template .info file.

2. Run the string through the function in a non-standard language mode.
In order for the translation system to add your translatable string, the t() function must run at least once in a non-standard language. To achieve that, you will need to switch the language of the site to one you are going to translate into and then visit the page that displays the string.

3. Mind the case sensitive search filter.
Be accurate when using the translate interface filter - it does not forgive.

The Honeypot module is a great captcha alternative, as it keeps spam bots from submitting content while also saving your site visitors from having to type in mundane character combinations.
Configured properly it will prevent the majority of bots from submitting forms on your site including registration forms, contact forms, comment forms, content forms... any drupal forms.
It works differently from Captcha: it lures the bot into filling out a form field invisible to regular users. By doing so, the system recognizes the bot for what it is and denies the submission.

While being very user friendly, this reversed bot detection system comes at the cost of some bot submissions getting through anyway. This is why I would advise against using this module on large sites, where it is difficult to track every piece of submitted content. It should work well for smaller and medium sites however, it has been working well in many of my projects including this very site.

Honeypot configuration

Correct configuration of the module is extremely important, as wrong settings might make the module inefficient or worse, prevent real users from submitting forms. After configuring the module, make sure to double check it works by submitting a protected form as an anonymous user.

Once installed and enabled, go to admin/config/content/honeypot to configure the module.

First of all careful with the "protect all forms" option, as caching will be disabled on every page that includes a form. This can be problematic in cases where e.g. a login block is embedded in the sidebar. In addition to ticking what forms to protect, there are two important settings to keep in mind.

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!