This idea is separate and completely unrelated to the Documentation and Help Initiative. My goal is to be able to link to the article and videos I create for my Drupal contributions, which I create outside drupal.org. This comes after I have had to point to multiple people to those links, even if they are in the project’s page.
Decoupling separates the system that stores the content from how that content is displayed on other independent systems. This can come with many benefits but also some downsides and tradeoffs. With progressive decoupling, you can get some of the benefits of decoupling while avoiding some of the downsides.
I proposed this session to DrupalCon, but it was not selected. I think that is good. I have had my fair share of stage time in DrupalCons in the past, new contributors should take the lead. However, I still did the work of creating the presentation, then recorded myself giving the talk.
I am a GNOME user, but I still use fantastic apps written using the Qt framework. However in my HiDPI screen (retina screen for macOS people) the Qt apps were rendering too small. They were not applying the scaling factor I requested in my GNOME settings.
I have blogged about ensuring you connect to a VPN when connecting to certain wi-fi networks. I have also blogged about connecting to a VPN when the computer boots. Both of those methods have merit, but also some inconveniences, like conflicting VPN profiles, or difficulty connecting on boot (before the password keyring for the VPN password is ready), etc.
I simplified my solution quite a bit, and I made it more resilient.
I recently recorded a video series tutorial about progressive Drupal decoupling. In this series I take two of the official React app examples and turn them into widgets. Your Drupal editorial team can then embed those React applications (a calculator, and an emoji selector) as blocks in a page, as a field in a content type, as an embedded entity in the body field using the WYSIWYG, …
Yesterday I had an interesting conversation about the principles of decoupled Drupal with Gabe Sullice in the context of menus. We agree that decoupled Drupal should not be only about websites, there are plenty solutions for that already. Not picking sides with the web prepares Drupal for the future. However, we hold slightly different visions on how to go about this.
What is your view?
I pasted the Slack conversation here in case anyone is interested in it.
You may know Contenta CMS. It is a decoupled Drupal starter kit. It is aimed to teach developers, and site builders, about the tools available in the decoupled landscape. It also serves as an example for both Drupal and client side best practices.
It took a while, but the distribution and all the associated projects are now running on Drupal 9.
Recently I read “Click Here to Kill Everybody” by Bruce Schneier. I really recommend this book to anyone. It is not targeted to a technical audience, although you might enjoy it a tiny bit extra if you are familiar with cyber security.
In this post I want to highlight one of my favorite parts, where Schneier lists ten principles to secure our devices.
Today my friend Andrew Berry pointed out to me that his browser was warning him about this blog not having HTTPS enabled. For additional irony he noticed that while reading my article on How to use HTTPS in your local environment.