🇦🇺Australia @pameeela

I think this is at least major, maybe even critical, because there is no workaround that I can see.

Clicked around to see whether there were any other forms affected but didn't find any.

I think @catch's comment counts as security review, but feel free to disagree :)

I've updated the IS with a screenshot showing the default (blank) form and to remove the stuff about default values. Also tested manually with a fresh Drupal CMS instance:

• Project Browser worked OOTB with the empty form
• Project Browser worked with manually entered values
• Validation works if the provided path is not executable
  

Just noting that Softaculous has now updated to use the cpanel package, as of Saturday July 5.

We should not assume that we can “tell Softaculous to” do anything. We don’t even know if they’re going to agree to use this template, but the request has been sent.

I’m OK with it being removed for security, I agree that anyone who wants to use it will be able to install it themselves. Hosting.com has a dedicated doc for it, so I’m guessing others do too.

Just noting all of my testing was done with Drupal core, because that was the only option at the time with Softaculous.

If memory serves it was still nearly 30k files for core plus the necessary contrib modules.

@catch, the limit on the number of files is a totally separate problem. I did hit that once but the resulting behaviour is not the same (500s instead of 403).

But I believe that I only hit that because of the failing jobs from being blocked, since the job never finished and the cleanup didn’t happen. In my testing, the cleanup happens just fine as long as the job completes, the number of files was not meaningfully growing in normal usage. (The number of files as well as the limit is displayed in CPanel allowing you to easily track it.) However, it would still be worthwhile trying to reduce the number of files!

Update Drush docs link

A2 has been rebranded as Hosting.com

Evidently A2 has been rebranded as 'Hosting.com' so just updating to reflect that.

pameeela → created an issue. See original summary → .

pameeela → created an issue.

Errrm oops again.

Oops!

pameeela → created an issue.

@the_g_bomb ahh sorry, I always forget about the 'More' link, I didn't even think about it being that. How strange that this link is getting button classes added but the other one isn't.

Tested in the other issue.

Whoops! I read that comment then immediately forgot about it. Of course, it works with the other change.

Thanks @jurgenhaas that does indeed fix the issue, but seems to cause a new one. With this change, the 'Edit' CTA becomes 'Edit with BNPM.io' in some cases (did not look into why, but probably obvious to you) and clicking that results in:

Error: Call to undefined method Drupal\eca\Plugin\ECA\Modeller\Fallback::prepareEmptyModelData() in Drupal\bpmn_io\Services\Converter\Converter->convert() (line 76 of modules/contrib/bpmn_io/src/Services/Converter/Converter.php).

So, wondering if this should just be "won't fix" since it's in the older branch anyway and is an edge case.

FWIW there is a bulleted list with a list item for each of the modules you are enabling, with the dependencies listed as comma separated. But I think it has to work this way, nesting lists with the specific modules would make this pretty awkward.

Just looking at the view config. I don't think that a title override is the right behaviour for no results -- I think the title should stay the same, but with a message in the view explaining that either there are no issues or pages need to be viewed in order to show results.

Also the button to view all should not appear if there are no results. Is this feedback better against the module rather than here? I don't think these are Drupal CMS overrides, IMO this should be the default behaviour.

pameeela → created an issue.

pameeela → created an issue.

Screenshot:

Thanks, I think it is probably better to close these than leave them open indefinitely. We can open a new issue when we have new info!

Thoughts about what? Its overall usage?

No, the comment on usage was just an observation. I was asking whether other members of the community have thoughts on adding this module.

Not sure if it messes things up in the module but for our purposes, it would be better if the link was styled to match the block above, not as a button.

pameeela → created an issue. See original summary → .

OK, that aligns with our general approach to only add modules we actively need rather than adding ones that may come in handy.

We have no need for it now, so I don't see any reason to keep this open. Generally our approach is to add a module as the need arises, so if in future we need it, we will add it.

This seems like a great idea, and I just went to try out Contribute but I see it stalled out a few years ago (and stopped at Drupal 9).

Does anyone from the original discussion want to weigh in on the module's future? I'm open to promoting contribution in Drupal CMS, but it's possible the module is no longer the best option for that.

Also not sure how this applies to XB which is now our focus. I can imagine that a diff for fielded content will be useful, but it's not totally clear how this would work in the UI. I don't object to assessing that but safe to say we won't add new modules that aren't directly compatible with XB at this point.

Thank you for the screenshot @phenaproxima! Agree this is not commit-able in its current state, but to be fair it would probably be good to provide some specific advice.

But I think this also needs an IS update because the current proposal is to add a block to the existing dashboard. @the_g_bomb are you able to update it with a description of how this block works and what it is intended to provide to the user?

I've never used this module myself. The usage is not overwhelming but not nothing either. Wondering if anyone has strong thoughts on this either way?

This is a pretty specific request to add relatively simple functionality to core itself. Drupal CMS could add the link attributes module but that's not really what's being requested. I think it makes sense to evaluate the request for core first?

Navigation has addressed the Admin Toolbar need in the meantime. It's true that things are hard to find sometimes, but adding metadata for searchability feels like adding more complexity. It would be better to improve the overall IA so that things are easier to find!

This isn't something core could do, it would have to be a Drupal Association initiative. But given where things stand, I don't think it aligns with the current DA strategy. Still, giving credit for those who commented with thoughtful suggestions :)

Although this is a fine idea in general, I don't see why core would add this complexity when it's clearly an edge case and could be done in contrib.

Although this is still valid, it's pretty vague and there isn't much to go on. Meanwhile there has been a lot of change since then and still lots being worked on now :)

This is totally valid, and a revamp of the IA is in the works (slowly but surely). So I'll close this in favour of the active one.

Wondering if we can consider this outdated in light of Project Browser / Drupal CMS / Auto Updates? These still leverage Composer, but the user doesn't need to know about it. We are not done yet obviously, but certainly on the right track I think, if a bit late in coming.

I think the Drupal CMS privacy track essentially did what was proposed here. None of that was directly merged to core, but all of the contrib efforts were consolidated. I think the results speak for themselves and there is a roadmap for ongoing improvements. Do we think we still need to pursue this based on the current state of things?

I feel like this is somewhat obsolete given that this will be included in XB and site templates. Does anyone who has already commented want to weigh in?

If we do this, we will do it for the site templates that we ship rather than Olivero. I'm going to close to avoid confusion/repurposing.

I know this was discussed plenty in Slack, I'm going to close it off and credit the participants. Obviously, we shipped with it as a theme. But since we're shifting to site templates in 2.0, we won't be shipping it soon enough. Those sites lucky enough to be using it can continue using it until Drupal 12 I guess!

We won't do any further development on Olivero (unless it's a bug fix!).

I'm really, really sorry to do this, but given that we are shifting to site templates in 2.0, we don't plan to add new features to the 1.x branch and Olivero in particular. Everyone who worked on this should still get credit for their contributions, which we really appreciate!

I'm really, really sorry to do this, but given that we are shifting to site templates in 2.0, we don't plan to add new features to the 1.x branch and Olivero in particular. Everyone who worked on this should still get credit for their contributions, which we really appreciate!

Don't think that we will progress with Olivero XB any further.

The separate dashboard was removed and now the relevant widget will be added to the default dashboard. We should review what is being added as part of that issue.

Did this progress elsewhere or is it still in the works?

Discussed with @phenaproxima that we aren't pursuing this in light of the launcher app. Happy for solutions like Drupal Forge and Gitpod to continue but no plans to choose an 'official' environment right now.

Closing but not adding any credits because they should have been given elsewhere.

We don't plan to do any more development (other than major bug fixes) in the Olivero subtheme so closing this.

I think the launcher app achieves this in a much better way than we imagined at the time of writing! Feel free to re-open if you disagree.

This was a useful discussion, and it has progressed a lot since the last comment. Between the launcher app and the package for cpanel, I think we can close this off in order to focus on streamlining / enhancing those efforts.

I think we might be able to close this, but for now marking postponed to note that the related issue should resolve this.

I personally have never used the Currency or Country field and their usage is quite low. Address is included in the event recipe, and would be for other relevant recipes. I would be open to the argument that we should ship Address by default, but is there a case for the other two?

Doesn't seem like either of the core issues deals specifically with restricting the roles that can be assigned, although ✨ Split 'administer permissions' into a new administer roles permissions Needs work prevents non-admins from granting the admin role so IMO that would still be a big improvement and might mitigate the need for this.

IMHO, role assign/delegation isn't a feature on its own, merely a means to provide the staff-level role feature that can manage users with the same or lower level of access. That seems better suited to an optional recipe, bundled or not, than having it on/shipped by default?

Yes, that's correct, site templates would provide the roles and configure this sensibly. But if we include the module it eliminates the module selection process by the site template creator and consolidates usage to that module.

The fact that Role Delegation is a better choice (which I agree with) makes me even more inclined to add it, so there is consistency in solving this problem.

I'm against adding modules just so that they'll be there for site templates to use

I am too, but considering making an exception here because this is a real "gotcha" in Drupal and it would be nice to provide a way around it OOTB.

Apologies, I think I was trying to be a bit too efficient in handling these once they landed in the Drupal CMS queue. It certainly is a separate question as to whether it should be in core and there should be a 'final' answer from core documented in this issue.

Ah yep, good idea :)

I'm not sure why this didn't make it into 1.0.

@donquixote fair enough!

This was on a list somewhere, but fell off. I think it probably belongs in the site template rather than vanilla Drupal CMS though because the permissions need to be specific to the roles provided. In theory, Drupal CMS could include it by default though and allow the templates to configure it.

This wouldn't go into vanilla Drupal CMS, but would make sense for site templates with this requirement.

I don't see this as a Drupal CMS issue to solve, since it's more about developer experience. Closing for that reason but if folks think it is something for core to address, please re-open or possibly create a new issue to restart the discussion.

This module is only relevant for the Seven admin theme :)

Drupal CMS includes metatag module, and XB is also tackling this problem somewhat. Since Drupal CMS doesn't have any actual code, I don't think there is anything more we can do here.

This module is great but it's not really possible to make it useful out of the box, since it needs configuration based on a site's domain(s), so not a great candidate for inclusion in vanilla Drupal CMS IMO. It would probably make sense to include in certain site templates though.

We aren't really using block visibility settings currently and will move away from it completely with XB, so we won't need this module.

It would make sense to add this to a site template for a recipes website or any other example where it makes sense, but since it's not that widely applicable, I don't see us adding it to vanilla Drupal CMS.

Field group is already included in Drupal CMS.

Pathauto is already in Drupal CMS.

This isn't something we would add to vanilla Drupal CMS but I think it would be great as part of a site template.

With the plan for workspaces to replace content moderation in core, the initial problem described in this issue will be solved. And since that should ideally get in for 11.3, and we have not had any other reason to add ERR to Drupal CMS, we won't add this module.

Our policy for adding modules has been to only add modules we are using. We have not had any need for this module, and with the transition to XB, are not likely to need it in future. So I'm going to close this for now.

xjm → credited pameeela → .

pameeela → created an issue.

pameeela → created an issue.