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.

Creating a duplicate of an entity

Creating a duplicate of an entity is easily done via the entity API method Entity::createDuplicate(). This is a convenient method if the goal is to clone an entity into a new entity, as all identifiers of the previous entity get unset when using this method.

Apparently there are still pretty common Drupal 8 theming tasks that cannot be accomplished with the great twig_tweak module. This by the way was me giving a plug to a great little module, which makes half of all your theme preprocess hooks unnecessary.

Update: Apparently there is a module like twig_tweak but with the ability to do the above. It is called bamboo_twig and its documentation can be found here - thanks to Luckhardt Labs for mentioning it. Mind you I have not tested it yet. There is a rather interesting issue in its queue about the lack of collaboration between the two module maintainers.

If you would like to get the URL from an image that is trapped inside of a media entity however, you can either extract it using the aforementioned preprocess function like so:

This is a technical description of the 3.x branch of the module. For the newer 4.x branch, see this article.

Simple XML sitemap 3.0 has been released

The third major version of simple_sitemap has been seven months in the making. The module has been rewritten from the ground up and now features a more reliable generation process, a significantly more versatile API and many new functionalities.

Major new features

Ability to create any type of sitemap via plugins

The 8.x-3.x release allows not only to customize the URL generation through URL generator plugins as 2.x did, but also creating custom sitemap types that mix and match a sitemap generator along with several URL generators to create any type of sitemap.

This 3-plugin system coupled with the new concept of sitemap variants makes it possible to run several types of sitemaps on a single Drupal instance. Now e.g a Google news sitemap can coexist with your hreflang sitemap.

A sitemap variant can but does not need to be coupled to entity types/bundles. When creating a sitemap generator, one can define where the content source is located and what to do with it upon sitemap generation/deletion.

Ability to create sitemap variants of various sitemap types via the UI

In 3.x links form a specific entity bundle can be indexed in a specific sitemap variant with its own URL. This means, that apart from /sitemap.xml, there can be e.g

This is a technical description of the 3.x branch of the module. For the newer 4.x branch, see this article.

Simple XML sitemap 3.1 has been released

The third major version of simple_sitemap has been long in the making bringing a more reliable generation process, a significantly more versatile API and many new functionalities. The first minor ugrade of the 3.x branch comes with views support and human readable sitemaps.

Major new features in 3.1

Views and views arguments support

Including view display URLs in the sitemap has been possible through adding these URLs as custom links in the UI (or via the API).

View variations created by view arguments however are tedious to include as one would have to include every version of the URL.

The integration of the simple_sitemap_views inside simple_sitemap 3.x makes it easily doable via the UI.

Thanks to @WalkingDexter for his tremendous work on this submodule!

Human-readable sitemaps with XSL stylesheets

Before:

Occasionally I find myself needing plugin-like functionality, where users/downstream can throw a class into a folder and expect it to work. My script is supposed to find and instantiate these plugins during runtime without keeping track of their existence.

In a regular Drupal module, one would usually use the plugin architecture, but that comes with its overhead of boilerplate code and may not be the solution for the simplest of use cases.

Many class finder libraries rely on get_declared_classes() which may not be helpful, as the classes in question may not have been declared yet.

If you are on a Drupal 8/9 installation and want to use components already available to you, the Symfony (file) Finder can be an alternative for finding classes in a given namespace.

Installing dependencies

Ouside of Drupal 8/9, you may need to require this library in your application:

Bing 410 Gone

Microsoft recently killed their search engine's public API responsible for accepting sitemap ping requests (those where you let search engines know your XML sitemap's content has changed). They did so completely unannounced leading to logs filling up and users unsurprisingly assuming their sitemap submitting code was somehow at fault. It wasn't.

It became apparent that this was a step for Microsoft towards switching to the IndexNow protocol instead.

IndexNow supplements XML sitemaps

With IndexNow you now can quickly notify all participating search engines (Bing, Yandex) about a change that happened on your page eliminating the need to wait for them to come and scan your sitemap. The benefits of this approach are

• Instant submission of changes including creating, deleting and updating of content
• An alleged greener approach to indexing content as sitemap scanning requests get deprioritized
• Only one search engine needs to be notified and it will notify the others for you

Still, this new approach is more of a supplement than a revolution:

Can I submit all URLs for my site?

Use IndexNow to submit only URLs having changed (added, updated, or deleted) recently, including all URLs if all URLs have been changed recently. Use sitemaps to inform search engines about all your URLs. Search engines will visit sitemaps every few days.

After six months of work I'm delighted to tag the first stable release of the 4.x branch of the (Not-so-) Simple XML Sitemap module.

The project is in a really good place right now. At the moment of writing, drupal.org reports it being actively used on around 90k of Drupal 8/9 websites while having 0 open bug reports. This either means you people are lousy bug reporters, or we are doing a descent job at responding. :)

Module rewrite with developers/integrators in mind

4.x makes much greater use of Drupal's entity API dropping some of its very specific chaining API. Feel free to take a look at the roadmap ticket for specifics.

New UI

We now have a much nicer UI for creating, editing and sorting sitemaps as well as sitemap types.

API usage

In a nutshell, sitemap variants are now sitemap entities. These are of a sitemap type (sitemap type entity) that is defined by URL generator plugins as well as sitemap generator plugins.

When migrating content with the Drupal 8 migrate module, the creation and updating of new entities may fire lots of custom module hooks. This may or may not be desired; if you have found yourself here, it probably interferes with the source data in a problematic way, or unnecessarily slows down the migration process.

The cleanest way I found to stop specific hooks for specific migrations, is to add a dummy/meta field to the migration and check for its value in the hook.

Include a dummy field in the migration

In the process section of the migration, add a field with a name that will not interfere with any field name of the target entity:

abgeordnetenwatch.de is not your generic community platform - it's a tool that actively creates and enforces communication channels between the people and their political representatives thereby strengthening the democratic process while also being a comprehensive source of information of the political system in Germany.

Because of that and because of the project's high functionality and high efficiency requirements, it is one gbyte is particularly proud to be involved in.

The project has recently won the Drupal Splash Awards 2020 for Germany & Austria in the non-profit category. It is a huge compliment to the small team of developers and to Parlamentwatch e. V. (the organization behind the service), as the Splash awards are regarded as the most prestigious award within the Drupal community.

Award ceremony: Youtube video (with timestamp)

Splash awards entry: Entry description

Drop us a line if you are interested in what makes this awesome project tick.