🇺🇸United States @ao5357

ao5357 → made their first commit to this issue’s fork.

tr can you either link to the other issue where votingapi will be updated to be compatible with the current version of Drupal or explain why this module won't be updated?

It looks like the rector patch only added ^11 to the info yaml file. It's unclear if other Drupal 11 compatibility fixes are required against 3.x, but it's certainly worthwhile to support Drupal 11. I've manually applied the patch to the MR for ease of composer-ing.

ao5357 → made their first commit to this issue’s fork.

There might be a little bit of talking past one another going on.

As reiterated in #23, there's two aspects to the name:

1. The marketing name for the product
2. The name that follows drupal/ in git repos and composer packages

I think there's merit in those being the same name, whether drupal/drupal in code and we call the bundled-up package just plain-old Drupal, or a new name for both.

The marketing name is also sort of a guess at what people will call it informally, and Drupal is a pretty solid guess at that.

Keep in mind that this issue isn't about renaming core or doing anything with version numbers. We're trying to name the new product, so while those aspects are small factors they shouldn't be determinative.

A new name (that isn't just Drupal) could be simple, such as Drupal+ (with drupal/plus) or more involved. While so far we've all mostly aligned that it should either just be Drupal or something like "Drupal Start", it's probably worth discussing here whether there's marketing value in giving this a whole-new name. Specifically, for the persona of someone who had tried out Drupal in the past and been frustrated by that trial. That persona may be reluctant to try something that's still called Drupal without qualification, though a rose by any other name...

Keeping in mind that it would be something like drupal/plus in package names, then. It seems like there are two matters here: the marketing name and how it would appear in slash-separated git repos or composer packages. That's the reason for the one-word segments in #13

Dries mentioned in today's zoom that a potential future-state would be that the resulting package from Starshot could eventually be the main offering, and discussion on #3453043: Review initial Starshot wireframes → is already pointing in that direction to some extent, too.

Here are a few one-word options that could be put after Drupal, in case there isn't other brainstorm/workshop work product out there:

• CMS
• Site
• Go
• Start
• Kit
• Package
• Guided
• Pack
• Launcher
• Drop
• Bundle
• Wizard
• Stroom

(going Dutch and watery)

I'm loving the progress on these @ckrina and thank you for presenting them on the superzoom

Two quick things I wanted to raise:

1. Since wireframe 3 is kind of a fine-grained way of asking the same question as wireframe 2, do we really need 2 at all? If I select on 3 that I want to publish news and (for example) "sell products", at that point in the install it's sort of implicitly a magazine-style site but also a store (which is of course possible and encouraged -- no need to pigeonhole the new site!). Wireframe 2 would make sense to me in the context of a theme, but with composable experience building being a target goal for Starshot I'd assume there would be less emphasis on themes as we tend to construe them in Drupal
2. When does a user leave the modal wizard experience and enter the kind of business-as-usual site interface? When a user gets to the home page, will there be some existing content to prime them on the editing experience, without having to click "Add block to section" which can be a cognitive load?

Not sure how directly valuable it would be for these wires in particular, but I've got a proof-of-concept Starshot-predecessor side project I'd love to briefly demo for you. Maybe some of the prior art there would be useful or inspiring.

tekNorah → credited ao5357 → .

andrewozone → credited ao5357 → .

I reviewed @JI_Gravityworks split MRs and everything looked good to me. Could use an independent review to get to RTBC.

tekNorah → credited ao5357 → .

ao5357 → made their first commit to this issue’s fork.

I'm hesitant to remove the existing default cookie notice at present time for two main reasons:

1. As shown in the attached picture, the notice is a block placed via the admin UI, and can be disabled or deleted by a site owner quickly and easily. It is a single file with 50 lines of code and does not perform any cookie-blocking operations via JavaScript or any other means
2. The block, like the site-wide alert placed in the header by default, demonstrates the out-of-the-box functionality, and is a good example of creating a fixed-position block using the frost_theme utility CSS library (though it could be improved a bit with translation functions)

Your point about the basic cookie notice perhaps not being compliant for a particular consuming site is well-taken, though. Ideally this issue will be closed as completed following one or both of these kinds of contributions to the project:

• Legal review and textual/functional changes to the existing block to improve compliance with as many acts/regulations in as many jurisdictions as possible
• Documentation, whether in the root readme, a module readme, a module's hook_help() implementation, a new markdown docs directory, or other appropriate location, recommending the best contrib replacements for the default block for sites that need more compliance/functionality

The out-of-the-box frost site doesn't actually use cookies for regular visitors: though, dismissed element IDs are stored in LocalStorage. Only logged-in admins get a session cookie. That said, the fixed cookie notice block is a good-faith effort by a site outside of California (USA) or the Euro-zone to inform users of the potential use of cookies and an easy way to direct interested users to the privacy policy. (Keeping in mind I am not a lawyer and this isn't legal advice) Site owners in California or Europe (or doing significant business in those places) may want to consider a 'contrib' module or two as a replacement to ensure greater compliance with local data privacy regulations.

@JI_Gravityworks there shouldn't be any technical reason preventing another branch/release strategy to support both group 2.x and 3.x, but before I'd go down that route I'd want to get feedback from one or more of this module's maintainers. I posted this 2.x MR 6 months ago and it hasn't got much traction, so before putting in more effort I'd want to confirm that's a direction desired for this module.

Not sure which requirements would be preferable for groupmenu over group_content_menu, but overall I'd go with that module if at all possible. I only did the v2 port for an upgrade path of an existing project using this module, but would likely use group_content_menu for any new project.

Thank you for the suggestion, @rrotari -- I'm on my way out the door right now, but upon return will write out a more-considered response.

ao5357 → made their first commit to this issue’s fork.

ao5357 → made their first commit to this issue’s fork.

In the last 9 days I've added some commits and tested the functionality more thoroughly. At this point I think it's ready for review and a new 2.x version branch is probably appropriate to differentiate it per the group parent module's majors.

The aspect I feel iffiest about is non-admin permissions at the group level. If you're an admin everything works as you'd expect, but I haven't tested nor dug into the code surrounding more granular permissions of menus associated with groups.

As a note, I applied similar changes to these patches in the issue fork for https://www.drupal.org/project/groupmenu/issues/3351701 🐛 Group menu compatibility with group V2 and V3 Needs review and was able to get the menu tree to appear in that fork per #7 .

The trick, at least in the issue fork, was to switch $menu_name to $menu->id() in the build() method's foreach loop, where it loads the menuTree(s). See https://git.drupalcode.org/issue/groupmenu-3351701/-/blob/3351701-group-...

I wouldn't say the issue fork is MR-ready, but so far the edits there are working with feature parity to the 1.x version as far as I could see. The module itself doesn't contain tests from what I saw, but I didn't add any, which is usually a blocker on contrib MRs.

The main things I'm iffy about before submitting an MR, in case anybody has insight:

• In groupmenu.services.yml I had to remove the tag and its priority from the config overrides, in order for the new DI of the entityTypeManager to not throw a circular dependency error
• It looks like the 2.x API for group handles permissions a bit differently. I only poked at it enough to get it working, so there's likely permissions and security concerns to approach in the issue branch

The issue branch, by the way, is set up fro 2.x rather than being explicitly 3.x compatible. From my digging, it seems the main difference is that the database tables are names like group_relationship rather than group_content, so making a 3.x version from what's in the issue branch should be about as easy as swapping some query parameter strings, but definitely ymmv with that.

ao5357 → made their first commit to this issue’s fork.

Wasn't able to push to the issue fork, but added a composer.json at https://github.com/solve-it-once/pwa/commits/3289196-automated-drupal-10 so it works with https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → . You might want to get this into the MR before merging, in the event the D10 compatibility fixes don't get picked up by composer.

ao5357 → made their first commit to this issue’s fork.

Re-roll patch for 9.5.x