[meta] Roadmap for version 8.x-2.0 of the Real-time SEO module

Happened to spot a broken link on the summary so just amended that - no protocol was on separate git repo link so it was shown relative to the issues url.

We have some good news:

https://github.com/Yoast/wordpress-seo/issues/17899

An alpha of the standalone YoastSEO.js has been released. This was a blocker per comment in #14
https://www.npmjs.com/package/yoastseo
https://github.com/Yoast/wordpress-seo/issues/17899

As this module has been selected to be in Drupal CMS, and will be featured prominently in the Advanced SEO recipe, I would love it if we could move this project forward. I know the delays with the changes in the underlying library have been frustrating and may have caused maintainer burnout.

What would be required to help move development of this module, and an update release forward?

A similar project has also been created on Drupal.org, yoast_analysis
https://www.drupal.org/project/yoast_analysis →

I created an issue there to see if we could work together to create a unified solution.
💬 Consider working with Real-time SEO for Drupal maintainers Active

In addition to the 3 remaining roadmap issues, there are a dozen issues in RTBC, and another 10 that are in Needs Review on the 8.x branch at the time of this comment.

Thank you for your consideration and contribution!

Hey everyone!

I'm excited that a release for the Yoast SEO library has been created, which unblocks some of the work.

2.x made some important changes vs 1.x. Most notably it provides better analysis support in how entities are rendered rather than looking at individual fields itself. It also better manages how the Real-Time SEO module attaches fields to entities. I initially wanted to use that momentum to make some more changes.

Most notably I wanted to change how the analysis results were stored to enable a few things:

1. Store both the SEO score and the reading ease score; currently only the SEO score is stored (the library has since also added an "inclusivity score"
2. Adjust storage and the widget in a way that allows multiple keywords to be analysed
3. Store these results in a way that allows creating overviews to enable insights into how pages rank (e.g. comparing pages for the same (related) keywords).
4. Decouple analysis from the form itself so that in the future it could also be used for on-page analysis.

Secondarily I want to ensure the webworker is used by the widget to fix issues like 🐛 The page freezes while the Real-Time SEO module runs script Needs work without adding a button the user needs to press manually.

Finally this module currently allows editing the title and description, but realistically a better UX can be provided by having a site builder provide a dedicated field for this and only rendering the result from the metatag module (that also ensures more complex logic can be included).

The biggest reason not to tag a stable 2.0 would be that these changes might cause changes to the code or storage which can break other modules if they rely on a specific structure. From a data perspective these changes can usually be made while preserving the data itself so that for actual site users there's be an upgrade path within the 2.x-* range of versions.

I think the next steps now that this module will make it into Drupal CMS would be to create a clear plan of which of these features would be needed for 2.0 and which should be pushed onwards to a 3.x version.

One of the things I hope to do in the coming week is to move development of the module from Drupal's GitLab to https://github.com/Kingdutch/drupal-real-time-seo. This is because the module requires both the Drupal code of the module itself as well as a custom JavaScript library which contains the widget: https://github.com/Kingdutch/RTSEO.js This allows both the module and library to be developed and versioned in a single repository (with the same version) and allows the Behat tests to run on GitHub (I've not been able to get those to work in Gitlab). The module code can be subtree split back to GitLab so that MRs here are still possible. The library code was previously split out in #2726871: External library included without exception approval from the Licensing Working Group → . That should massively ease development.

I'll also be at DrupalCon Barcelona where I hope to have time to do some of the above things :)

Thanks for the update @kingdutch!

Please also mind 📌 Make 8.x-2.x the default branch in GitLab Active on this road :)

Hi @kingdutch,
I can confirm that web worker prevents the page freezes.
Nevertheless, I did some research, and found the reason of those freezes, it is related mainly to findKeywordInFirstParagraph and KeywordDensityAssessment stuff.

In getSentences.js there is a code:

exports.default = function (text) {
	text = (0, _unifyWhitespace.unifyNonBreakingSpace)(text);
	let blocks = (0, _html.getBlocks)(text);

	// Split each block on newlines.
	blocks = (0, _lodashEs.flatMap)(blocks, function (block) {
		return block.split(newLineRegex);
	});

It takes sometime for it to execute on long strings.
I have no freezes even with 600kb body text, but have ones if set in SEO widget to use the default display mode, which also parses header and footer because of Layout Builder.

So if there is any base64 image it will freeze in order to do some operations by researcher. In my case it was 78kb long base64 string, making the researcher stuck.
Replacing it with svg ~10kb resolves the issue, but still a small delay is present.
So, without web worker the only solution to fix it without having preview button - use pre-defined display mode for SEO.