A little Exit Eden to get the day moving

 Although I haven't put keyboard to code editor yet, I spent a lot of time yesterday thinking about the new feed processing system for my personal feed reader. Back when I built the original feed system and Drupal 7,  feed items from the aggregator module weren't entities.  Now that they are entities in Drupal 9, they are fieldable, so I can do far more with the items than I could a few years ago, so maybe I can get away with using the aggregator module instead of the feeds module. However, as memory serves. the aggregator module did not handle title-less items very well. That might not take a big deal to some but some of my fields on my feeds have title-less posts. If you can't picture a title-less post imagine a tweet or better yet this post which has no title it is just a body. I'll have to do some testing to see how well it can be handled.

Also I'm giving a lot of thought to whether I want to add the feed reader to this site or if I wanted to leave it on its own Drupal instance. Having it all in one site will make support and maintenance easier at the cost of some performance because I have a number of modules turned on to support the feeds Bajwa that I don't need today. Another thing to consider, if I ever decided to go back to hosting the site at Pantheon or some other cloud platform, I'll have increased fees to host it.

Lots of little things to consider.

Lunchtime Learning
Drupal Security and Leftover Steak

Security in Drupal: what can go wrong?, DrupalCamp 2022

It's funny that the subtitle for this talk is "what can go wrong?". I've been asked that question on a couple of occasions when pointing out that security updates are important when onboarding a new client, and my answer is generally the same, "your site can be turned into a giant ad for Viagra". Now I might be being hyperbolic what I say that but it goes to show what can happen and how an organization can be embarrassed.

I have lost count of the number times I'll come into a new client, do my audit and realize that security and patch updates haven't been done in a long time. Also on many occasions the client's Drupal agency will only apply security updates, not patch fixes. This talk goes to show why I feel it important to apply patch updates in a timely matter ,even if the issues resolved in the patch aren't an issue for that site. Amazingly, I've seen this behavior from agencies that are big-name Drupal shops.

Although this isn't a marketing document, I'll point out that my policy around updates is:

• Security updates are applied within 6 hours of them being issued on drupal.org.
• Patch updates are applied on a bi-monthly basis.
• Minor updates are applied within a month of them being issued

The rest of the talk discussed SQL injections, including an analysis of Drupalgeddon.

I've had this ear worm in my head since watching 13 ways to personalise your Drupal website yesterday.

So I'm looking at a job posting on LinkedIn for a Remote Drupal Developer and this is included :

I sit here having to wonder why a person who's working remotely requires strength to do anything. Assuming they can access their computer and code, I don't say any reason why it should be a concern. If the candidate were working inside the companies' office, there might be a some back up IT functions. carrying computers and monitors and such but that wouldn't be the case for a remote position. I know it could just be boilerplate language, but it's also exclusionary language. There may be somebody who doesn't apply for this job who is otherwise qualified but has a physical condition preventing them from lifting.

On top of what I learned watching the lunchtime learning video today, I got smacked in the face about my biases as an American. The name of the conference is DrupalSouth. Now I don't know the name of every conference and camp that goes on across the world for Drupal but when I saw her self I naturally thought southern United States: Georgia, Carolinas, Tennessee etc.. The conference was hosted out of Australia.