Create a skeleton for the individual module page

One thing to consider is whether some of these good suggestions about the design, layout, and featured information about modules should actually be incorporated into the Drupal.org project pages, instead or in addition to having them be their own pages within the project browser.

It would be good to offer the same insights whether someone is browsing in Drupal or on Drupal.org.

#4 I agree 100%, but that is out of scope here. I think this issue will be no more than opening the minimal information we have already, but full screen. Deciding what goes ON the page can happen in a follow-up once this plumbing is done.

Had a discussion with Ben, Srishti, and Narendra.

Multi Page App

Pros:

• deep links to a specific project (could be built in modal with extra effort)

Cons:

• not doable with regular svelte, would need a package
• no way to maintain scroll position when navigating between pages

Modal

Pros:

• reliable library available in core
• faster to build
• can mimic the pros of a multi page approach with extra effort

Cons:

• potential issues with stacking (download dialog over modal?)
• needs investigation into Drupal Dialog handling a full page modal
• reloading the page will close the modal

Despite the cons for modals being a longer list, the pros are compelling enough that we've decided to proceed with a modal approach.

Pushed a few changes to help with image issues + making the random_data plugin provide more useful content for testing these changes. MR has some comments on additional things.

Reviewing this

Verified merge request for Drupal 9.5.x dev version
https://git.drupalcode.org/issue/project_browser-3292996/-/tree/3292996-...

Testing Steps:
* Install a new Drupal instance
* Clone Project browser module using git clone https://git.drupalcode.org/project/project_browser.git
* Add & fetch this issue fork’s repository using
git remote add project_browser-3292996 git@git.drupal.org:issue/project_browser-3292996.git
git fetch project_browser-3292996
* Switch to that branch
git checkout 3292996-create-a-skeleton
* Run update.php
* Clear all catches
* Go to /admin/modules/browse
* click on module

Test Result:
New structure gets opene for each module which has detailed information of the module such as use cases, module information, release information, compatibilities, category details, and many more.

Refer SS

Test result : Pass
Can be move to RTBC

Found a few things that are going from the mock all the way to the front-end, and shouldn't. Will comment in the MR.

This isn't working particularly well on mobile. This is from an iPhone simulator:

I didn't notice mobile designs on the Figma, so there might not be a specific design to reference. As long as it doesn't look broken like it currently does at narrow widths, I'm fine with that and the design refinements can happen later. At the moment, however, this could even be a problem on some smaller laptops.

I'm happy with how things look code-wise. After checking this issue, I think at some point we might want to split logo vs images into separate fields, but that can be a follow-up issue.

Design-wise, when the categories expand to more than one line, the commas separating them, look weird, as they're placed before the item to show. See the image:

I think we could add the comma after each category, except for the last one.

The other feedback I have is that logos look very small on the detail page (100px height limit). This probably comes from the figma, but wanted to at least mention it.

Once these things are addressed/agreed I'm happy to mark it as RTBC, but maybe we somebody more "frontendy" than me to review the visual side of things.

Looking much better in my opinion.

I noticed a small thing, when there are no categories, the detail page does show "Categories", and then nothing. I guess it shouldn't show at all if there are no categories.

Also, as we are now using the full body on projects, this contains relative paths for the images, which makes them broken. This is not the code's fault, as the D7 api is serving those links as relative, but we do need to implement a mechanism to translate relative to absolute links, if the plugin does not do this for us by default.

I think that a good place to do this would be the "getProjects" method inside the plugin. In there, we massage the data to be in the right format, so we take what the api gives us, and tweak it to what project_browser needs (ie: we transform taxonomy_vocabulary_46 into field_development_status). So I think that'd be a good place to put something like this:

$project['body'] = $this->relativeToAbsoluteLinks($project['body'], 'https://www.drupal.org');

Which would take the body and a base URL and then prepend that to any part of the $project['body']['value'] that contains a relative URL. See the answer to this question in stackoverflow as reference: https://stackoverflow.com/questions/48836281/replace-all-relative-urls-w...

This could be filed as a separate issue altogether, but I think that shipping a page that looks like the below would look weird:

I am happy to help with the code on this part if you need it (I am doing something very similar in the gitlab migration scripts from www.drupal.org to gitlab). So, if you want you can assign it to me and I can complete that part, but also you are totally free to give it a go yourself, I'm just offering :-)

Makes perfect sense to me. I'll create the follow up issue then and I can work on it once this one is merged.
Great work here!

Follow-up issue: #3298575: URLs in body for projects are relative in the Mock plugin and creates 404s links and broken images

I have checked the code and tested the functionality via drupalpod and I think it ticks all the boxes.
All the feedback in the MR was addressed so I'm marking this as RTBC but happy if somebody else wants to give it a once over too.

I have a few points of feedback, but it's looking excellent overall and it's very close

I'm working on tests. Found some weirdness, will follow-up shortly

Everything was working correctly in the "real" code, just some weirdness where the mock stores the title in two different places in two different formats. Not worth untangling now, but the test data needed to be adjusted.

If someone else could re-review this, I would be happy to commit it!

I checked the comments and code since my last review and re-checked the whole MR overall and things look good from my point of view. Good finds with the test data.

I also re-tested everything via drupalpod and everything is looking really good.

I only raised a really small thing related to the breadcrumb. I think there shouldn't be a link to the same page we're in, it should appear in the breadcrumb, but not as a link.

After this, I think it can be marked as RTBC.

As the change was really minimal, I only checked the commit and that it contained the newly compiled files, which it does, so I'm marking this RTBC. Great work!

This is a huge step forward for PB! Thanks @srishtiiee for the great work, and to everyone else for helping.