search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 38 forks source link

Add more properties to project .info files... Initial Release date, Current Release Date, Categories, D7 base module or theme if any #5367

Open albanycomputers opened 2 years ago

albanycomputers commented 2 years ago

Description of the need

Add more properties to the .info file to make it easier, in the long run, to find modules and themes and when a module or theme was last updated.

For example: -

  1. Date of the first release
  2. Date of this release
  3. The D7 module or theme name this module is based on if applicable.
  4. Category could be the same or similar to the Drupal Module categories

Proposed solution

Add a recommended section to the .info file.

Alternatives that have been considered

Pulling the information directly from GitHub

Is there a Drupal or Backdrop contributed module that accomplishes this? Nope

Additional information

With more and more modules being converted and new modules being released it will become harder and harder for people to find the right modules, so I think implementing some solution is better than no solution, even if it's optional. I would have thought that module and theme developers would want to make their creations more findable.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop now includes a new module and theme category to make finding the right module easy!

docwilmot commented 2 years ago

Well I'm happy you asked! This is one of our most longstanding issues: https://github.com/backdrop-ops/backdropcms.org/issues/487. An issue to support more data in info files, and even better, its been merged, and active but not tested.

So literally right now, if your module info file has tags[] = Spam Prevention, once you cut a release, the project node on BackdropCMS.org should have a field populated with that value. We should have existing support for

But as the issue will explain, maybe, I did this without access to backdropcms.org, which means an inability to really test the webhooks. So havent publicised it to devs so no one really including these tags in their modules yet.

So if youre looking for a project, I would consider you a great hero if you could fix this finally. Maybe elicit help from @bugfolder, who is doing a lot of the bdcmsorg maintenance these days.

albanycomputers commented 2 years ago

@docwilmot Many thanks... I did a search but couldn't find anything relating to this "issue" (Probably the wrong word).

bugfolder commented 2 years ago

Quoth @docwilmot:

I did this without access to backdropcms.org, which means an inability to really test the webhooks. So havent publicised it to devs so no one really including these tags in their modules yet.

I'm happy to report that the webhooks seem to be doing their job; in a PR for https://github.com/backdrop-ops/backdropcms.org/pull/851, I've created a View that includes a column for Tags, and they're showing up (and you can try them out in the Tugboat preview). Screenshot here: https://github.com/backdrop-ops/backdropcms.org/issues/839#issuecomment-985165185

docwilmot commented 2 years ago

I suspected that tags work, not sure about the other things, and I believe that we may be getting watchdog errors.

bugfolder commented 2 years ago

I'm seeing watchdog errors on the Tugboat site that relate to a missing .htaccess file, but can't think of how that would be related to the View. (They seem to be timed with cron runs.)

With respect to the "other things" (colors, screenshots, maintainers), any thoughts on how and where they should be displayed on b.org?

docwilmot commented 2 years ago

With respect to the "other things" (colors, screenshots, maintainers), any thoughts on how and where they should be displayed on b.org?

Havent thought that far yet.

To test though, perhaps I could whip up a test module with all of those additional tags while you monitor the back end? If we dont have a dev version of the webhooks then we may as well test the real thing

bugfolder commented 2 years ago

Sounds good.

klonos commented 2 years ago

With respect to the "other things" (colors, screenshots, maintainers), any thoughts on how and where they should be displayed on b.org?

I'd expect:

bugfolder commented 2 years ago

click to pop up an enraged version of the image

I've seen some pretty unhappy screenshots out there.

bugfolder commented 2 years ago

There's a test theme on b.org: Info Tester Theme. (Not a real theme, just there to demonstrate this capability.) Its .info file contains:

name = Info Tester theme.
description = Test theme to test info file data on BackdropCMS.org
backdrop = 1.x
type = theme

; Themes can have colors, tags, maintainers, and screenshots.

; Aquamarine shouldnt work, since its not in the allowed list.
colors[] = Blue
colors[] = Beige
colors[] = Aquamarine

tags[] = Testing
tags[] = Development

maintainers[] = docwilmot
maintainers[] = bugfolder

; Screenshot handling rules
screenshots[default] = firstpng.png

The project folder contains a screenshots directory with several images. One of them is firstpng.png, which is the one you currently see on the project page; the others are stored in the project node in a field "Project Screenshots," so they're accessible to display on b.org.

In this example, the maintainers are listed by their Github user names, so it would be straightforward to Github-linkify them and list them in the right sidebar of the project page. Currently, the standard for maintainers is to list them in the body of the README file, so if we did display them in the sidebar, there'd be duplication unless people updated their .info and README files at the same time. Perhaps we could encourage people to put active maintainers in the .info file, but if they're seeking maintainers (or have any other maintainer-related information that isn't a Github user name) they continue to put that in the README file.

Seems like we could proceed with adding the Github-linkified maintainers to the right sidebar in preparation for adding them to the .info files more widely, if folks agree with that course of action.

klonos commented 2 years ago

click to pop up an enraged version of the image

I've seen some pretty unhappy screenshots out there.

🤣 🤣 🤣

...so if we did display them in the sidebar, there'd be duplication unless people updated their .info and README files at the same time.

Yeah, I think that that'd be acceptable until all contrib has a chance to update their .info and README.md files accordingly.

Some thoughts:

bugfolder commented 2 years ago

It just occurred to me that dependencies[] would be another nice .info file field to add and display in the right sidebar of a module/theme/layout's project page, where we could link to the dependent-upon project's page, thereby letting people explore the dependency chain entirely within b.org; and it would also (eventually) let users find the answers to questions like "what other contrib modules depend on Rules?" (Which was the actual question that brought this to mind.)

docwilmot commented 2 years ago

dependencies[] is already in info files. Are you suggesting add a field to the project nodes?

bugfolder commented 2 years ago

dependencies[] is already in info files. Are you suggesting add a field to the project nodes?

Yes, that. Sorry for the unclarity.

klonos commented 2 months ago

Related: I have raised #6045 for allowing projects to declare min/max supported versions of php/jQuery/CKeditor.

klonos commented 2 months ago

I converted this comment to its own separate issue here: #6478

yorkshire-pudding commented 4 days ago

There was some discussion here: https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/Maintainer.20list.20in.20.2Einfo

And I have opened a ticket here: https://github.com/backdrop-ops/docs.backdropcms.org/issues/235 to try and agree a format for maintainers to document. I think documenting comes before the functionality to do something with.