drupal
Specbee: Why You Can’t Ignore Google Crawlability, Indexability & Mobile-First Indexing in SEO
Metadrop: Improving headers in a Drupal site using Dries' HTTP Header Analyzer
In a previous article I wrote about the importance of the HTTP headers and web security avoiding the technical stuff. In this article I want to get into all the dirty technical details.
Some time ago we came across the HTTP Header Analyzer by Dries Buytaert. This tool, as the name suggests, analyses the headers of the HTTP response from a website. There are other header analysers out there, but this one, published by the creator of Drupal, also takes into account Drupal-specific headers. The tool displays a report of all headers found, along with an explanation of the purpose of the header and notes on the values of the header, sometimes including recommendations for better values. It also displays information about missing headers that should be present.
With all this information, the tool gives a score based on the missing headers, warnings and notices detected during the analysis. On the first runs on our website, I have to admit that the score was not bad, but not good: 6/10. Now I am happy to say that we get a score of 10/10 on the home page. Unfortunately, not all pages can get the highest score, as I explain below.
…The Drop Times: Drupal CMS Expected by 15 Jan, XB Further Away in 2025: A Quick and Dirty Summary of Driesnote
Drupal life hack's: Practical Use Cases of Tagged Services in Drupal
The Drop Times: Lupus Decoupled Drupal: Bridging Drupal’s Backend Strength with Frontend Freedom
Specbee: A practical guide to Personalization with user personas (sample campaigns included!)
Talking Drupal: Talking Drupal #468 - Drupal AI
Today we are talking about Artificial Intelligence (AI), How to integrate it with Drupal, and What the future might look like with guest Jamie Abrahams. We’ll also cover AI SEO Analyzer as our module of the week.
For show notes visit: www.talkingDrupal.com/468
Topics- What is AI
- What is Drupal AI
- How is it different from other AI modules
- How do people use AI in Drupal
- How does Drupal AI make AI easier to integrate in Drupal
- What is RAG
- How has Drupal AI evolved from AI Interpolator
- What does the future of AI look like
Jamie Abrahams - freelygive.io yautja_cetanu
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Martin Anderson-Clutz - mandclu.com mandclu
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
- Brief description:
- Have you ever wanted an AI-based tool to give your Drupal site’s editors feedback on the SEO readiness of their content? There’s a module for that.
- Module name/project name:
- Brief history
- How old: created in Aug 2024 by Juhani Väätäjä (j-vee)
- Versions available: 1.0.0-beta1, which supports Drupal 10.3 and 11
- Maintainership
- Actively maintained
- Number of open issues: none
- Usage stats:
- 2 sites
- Module features and usage
- Once you enable this module along with the AI module, you can select the default provider, and optionally modify the default prompt that will be used to generate the report
- With that done, editors (or anyone with the new “view seo reports” permission) will see an “Analyze SEO” tab on nodes throughout the site.
- Generated reports are stored in the database, for ongoing reference
- The reports are also revision-specific, so you could run reports on both a published node and a draft revision
- There’s a separate “create seo reports” permission needed to generate reports. Within the form an editor can modify the default prompt, for example to get suggestions on optimizing for a specific topic, or to add or remove areas from the generated report.
- By default the report will include areas like topic authority and depth, detailed content analysis, and even technical considerations like mobile responsiveness and accessibility. It’s able to do the latter by generating the full HTML markup of the node, and passing that to the AI provider for analysis
- It feels like it was just yesterday that the AI module had its first release, so I think it’s great to see that there are community-created additions like this one already evolving as part of Drupal’s AI ecosystem
The Drop Times: Winners of the 2024 Women in Drupal Awards Announced at DrupalCon Barcelona
Wim Leers: XB week 19: flickering cliffhanger
Last week ended with 12 remaining issues. Did we make it? :D
Major loose ends
Like last week, I’m starting with the major loose ends.
Thanks to the impressive work by Dang “sea2709” Tran and the reviews and guidance from Jesse “jessebaker” Baker as well as many others, Experience Builder (XB) now has a robust solution for previewing components when hovering them in the “insert” menu. It required both server-side changes (global theme asset libraries were missing previously) and client-side changes (shadow DOM didn’t offer sufficient isolation; we needed <iframe>
).
The result is so nice that I almost spat out my coffee because of a deep, unavoidable “OOOOOHHHHHHHHHHHHHHHHHHHHHHHH!!!!!” when reviewing it! :D
Component previews prior to placing them on the canvas now provides accurate previews. (You can tell that I could not resist the temptation of hovering over Shoe badge multiple time :D)
Issue #3469856, image by me.
Once a component is placed, the preview canvas’ <iframe>
must be updated: an updated HTML response is fetched and rendered. But every update to the component tree must result in an update to the preview. That means any typing the Content Creator does in the component props form results in the entire preview 1 getting re-rendered, which easily results in flickering. Jesse devised a very clever solution, inspired by … computer games!
He introduced an IframeSwapper
that keeps two <iframe>
s active, but with only one visible. Once the preview has updated (i.e. the invisible <iframe>
has finished loading), he swaps it with the visible <iframe>
2 — eliminating all flicker:
Zero flickering when updating previews thanks to double buffering/
<iframe>
swapping.
Issue #3469677, image by Jesse.
Updating the props of a Single-Directory Component (SDC) can be done by clicking the placed component in the preview, and the “component props form” will appear on the right side. This generally works well, but there are still lots of rough edges. The roughest of edges has now been fixed by Atul, Dave “longwave” Long, Travis “traviscarden” Carden and Bálint “balintbrews” Kléri (with Ben “bnjmnm” Mullins shepherding that issue after its many twists and turns to clarity): the server side now correctly handles SDC props that are required, the client side now uses browsers’ native reportValidity
functionality. The result is that premature preview updates no longer occur. 3
While placing components and inspecting the component tree you’re creating, it can be handy to quickly get an overview. Browsers have ⌘+
/⌘-
(Ctrl+
/Ctrl-
) keyboard shortcuts to zoom in/out. But for XB, you typically want to zoom in/out only the preview, not the entire UI. So thanks to Jesse and Atul “soaratul” Dubey, XB now allows zooming in/out just the preview by pressing +
or -
. 4
Another rough edge in that component props form was fixed: some field widgets are highly complex, and need to load CSS/JS to work correctly. An example is the most complex widget in Drupal core: the media library widget, which we the recently added support for. Our naïve initial approach failed whenever switching between different components that each used the media library widget: the same JS was loaded again, resulting in JS errors! Fortunately, Drupal already solved this problem: Ben added ajaxPageState
support — solved!
With all of those UI improvements in, parts of XB are starting to feel solid!
Better defaults
To make it easier for future (and existing) contributors to start contributing to/playing with XB, we changed two important defaults:
- Ben made XB depend on the Media Library module, because it offers a superior UX for (re)using images
- Deepak “deepakkm” Mishra, Ted “tedbow” Bowman and I updated the default XB config to start with an empty XB canvas
Only one 0.1
priority left!
With only one 0.1
priority left (#3469672: The XB annotations and labels should not change size when zooming), it became possible to help land non-priority fixes, such as:
- Thanks to fazilitehreem and Utkarsh “utkarsh_33”, the “duplicate” action on component instances now works as expected, rather than resulting in an error
- Jesse and Gaurav “gauravvvv” made the canvas size dynamic based on browser viewport size, improving what we landed 4 weeks earlier
- Abhisek “abhisekmazumdar” Mazumdar, Dave and I updated the XB field type to no longer store SDC plugin IDs, but
Component
config entity IDs (a small but necessary first step towards supporting multiple component types — starting with Blocks)
Accelerating what’s to come after 0.1
With 0.1
essentially done, it’s important to prepare for what’s next, and set us up for success and facilitate wider contribution:
- James “q0rban” Sansbury, abhisekmazumdar and Alex “effulgentsia” Bronstein made MR reviews much easier and faster by adding Tugboat integration!
- Dave ensured that OpenAPI validation errors now result in a JSON response, which unblocks #3470321: Surface API error response in the UI — for better bug reports and faster DX — the issue title says it all!
- Together with Feliksas “f.mazeikis” Mazeikis and Dave, I documented the current component discovery + SDC criteria +
`Component
config entity, and described the status quo in an ADR. Because the status quo is now documented in depth, we’ll be able to make it crystal clear in #3454519: [META] Support component types other than SDC and child issues how we aim to evolve XB to supporting multiple component types, reducing the time to get to consensus on how to achieve that.
Can’t wait to see what product lead Lauri “lauriii” Timmanee prioritizes for milestone 0.2
! :D (Spoiler: supporting blocks and actually saving what you see in the XB UI will definitely be in there!)
Week 19 was September 16–22, 2024.
-
This will improve later, once we do #3462360: Partial preview updates: update preview of modified component only, not entire component tree, although later the previously mentioned abstract syntax tree (AST) would make that unnecessary (in most cases). ↩︎
-
In lower-level contexts this is called double buffering — and for example Microsoft .NET forms documentation has a great explanation. ↩︎
-
This is not yet completely solved — next in line is #3474732: Premature prop validation can break the UI. The value entered by the user must first meet the required shape that the SDC’s metadata conveys it needs (using JSON schema in its
*.component.yml
file). ↩︎ -
Interesting follow-up issues for this: #3475838: Consider a11y impact and/or competitor analysis for preventing browser zoom and #3475749: Pinch gesture zooming sometimes invokes OS zoom behavior. ↩︎
Pagination
- Previous page
- Page 100
- Next page