Feeds

CKEditor is a powerful and versatile web-based text editor commonly used in content management systems like Drupal. It empowers content creators and editors with a user-friendly interface for crafting and formatting text, incorporating multimedia elements, and managing a wide range of content types.

Last month, in October 2023, I started a new job as a Senior Site Reliability Engineer at the Germany-headquartered technology company Spryker. They are primarily focused on e-commerce and infrastructure businesses.

I joined this company with excitement and curiosity, as I would be working with a new technology stack: AWS and Terraform. I had not been directly exposed to them in the past, but I was aware of the vast industry impact of both.

Suddenly, things like PXE boot, NIC firmware, and Linux kernel upgrades are mostly AWS problems.

This is a full-time, 100% remote job position. I’m writing this post one month into the new position, and all I can say is that the onboarding was smooth, and I found some good people in my team.

Prior to joining Spryker, I was a Senior SRE at the Wikimedia Cloud Services team at the Wikimedia Foundation. I had been there since 2017, for 6 years. It was a privilege working there.

Dear Readers,

Have you ever found yourself standing on the hallowed grounds of a game field, surrounded by the dispersing crowd after the exhilarating clash of Titans? You close your eyes and immerse your soul into a space, in all its nooks and corners, you so wished to be present. It's a unique form of astral projection, fueled not by science but by the sheer force of desire.

You stand there, taking in all the heat and vigor that field contained minutes before. You feel the lingering warmth of the competition, the echoes of cheers and roars that once filled the air. The field was a sacred space where legends once broke sweats, champions basked in glory, and hearts shattered in defeat. I can't fathom which will be louder, the cheers of the win or the agony of the loss. I suppose it will be what your heart resonates with most.

Nevertheless, your favorite heroes might be grappling with the sting of loss, but amidst the pain, there's an undeniable awe for the magnificent game played by others. You might catch snippets of satisfaction, determination, and even complaints in the fading murmurs. After all, it's a game; one wins while the other loses, and still, it is only a game, and more games will come!

In this field of desire, the cycle continues. Your heroes are already picking themselves up, now bearing the weight of criticism and shame. They brush off their shoulders, drowning out the din of naysayers. It's a journey!

Similarly, there are instances where Drupal may face setbacks, encountering the echoes of coding challenges and the occasional murmurs of discontent. It's a dynamic game where advancements and setbacks coexist. Yet, like the heroes on the physical field, the Drupal community persists. After moments of criticism and setbacks, Drupal picked itself up, learning from the experiences and evolving to conquer new coding horizons powered by desire.

On that note, let's look into the top stories by The DropTimes from the past week.

With a bang, Drupal debuted at the Web Summit Lisbon, one of the largest and most influential technology conferences worldwide! The keynote address was delivered by Baddy Sonja Breidert, the former chair of the Drupal Association. Dries Buytaert expressed gratitude for the substantial support from key sponsors, including 1xINTERNET, Acquia, FFW, and Phase 2. Alex Moreno posits the recent foray into Web Summit in Lisbon served as a concrete stride toward escaping the confines of the Drupal bubble. The NEDCamp 2023 also came to a glorious conclusion!

In the wake of the end of the life of Drupal 9, the Drupal community is buzzing with calls for migration. The blog post by Symetris highlights the need to upgrade to Drupal 10, which offers improved content management, enhanced security, performance optimizations, personalization features, and a new front-end theme, among other benefits. Also, Acquia has strategically moved to retire the Drupal 9 Certification exams, scheduled for November 30, 2023. With a substantial 47.5% of websites remaining in Drupal 7, Promet Source stresses the growing disparity between the capabilities of Drupal 7 and the advancements incorporated into Drupal 10, positioning the latter as a superior, performance-optimized, and feature-rich web platform.

The hums of DrupalCon Lille still haven't settled with Drupalists discussing sustainability and inclusivity lessons from the Conference. Specbee's latest blog post, penned by Siddhant, explores the transformative power of Google Analytics 4 (GA4) and its impact on Drupal marketing strategies. Meanwhile, DrupalCon Portland 2024 has initiated the Call for sponsors. Acquia has unveiled the winners of the 2023 Engage Awards, recognizing organizations that excel in delivering innovative digital experiences by uniting marketers and technologists.

Remarkably, PreviousNext recently wrapped up a crucial phase in developing a decoupled Layout Builder for Drupal, led by Lee Rowlands, as part of the Pitchburg Project. Notably, the project's success extends beyond the conclusion of its statement of work, as it serves as a foundation for continued advancements within the Drupal community. Acquia has announced its acquisition of Monsido, a platform specializing in website accessibility, content quality, search engine optimization, data privacy, and performance.

The Commerce CyberSource module for Drupal has successfully tackled third-party library conflicts, unveiling its Drupal 10 version with improved payment processing capabilities. Drupal users seeking optimal page caching now have a robust solution with the LiteSpeed Cache module tailored for Drupal 8 and beyond. The article by Kevin Quillen from Velir discusses the key module, which offers multiple methods for referencing and safeguarding secrets in the Drupal content management system.

DrupalEasy is set to commence its spring semester of Professional Module Development on January 30, 2024. The 12-week course is led by industry veteran Mike Anello. Similarly, Emble provides personalized Drupal training courses at three proficiency tiers: Drupal Web Editor, Drupal Application Manager, and Drupal Developer. The classes are designed to cater to individual needs and organizational requirements, ensuring effective and swift knowledge transfer.

Oliver Davies launches the inaugural episode of the Beyond Blocks podcast featuring Matt Glaman. Authored by the experienced Mike Hubbard, Acro Commerce shared insights on configuring Drupal and React/TypeScript components. Lucio Waßill has introduced the "Monitoring Ntfy.sh Integration" module. This innovative addition to the Drupal ecosystem promises to enhance monitoring capabilities by providing real-time notifications through the Ntfy.sh platform. Gatsby.js, the open-source framework powered by React, GraphQL, and Node.js, excels in crafting high-performing, content-rich sites and is the prime discussion in the latest article by the AIVAnet team.

This encapsulates the highlights from The Drop Times. We invite you to share any suggestions, contributions, or feedback, as we sincerely value your engagement within our community. Thank you for being part of this journey. Until our next edition, keep exploring, sharing, and embracing the power of knowledge!

Follow us on LinkedIn, Twitter, and Facebook for regular updates.

Warm Regards,

Alka Elizabeth
Sub-editor, TheDropTimes

Review: The Exiled Fleet, by J.S. Dewes

Series: Divide #2 Publisher: Tor Copyright: 2021 ISBN: 1-250-23635-5 Format: Kindle Pages: 421

The Exiled Fleet is far-future interstellar military SF. It is a direct sequel to The Last Watch. You don't want to start here.

The Last Watch took a while to get going, but it ended with some fascinating world-building and a suitably enormous threat. I was hoping Dewes would carry that momentum into the second book. I was disappointed; instead, The Exiled Fleet starts with interpersonal angst and wallowing and takes an annoyingly long time to build up narrative tension again.

The world-building of the first book looked outward, towards aliens and strange technology and stranger physics, while setting up contributing problems on the home front. The Exiled Fleet pivots inwards, both in terms of world-building and in terms of character introspection. Neither of those worked as well for me.

There's nothing wrong with the revelations here about human power structures and the politics that the Sentinels have been missing at the edge of space, but it also felt like a classic human autocracy without much new to offer in either wee thinky bits or plot structure. We knew most of shape from the start of the first book: Cavalon's grandfather is evil, human society is run as an oligarchy, and everything is trending authoritarian. Once the action started, I was entertained but not gripped the way that I was when reading The Last Watch. Dewes makes a brief attempt to tap into the morally complex question of the military serving as a brake on tyranny, but then does very little with it. Instead, everything is excessively personal, turning the political into less of a confrontation of ideologies or ethics and more a story of family abuse and rebellion.

There is even more psychodrama in this book than there was in the previous book. I found it exhausting. Rake is barely functional after the events of the previous book and pushing herself way too hard at the start of this one. Cavalon regresses considerably and starts falling apart again. There's a lot of moping, a lot of angst, and a lot of characters berating themselves and occasionally each other. It was annoying enough that I took a couple of weeks break from this book in the middle before I could work up the enthusiasm to finish it.

Some of this is personal preference. My favorite type of story is competence porn: details about something esoteric and satisfyingly complex, a challenge to overcome, and a main character who deploys their expertise to overcome that challenge in a way that shows they generally have their shit together. I can enjoy other types of stories, but that's the story I'll keep reaching for.

Other people prefer stories about fuck-ups and walking disasters, people who barely pull together enough to survive the plot (or sometimes not even that). There's nothing wrong with that, and neither approach is right or wrong, but my tolerance for that story is usually lot lower. I think Dewes is heading towards the type of story in which dysfunctional characters compensate for each other's flaws in order to keep each other going, and intellectually I can see the appeal. But it's not my thing, and when the main characters are falling apart and the supporting characters project considerably more competence, I wish the story had different protagonists.

It didn't help that this is in theory military SF, but Dewes does not seem to want to deploy any of the support framework of the military to address any of her characters' problems. This book is a lot of Rake and Cavalon dragging each other through emotional turmoil while coming to terms with Cavalon's family. I liked their dynamic in the first book when it felt more like Rake showing leadership skills. Here, it turns into something closer to found family in ways that seemed wildly inconsistent with the military structure, and while I'm normally not one to defend hierarchical discipline, I felt like Rake threw out the only structure she had to handle the thousands of other people under her command and started winging it based on personal friendship. If this were a small commercial crew, sure, fine, but Rake has a personal command responsibility that she obsessively angsts about and yet keeps abandoning.

I realize this is probably another way to complain that I wanted competence porn and got barely-functional fuck-ups.

The best parts of this series are the strange technologies and the aliens, and they are again the best part of this book. There was a truly great moment involving Viator technology that I found utterly delightful, and there was an intriguing setup for future books that caught my attention. Unfortunately, there were also a lot of deus ex machina solutions to problems, both from convenient undisclosed character backstories and from alien tech. I felt like the characters had to work satisfyingly hard for their victories in the first book; here, I felt like Dewes kept having issues with her characters being at point A and her plot at point B and pulling some rabbit out of the hat to make the plot work. This unfortunately undermined the cool factor of the world-building by making its plot device aspects a bit too obvious.

This series also turns out not to be a duology (I have no idea why I thought it would be). By the end of The Exiled Fleet, none of the major political or world-building problems have been resolved. At best, the characters are in a more stable space to start being proactive. I'm cautiously optimistic that could mean the series would turn into the type of story I was hoping for, but I'm worried that Dewes is interested in writing a different type of character story than I am interested in reading. Hopefully there will be some clues in the synopsis of the (as yet unannounced) third book.

I thought The Last Watch had some first-novel problems but was worth reading. I am much more reluctant to recommend The Exiled Fleet, or the series as a whole given that it is incomplete. Unless you like dysfunctional characters, proceed with caution.

Rating: 5 out of 10

Sale: Until Nov. 27, you can get lifetime access to Python Morsels

Table of contents

1. How far Python Morsels has come
2. The sale: lifetime access

How far Python Morsels has come

My initial idea was simple — sending one real-world Python exercise every week via email. I had been teaching Python to teams and I wanted to see if I could bring learning techniques that I know work to a much larger audience.

Fast forward to today, and Python Morsels has grown into a sophisticated web app with a treasure trove of hands-on learning materials and a level-based recommendation system. It's been quite a journey, and I'm immensely proud of what we've built.

The heart of Python Morsels has always been you: the Python learners and enthusiasts who've joined me on this journey. Your feedback and support have been the driving force behind this platform's evolution. Your success stories are my biggest source of motivation and I'm grateful to be a part of your learning journey.

Eric Pederson

The time I spent working on Python Morsels problems translates into saved time programming for work. And it's not a grind - it's actually fun. I've learned advanced Python concepts that I would have never had the opportunity to use in my day to day work.

The sale: lifetime access

Now, I'm excited to announce …

Read the full article: https://www.pythonmorsels.com/python-morsels-lifetime-access-sale/

I do not think seasons Debian contributors quite appreciate how much knowledge we have picked up and internalized. As an example, when I need to look up documentation for debhelper, I generally know which manpage to look in. I suspect most long time contributors would be able to a similar thing (maybe down 2-3 manpages). But new contributors does not have the luxury of years of experience. This problem is by no means unique to debhelper.

One thing that debhelper does very well, is that it is hard for users to tell where a addon "starts" and debhelper "ends". It is clear you use addons, but the transition in and out of third party provided tools is generally smooth. This is a sign that things "just work(tm)".

Except when it comes to documentation. Here, debhelper's static documentation does not include documentation for third party tooling. If you think from a debhelper maintainer's perspective, this seems obvious. Embedding documentation for all the third-party code would be very hard work, a layer-violation, etc.. But from a user perspective, we should not have to care "who" provides "what". As as user, I want to understand how this works and the more hoops I have to jump through to get that understanding, the more frustrated I will be with the toolstack.

With this, I came to the conclusion that the best way to help users and solve the problem of finding the documentation was to provide "online documentation". It should be possible to ask debputy, "What attributes can I use in install-man?" or "What does path-metadata do?". Additionally, the lookup should work the same no matter if debputy provided the feature or some third-party plugin did. In the future, perhaps also other types of documentation such as tutorials or how-to guides.

Below, I have some tentative results of my work so far. There are some improvements to be done. Notably, the commands for these documentation features are still treated a "plugin" subcommand features and should probably have its own top level "ask-me-anything" subcommand in the future.

Automatic discard rules

Since the introduction of install rules, debputy has included an automatic filter mechanism that prunes out unwanted content. In 0.1.9, these filters have been named "Automatic discard rules" and you can now ask debputy to list them.

$ debputy plugin list automatic-discard-rules +-----------------------+-------------+ | Name | Provided By | +-----------------------+-------------+ | python-cache-files | debputy | | la-files | debputy | | backup-files | debputy | | version-control-paths | debputy | | gnu-info-dir-file | debputy | | debian-dir | debputy | | doxygen-cruft-files | debputy | +-----------------------+-------------+

For these rules, the provider can both provide a description but also an example of their usage.

$ debputy plugin show automatic-discard-rules la-files Automatic Discard Rule: la-files ================================ Documentation: Discards any .la files beneath /usr/lib Example ------- /usr/lib/libfoo.la << Discarded (directly by the rule) /usr/lib/libfoo.so.1.0.0

The example is a live example. That is, the provider will provide debputy with a scenario and the expected outcome of that scenario. Here is the concrete code in debputy that registers this example:

api.automatic_discard_rule( "la-files", _debputy_prune_la_files, rule_reference_documentation="Discards any .la files beneath /usr/lib", examples=automatic_discard_rule_example( "usr/lib/libfoo.la", ("usr/lib/libfoo.so.1.0.0", False), ), )

When showing the example, debputy will validate the example matches what the plugin provider intended. Lets say I was to introduce a bug in the code, so that the discard rule no longer worked. Then debputy would start to show the following:

# Output if the code or example is broken $ debputy plugin show automatic-discard-rules la-files [...] Automatic Discard Rule: la-files ================================ Documentation: Discards any .la files beneath /usr/lib Example ------- /usr/lib/libfoo.la !! INCONSISTENT (code: keep, example: discard) /usr/lib/libfoo.so.1.0.0 debputy: warning: The example was inconsistent. Please file a bug against the plugin debputy

Obviously, it would be better if this validation could be added directly as a plugin test, so the CI pipeline would catch it. That is one my personal TODO list. :)

One final remark about automatic discard rules before moving on. In 0.1.9, debputy will also list any path automatically discarded by one of these rules in the build output to make sure that the automatic discard rule feature is more discoverable.

Plugable manifest rules like the install rule

In the manifest, there are several places where rules can be provided by plugins. To make life easier for users, debputy can now since 0.1.8 list all provided rules:

$ debputy plugin list plugable-manifest-rules +-------------------------------+------------------------------+-------------+ | Rule Name | Rule Type | Provided By | +-------------------------------+------------------------------+-------------+ | install | InstallRule | debputy | | install-docs | InstallRule | debputy | | install-examples | InstallRule | debputy | | install-doc | InstallRule | debputy | | install-example | InstallRule | debputy | | install-man | InstallRule | debputy | | discard | InstallRule | debputy | | move | TransformationRule | debputy | | remove | TransformationRule | debputy | | [...] | [...] | [...] | | remove | DpkgMaintscriptHelperCommand | debputy | | rename | DpkgMaintscriptHelperCommand | debputy | | cross-compiling | ManifestCondition | debputy | | can-execute-compiled-binaries | ManifestCondition | debputy | | run-build-time-tests | ManifestCondition | debputy | | [...] | [...] | [...] | +-------------------------------+------------------------------+-------------+

(Output trimmed a bit for space reasons)

And you can then ask debputy to describe any of these rules:

$ debputy plugin show plugable-manifest-rules install Generic install (`install`) =========================== The generic `install` rule can be used to install arbitrary paths into packages and is *similar* to how `dh_install` from debhelper works. It is a two "primary" uses. 1) The classic "install into directory" similar to the standard `dh_install` 2) The "install as" similar to `dh-exec`'s `foo => bar` feature. Attributes: - `source` (conditional): string `sources` (conditional): List of string A path match (`source`) or a list of path matches (`sources`) defining the source path(s) to be installed. [...] - `dest-dir` (optional): string A path defining the destination *directory*. [...] - `into` (optional): string or a list of string A path defining the destination *directory*. [...] - `as` (optional): string A path defining the path to install the source as. [...] - `when` (optional): manifest condition (string or mapping of string) A condition as defined in [Conditional rules](https://salsa.debian.org/debian/debputy/-/blob/main/MANIFEST-FORMAT.md#Conditional rules). This rule enforces the following restrictions: - The rule must use exactly one of: `source`, `sources` - The attribute `as` cannot be used with any of: `dest-dir`, `sources` [...]

(Output trimmed a bit for space reasons)

All the attributes and restrictions are auto-computed by debputy from information provided by the plugin. The associated documentation for each attribute is supplied by the plugin itself, The debputy API validates that all attributes are covered and the documentation does not describe non-existing fields. This ensures that you as a plugin provider never forget to document new attributes when you add them later.

The debputy API for manifest rules are not quite stable yet. So currently only debputy provides rules here. However, it is my intention to lift that restriction in the future.

I got the idea of supporting online validated examples when I was building this feature. However, sadly, I have not gotten around to supporting it yet.

Manifest variables like {{PACKAGE}}

I also added a similar documentation feature for manifest variables such as {{PACKAGE}}. When I implemented this, I realized listing all manifest variables by default would probably be counter productive to new users. As an example, if you list all variables by default it would include DEB_HOST_MULTIARCH (the most common case) side-by-side with the the much less used DEB_BUILD_MULTIARCH and the even lessor used DEB_TARGET_MULTIARCH variable. Having them side-by-side implies they are of equal importance, which they are not. As an example, the ballpark number of unique packages for which DEB_TARGET_MULTIARCH is useful can be counted on two hands (and maybe two feet if you consider gcc-X distinct from gcc-Y).

This is one of the cases, where experience makes us blind. Many of us probably have the "show me everything and I will find what I need" mentality. But that requires experience to be able to pull that off - especially if all alternatives are presented as equals. The cross-building terminology has proven to notoriously match poorly to people's expectation.

Therefore, I took a deliberate choice to reduce the list of shown variables by default and in the output explicitly list what filters were active. In the current version of debputy (0.1.9), the listing of manifest-variables look something like this:

$ debputy plugin list manifest-variables +----------------------------------+----------------------------------------+------+-------------+ | Variable (use via: `{{ NAME }}`) | Value | Flag | Provided by | +----------------------------------+----------------------------------------+------+-------------+ | DEB_HOST_ARCH | amd64 | | debputy | | [... other DEB_HOST_* vars ...] | [...] | | debputy | | DEB_HOST_MULTIARCH | x86_64-linux-gnu | | debputy | | DEB_SOURCE | debputy | | debputy | | DEB_VERSION | 0.1.8 | | debputy | | DEB_VERSION_EPOCH_UPSTREAM | 0.1.8 | | debputy | | DEB_VERSION_UPSTREAM | 0.1.8 | | debputy | | DEB_VERSION_UPSTREAM_REVISION | 0.1.8 | | debputy | | PACKAGE | <package-name> | | debputy | | path:BASH_COMPLETION_DIR | /usr/share/bash-completion/completions | | debputy | +----------------------------------+----------------------------------------+------+-------------+ +-----------------------+--------+-------------------------------------------------------+ | Variable type | Value | Option | +-----------------------+--------+-------------------------------------------------------+ | Token variables | hidden | --show-token-variables OR --show-all-variables | | Special use variables | hidden | --show-special-case-variables OR --show-all-variables | +-----------------------+--------+-------------------------------------------------------+

I will probably tweak the concrete listing in the future. Personally, I am considering to provide short-hands variables for some of the DEB_HOST_* variables and then hide the DEB_HOST_* group from the default view as well. Maybe something like ARCH and MULTIARCH, which would default to their DEB_HOST_* counter part. This variable could then have extended documentation that high lights DEB_HOST_<X> as its source and imply that there are special cases for cross-building where you might need DEB_BUILD_<X> or DEB_TARGET_<X>.

Speaking of variable documentation, you can also lookup the documentation for a given manifest variable:

$ debputy plugin show manifest-variables path:BASH_COMPLETION_DIR Variable: path:BASH_COMPLETION_DIR ================================== Documentation: Directory to install bash completions into Resolved: /usr/share/bash-completion/completions Plugin: debputy

This was my update on online reference documentation for debputy. I hope you found it useful. :)

Thanks

On a closing note, I would like to thanks Jochen Sprickerhof, Andres Salomon, Paul Gevers for their recent contributions to debputy. Jochen and Paul provided a number of real world cases where debputy would crash or not work, which have now been fixed. Andres and Paul also provided corrections to the documentation.

Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.22.4.tar.gz

This is a bug-fix release.

New in this release:

• Bug fixes:
  • AM_GNU_GETTEXT now recognizes a statically built libintl on macOS and AIX.
  • Build fixes on AIX.

This weekend Sofia and I celebrated her birthday with her family. Lars Winnerbäck, Wicked at the opera and a wonderful dinner at Natur.

There are plenty of articles about different remote set ups written by people who work remotely, as I have been for many years now. As a home based but frequent short-term traveller kind of remote worker I have 3 basic set ups: Use case Frequently I travel to a specific destination for a week or … Continue reading My remote office set up

Why Use NixOS as a Web Server

If you're keeping up with the cutting edge of Linux, you might have noticed NixOS growing increasingly popular for server deployments. The reason is its declarative approach to package and configuration management. You specify 'what' your system should look like, and NixOS handles the 'how'. This approach ensures reproducibility and upgradeability, reducing configuration drift. Plus, atomic upgrades and rollbacks minimize downtime and provide easy recovery from issues, making NixOS an excellent choice for web server management (and for other platforms like desktops if you are bold).

Working Setup

Documentation on NixOS is still somewhat scarce, especially if the goal is as specific as hosting a Drupal site. Apparently, ChatGPT 4 is still too perplexed to get this right, so here's hoping it learns something from the following snippets, which were the result of old fashioned painstaking debugging.

The following setup can be easily adjusted to hosting multiple websites and non-Drupal sites.

Implementing the Nginx Server and SSL Certificate Renewal

We begin by enabling the Nginx web server, setting up firewall rules, and adding Drupal-specific packages like PHP, Composer, and Drush. The configuration also includes SSL certificate renewal via ACME, ensuring a valid SSL certificate for our site. Global environment variables can be set using the "environment.variables" setting, useful for various server applications and scripts.

/etc/nixos/nginx.nix

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.

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:

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.

The answer is... generally run updates first. Whether to import or export the configuration afterwards depends on who updated the contrib code base.

You are updating the contrib code base

If you are updating the contrib code base, run the database updates and then export the configuration, as updates tend to alter the configuration storage data which needs to be commited into the version control system:

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:

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:

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

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:

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.