🇮🇪Ireland @lostcarpark

Nightwatch tests now working for all current versions.

Jonathan had enabled "previous major", so I tried leaving that in, but one of the FunctionalJavascript tests was failing, and fixing that would be outside the scope of this change, so I turned it off.

I've had some success at last.

I can run Nightwatch locally, but it doesn't seem to be running with the same settings as in GitLabCI, as the tests are failing on things that pass on GitLabCI.

However, I have been able to get enough information from the local runs to fix the tests so they run in GitLabCI.

The main issue seems to be the browser.keys() call, which is deprecated, and I was using to send keypresses. I have replaced with browser.perform(), and send the appropriate key in the callback function as a user action.

The next step is to rebase for the recent changes, and add back the tests that were disabled for this issue.

I think trying to implement the simplest possible solution makes sense, otherwise the conversation is likely to drag on another 2½ years...

A modal popup activated by a "?" icon outside the category drop-down would have several big advantages:

• It avoids adding complication to the Category drop-down JavaScript, which is already quite involved
• It keeps the user on the page, rather than diverting them to an external page, avoiding load time and having to use the back button to return
• It should be quick to implement

Perhaps a more complex solution could be considered later, but at least this approach should get a basic solution merged quickly.

Thanks Chris, I'll keep working on the Nightwatch tests.

mradcliffe → credited lostcarpark → .

mradcliffe → credited lostcarpark → .

mradcliffe → credited lostcarpark → .

mradcliffe → credited lostcarpark → .

mradcliffe → credited lostcarpark → .

mradcliffe → credited lostcarpark → .

Does PB not support D10 any more?

I've rebased this issue against the latest 2.x changes.

There were a number of changes to the UI that affected the Nightwatch tests, including changes to the labels and values in the category drop-down, as well as changing the project browser route to include the source plugin.

As the new route can take the browser directly to the project-browser-test-mock source, I've taken out the config step that was disabling other sources.

I'm still running the older Nightwatch version on my local, so I'll do some more on this as soon as I figure out how to upgrade it.

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

Verified the ESLint and CSpell issues are fixed.

There is an issue open for the Nightwatch test: 🐛 Nightwatch "next major" failing Active

I'm suggesting we merge this issue and leave the Nightwatch tests for the above one.

I think this should be ready to move to RTBC.

I'll feed back the side note, however checking multiple branches sounds problematic at best, as if two non-default branches have different logo.png files, how do you decide which takes precedence? Also, could trigger a lot of extra processing on a module with a lot of branches.

Hi,

The logo has been added to the 5.0 branch, but the default branch is still 4.0.

The logo needs to be in the default branch to be picked up by the project page and Project Browser.

Would it be possible to also add the logo to the 4.0 branch?

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue. See original summary → .

lostcarpark → created an issue. See original summary → .

lostcarpark → created an issue. See original summary → .

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue. See original summary → .

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

I've done some optimisation of the SVG file, and got it down to 2.5KB.

lostcarpark → created an issue.

drumm → credited lostcarpark → .

I have uploaded PNG and SVG versions of the logo, both sized to 512x512 pixels.

Here's a preview of the PNG. I had to give the SVG a .TXT extension, so I don't think I can embed here. However they should both look the same unless you zoom in.

In terms of file size, the PNG is 9KB, while the SVG is 5KB. Both are under the Project Browser requirement of 10KB.

I would favour using the SVG since it's smaller, and we already use a SVG for the module default image.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue.

lostcarpark → created an issue. See original summary → .

lostcarpark → created an issue.

lostcarpark → created an issue. See original summary → .

I'm relatively new, but if I can help, I would be happy to be added to the list (or also happy to help without being on the list). I've run a couple of the meetings in the past.

Updated .gitlab-ci.yml to delete recipes before running eslint. Checks are now passing.

Ready for review.

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

This is partly my fault. I fixed up the tests to work for the drop-downs. Rather than just plow in and work out selectors for the new markup, I should have asked can we make the checkboxes easier for the tests to select. I'll know better next time.

I have reviewed the changes and everything looks good to me. The revised selecters look much cleaner. I've also carried out a manual test, and everything seems to work correctly.

I note that the eslint check is failing due to the recipe.yml file. This file has not been touched by this change, so I think it's an unrelated issue, so I think it should be fixed in a separate issue.

I'm still in favour of being consistent with Drupal terminology. If the Drupal term is "Apply" we should use it. If we think that's going to be confusing in Project Browser, we should petition to have the term changed in the rest of the Drupal project.

Also, I think an important distinction with recipes is that they can be re-applied multiple times (I think the current Project Browser implementation blocks this), and they can't be "uninstalled". I think if we use the same install/uninstall terminology we use for modules, it masks this distinction.

I think Simplenews makes sense as an initial focus.

However, as Drupal CMS evolves, it would be great to offer options for other solutions, whether they are alternative Drupal solutions (I don't have a specific one in mind), locally hosted options, such as Mautic, or SAAS solutions like Mailchimp.

I would guess a separate recipe would be needed for each option.

Got to agree that improving the description for the cookie option on the settings form would be really helpful.

Rebased for latest changes. Tests passing. Manually tested, and verified appearing correctly for modules with a single install.

As far as I can tell, Package Manager is still in all branches of Automatic Updates 3.x. Adding the Automatic Updates project with Composer, and enabling the Automatic Updates module should enable installing in Project Browser.

I presume there will be a version of Automatic Updates that removes Package Manager, but that doesn't seem to exist yet.

The initial check-in was just some reorganisation of the ToolsMenuDeriver class so that child menus are added by logically named methods rather than a single monolithic one. I created the MR just to check that the change still pass the automated testing before starting on new functionality.

The latest commit adds child options to the "People" menu, including listing all the roles under the Rolls option, as well as adding options to the "Config->People" menu. The "Manage user fields", "Manage user form display", and "Manage user display" options ought to be 4th level items, but I've placed them as 3rd level for now.

Yes, the require-dev ensures the Devel module gets loaded on development systems to allow the automated tests to run. There is a test that checks the Tools->Development menu gets created if the Devel module is enabled.

If you add this module to your site with composer require, it should not add the Devel module, so it should not get added to production sites.

Enabling level 3 menus (grandchild items) would be extremely useful to the Navigation Extra Tools module.

I'm working on replicating functionality from the Admin Toolbar Extra Tools ✨ Add bundle derivatives like admin_toolbar_tools Active module to place entity items as sub-items in the Navigation menus.

For example, the level 1 Content Types menu gets expanded to show a list of content types as level 2 items, which would expand to options like "manage fields" and "manage display" as level 3 items, if those were available.

I think the level 2 items are still helpful, but we're dependent on this issue to provide the level 3 items.

Currently, Navigation is limited to a maximum of 3 levels. This is going to limit us, as Admin Toolbar Extra Tools adds many 4th level menu items.

Where practical, I can add them as 3rd level items for now. For example, Admin Toolbar Tools adds items for managing fields and display under "Config->People->Account Settings". For now, I've added these items at the 3rd level for now.

However, there are other 4th level items where this isn't practical. For example, a third level item for each user role is added under "People->Roles". Admin Toolbar Extras adds "Permissions", "Delete", and "Devel" options as 4th level items under these. I think trying to add these at the 3rd level would be unwieldy, so I'm deferring for now.

There is an issue open to add 4th level menus to Navigation 💬 Support Deeper Navigation Levels Active , but it doesn't look like much has been done on it yet.

For now, I think we'll just have to live with this limitation.

I'm working on this issue now.

Accidentally merged to 1.0.x branch instead of 1.1.x branch. Reverted and merged to 1.1.x.

I've checked the CSS styles, and as far as I can tall all the pb-module-page styles are still required for the Modal Detail page. However, I have renamed them to pb-detail-modal, which seems more appropriate.

I think we are ready for another review again...

Rebased to include latest changes. As the number of commits in this issue has grown, the rebase is taking quite a long time, so hopefully we can avoid too many more!

I've removed ModulePage, and stripped everything relating to it out of App.svelte. It makes it quite svelte!

A possible future enhancement would be to make the pop-up update the address bar and give the detail modal a unique URL.

I agree with Chris, the Queue/Dequeue issue is no also present on the existing 2.0.x branch, so not caused by this change, so I think it should be dealt with by a follow up issue.