Classes missing from Drupal 10

Another missing class:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Template%...

QT @catch

but first guess would be PHP 8 syntax causing a parsing issue.

Thought the same but:

TwigNodeVisitor uses a ?bool attribute. TwigTemplate has ?string as getFileUrl parameter. Those are available since 7.4 iicr.
Didn't find any php 8 features.

CssCollectionOptimizerLazy was introduced in 10.1.x, that's a false positive.

I will check if this is parsed in the new version of the api site and module (still not live).
For now, this issue would be in the current version of the D7 module used in the D7 site.

I've checked this in the newer version of api and api.drupal.org (not live yet) and the issue does not appear.

So it's just D7 version. Perhaps the content is not totally parsed and indexed.

Fascinating — so this is an example where not doing ANY work on the (currently live) D7 api.d.o site would be fixed by "simply" switching to the D10 api.d.o site?

Correct.

I suspect that is due to the D7 version of the site using a much older version of https://github.com/nikic/PHP-Parser than the D10 version, and paired together with the PHP version being run (D7 older, D10 newer), it makes some classes to not be parsed.

The not-yet-live version of the api site is here: https://api.stage.cluster.drupalsystems.org/api/drupal/10.1.x
There is no timeline for when the switch will happen but other competing projects are getting more priority (TUF, project browser endpoint, etc).

@fjgarlin Is there anything we can do to help hasten the launch of the new API site? Are there any project issues that are blocking it that we could help with? My colleagues and I would welcome opportunities to help, as we have so many API links on Drupalize.Me that are breaking, and we get weekly support messages from our members telling us about the broken URLs. It's a bit of a maintenance pain, as we try to keep the links up to date with the latest version of Drupal, and now I'm having to change some of them back to "9". It's confusing for folks.

We totally get the project priority thing, but if there is a way to help and get the new API site launched, we'd love to know about it.

Hi Amber, I guess the issue of the branches will happen every time we do "clean up" and maintenance of them (ie: we unified all the 9.x into just 9, to avoid having 9.1, 9.2, 9.3...). The same happened with old 8.x branches that were cleaned up, as we just left the last one (8.9.x).

I'm afraid that the main blocking priorities that need sorting are infra related, and I think that's not a place where you or your team could be able to help.

--

What I'm about to say might sound counter-intuitive, but if drupalize.me has many links to the documentation pages, wouldn't it make sense to have a separate internally-owned project for documentation using the "api" module? ie: "api.drupalize.me" site... Sites like https://api.druphelp.com/ or https://api.hostdog.eu/ do exactly this, maintaining their own branches, modules.. parsed. Tho they do it using the "old" version of the module.

The 2.x version of the module was created with the goal of reusability in mind, it has a demo folder where it creates a brand new D10 latest site, installs the module and configures it, and parses a few repos. See it here: https://git.drupalcode.org/project/api/-/tree/2.x/demo?ref_type=heads

I'd be happy to spend some time with you and/or your team helping you set it up if it's an idea that you like. From that point on, you'd have full control of the site, and no more broken links if/when we refactor things. All links could be changed from api.drupal.org to api.drupalize.me. When I did the first version of the 2.x site, I managed to get a 100% url matching between the D7 and the D10 site, so it's something that can be achieved if you would want to keep older branches (ie: 8.8.x, 8.9.x, 9.1.x, etc).

Another missing class: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!ContentEnt...

This is becoming more urgent now that 9.5 is out of support and Drupal 11 will require PHP 8.3.

The API site currently shows the 4.7 API but not 10.2, too. https://api.drupal.org/api/drupal

I think this is at least Major.

I know this is not the fix (yet), but the new site has no problem with the class reported in #10.
https://api.stage.cluster.drupalsystems.org/api/drupal/core!lib!Drupal!C...

I don't think there is a fix that we can do to the 7.x-2.x version of the module, so changing back to 2.x.

Re #11, the site shows the latest for each major, so in this case it shows 10.3.

In any case, I agree that we are getting more and more cases, so the new priority feels correct.

The upgraded site needs two things: infrastructure and #3338978: Replace Bakery with KeyCloak SSO & social sign on →

SSO is used for people to be able to log in and comment. Comments are per-branch, with more branches recently, comments are used less. And many comments would be better as MRs to improve the documentation itself. If we remove comments, people no longer need to log in. We remove a blocker to upgrading, and get a more straightforward site to maintain and bring through future upgrades.

To try this out, I’m removing access to comments on the production site, to see how necessary they are.

api.drupal.org has been broken for about 18 months now. There are MANY classes that don't show up in the D10 documentation that are present in the D9 documentation, and there are MANY instances of things like @inheritdoc not displaying the documentation in a subclass in the D10 documentation.

Two examples I brought up on Slack more than a year ago:

Search for the class PhpMail. Class documentation does not exist in D10. This is one of MANY.

Search RouteMatchInterface. Documentation exists, but apparently in D10 nothing implements RouteMatchInterface and nothing extends RouteMatchInterface. But that's not true.
Search CurrentRouteMatch (which DOES implement RouteMatchInterface BTW ...). Six of the methods in CurrentRouteMatch don't show method documentation on the API page. These methods all implement methods defined in RouteMatchInterface, and use @inheritdoc. Yet the documentation is not inherited.

All this still works properly in the Drupal 9 documentation, but Drupal 9 is now obsolete.

I understand that the new site *should* fix these things, but how is it acceptable to leave the public API documentation broken for so long in so many ways?

More history: https://drupal.slack.com/archives/C220WV2TW/p1676782359961389

Exists: https://api.drupal.org/api/drupal/core%21tests%21Drupal%21Tests%21Browse...

Does not Exist: https://api.drupal.org/api/drupal/core%21tests%21Drupal%21Tests%21Browse...

BrowserTestBase is a pretty fundamental class ... no D10 documentation on api.drupal.org

Every time I use api.drupal.org I run across an example of some class that doesn't have D10 documentation.

New staging system: https://api.stage.cluster.drupalsystems.org/api/drupal/core%21tests%21Dr...

Again, another basic class missing from D10 API documentation:
Exists: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Co...
Does not exist: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Co...

Things like this have a cascading effect - ConfigFormBase is subclassed by 33 classes in D9, and those 33 classes are not visible/have missing @inheritdoc documentation in D10. I don't know how many subclasses there are in D10, because the documentation is missing.

I ALREADY KNOW ABOUT THE BETA SITE.

But that doesn't help because I have written hundreds of pages of documentation on drupal.org which now have BROKEN LINKS because the D10 documentation is missing.

I CAN'T replace those links with links to the beta site, because that would be stupid.

Another relevant and critical example is https://api.drupal.org/api/drupal/elements/10, which used to list all potential render elements in core (https://api.drupal.org/api/drupal/elements/9), and now there's none.

As a side note, the staging system has its own issues, which are evident in https://api.stage.cluster.drupalsystems.org/api/drupal/core%21modules%21..., for example. I know there is no stable release for the 2.x branch, but the parser seems to have regressions too.

Yup, the new will have issues too. Issues like this can already be reported against the 2.x branch. I'll create the issue: 🐛 Parsing comments with quotes and html symbols makes page render wrong markup. Active

Linking duplicate issue.

I also got here trying to find the list of render elements, and begging for help on Slack.

If this is going to stay broken, can we set the default branch at api.drupal.org back to 9.x until it's fixed?

Having the core dev documentation broken for the project is not a great look, and it looks like Google has dropped the results for all the API render elements.

The main problem is https://git.drupalcode.org/project/drupal/-/blob/11.x/core/MAINTAINERS.t...

If that link doesn’t jump to line 444, my point is there are no documentation maintainers.

It's true, but this is a regression that wiped out some seriously key stuff for onboarding new community members.

I guess if nobody else thinks this is worth fixing I'll just go into all the Drupal doc pages I can find that tell developers to read the render API pages, and change the links to point to the last-good d9 URL. That will create some terrible technical debt, but I can leave a list here so they can be changed back if this fixed.

Looks like the 10.x version of the site has been deployed which is great.

I couldn't see an obvious pattern for which pages are coming back with 5xx responses but at least https://api.drupal.org/api/drupal/core%21core.api.php/group/ajax/11.x and https://api.drupal.org/api/drupal/core%21core.api.php/group/form_api/11.x seem to fail consistently.

https://api.drupal.org/api/drupal/classes/11.x worked for me once, but then started failing.

We deployed it a couple of hours ago and we are doing some load testing on the D10 cluster, so it might come and go for a few hours.
If everything goes well, the new D10 site will stay (yay!), otherwise (mainly problems with load in the cluster before DrupalCon) we might revert to the D7 site and revisit later.

This is HUGE Fran. Didn't check everything, but all the links mentioned in this issue that I've checked are working as expected.

Is it expected that I see `https://api.prod.cluster.drupalsystems.org/` in the URL on production instead of `https://api.drupal.org`?

Steps to reproduce:
- Go to api.drupal.org
- Search for `NodeInterface` in the sidebar.
- Click on the result/press enter.

Expected result:
- Redirect to `https://api.prod.cluster.drupalsystems.org/api/drupal/core%21modules%21n...`

Actual result:
- Redirect to `https://api.drupal.org/api/drupal/core%21modules%21node%21src%21NodeInte...`

Still doing more testing, but for now it looks great :)

We might need to re-index search post domain-swap. I can trigger that later. Thanks for the step by step.

Cool, you're using search api. If you ever write a case study on the API page, make sure to share the link with us, it might be interesting. And no rush on the reindex from my side, as long as the content is what I expect, I'm happy :)

The 5xx responses were due to an under-provisioned database, and should be resolved now. See #3444876: api.drupal.org returning 500 errors for all classes →

URLs where a specific version is present as the last path segment are redirecting to a page that appends (not replaces) `11.x` as the last path segment. Which results in a 404 because there are 2 versions in the path.

For example, this URL:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Util...

Redirects to an 11.x search page, with the following message:

Sorry, api/drupal/core%21lib%21Drupal%21Component%21Utility%21Unicode.php/function/Unicode%3A%3Astrlen/8.5.x/11.x cannot be found.

(Notice the “8.5.x/11.x” at the end of the url in the message.)

Keeping at “needs review” to invite other reviews.

This is huge; thank you thank you thank you

oops sorry didn't mean to bump the status

@penyaskito - thanks for checking the links, I really appreciate the extra testing.

--

@FeyP - the behaviour in #32 is fixed now. It was a hosting related setting so we didn't need to reindex.

As for case study, I did a session at DrupalCon Lille where I talked a bit about the new site:
- Slides: https://tinyurl.com/apidrupalorg-lille
- Video: https://www.youtube.com/watch?v=JiJ0GcLPGlM

It doesn't go too deep into technical details but you can get a good idea of the architecture of the site and how it all works.

--

@amber-himes-matz - yeah, as the 8.5.x no longer exists, changes are that it'll be a 404, but having said that, we can definitely improve the behaviour and try to extract a proper search term and do the search. Could you open a new issue for this? You can literally copy/paste your comment as the issue description 🙂 Thanks in advance.

Issue for #36: 🐛 Links for Drupal 8 documentation are wrongly redirected Closed: duplicate

When searching for FileSystemInterface in 11.x branch, the result doesn't look right. I get a page for the @file_system service in core.services.yml. The class providing this service implements the interface, but I'd expect a page listing all the constants and methods in the interface. I also don't see a "same name elsewhere in this branch" box (or whatever is the exact name of that box), so it can't be just the "wrong" page:

https://api.drupal.org/api/drupal/core%21core.services.yml/service/Drupa...

On the page for the FileSystem service, it says it implements FileSystemInterface, but there is no link, so it seems it is indeed missing:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi...

And thanks for fixing #32 and for the interesting link to your presentation @fjgarlin .

There is no link because in this case it'd be pointing to itself. It's the same for all pages, they won't link to themselves.

I'd actually create a new issue for this under the 2.x-dev version, as this is not the same. I think that this "services" detail pages might not be needed at all.

It seems that the second link is what you would expect:

It seems that the second link is what you would expect:

Yes, that was the page I expected. Thanks for pointing that out.

Still, on https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi... I would expect, that FileSystemInterface in the class hierarchy links to https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi... , which it doesn't. Those are different pages.

And I'd expect the box "Same name in this branch" on https://api.drupal.org/api/drupal/core%21core.services.yml/service/Drupa... , so that I can at least quickly switch to the page I'm looking for.

I think that this "services" detail pages might not be needed at all.

The services detail page is fine, if it links to the service class, but I agree it is probably not needed under the name of the interface the service class implements.

So this is useful: https://api.drupal.org/api/drupal/core%21core.services.yml/service/file_...
I think we can drop this one: https://api.drupal.org/api/drupal/core%21core.services.yml/service/Drupa...

Still, on https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi... I would expect, that FileSystemInterface in the class hierarchy links to https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi... , which it doesn't. Those are different pages.

Can we have a separate follow-up about this?

And I'd expect the box "Same name in this branch" on https://api.drupal.org/api/drupal/core%21core.services.yml/service/Drupa... , so that I can at least quickly switch to the page I'm looking for.
Same here.

--

I created these three issues:
- 📌 Core services individual pages not helpful and jumping to the top result in searches Active
- 📌 Hierarchy missing links Active
- 📌 Same name in this branch links in services are confusing Active

I'm also marking this issue as solved. I think that any possible future issues should go as follow-ups instead of this one.
Thanks all for the patience.

Automatically closed - issue fixed for 2 weeks with no activity.